Repository navigation
Studio: build for macOS with Swift packages only - #394
Merged
Merged
Conversation
Every macOS plugin the studio uses is a Swift package, so CocoaPods was wrapping nothing but FlutterMacOS in a Pods_Runner framework. The Podfile differed from Flutter's template only by use_modular_headers!, which no pod has needed since the last plugin pod left, so the SDK called it non-standard and asked for a manual migration. pod deintegrate, then the Podfile, its lock, the Pods xcconfig includes and the Pods project in the workspace go. The deployment target (12.0) and the runner's runpath were already set in the Xcode project itself, so nothing had to move there. What it buys is not build time, which is the same within noise, but a first run that no longer needs CocoaPods: with the Podfile present, `flutter build macos` ran pod install on every fresh working copy and stopped at "CocoaPods not installed" on a machine without it. Swift Package Manager is on by default on every Flutter the package supports (stable since 3.44, floor 3.47), so nothing needs to be set. A user who turned it off globally gets the SDK's own fallback: it writes a template Podfile into the working copy and builds with CocoaPods, as every user did before.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The studio's macOS project drops CocoaPods. Every macOS plugin it uses is a Swift package, so the Podfile was wrapping nothing but FlutterMacOS in a
Pods_Runnerframework. It differed from Flutter's template only byuse_modular_headers!, a 2022 leftover that no pod has needed since the last plugin pod left. That is why the SDK called it non-standard and asked for a manual migration.The change
pod deintegrateinapp/macos, then delete the Podfile and its lock, thePods-Runnerxcconfig includes and the Pods project inRunner.xcworkspace. The workspace now matches the SDK's own template byte for byte. The diff is deletions only.Nothing had to move into the Xcode project. The Podfile's
platform :osx, '12.0'only ever applied to the Pods targets, and the project already setsMACOSX_DEPLOYMENT_TARGET = 12.0. The runner already has@executable_path/../Frameworksin its runpath. Nothing reads theCOCOAPODS=1define.What it buys: a first run that needs no CocoaPods
The launcher builds the studio in a fresh working copy on a user's first run (
DesktopGui.build). With the Podfile present, that build ranpod install, and on a machine without CocoaPods it stopped:flutter build macos --releasePATHtool/publish/install_check.dart --guialso passes locally with no CocoaPods onPATHand an empty flutter config. That is the hosted first-run path: pack, unpack, resolve, build the CLI, build the studio. CI never saw the failure because GitHub's macOS runners ship CocoaPods.Build time: the same within noise
These were clean builds (
flutter clean,Pods/removed as in a fresh copy), alternating the two trees to cancel out load drift. Load average on the machine was 13–34.* The log is line for line the same as the 56 s run, so the extra time was other work on the machine.
pod installitself took 0.42–0.47 s, because the only pod was FlutterMacOS. The SDK's "improve the project's build time" is about one second here.The Swift Package Manager setting
enable-swift-package-manager(Not set) uses Swift packages and needs no Podfile. Tested with an empty flutter config dir.enable-swift-package-manager: falseset globally, the SDK writes a template Podfile into the working copy, re-integrates Pods, runspod installand builds, so the plugins become pod frameworks. That is where every user was before this change. They need CocoaPods, and anyone who opted out of SwiftPM has it.FlutterFeaturesConfigthe environment variable ranks below the global config (pubspec ?? global ?? env ?? channel default), even though a comment influtter_features.dartsays the opposite. Measured: a global opt-out plusFLUTTER_SWIFT_PACKAGE_MANAGER=truestill ranpod install. The only override isflutter: config: enable-swift-package-manager: trueinapp/pubspec.yaml, which does win over the opt-out (tested). It is left out: it would override a choice the user made on purpose, to spare a case that already builds.Checked on the running studio
url_launcher:canLaunchUrlround trip,true.package_info_plus: platform channel round trip,dev.flutterware.studio 0.6.0.file_selector: Save the screenshot as PNG… presented its panel. There was no channel error, and the call stayed pending on it.webview_flutter: this branch cherry-picked onto the Worlds mail-view work. A clean release build pullswebview_flutter_wkwebviewin as a Swift package with no Podfile. In the running studio, Pickup order → Mia orders a flat white → Mail → Read it → Page, the live WKWebView held the rendered mail. Its text was read back from WebKit.