This PR adds initial support for Swift Package Manager (SPM). Users must opt in. Only compatible with Xcode 15+.
Fixes https://github.com/flutter/flutter/issues/146369.
## Included Features
This PR includes the following features:
* Enabling SPM via config
`flutter config --enable-swift-package-manager`
* Disabling SPM via config (will disable for all projects)
`flutter config --no-enable-swift-package-manager`
* Disabling SPM via pubspec.yaml (will disable for the specific project)
```
flutter:
disable-swift-package-manager: true
```
* Migrating existing apps to add SPM integration if using a Flutter plugin with a Package.swift
* Generates a Swift Package (named `FlutterGeneratedPluginSwiftPackage`) that handles Flutter SPM-compatible plugin dependencies. Generated package is added to the Xcode project.
* Error parsing of common errors that may occur due to using CocoaPods and Swift Package Manager together
* Tool will print warnings when using all Swift Package plugins and encourage you to remove CocoaPods
This PR also converts `integration_test` and `integration_test_macos` plugins to be both Swift Packages and CocoaPod Pods.
## How it Works
The Flutter CLI will generate a Swift Package called `FlutterGeneratedPluginSwiftPackage`, which will have local dependencies on all Swift Package compatible Flutter plugins.
The `FlutterGeneratedPluginSwiftPackage` package will be added to the Xcode project via altering of the `project.pbxproj`.
In addition, a "Pre-action" script will be added via altering of the `Runner.xcscheme`. This script will invoke the flutter tool to copy the Flutter/FlutterMacOS framework to the `BUILT_PRODUCTS_DIR` directory before the build starts. This is needed because plugins need to be linked to the Flutter framework and fortunately Swift Package Manager automatically uses `BUILT_PRODUCTS_DIR` as a framework search path.
CocoaPods will continue to run and be used to support non-Swift Package compatible Flutter plugins.
## Not Included Features
It does not include the following (will be added in future PRs):
* Create plugin template
* Create app template
* Add-to-App integration
Changing the web renderer doesn't directly modify the environment's dart defines, and so doesn't do a full build invalidation. We need to include the web renderer in the build key for the compiler configuration. This information is used directly by the web targets to modify the dart defines that are passed into the compiler, so we need to rebuild if this information changes.
When performing artifact lookups for `Artifact.genSnapshot` for macOS desktop builds, a `TargetPlatform` is used to determine the name of the tool, typically `gen_snapshot_$TARGET_ARCH`. Formerly, this tool was always named `gen_snapshot`.
The astute reader may ask "but Chris, didn't we support TWO target architectures on iOS and therefore need TWO `gen_snapshot` binaries?" Yes, we did support both armv7 and arm64 target architectures on iOS. But no, we didn't initially have two `gen_snapshot` binaries. We did *build* two `gen_snapshots`:
* A 32-bit x86 binary that emitted armv7 AOT code
* A 64-bit x64 binary that emitted arm64 AOT code
At the time, the bitness of the `gen_snapshot` tool needed to match the bitness of the target architecture, and to avoid having to do a lot of work plumbing through suffixed `gen_snapshot` names, the author of that work (who, as evidenced by this patch, is still paying for his code crimes) elected to "cleverly" lipo the two together into a single multi-architecture macOS binary still named `gen_snapshot`. See: https://github.com/flutter/engine/pull/4948
This was later remediated over the course of several patches, including:
* https://github.com/flutter/engine/pull/10430
* https://github.com/flutter/engine/pull/22818
* https://github.com/flutter/flutter/pull/37445
However, there were still cases (notably `--local-engine` workflows in the tool) where we weren't computing the target platform and thus referenced the generic `gen_snapshot` tool.
See: https://github.com/flutter/flutter/issues/38933
Fixed in: https://github.com/flutter/engine/pull/28345
The test removed in this PR, which ensured that null `SnapshotType.platform` was supported was introduced in https://github.com/flutter/flutter/pull/11924 as a followup to https://github.com/flutter/flutter/pull/11820 when the snapshotting logic was originally extracted to the `GenSnapshot` class, and most invocations still passed a null target platform.
Since there are no longer any cases where `TargetPlatform` isn't passed when looking up `Artifact.genSnapshot`, we can safely make the platform non-nullable and remove the test.
This is pre-factoring towards the removal of the generic `gen_snapshot` artifact from the macOS host binaries (which are currently unused since we never pass a null `TargetPlatform`), which is pre-factoring towards the goal of building `gen_snapshot` binaries with an arm64 host architecture, and eliminate the need to use Rosetta during iOS and macOS Flutter builds.
Part of: https://github.com/flutter/flutter/issues/101138
Umbrella issue: https://github.com/flutter/flutter/issues/103386
Umbrella issue: https://github.com/flutter/flutter/issues/69157
No new tests since the behaviour is enforced by the compiler.
This tweaks the Flutter doctor messages for CocoaPods.
This also switches the "unknown version" error to link to the update instructions instead of the installation instructions; the user has already installed CocoaPods in this scenario.
Example error before:
```
â CocoaPods not installed.
CocoaPods is used to retrieve the iOS and macOS platform side's plugin code that responds to your plugin usage on the Dart side.
Without CocoaPods, plugins will not work on iOS or macOS.
For more info, see https://flutter.dev/platform-plugins
To install see https://guides.cocoapods.org/using/getting-started.html#installation for instructions.
```
Example error after:
```
â CocoaPods not installed.
CocoaPods is a package manager for iOS or macOS platform code.
Without CocoaPods, plugins will not work on iOS or macOS.
For more info, see https://flutter.dev/platform-plugins
For installation instructions, see https://guides.cocoapods.org/using/getting-started.html#installation
```
In a ProxiedDevicePortForwarder, there might be a race condition where the local socket has been disconnected, but the remote end was still sending new data. In this case, avoid forwarding new data to the socket.
The interface for `ArgResults` from `package:args` has added new fields. Change the implementations of these in the conductor to extend `Fake` so that these aren't analyzer errors.
This broke the pub roll here: https://github.com/flutter/flutter/pull/146642#issuecomment-2050169629
This adds support for adding the `--wasm` flag to `flutter run` and `flutter drive`
* Emits errors if you attempt to use the skwasm renderer without the `--wasm` flag
* Emits errors if you try to use `--wasm` when not using a web device
* Uses the skwasm renderer by default if you pass `--wasm` and no `--web-renderer`
It looks like the formatter was updated.
We have a test running on the FFIgen repo that checks that rerunning the generated bindings with FFIgen generates identical bindings.
Closes:
* https://github.com/dart-lang/native/issues/1072
Convert `ProjectMigration.run()` and `ProjectMigrator.migrate()` to be async.
Needed for Swift Package Manager migration, which requires some async processes: https://github.com/flutter/flutter/pull/146256
Also move the vm service discovery logic into platform-specific implementation of `Device`s. This is to avoid having platform-specific code in attach.dart.
Xcode 15 will be required for iOS App Store submission
> Please note that as of April 2024 all iOS and iPadOS apps submitted to the App Store must be built with a minimum of Xcode 15 and the iOS 17 SDK.
https://developer.apple.com/ios/submit/
And will also be required for Swift Package Manager support https://github.com/flutter/flutter/pull/146256.
We could swap to "required" but macOS developers don't technically need to upgrade. We can let the Store itself enforce its policies. And we can swap to Xcode 15 "required" when SPM adoption is further along.
Part of https://github.com/flutter/flutter/issues/144582
Part of #137040 and #80374
`possibleResolutions` and `possibleResolutions` used a key containing the platform and the plugin name via `getResolutionKey`. The global list is not necessary and also confusing. It can be avoided by handling the resolution of plugins per platform. This helps to have a more self-contained plugin resolution. This also is necessary to reuse the plugin resolution logic (per platform) for #137040.
This PR is to update material_color_utilities package version to the latest. `material_color_utilities/scheme/scheme_fruit_salad.dart` and `material_color_utilities/scheme/scheme_rainbow.dart` are exported after version 0.9.0.
Once this PR is merged, we don't need to explicitly import these two files like the change in PR #144805, which breaks some dependencies in `Google testing`.
This PR is a follow-up of a previous PR of mine:
https://github.com/flutter/flutter/pull/141417. It was unfinished, i.e.
I only implemented it and used it in `examples/hello_world`. No "flutter
create" templates were modified.
This change is theoretically breaking, but in practice, I am pretty sure
nobody uses this. It was not accounced anywhere, the only app using it
is `examples/hello_world`. I did not do that (that=update docs and
templates) because I wanted a solution that is idiomatic in both Gradle
and Kotlin, and only now I found time to do this.
### Without this change
```groovy
defaultConfig {
applicationId = "io.flutter.examples.hello_world"
minSdk = flutter.minSdkVersion
targetSdk = flutter.targetSdkVersion
versionCode = flutter.versionCode()
versionName = flutter.versionName()
}
```
### With this change
```groovy
defaultConfig {
applicationId = "io.flutter.examples.hello_world"
minSdk = flutter.minSdkVersion
targetSdk = flutter.targetSdkVersion
versionCode = flutter.versionCode
versionName = flutter.versionName
}
```
Idiomatic getter - yay! It's consistent between assignment of all four
props.
### Issue
fixes https://github.com/flutter/flutter/issues/146067
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
---------
Co-authored-by: Reid Baker <reidbaker@google.com>
Fixes https://github.com/flutter/flutter/issues/144454
For reference, after formatting it looks like:
```
ââ Flutter Fix âââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
â [!] Your project requires a newer version of the Kotlin Gradle plugin. â
â Find the latest version on https://kotlinlang.org/docs/releases.html#release-details, then update the â
â version number of the plugin with id "org.jetbrains.kotlin.android" in the plugins block of â
â /Users/mackall/development/BugTesting/ELIMINATEME/blah/android/settings.gradle. â
â â
â Alternatively (if your project was created before Flutter 3.19), update â
â /Users/mackall/development/BugTesting/ELIMINATEME/blah/android/build.gradle â
â ext.kotlin_version = '<latest-version>' â
ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
```
In service of https://github.com/flutter/flutter/issues/143348
This PR makes hot reloads reflect changes to transformer configurations under the `assets` section in pubspec.yaml.
This PR is optimized for ease of implementation, and should not be merged as-is. If it is merged as-is, seriously consider creating a tech debt issue and assigning it to someone to make sure it gets resolved.
There are two issues in the previous implementation:
1. `_populateDevices` will return the devices from `deviceNotifier` if it had been initialized, assuming that once it's initialized, it has been properly populated. That assumption is not true because calling getters like `onAdded` would initialize `deviceNotifier` without populating it.
2. `deviceNotifier` instance might be replaced in some cases, causing `onAdded` subscribers to lose any future updates.
To fix (1), this commit added the `isPopulated` field in `deviceNotifier` as a more accurate flag to determine if we need to populate it.
To fix (2), this commit made `deviceNotifier` a final member in `PolingDeviceDiscovery`.
