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

[ivanpovazan]

Summary

This PR adds documentation describing how to build and consume native libraries with NativeAOT targeting iOS-like platforms.

---

Fixes dotnet/runtime#96742
Contributes to: dotnet/runtime#96664

---

Internal previews

📄 File	🔗 Preview link
docs/core/deploying/native-aot/index.md	Native AOT deployment
docs/core/deploying/native-aot/ios-like-platforms/creating-and-consuming-custom-frameworks.md	Create and consume custom frameworks for iOS-like platforms
docs/core/deploying/native-aot/ios-like-platforms/index.md	Native AOT support for iOS-like platforms
docs/navigate/devops-testing/toc.yml	docs/navigate/devops-testing/toc

[jkotas]

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

[jkotas]

#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]

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]

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]

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]

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.

[gewarren]

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

[ivanpovazan]

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

[gewarren]

Please squash and merge when you're ready.

[jkotas]

LGTM. Thanks!