You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Flutter.framework is as a dylib, so providing both a dylib and static lib would involve a lot of work producing both as part of the build process, and double the size of those artifact downloads.
Building the other frameworks statically would mean updating the Podfile to remove use_frameworks! when the command is invoked, and test with the XCFrameworks flows. You can try this manually by adding use_frameworks! to .ios/Podfile, though note that file is recreated after every flutter clean.
Dynamic frameworks have a cost at launch time. We're evaluating integrating Flutter in a large application where it could be a deal breaker given the fact that a dynamic framework is generated for every plugin.
We're evaluating integrating Flutter in a large application where it could be a deal breaker given the fact that a dynamic framework is generated for every plugin.
@abhaysood As it's written now, flutter build ios-framework generates Flutter.framework (the Flutter SDK), App.framework (your compiled dart code), pub plugins (as specified in your pubspec), and their CocoaPods dependencies (from the pub plugins's respective podspecs, if any) as dynamic frameworks. One thing you could do is to not use the generated CocoaPods frameworks, and instead use CocoaPods in your host app and add them yourself to your Podfile without the use_framework! to generate at least those as static libs.
For example, if you were using the Flutter firebase_admob plugin, instead of embedding the generated Google-Mobile-Ads-SDK.framework you could instead add pod 'Google-Mobile-Ads-SDK' to your host app Podfile, and you would be on the hook for managing version ranges.
We're evaluating integrating Flutter in a large application where it could be a deal breaker given the fact that a dynamic framework is generated for every plugin.
@abhaysood As it's written now, flutter build ios-framework generates Flutter.framework (the Flutter SDK), App.framework (your compiled dart code), pub plugins (as specified in your pubspec), and their CocoaPods dependencies (from the pub plugins's respective podspecs, if any) as dynamic frameworks. One thing you could do is to not use the generated CocoaPods frameworks, and instead use CocoaPods in your host app and add them yourself to your Podfile without the use_framework! to generate at least those as static libs.
For example, if you were using the Flutter firebase_admob plugin, instead of embedding the generated Google-Mobile-Ads-SDK.framework you could instead add pod 'Google-Mobile-Ads-SDK' to your host app Podfile, and you would be on the hook for managing version ranges.
@jmagman how about now? We very much hope that this requirement will be realized.
There's no plans to make Flutter.framework or App.framework static. For the other frameworks from CocoaPods you could follow the instructions from #52217 (comment).
I'm a bit confused. There are tons of places claiming that while dynamic libraries work on ios, they don't pass the app store review process. Does this mean that ios apps created with flutter can not be published to the app store or has this restriction been lifted?
There are tons of places claiming that while dynamic libraries work on ios, they don't pass the app store review process
Not sure what you mean here, iOS frameworks created in Xcode by default are MACH_O_TYPE=mh_dylib, they are embedded into the app bundle and loaded as needed. I've never heard of an issue with App Store failures because the dynamic Flutter framework was embedded in the app.
Reacted by Abhay Sood, David Craven and Ravi Tripathi
after more careful reading it looks like that was before ios 8. here would be a source [0]. an additional source of confusion was rust not supporting building dynamic libraries for ios, but that seems to stem from a combination of before ios 8 times + backwards compatibility concerns [1].
Created a PR to add a --static flag to create just the plugins as static xcframeworks #104576. Note these still look like framework bundles, but the binaries are static libs instead of dylibs. You will only need to link these frameworks in your host app. Do not embed them in your app!
Flutter.xcframework and App.xcframework are still dynamic libraries.
Activity
dnfield commentedon Mar 9, 2020
/cc @jmagman
jmagman commentedon Mar 9, 2020
It's not possible at the moment.
Flutter.framework is as a dylib, so providing both a dylib and static lib would involve a lot of work producing both as part of the build process, and double the size of those artifact downloads.
Building the other frameworks statically would mean updating the Podfile to remove
use_frameworks!when the command is invoked, and test with the XCFrameworks flows. You can try this manually by addinguse_frameworks!to.ios/Podfile, though note that file is recreated after everyflutter clean.lupeihong commentedon Mar 10, 2020
OK! THS
iapicca commentedon Mar 16, 2020
Hi @lupeihong @jmagman
is this issue meant to stay open?
Thank you
jmagman commentedon Apr 7, 2020
Sure, it's a valid feature request.
abhaysood commentedon Feb 26, 2021
Dynamic frameworks have a cost at launch time. We're evaluating integrating Flutter in a large application where it could be a deal breaker given the fact that a dynamic framework is generated for every plugin.
Reference to official documentation which mentions limiting number of dynamically linked frameworks.
https://developer.apple.com/documentation/xcode/improving_your_app_s_performance/reducing_your_app_s_launch_time#3323366
It would be great if there was a way to generate static frameworks or have any other alternate approach to resolve this.
jmagman commentedon Feb 26, 2021
@abhaysood As it's written now,
flutter build ios-frameworkgeneratesFlutter.framework(the Flutter SDK),App.framework(your compiled dart code), pub plugins (as specified in your pubspec), and their CocoaPods dependencies (from the pub plugins's respective podspecs, if any) as dynamic frameworks. One thing you could do is to not use the generated CocoaPods frameworks, and instead use CocoaPods in your host app and add them yourself to yourPodfilewithout theuse_framework!to generate at least those as static libs.For example, if you were using the Flutter
firebase_admobplugin, instead of embedding the generatedGoogle-Mobile-Ads-SDK.frameworkyou could instead addpod 'Google-Mobile-Ads-SDK'to your host app Podfile, and you would be on the hook for managing version ranges.hello-david commentedon Jan 12, 2022
@jmagman how about now? We very much hope that this requirement will be realized.
jmagman commentedon Jan 12, 2022
There's no plans to make
Flutter.frameworkorApp.frameworkstatic. For the other frameworks from CocoaPods you could follow the instructions from #52217 (comment).dvc94ch commentedon Apr 3, 2022
I'm a bit confused. There are tons of places claiming that while dynamic libraries work on ios, they don't pass the app store review process. Does this mean that ios apps created with flutter can not be published to the app store or has this restriction been lifted?
jmagman commentedon Apr 4, 2022
Not sure what you mean here, iOS frameworks created in Xcode by default are
MACH_O_TYPE=mh_dylib, they are embedded into the app bundle and loaded as needed. I've never heard of an issue with App Store failures because the dynamic Flutter framework was embedded in the app.dvc94ch commentedon Apr 4, 2022
after more careful reading it looks like that was before ios 8. here would be a source [0]. an additional source of confusion was rust not supporting building dynamic libraries for ios, but that seems to stem from a combination of before ios 8 times + backwards compatibility concerns [1].
jmagman commentedon May 25, 2022
Created a PR to add a
--staticflag to create just the plugins as static xcframeworks #104576. Note these still look like framework bundles, but the binaries are static libs instead of dylibs. You will only need to link these frameworks in your host app. Do not embed them in your app!Flutter.xcframework and App.xcframework are still dynamic libraries.
jmagman commentedon May 25, 2022
This could use some docs.
jmagman commentedon Dec 4, 2023
New mergeable libraries is relevant here:
https://developer.apple.com/documentation/xcode/configuring-your-project-to-use-mergeable-libraries
#139501