Skip to content
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

Open
43 of 52 tasks
ivanpovazan opened this issue Jan 20, 2023 · 18 comments
Open
43 of 52 tasks

Enable support for NativeAOT targeting iOS via opt-in feature #80905

ivanpovazan opened this issue Jan 20, 2023 · 18 comments
Assignees
Labels
area-NativeAOT-coreclr Epic Groups multiple user stories. Can be grouped under a theme. os-ios Apple iOS tracking This issue is tracking the completion of other related issues.
Milestone

Comments

@ivanpovazan
Copy link
Member

ivanpovazan commented Jan 20, 2023

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

.NET8 Preview 7

.NET8 GA

.NET9

.NET10+

Other relevant issues:


/cc: @marek-safar @SamMonoRT @steveisok @lambdageek @rolfbjarne @kotlarmilos @akoeplinger

@ivanpovazan ivanpovazan added Epic Groups multiple user stories. Can be grouped under a theme. os-ios Apple iOS area-NativeAOT-coreclr labels Jan 20, 2023
@ivanpovazan ivanpovazan added this to the 8.0.0 milestone Jan 20, 2023
@ghost
Copy link

ghost commented Jan 20, 2023

Tagging subscribers to 'os-ios': @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

Issue Details

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 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.

Tasks

Priority 0

  • Investigate limitations and document findings of enabling NativeAOT for MAUI iOS application
  • Enable building NativeAOT for iOS platforms
  • Support targeting iOS platforms with ILCompiler
  • Enable dotnet SDK to support targeting iOS with NativeAOT
  • Enable AppleAppBuilder to bundle applications compiled with NativeAOT
  • HelloiOS sample for NativeAOT
  • Introduce symbol stripping build task for HelloiOS sample
  • Include measuring HelloiOS application size without debug symbols
  • Static registrar with NativeAOT design – discussion
  • Static registrar with NativeAOT implementation
  • Enable start-up hooks to wrap managed entry points: [NativeAOT] support calling UnmanagedCallersOnly functions before managed main() #77957
  • Objective-C marshalling and GC support: [NativeAOT] Low level API support for Objective-C scenarios #77472
  • Enable building/running dotnet/runtime libraries tests on a simulator and device with NativeAOT
  • Support NativeAOT as a third runtime variant with Xamarin (managed-to-native bridge and build system)

Priority 1

  • UnmanagedCallersOnly functions should be exposed from referenced libraries with NativeAOT
  • Marshalled delegates vs function pointers support with NativeAOT
  • Trimming and extensions compatibility design – discussion
  • Trimming and extensions compatibility implementation
  • Enable dotnet/runtime functional tests for iOS platforms to run with NativeAOT
  • Enable Xamarin iOS testing to run with NativeAOT

Priority 2

  • Investigate debugging support with NativeAOT
  • Improve methodology for start-up profiling and measuring SOD for iOS platforms
  • Completely move from marshalled delegates to function pointers throughout the Microsoft.iOS library
  • App size-regression tracking for NativeAOT iOS
  • App startup time tracking for NativeAOT iOS
  • App build time tracking for NativeAOT iOS

/cc: @marek-safar @SamMonoRT @steveisok @lambdageek @rolfbjarne @kotlarmilos @akoeplinger

Author: ivanpovazan
Assignees: -
Labels:

Epic, os-ios, area-NativeAOT-coreclr

Milestone: 8.0.0

@SamMonoRT
Copy link
Member

/cc @agocke @jkotas @AaronRobinsonMSFT

@AaronRobinsonMSFT
Copy link
Member

AaronRobinsonMSFT commented Jan 20, 2023

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

@tommcdon
Copy link
Member

Adding @thaystg @lateralusX. It is my understanding that Mono uses an in-proc debugger model due to mobile diagnostics restrictions.

@filipnavara
Copy link
Member

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.

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.

@ivanpovazan
Copy link
Member Author

@AaronRobinsonMSFT thank you for the suggestion. I have added it to the list.

@marek-safar marek-safar changed the title NativeAOT on iOS as an experimental feature in .NET8 Enable support for NativeAOT targeting iOS via opt-in feature Jan 27, 2023
MichalStrehovsky pushed a commit that referenced this issue Feb 15, 2023
)

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
@curia-damiano
Copy link

Does this feature mean that it will be possible to export a .NET class library as a native iOS library?

@lateralusX
Copy link
Member

lateralusX commented May 22, 2023

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.

@ivanpovazan
Copy link
Member Author

Does this feature mean that it will be possible to export a .NET class library as a native iOS library?

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?

@filipnavara
Copy link
Member

Would you mind sharing what would be the use case that you have in mind for native iOS libraries?

#79377 (comment)

@curia-damiano
Copy link

Sorry @ivanpovazan, I missed your request for comments. Thank you @filipnavara for the link!

@ivanpovazan ivanpovazan modified the milestones: 8.0.0, 9.0.0 Aug 17, 2023
@vitek-karas
Copy link
Member

Moving to 10 since all the remaining 9 tasks are documentation and are tracked by separate issues.

@vitek-karas vitek-karas modified the milestones: 9.0.0, 10.0.0 Aug 22, 2024
@AlexeiNaabal
Copy link

AlexeiNaabal commented Sep 4, 2024

Does this feature mean that it will be possible to export a .NET class library as a native iOS library?

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?

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 <NativeLib>Shared</NativeLib>, the compiler force us to enable self-contained.

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.

@pavelsavara
Copy link
Member

We are now testing publish managed class to native library, only find out we have to enable self-contained.
when we set <NativeLib>Shared</NativeLib>, the compiler force us to enable self-contained.

This touches on our rooting/trimming WASM use-case #101434

@curia-damiano
Copy link

As I see that this issue is not closed yet, I would like to ask this:

  • the Swift SDK for Application Insights has been deprected less than a couple of years ago
  • with perfect timing, we retire App Center
  • the idea would be to use the .NET SDK for Application Insights in a native iOS library developed in Swift, compiling the SDK to a native library (eventually adding some entry point methods).

Do you think that this is possible with .NET 8? And if not, will it be possible in .NET 9?

@lemonmojo
Copy link

@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.

@curia-damiano
Copy link

I was not aware of it, thank you very much @lemonmojo for telling me!

@ivanpovazan
Copy link
Member Author

@AlexeiNaabal

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 Shared, the compiler force us to enable self-contained.

This is by design. Building a managed library into a shared native one embeds the runtime with it.

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.

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.


@curia-damiano

  • the idea would be to use the .NET SDK for Application Insights in a native iOS library developed in Swift, compiling the SDK to a native library (eventually adding some entry point methods).

Do you think that this is possible with .NET 8? And if not, will it be possible in .NET 9?

/cc: @kotlarmilos ^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-NativeAOT-coreclr Epic Groups multiple user stories. Can be grouped under a theme. os-ios Apple iOS tracking This issue is tracking the completion of other related issues.
Projects
Status: No status
Development

No branches or pull requests