4.2 Beta 1 iOS Export fails if there are any C# scripts in the project

[RichP]

Godot version

4.2beta1

System information

Godot v4.2.beta1.mono - macOS 14.0.0 - Vulkan (Mobile) - integrated Apple M2 Max - Apple M2 Max (12 Threads)

Issue description

Export works as long as no .cs files in the project. If there are any .cs files a popup is displayed with:
"Failed to generate xcFramework"

An Xcode project is built that will install build and run on a device but then hang on launch.

Steps to reproduce

Create a new project.
Create a 3d scene add a cube and a camera.

Verify export works

Add a c# script.

export no longer works

Minimal reproduction project

test.zip

[raulsntos]

Please share the build log to make this easier to troubleshoot. The build log should be in the MSBuild panel, under the Output tab:

[RichP]

Log Here

log.txt

[raulsntos]

What version of XCode are you using? It seems XCode 15 struggles with symlinks. Can you try XCode 14?

[bruvzg]

What version of XCode are you using?
macOS 14.0.0

Xcode 15 is the only version supported on 14.0.

36149-ExportDebug-iossimulator-arm64/iosGame.dylib

Are you building for ARM64 simulator? Official template builds doesn't include libraries for the ARM64 simulator, only for the device and x86 simulator.

[RichP]

Using Xcode 15.0.1. Unable to downgrade to 14 as it will no longer run on Sonoma

Are you building for ARM64 simulator?

The "Failed to generate xcFramework" error is coming from the Godot IDE before I even attempt to open it in Xcode. I have then opened it in Xcode and built for device. It installs on device but crashes after the splash screen as it is missing the .NET dependencies.

and x86 simulator

I'm not using simulator but, is there much point in including this as Rosetta is no longer supported?

[akien-mga]

CC @shana

[bruvzg]

I can reproduce the issue, seems like Xcode does not like libraries in the temp folder (or just in the different locations), no idea why C# exporter is writing device lib into .godot/mono/temp/bin/godot-publish-dotnet/ and simulator libs into a random temp folder?

is there much point in including this as Rosetta is no longer supported?

Rosetta is supported, and macOS Sonoma have x86-64 version for Intel Macs, Apple was still selling Intel Mac Pros a few months ago, so it's unlikely Intel support is going to be removed any soon.

[CVSJason]

no idea why C# exporter is writing device lib into .godot/mono/temp/bin/godot-publish-dotnet/ and simulator libs into a random temp folder?

At godot-master/modules/mono/editor/GodotTools/GodotTools/Export/ExportPlugin.cs:197,

            if (platform == OS.Platforms.iOS)
            {
                targets.Add(new PublishConfig
                {
                    BuildConfig = publishConfig.BuildConfig,
                    Archs = new List<string> { "arm64", "x86_64" },
                    BundleOutputs = false,
                    IncludeDebugSymbols = publishConfig.IncludeDebugSymbols,
                    RidOS = OS.DotNetOS.iOSSimulator,
                    UseTempDir = true, // here
                });
            }

I think this line makes simulator libs to be written into a temp folder.

I'm trying to change this line and rebuild the editor, maybe this can make the export tool working.

[shana]

Sorry, I totally missed the ping on this.

I can reproduce the issue, seems like Xcode does not like libraries in the temp folder (or just in the different locations), no idea why C# exporter is writing device lib into .godot/mono/temp/bin/godot-publish-dotnet/ and simulator libs into a random temp folder?

This is because the xcframework is created in the .godot output folder, and referenced directly by the Xcode project, and all the build outputs of the non-simulator build are included in the godot packaged data. The simulator build is only used to create the dylib, and that dylib is then combined with the non-simulator dylib with lipo, so we don't need any of the outputs of the simulator build once the export is done, which is why that one goes to a temp folder.

I tested this pre-Sonoma, so maybe something changed with Xcode 15, I'll run some a test and see what is going on.