Known issues in .NET8

This document lists known issues in the SDKs.

Binding libraries with a static library from Windows

If a binding project or NuGet contains a native library in the form of a static library (as opposed to a framework or xcframework), the static library might be included twice in any referencing executable projects. This is innouous when building from Mac (the duplicated arguments are ignored), but when building remotely from Windows, those duplicated libraries might actually be from different locations on disk, and the duplicated libraries won't be ignored. This leads to a build error like "Clang++ exited with code 1" with numerous mentions in the build log about duplicate symbols.

There are two workarounds:

1. Create an [XCFramework][5] for the static library instead. This is recommended anyways, because it's required in order to support both an arm64 slice for the simulator + an arm64 slice for the device.
2. Change the binding project to embed the static library in the managed assembly. This can be done by setting the following property in the binding project:

<PropertyGroup>
    <NoBindingEmbedding>false</NoBindingEmbedding>
</PropertyGroup>

We'll fix this in a service release.

Ref: https://github.com/xamarin/xamarin-macios/issues/19378

The launch screen isn't displayed in the simulator.

Starting with the iOS 16.4 simulator, apps must be signed for the iOS simulator to load and show the launch screen.

By default apps aren't signed when building for the simulator, which means the launch screen won't show up on iOS 16.4+ simulators.

The workaround is to enable codesigning for the simulator:

<PropertyGroup Condition="$(RuntimeIdentifier.Contains('simulator'))">
    <EnableCodeSigning>true</EnableCodeSigning>
    <CodesignRequireProvisioningProfile>true</CodesignRequireProvisioningProfile>
    <DisableCodesignVerification>true</DisableCodesignVerification>
</PropertyGroup>

References:

• https://github.com/xamarin/xamarin-macios/issues/19430
• https://github.com/xamarin/xamarin-macios/issues/18469

Apps built with NativeAOT will show warning ITMS-90999 when published to the App Store

Apps built with NativeAOT will show the following warning when published to the App Store:

We identified one or more issues with a recent delivery for your app, "MyApp" 1.0.0 (1.0.0). Your delivery was successful, but you may wish to correct the following issues in your next delivery: 
ITMS-90999: Invalid executable - The executable in “MyApp.iOS.app” contains multiple segments with the executable permission bit set when it should only contain one. 

There is currently no workaround, but since it's a warning it doesn't block app submission.

Ref: https://github.com/dotnet/runtime/issues/94655

Not able to debug extensions on device in iOS 17+

Apple rewrote their internal code to interact with devices in iOS 17 / Xcode 15, and we haven't been able to update our code accordingly to make debugging extensions work yet.

Ref: https://github.com/xamarin/xamarin-macios/issues/19484

Can't run mobile app from the command line on Windows

It's currently not possible to run a mobile app (iOS, tvOS) on Windows using the command line. Please use an IDE to launch apps from Windows.

Ref: https://github.com/xamarin/xamarin-macios/issues/16609

The simplified output path format is not supported when building remotely from Windows.

The simplified output path format (which can be opted into by setting the ArtifactsPath property to a path, or by setting UseArtifactsOutput=true) is not supported when building remotely from Windows.

References:

• https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-8#simplified-output-paths
• https://github.com/xamarin/xamarin-macios/issues/18510

Launching from the command line is awkward

Launching an app in the simulator (iOS, tvOS)

1. Use the following command to get a list of all the simulators:

$ /Applications/Xcode.app/Contents/Developer/usr/bin/simctl list

2. Choose one, and copy the corresponding UDID.

3. Set the _DeviceName property like this to select the simulator:

dotnet build -t:Run -p:_DeviceName=:v2:udid=<UDID>

Note that a simulator runtime identifier must be used (either set in the project file, or passed to the command above like this: /p:RuntimeIdentifier=iossimulator-x64).

Launching an app on device (iOS, tvOS)

1. Open Xcode, then the menu Window -> Devices and Simulators.

2. Choose a device on the left, and copy the Identifier from the device info section.

3. Set the _DeviceName property like this to select the device:

dotnet build -t:Run -p:_DeviceName=<IDENTIFIER>

Note that a device runtime identifier must be used (either set in the project file, or passed to the command above like this: /p:RuntimeIdentifier=ios-arm64).

Launching an app on desktop (macOS, Mac Catalyst)

Just dotnet run should work just fine.

If something goes wrong (the app crashes, etc.), it's often useful to see stdout and stderr (Console.Out / Console.Error) from the app (this can even be useful as a debugging mechanism in certain cases). In order to see this output, it's necessary to execute the actual macOS executable directly from the terminal. The executable can be found inside the Contents/MacOS directory of the app, which can be found in the output directory.

An example path for a Mac Catalyst app built for x86_64 (relative to the project directory):

$ ./bin/Debug/net6.0-maccatalyst/maccatalyst-x64/MySimpleApp.app/Contents/MacOS/MySimpleApp
[output]

If the app is a universal app (built for both x64 and arm64), the path to the app won't contain the runtime identifier:

$ ./bin/Debug/net6.0-maccatalyst/MySimpleApp.app/Contents/MacOS/MySimpleApp
[output]

Ref: https://github.com/dotnet/xamarin/issues/26.

Selecting the simulator architecture remotely from Windows

When:

• Building remotely from Visual Studio (on Windows).
• Building for the simulator.
• The remote mac is an ARM64 machine.

Visual Studio will build using the iossimulator-arm64 RuntimeIdentifier.

For some projects this may not work correctly (in particular projects that depend on third-party native libraries that don't provide an iossimulator-arm64 version of their library), and for those cases it's possible to make Visual Studio build using iossimulator-x64 instead, by setting the following property in the project file:

<PropertyGroup>
  <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>

This is supported starting in Visual Studio 17.7 preview 3.