Support NativeAOT as a runtime variant for iOS platforms

[ivanpovazan]

Description

To enable Supporting NativeAOT on iOS platforms as an experimental feature in .NET8 it is required to adjust Xamarin runtime, build system and SDK accordingly.

Tasks

The following list of tasks give a top-level overview of work that is required to enable this feature:

.NET 8

• Introduce new managed-to-native bridge for NativeAOT runtime (Add support for using NativeAOT. #17374)
• Enable building Xamarin framework and runtime libraries for NativeAOT runtime (Add support for using NativeAOT. #17374)
• Enable Xamarin SDK for iOS platforms to build applications with NativeAOT compiler, framework and runtime libraries (Add support for using NativeAOT. #17374)
• Make the static registrar work with NativeAOT #17324
• Pass linker flag to set __THUNKS permission for NativeAOT #17629
• Enable Xamarin tests with NativeAOT (Add support for using NativeAOT. #17374)
• Adapt monotouch-test to work with NativeAOT #17774
• NativeAOT: stop shipping assemblies #18472
• NativeAOT: investigate whether we still need separate min OS versions #18477
• NativeAOT: investigate whether setting IlcKeepManagedDebuggerSupport is still needed #18478
• NativeAOT: investigate if we want _AggressiveAttributeTrimming set for NativeAOT #18479
• NativeAOT: investigate whether we want to pull in linker features from ILC build logic and pass to ILLinker #18480
• NativeAOT: investigate whether we still need workaround for tvOS #18481
• NativeAOT: investigate default rooting behavior #18482
• Investigate whether we can set ILC/ILLinker feature flags using RuntimeHostConfigurationOption #18483
• NativeAOT: Do not pass -dead_strip to the native linker #18552
• NativeAOT: Consider enabling trim/AOT/single-file warnings by default #18571
• NativeAOT: implement better logic for finding the icu data file #18471
• Enable tests for universal apps once Overeager check for RuntimeIdentifier when PublishAot=true dotnet/sdk#33414 is fixed.
• Enable tests for macOS apps Add support for NativeAOT on macOS #18765

.NET 9

UPDATE: .NET9 tasks are moved to the top-level tracking issue:

• NativeAOT: Investigate whether we can narrow down the list of assemblies to look for UnmanagedCallersOnly entry points #18484
• NativeAOT: re-enable dead stripping #18605

---

PS The list of tasks is not complete. Feel free to extend it, change it and add more context.

[ivanpovazan]

• Introduce new managed-to-native bridge for NativeAOT runtime

The bridge will be responsible for properly initialising the NativeAOT runtime, invoking any managed code initialisation e.g.:

xamarin-macios/src/ObjCRuntime/Runtime.cs

Line 232 in 608765e

unsafe static void Initialize (InitializationOptions* options)

, and finally invoking the managed Main method.

See this comment for more information: dotnet/runtime#77957 (comment)

[jkotas]

Introduce new managed-to-native bridge for NativeAOT runtime

Why is this bridge better than just injecting static constructor into the app with default bootstrapper? Injecting static constructor into the app looks more composable.

[ivanpovazan]

Why is this bridge better than just injecting static constructor into the app with default bootstrapper? Injecting static constructor into the app looks more composable.

Thanks for the suggestion, but at the moment there seem to be some limitations around it. If you are referring to the default bootstrapper provided by NativeAOT, it currently cannot be used from a native hosting app, when the managed executable is compiled as a static library, as the ILCompiler will not expose its managed Main method entry point (reported here: dotnet/runtime#81097).

@rolfbjarne also gave an explanation on why it is required Xamarin to act as a native hosting application here: dotnet/runtime#77957 (comment)

Finally, the requirement for:

Introduce new managed-to-native bridge for NativeAOT runtime

is written in more general terms, as mono and coreCLR runtimes have their dedicated bridges, so supporting NativeAOT would use the same logic without changing current implementation much.

Afaik, injecting static constructor does not allow the method to have parameters, so if we would want to use it for initializing Xamarin's ObjCRuntime, we would have to change the code to PInvoke into the native to get the required parameters. It is not my call and I could be wrong, but this sounds like more work (especially making sure that the change does not break what is already supported).

[ivanpovazan]

Closing this issue as all subtasks have been completed for the .NET8 timeframe.
The remaining 2 issues for .NET9 milestone are moved to the top-level tracking issue.