[ios] Support bundling shared libraries into frameworks

[ivanpovazan]

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

[ghost]

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

Issue Details

---

Description

Currently, we support building shared iOS libraries:

• with MonoAOT: [mono] Add support for library mode in the aot compiler #79377
• (soon) 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 xamarin/xamarin-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.

Author:	ivanpovazan
Assignees:	-
Labels:	os-ios
Milestone:	9.0.0

[ivanpovazan]

@rolfbjarne @steveisok what are your thoughts on the proposed approaches?

[rolfbjarne]

Creating a .framework isn't very difficult:

1. Create the correct directory structure (differs between iOS/tvOS and MacCatalyst/macOS).
2. Add the native library + any other files the native library depends on (the assembly maybe?) in the correct location.
3. Add an Info.plist in the correct location.

The biggest complication is probably the Info.plist: should it be completely user-provided? do you generate a default file if the developer doesn't specify one? Note that the developer should at least be able to override any defaults.

IMHO this the simplest is just to create your own logic, no need to copy/move ours (it's not trivially extractable anyway).

[ghost]

Tagging subscribers to this area: @directhex
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Currently, we support building shared iOS libraries:

• with MonoAOT: [mono] Add support for library mode in the aot compiler #79377
• (soon) 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 xamarin/xamarin-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.

Author:	ivanpovazan
Assignees:	-
Labels:	area-Infrastructure-mono, os-ios, needs-area-label
Milestone:	9.0.0

[jkotas]

Creating a .framework isn't very difficult:

If it is that simple, do we need the whole AppleAppBuilder for it? Can it be just a few lines of build targets (for native AOT at least)?

[ivanpovazan]

Since we provided documentation on required steps to create and consume custom frameworks from shared native libraries, I will close this issue as out-of-scope.

If it becomes necessary to automate these steps as part of the build, we can reopen the issue.