**THIS IS A BREAKING CHANGE.** See below for migration steps for
existing projects.
Previously, Flutter app code was built as a raw dylib on iOS. Dynamic
libraries outside of a framework bundle are not supported on iOS, except
for the system Swift libraries provided by Xcode.
See:
https://developer.apple.com/library/content/technotes/tn2435/_index.html#//apple_ref/doc/uid/DTS40017543-CH1-TROUBLESHOOTING_BUNDLE_ERRORS-EMBEDDED__DYLIB_FILES
* Migrates Xcode build from app.dylib to App.framework
* Migrates flutter create template
* Migrates example projects
Migration steps for existing projects
=====================================
The following steps should be taken from the root of your Flutter
project:
1. Edit `ios/.gitignore`: add `/Flutter/App.framework` on a new line.
2. In the Xcode project navigator, remove `app.dylib` from the Flutter
folder. Delete this file from the `ios/Flutter` directory in your project.
3. Run a build to generate `ios/Flutter/App.framework`. From the command
line, run `flutter build ios`. If you have not configured app signing
in Xcode, an alternative method is to open the simulator, then run
`flutter run -d iP`.
4. In the Xcode project navigator, select the `Runner` project. In the
project settings that are displayed in the main view, ensure that the
`Runner` target is selected. You can verify this by exposing the
sidebar using the [| ] icon in the upper-left corner of the main
view.
5. Select the *General* tab in the project settings. Under the
*Embedded Binaries* section, click '+' to add `App.framework`. In the
sheet that drops down, click the *Add Other...* button. Navigate to
the `ios/Flutter` directory and select `App.framework`. Click *Open*.
In the sheet that drops down, select *Create folder references*, then
click *Finish*.
6. In the project settings, verify that `App.framework` has been added to the
*Embedded Binaries* and *Linked Frameworks and Libraries* lists.
7. In the Xcode project navigator, drag `App.framework` under the
Flutter folder.
8. In the Xcode project navigator, select `Flutter` then from the
*File* menu, select *Add Files to "Runner"...*. Navigate to the
`ios/Flutter` directory, select `AppFrameworkInfo.plist` and click
the *Add* button.
9. From the command line, in your project directory, run
`flutter build clean`, then `flutter run`.
At this point your project should be fully migrated.
* Do not attempt to merge non-fat frameworks in Xcode build
During the Xcode build, we strip code irrelevant to the target
architecture in frameworks used by the application. In the case of
non-fat executables, no stripping occurs, so the frameworks can be used
as-is. No merge & replace step is necessary.
* fixup! Do not attempt to merge non-fat frameworks in Xcode build
Required to handle Flutter SDK (and other) paths that include spaces.
Also includes general cleanup:
* Declare explicitly that we use /bin/bash, since we rely on its
features.
* Add -- where possible, to avoid interpreting files starting in - as
options.
* Suppress output of pushd/popd.
* Avoid stringifying arrays.
Support for thinning app frameworks to the target architecture was added
in 708909fc6b4a6f50d024c0d36843883284001219. This commit adds support
and error-checking for non-fat frameworks that are not of the target
architecture. In such cases, we now fail the build, and emit an error
message and the contents of lipo -info for the affected framework.
* Support thinning iOS frameworks to supported architectures
When building against frameworks that are distributed as
multi-architecture fat binaries, we want to strip the frameworks we
distribute down to only the architectures specified in $ARCHS.
This patch adds:
* The ability to specify commands to xcode_backend.sh (if none is
specified, run BuildApp for backward compatibility).
* A 'thin' command that invokes lipo to thin down the distributed as
described above.
* Add framework thinning step to iOS build
Invokes xcode_backend.sh thin on the build application.
* Limit architectures to arm64 in Xcode template
Flutter does not yet support armv7 iOS devices. Limit the $ARCHS build
variable to arm64 until then.
This removes direct file access from within flutter_tools
in favor of using `package:file` via a `FileSystem` that's
accessed via the `ApplicationContext`.
This lays the groundwork for us to be able to easily swap
out the underlying file system when running Flutter tools,
which will be used to provide a record/replay file system,
analogous to what we have for process invocations.
* convert pubGet to throw ToolExit on non-zero exit code
* convert commandValidator to throw ToolExit for non-zero exit code
* convert flutter commands to throw ToolExit for non-zero exit code
* use convenience method throwToolExit
* only show "if this problem persists" for unusual exceptions
This is causing issues when integratting Flutter into GN as the
generated depfile refers to snapshot as the target instead of the
bundle. We instead use a separate GN action to generate the
snapshot use the Flutter compiler to only assemble the bundle.
This change adds a top-level getBuildDirectory func and funcs for
android, aot, asset, ios build products.
Developers may now add a "build-dir" mapping to their
~/.flutter_settings (JSON format) config file. Output directory is
relative to the main flutter application directory.
This change also changes the default build directory for iOS builds to a
subdirectory of the configured build directory, 'build/ios' by default.
