Framework support?

[knopp]

I'm hoping to replace a significant chunk of cargokit with native assets. I was looking at the model and the integration in Flutter tool, but it wasn't quite clear to me how frameworks are handled? There seem to be ony two types of assets (static lib and dylib).

The issue here is that iOS app store prevents putting dylibs in arbitrary locations (i.e. next to other frameworks). Each dylib must be packaged as a separate framework and there must to be nested frameworks. Any other layout, unless the rules changed very recently, will result in AppStore rejection.

[dcharkes]

I'm hoping to replace a significant chunk of cargokit with native assets.

Cool!

The issue here is that iOS app store prevents putting dylibs in arbitrary locations (i.e. next to other frameworks). Each dylib must be packaged as a separate framework and there must to be nested frameworks. Any other layout, unless the rules changed very recently, will result in AppStore rejection.

I'm not aware of such limitation. The current flutter plugin architecture does the same.

That being said, if this turns out to be a limitation, we can problably put all dylibs inside a "NativeAssets" framework inside the logic in https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/ios/native_assets.dart

Exposing frameworks as part of the build.dart script itself would make the various target OSes differ from each other, so we'd like to avoid that if possible.

static lib

We don't want to expose the static libs to xcodebuild at all. The goal is to link the dart aot snapshot with the static libraries with the native linker, so that all native code not referenced can be tree-shaken. dart-lang/sdk#49418
(XCode doesn't see inside the dar aot snapshot, because it's just an opaque binary file and we load it manually with our own ELF loader currently.)

[mkustermann]

The goal is to link the dart aot snapshot with the static libraries with the native linker, so that all native code not referenced can be tree-shaken. dart-lang/sdk#49418

Tree shaking native code could be made to work without linking the Dart AOT snapshot together with the native code: Instead the native code can be compiled to a static archive which we can then link to a shared library without exporting unused symbols.

(Theoretically an app can have 1 flutter engine <-> 2 Dart AOTed apps <-> 1 Native library.)

[knopp]

I'm not aware of such limitation. The current flutter plugin architecture does the same.

That being said, if this turns out to be a limitation, we can problably put all dylibs inside a "NativeAssets" framework inside the logic in https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/ios/native_assets.dart

The plugin architecture is using cocoapods on iOS, which results in one framework per plugin. About the bundle structure:

https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle?language=objc

iOS, watchOS, and tvOS support third-party frameworks but don’t support third-party standalone dynamic libraries, which are those outside a framework bundle, typically with the .dylib filename extension. The only exception to this rule is the Swift system libraries provided by Xcode.
iOS and tvOS support frameworks and Swift system libraries at the topmost app level; a nested bundle, like an app extension, can’t include a framework.

This means there must be a framework for each dylib. In my experience if there are extra dylibs in framwework bundles the submission will fail with "invalid bundle structure".

I think this can be resolved at flutter_tool level, simply package each dylib as a separate framework and link the framework with final executable, just bringing it up.

static lib

We don't want to expose the static libs to xcodebuild at all. The goal is to link the dart aot snapshot with the static libraries with the native linker, so that all native code not referenced can be tree-shaken. dart-lang/sdk#49418 (XCode doesn't see inside the dar aot snapshot, because it's just an opaque binary file and we load it manually with our own ELF loader currently.)

This sounds great. How do you determine which symbols to keep in the file? Edit: Nevermind, the answer is right there in the issue.

[dcharkes]

Thanks for the info @knopp!

I think this can be resolved at flutter_tool level, simply package each dylib as a separate framework and link the framework with final executable, just bringing it up.

That indeed sounds like the right thing to do.

If you feel comfortable, you could try to make a PR in flutter_tools to do this. Please tag me, and I'll review and tag the Flutter team members that should review it. Otherwise I'll get to it at some point.

[dcharkes]

FYI @vashworth

[dcharkes]

This was addressed in flutter/flutter#140907 downstream.

At this point we're not planning on supporting frameworks as output from build.dart. If this turns out to be a wish in the future, we should make a new asset type for it and track it in a new issue.

[knopp]

Thanks!