Embed Flutter and App frameworks for add-to-app on iOS#102538
Embed Flutter and App frameworks for add-to-app on iOS#102538fluttergithubbot merged 1 commit intoflutter:masterfrom
Conversation
86d0d33 to
2b32a72
Compare
There was a problem hiding this comment.
.ios/Flutter/engine no longer exists
There was a problem hiding this comment.
This is now called from the host app Podfile script, and the fake podspec is in the Flutter module, so don't assume they are sibling paths.
There was a problem hiding this comment.
This comment is already in parseFlutterBuildMode we don't need it twice.
There was a problem hiding this comment.
Instead of duplicating logic, call the ruby script in the tool
There was a problem hiding this comment.
Remove duplicated logic, call
There was a problem hiding this comment.
Stop making the dummy App.framework in the ephemeral module directory.
🐮
There was a problem hiding this comment.
Stop copying the engine into the module ephemeral directory. Let the tool handle copying the right version where it needs to go when assemble is called.
There was a problem hiding this comment.
Instead of letting CocoaPods copy/re-codesign/strip the frameworks from the ephemeral directory, instead let the tool copy it via embed_and_thin after the rest of the app has compiled. The tool already codesigned/stripped it during assemble.
Note this is the only real added logic to this PR, everything else is deletions or slight refactoring.
2b32a72 to
c46c66e
Compare
c46c66e to
5de2d33
Compare
|
friendly ping @christopherfujino |
christopherfujino
left a comment
There was a problem hiding this comment.
Sorry, thought I approved this, LGTM
Previously, the iOS Flutter module copied the Flutter.xcframework and created a dummy version of App.framework in the the ephemeral
.iosdirectory, as well as two correspondingpodspecs that pointed at these frameworks. On every compilation of the host app,flutter assemblewould create the real App.framework and copy the right Flutter.framework variant into the XcodeBUILT_PRODUCTS_DIR. On the first build, CocoaPods would then copy/re-codesign/re-strip the frameworks and embed them into the app.However, since
flutter assembleupdates the frameworks inBUILT_PRODUCTS_DIRand not the dummy frameworks in the ephemeral directory, on incremental builds CocoaPods would not run its copy script because the timestamp of the dummy ephemeral frameworks did not change. So the compiled dart code embedded in the app would not be updated, and would be stale until a hot reload.podhelperscripts that embed the frameworks into the app.assemblealready codesigns, bitcode strips, and debug symbol strips the frameworks, so all that's left it torsyncthem to the right place in the app.podhelper.rbruby script to use the Flutter SDKflutter_tools/bin/podhelper.rbversion of this file to push as much logic as possible into the SDK instead of the module project.Fixes #101979
Probably would have resolved parts of #94481
Follow-up to #101943
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.