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

[docs] Add building iOS-like native libraries with NativeAOT #43397

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

ivanpovazan
Copy link
Member

@ivanpovazan ivanpovazan commented Nov 11, 2024

@jkotas
Copy link
Member

jkotas commented Nov 11, 2024

#43399 (comment) applies to this change as well.

@jkotas
Copy link
Member

jkotas commented Nov 13, 2024

#43399 (comment) applies to this change as well.

Do you have thoughts about moving this doc to where the rest iOS-like specific native AOT docs live?

I understand that those are MAUI specific docs. However, a lot of content in there is more generally applicable than MAUI. We seem to be making simplifying assumption that everything mobile specific falls under MAUI.

@ivanpovazan
Copy link
Member Author

Do you have thoughts about moving this doc to where the rest iOS-like specific native AOT docs live?

I can see advantages and disadvantages with that approach:

  • advantages
    • all NativeAOT iOS-like specific docs are in one place
  • disadvantages
    • it may sound confusing describing a feature that does not require mobile workloads to be installed under MAUI docs, as if MAUI is a requirement, which is not
    • in this scenario we are explicitly targeting TFMs without OS-specific APIs, if someone would confuse a class library which specifies net9.0-ios publishing such library currently does not really do anything useful. Again, it seems confusing as MAUI utilizes OS-specific TFMs
    • MAUI does not support tvOS while Native AOT does (I admit I was not mentioning this in the doc, I can correct it if we decide to keep the docs here)
    • nit: In this scenario we still need to specify PublishAotUsingRuntimePack which we don't mention in MAUI docs as it is handled by mobile SDK

@jkotas
Copy link
Member

jkotas commented Nov 13, 2024

targeting TFMs without OS-specific APIs,

I would not be optimizing the docs layout around the fact that we do not have support for Objective-C interop in NAOT published libraries. It is not a fundamental limitation, it is just something that we have not found time for.

MAUI does not support tvOS while Native AOT does

Right, and this doc problem exists for Mono too. We do not seem to mention existence of the tvos workload anywhere in the docs.

nit: In this scenario we still need to specify PublishAotUsingRuntimePack which we don't mention in MAUI docs as it is handled by mobile SDK

Right, and it is also applicable to building raw iOS apps without mobile SDK. It is not specific to building libraries without mobile SDK.

After thinking about this some more, I would like to avoid the mainline docs to be cluttered with platform or app-model specific content. It makes them look complicated. At the same time, we should make the platform specific content more discoverable. For example, https://review.learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?branch=pr-en-us-43397&tabs=windows%2Cnet9plus mentions iOS as supported, but it does not point you to a place where you can find anything more about it.

How about we move the platform-specific to its own hives at the end, like:

  • Native AOT deployment
    • ...
    • AOT warnings
    • iOS-like platforms
      • Overview - this can mention RIDs to use, and that you need the PublishAotUsingRuntimePack if you use the RID that is not iOS specific, it can have a link to MAUI docs. It can be linked from the main page where iOS is mentioned as supported.
      • Creating and consuming a custom framework - the doc in your PR
      • ...
    • Android
      • potential future Android specific topics
    • WASI
      • potential future WASI specific topics

@ivanpovazan
Copy link
Member Author

How about we move the platform-specific to its own hives at the end, like:

Thats sounds like a good idea, I will look into it.
For experimental/unsupported platforms (Android, WASI) should we introduce a placeholder pages in this PR?

@jkotas
Copy link
Member

jkotas commented Nov 14, 2024

For experimental/unsupported platforms (Android, WASI) should we introduce a placeholder pages in this PR?

I do not think we have placeholder pages like that anywhere in the official docs.

Copy link
Contributor

@gewarren gewarren left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this great article @ivanpovazan. I left some grammatical suggestions.

@ivanpovazan
Copy link
Member Author

@jkotas I restructured the doc as suggested, could you please give it another look?

@@ -503,6 +503,12 @@ items:
href: ../../core/deploying/native-aot/interop.md
- name: Build native libraries
href: ../../core/deploying/native-aot/libraries.md
- name: iOS-like platforms
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would put this and future OS-specific topics at the end of "Native AOT deployment model" list.


Starting from .NET 8, Native AOT supports targeting iOS-like platforms. The term *iOS-like platforms* refers to Apple platforms that use similar APIs such as: iOS, MacCatalyst and tvOS.

In the first release, the support was experimental, while in .NET 9 these platforms received full support with Native AOT.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think we need to be going over the history and that we have shipped it as an experiment for one release. We should just say that this is supported starting .NET 9.


For specifics of building and consuming native libraries on iOS-like platforms, see [How to create and consume custom frameworks with Native AOT for iOS-like platforms](./creating-and-consuming-custom-frameworks.md).

## Support for applications and libraries referencing OS-specific APIs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be the first since it is the more common case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[ios][docs] Document how iOS library mode is supported
5 participants