[various] iOS/macOS example project automigrations#11227
[various] iOS/macOS example project automigrations#11227auto-submit[bot] merged 6 commits intoflutter:mainfrom
Conversation
|
@vashworth I originally made this as a trial to see if there would be any surprises in CI, but since it all passed I vote we land it if everything looks good to you. |
There was a problem hiding this comment.
Code Review
This pull request automates the migration of iOS and macOS example projects across various packages. The changes primarily involve updating Xcode project settings, such as deployment targets and Xcode version checks. It also migrates projects from CocoaPods to Swift Package Manager, which involves removing CocoaPods-related build phases and adding SwiftPM package references. One notable issue was found regarding the relativePath for SwiftPM packages in macOS projects, which appears to be inconsistent with the fix described in the linked issue.
| /* Begin XCLocalSwiftPackageReference section */ | ||
| 781AD8BC2B33823900A9FFBB /* XCLocalSwiftPackageReference "FlutterGeneratedPluginSwiftPackage" */ = { | ||
| isa = XCLocalSwiftPackageReference; | ||
| relativePath = Flutter/ephemeral/Packages/FlutterGeneratedPluginSwiftPackage; |
There was a problem hiding this comment.
The PR description mentions that macOS projects have been manually fixed to address the issue with relativePath for SwiftPM packages. However, this relativePath appears to be incorrect for macOS.
According to the linked issue comment, for macOS projects the correct path should be ephemeral/Packages/FlutterGeneratedPluginSwiftPackage.
This seems to apply to several other macOS projects in this PR as well. Could you please double-check this?
relativePath = ephemeral/Packages/FlutterGeneratedPluginSwiftPackage;
There was a problem hiding this comment.
For posterity: this is the project-level entry, which appears to be project-dir relative, not the files list entry under the Flutter group, which is explicitly marked as group-relative.
tarrinneal
left a comment
There was a problem hiding this comment.
I definitely read every change in this pr and after careful deliberation have decided that I think it is good to land.
flutter/packages@ecace66...02f231f 2026-03-12 [email protected] [various] iOS/macOS example project automigrations (flutter/packages#11227) 2026-03-11 [email protected] [webview_flutter_wkwebview] Add support for javaScriptCanOpenWindowsAutomatically (flutter/packages#10608) 2026-03-11 [email protected] [url_launcher] Disable flaky test (flutter/packages#11229) 2026-03-11 [email protected] Roll Flutter from 195ae7b to 3f400d7 (13 revisions) (flutter/packages#11228) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-packages-flutter-autoroll Please CC [email protected] on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
Builds all example apps on iOS and macOS using the current
master(cccee58dbb09922259bf64cbe819b2e6c5949ef4), and checks in the results. The main goal of this PR is to pick up the auto-migration to the new Swift Package Manager integration that includes plugin dependencies as local SwiftPM project entries (for a much better development experience), but this picks up some other incidental changes as well in many projects:masterandstablecurrent have the same minimums, so this doesn't incorrectly raise an requirements for the examples.stablewithout SwiftPM enabled.LastUpgradeCheck, which should be harmless.macOS projects have been manually fixed to address the bug described here.
Fixes flutter/flutter#183474
Pre-Review Checklist
[shared_preferences]///).Footnotes
Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩2