Repository navigation
[ios] Support bundling shared libraries into frameworks #96664
Description
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):
- 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
- 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.
Activity
ivanpovazan commentedon Jan 9, 2024
@rolfbjarne @steveisok what are your thoughts on the proposed approaches?
rolfbjarne commentedon Jan 9, 2024
Creating a .framework isn't very difficult:
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).
jkotas commentedon Jan 9, 2024
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 commentedon Nov 24, 2024
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.