Swift Package Manager is the default now — and CocoaPods has a deadline
Most Flutter developers have already migrated to Swift Package Manager without noticing. It has been enabled by default since Flutter 3.44, and the tooling adds the integration to your Xcode project the first time you build after upgrading. The reason to pay attention now is a date: the CocoaPods registry becomes read-only on December 2, 2026. After that, opting out stops being a supported escape hatch.
Flutter 3.47 reports that 92 of the top 100 iOS plugins have migrated to Swift Package Manager. The long tail is what will bite you, not the head of the distribution.
What actually changes in your project
When SwiftPM is enabled and you build, Flutter modifies your Xcode project in three ways:
- Adds
FlutterGeneratedPluginSwiftPackageas a package dependency of theRunnertarget. - Adds a Run Prepare Flutter Framework Script pre-action to your build scheme.
- Resolves and downloads the Swift packages your Flutter plugins depend on.
That generated package lives at ios/Flutter/ephemeral/Packages/FlutterGeneratedPluginSwiftPackage. The word ephemeral is doing real work there — it is regenerated, not hand-edited, and it does not belong in version control.
Crucially, CocoaPods does not disappear. Flutter falls back to CocoaPods automatically for any dependency that does not yet support SwiftPM, so a mixed project is the normal state during the transition, not a misconfiguration.
Turning it on, off, and per-project
If a previous version of your project disabled it, re-enable globally:
flutter config --enable-swift-package-managerTo disable globally:
flutter config --no-enable-swift-package-managerTo disable for one project only, in pubspec.yaml:
flutter:
config:
enable-swift-package-manager: falseThe per-project switch is the useful one. If exactly one app in your organisation depends on an unmigrated internal plugin, pin that app and leave everything else on the default.
Removing the integration entirely
If you need a clean rollback — for a bisect, or because a build broke and you want a known-good baseline:
- Turn SwiftPM off using one of the switches above.
- Run
flutter clean. - Open your Xcode workspace.
- Remove
FlutterGeneratedPluginSwiftPackagefrom Package Dependencies. - Remove it from Frameworks, Libraries, and Embedded Content.
- Delete the Run Prepare Flutter Framework Script pre-action.
Steps 3 through 6 are the ones people forget, and a half-removed integration produces confusing link errors.
When automatic migration fails
The tooling occasionally cannot patch an Xcode project — heavily customised schemes and hand-edited project.pbxproj files are the usual culprits. The manual path:
Add the package dependency. Open ios/Runner.xcworkspace, go to Package Dependencies, click add, choose Add Local…, and select ios/Flutter/ephemeral/Packages/FlutterGeneratedPluginSwiftPackage. Confirm it is attached to the Runner target and appears under Frameworks, Libraries, and Embedded Content.
Add the pre-action. Go to Product → Scheme → Edit Scheme, expand Build, click Pre-actions, add a run script action titled Run Prepare Flutter Framework Script, set Provide build settings from to Runner, and use:
"$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" prepareThen run the app and confirm the pre-action executes. If automatic migration failed, file a bug with your project.pbxproj and .xcscheme attached — that is the data the Flutter team needs and rarely gets.
The deployment target trap
This is the most common real-world failure, and it is not obvious from the error message. A SwiftPM plugin can declare a higher minimum OS version than your app. When it does, the build fails until you raise Minimum Deployments in Xcode and regenerate the config:
flutter build ios --config-only
flutter build macos --config-onlyFlutter 3.47 already raised the floors — iOS 13 → 15 and macOS 10.15 → 12 — so if you are upgrading from an older SDK you may clear this hurdle by accident.
| Concern | CocoaPods | Swift Package Manager |
|---|---|---|
| Dependency manifest | Podfile / Podfile.lock | Generated Package.swift |
| Toolchain | Ruby gem, installed separately | Built into Xcode |
| Integration point | .xcworkspace from pod install | Package dependency + scheme pre-action |
| Registry status | Read-only from Dec 2, 2026 | Actively developed |
| Flutter default | Fallback only | Default since 3.44 |
Your migration checklist
- Confirm you are on the default. Run
flutter configand check thatenable-swift-package-manageris not disabled anywhere, includingpubspec.yaml. - Build a clean iOS and macOS target and watch for the pre-action running.
- Audit your plugin list. For each iOS plugin, check whether its repository ships a
Package.swift. The ones that do not are your December risk. - Migrate your own plugins first — internal plugins are the ones nobody else will fix for you. Follow the plugin-author guide and ship a
Package.swiftalongside the existing podspec. - File or upvote issues on the unmigrated third-party plugins you depend on, now rather than in November.
- Raise deployment targets to iOS 15 / macOS 12 and regenerate with
--config-only. - Do not add
ios/Flutter/ephemeral/to version control.
The bottom line
SwiftPM is not a feature you need to adopt — you almost certainly already have. What you need to do is inventory the plugins that have not, because December 2, 2026 turns “we’ll handle it later” into a build break. The head of the ecosystem is done: 92 of the top 100 plugins have moved. Spend an hour on the tail — your internal plugins and the three obscure packages nobody has looked at since 2024 — and this transition costs you nothing at all.
Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.