-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable support for NativeAOT targeting iOS via opt-in feature #80905
Comments
Tagging subscribers to 'os-ios': @steveisok, @akoeplinger Issue DetailsOverviewSupporting NativeAOT on iOS platforms as an experimental feature in .NET8 would enable our customers to try the NativeAOT toolchain and runtime with their iOS applications, in order to benefit from advantages mostly concentrated around application size savings and start-up performance. This issues tracks progress on the identified work required for enabling NativeAOT on iOS platforms. The work will be organised and tracked with GitHub issues which are prioritised by their importance below. Some of the listed items can be considered as user stories and will require further break-down of work, while the others are plain tasks. TasksPriority 0
Priority 1
Priority 2
/cc: @marek-safar @SamMonoRT @steveisok @lambdageek @rolfbjarne @kotlarmilos @akoeplinger
|
We should also have a note/item around diagnostics and document what the user experience will be on iOS. I believe it would be rather different and having a comprehensive list would help users make informed decisions about using NativeAOT and what to expect post deployment. /cc @tommcdon |
Adding @thaystg @lateralusX. It is my understanding that Mono uses an in-proc debugger model due to mobile diagnostics restrictions. |
FWIW debugging with lldb on-device is possible, so in that sense it's comparable to the current model of debugging NativeAOT on Linux/macOS. |
@AaronRobinsonMSFT thank you for the suggestion. I have added it to the list. |
) This PR adds a new flag to ILC, `--splitinit` . The flag splits the initialization that is normally done for executable into two parts. The `__managed__Startup` function runs classlib and module initializers. The `__managed__Main` function performs the remaining initialization and executes the entry-point of the managed application. The use case for this is to allow calling `UnamanagedCallersOnly` functions before the managed `main` function. Running on iOS is the first use case for this feature (#80905). It was not clear to me how to fit this into the larger NativeAot build system. Should this be thought of as "a static library that also has a `__managed__Main` compiled in" or as "an executable that splits its initialization into two parts"? So I added support to ILC for both cases: compiling with the `--nativelib` flag and without it. Lastly, I added some build integration the "an executable that splits its initialization into two parts" case, along with test. The idea is the user sets the `CustomNativeMain` property in their project. They are then responsible for providing a `NativeLibrary` item pointing to an object file containing their native `main` function. At runtime, when they call their first managed function, NativeAOT initialization will run. This includes calling `__managed__Main`, so the user cannot forget to initialize the runtime. Related issues: #81097 #77957
Does this feature mean that it will be possible to export a .NET class library as a native iOS library? |
See #79377 for details on library build in .net8 for iOS/Android. Not sure if the experimental feature implemented here will have support for NativeLib=static|shared, since the main focus is building an iOS application, but the work done in #79377 is specifically targeting building a static|shared native library out of a set of .net class libraries and it is integrated into regular .net CLI, so you can do a publish -p:NativeLib=shared using iOS or Android rid's supporting the same features as doing NativeAOT library build. |
Thank you for the question @curia-damiano. In theory that would work as well, however, our current focus with NativeAOT is supporting full iOS applications. Would you mind sharing what would be the use case that you have in mind for native iOS libraries? |
|
Sorry @ivanpovazan, I missed your request for comments. Thank you @filipnavara for the link! |
Moving to 10 since all the remaining 9 tasks are documentation and are tracked by separate issues. |
Could you please provide more information @ivanpovazan? We are now testing publish managed class to native library, only find out we have to enable self-contained. Maybe the after-procedural (like library builder) is ready, but the publish itself is not? when we set Background: We already setup an embed mono runtime, thus self-contained is not suitable for our need :) Recently we are experimenting if we can extract certain managed class as native library for the native host to invoke, to see if it can improve performance. |
This touches on our rooting/trimming WASM use-case #101434 |
As I see that this issue is not closed yet, I would like to ask this:
Do you think that this is possible with .NET 8? And if not, will it be possible in .NET 9? |
@curia-damiano Sounds like the perfect use case for Beyond.NET. That being said, I would obviously very much appreciate if that was built in to .NET. |
I was not aware of it, thank you very much @lemonmojo for telling me! |
This is by design. Building a managed library into a shared native one embeds the runtime with it.
If I understand your setup correctly, you would have mono and NativeAOT runtime running in the same process, which is not a setup that is supported.
/cc: @kotlarmilos ^ |
Overview
Supporting NativeAOT on iOS platforms as an experimental feature in .NET8 would enable our customers to try the NativeAOT toolchain and runtime with their iOS applications, in order to benefit from advantages mostly concentrated around application size savings and start-up performance.
In .NET8 the default toolchain and runtime when targeting iOS platforms will remain to be Mono, while NativeAOT would become available as an option.
This issues tracks progress on the identified work required for enabling NativeAOT on iOS platforms. The work is organised and tracked with GitHub issues divided by upcoming .NET8 preview releases in which they should become available. Some of the listed items can be considered as user stories and will require further break-down of work, while the others are plain tasks.
NOTE: The breakdown of GitHub issues does not impose hard deadlines. If some of the functionality does not get upstreamed for a particular preview version, this issue will be updated accordingly.
Tasks
.NET8 Preview 5
.NET8 Preview 6
ios
,iossimulator
,maccatalyst
,tvos
andtvossimulator
.NET8 Preview 7
-dead_strip
to the native linker xamarin/xamarin-macios#18552.NET8 GA
System.Linq.Expressions.dll
is supported on iOS-like platforms #87924.NET9
.NET10+
Other relevant issues:
/cc: @marek-safar @SamMonoRT @steveisok @lambdageek @rolfbjarne @kotlarmilos @akoeplinger
The text was updated successfully, but these errors were encountered: