Description

Currently, we support building shared iOS libraries:

• with MonoAOT: [mono] Add support for library mode in the aot compiler #79377
• with NativeAOT: [NativeAOT] Support library mode with NativeAOT on iOS-like platforms #93658)

without depending on iOS workloads and pulling in Xamarin SDK.

This means that when users write their class libraries that do not have a dependency on iOS-specific API, can build such libraries by using the standard target framework and iOS-specific runtime identifier (e.g.,-f net8.0 -r ios-arm64) in order to produce a shared native library - *.dylib.

However, in order to properly consume a shared iOS library, one has to bundle it into a framework - Technical Note TN2435 which in most simplistic case comes down to generating the following bundle:

mylib.framework
    |_ mylib.dylib
    |_ Info.plist

This was also reported in: #93366

Approaches

At this point, I can think of two possible approaches we could take (there might be other solutions):

1. Lift up Xamarin SDK bundling logic from OS-specific framework and extend it to also be capable of producing framework bundles
   • This would also contribute in solving: .NET: Add support for producing a self-contained native framework/library macios#15217
2. Refactor and productise AppleAppBuilder which will have minimal viable set of features (a subset of Xamarin bundler) for producing minimal app/framework bundles, and which will be available with the standard target framework.