Swift Package Manager Is Now the Default in Flutter

For years, Flutter iOS development meant Ruby, CocoaPods, and a Podfile you hoped never to debug. Starting with Flutter 3.44, Swift Package Manager (SwiftPM) replaces CocoaPods as the default dependency manager for iOS and macOS apps — and the Flutter CLI migrates your project automatically.

Source: What’s new in Flutter 3.44, The Flutter Blog, May 20, 2026.

What happens when you upgrade

When you build or run your app on Flutter 3.44+, the CLI updates your Xcode project to use SwiftPM, removing the need to manage Ruby or CocoaPods installations at all. For most projects, the migration is invisible: flutter run just works, and the Podfile era is over.

The escape hatches, if you need them:

• Temporary opt-out: set --enable-swift-package-manager: false in your pubspec.yaml. The Flutter team asks that you file a bug report with your Xcode project files if you hit a breaking issue — and notes the opt-out will eventually be removed.
• Per-plugin fallback: if your app depends on plugins that still require CocoaPods, the CLI prints a warning and temporarily falls back to CocoaPods for those specific dependencies.

What plugin authors must do

This is where the ecosystem transition actually lives. If you maintain an iOS or macOS plugin:

1. Add SwiftPM support to your package. pub.dev now awards additional scoring points to packages with SwiftPM support — a direct incentive to migrate.
2. If you migrated during the 2024 pilot, add FlutterFramework as a dependency in your Package.swift.
3. Assume CocoaPods support will be removed entirely. Package maintainers who don’t migrate will become the reason other apps are stuck on the fallback path.

For app teams, this converts a dependency-management problem into a vendor-management problem: your upgrade path is gated by your slowest plugin maintainer.

A new add-to-app command

Add-to-app integration got more flexible alongside the default switch. The new command:

flutter build swift-package

packages your Flutter app or add-to-app module as a Swift Package, ready for easy consumption from a native Xcode project. That’s a cleaner boundary than the older embedding flows — your native app depends on a Swift Package, which is a first-class Xcode concept, rather than a bespoke integration artifact.

Why this matters beyond convenience

Fewer toolchain moving parts. CocoaPods brings Ruby version management, pod install state, and a separate dependency resolver into every Flutter iOS build. SwiftPM ships with Xcode. Fewer moving parts means fewer CI failures that have nothing to do with your code.

Native alignment. The broader Apple ecosystem is standardizing on SwiftPM. Flutter adopting it as default means the way you depend on Flutter plugins matches the way the rest of your iOS project depends on everything else.

Better scoring hygiene. Tying pub.dev points to SwiftPM support gives the ecosystem a visible, gradual migration signal rather than a cliff.

Migration checklist

For an existing app moving to 3.44:

1. flutter upgrade
2. Commit your Xcode project changes after the first build (the CLI’s SwiftPM conversion touches project.pbxproj).
3. Search your plugins for CocoaPods warnings and file/update issues on the ones that lag.
4. Remove any leftover Podfile-specific CI steps (Ruby setup, pod repo update) once warnings clear.
5. If you use add-to-app, evaluate flutter build swift-package for your native integration.
6. Watch for the --enable-swift-package-manager opt-out being removed in future releases — treat it as a bridge, not a destination.

The bottom line

SwiftPM as Flutter’s iOS/macOS default is the kind of change that’s boring in the best way: no new APIs to learn, no UI differences, just one less foreign tool in your build pipeline. The work lands on plugin authors — and on app teams keeping their dependencies current. Both are worth doing now, while the CocoaPods fallback still exists as a safety net.