Skip to content
Blog

Saying Goodbye to CocoaPods: Swift Package Manager Is Now the Default in Flutter

Flutter 3.44 replaces CocoaPods with Swift Package Manager as the default for iOS and macOS. What changes, what migrates automatically, and what to do now.

Published on • October 18, 2026

AI Assistant

Starting with Flutter 3.44, Swift Package Manager (SwiftPM) replaces CocoaPods as the default dependency manager for iOS and macOS apps. If you’ve been meaning to plan this migration, stop planning: the Flutter CLI now does most of it for you. Here’s what actually changes when you upgrade, what still needs human attention, and how long the CocoaPods escape hatch stays open.

Why the switch

CocoaPods has been the default way Flutter resolved iOS and macOS plugin dependencies for a decade. SwiftPM is Apple’s own package manager, integrated into Xcode, and it’s been the standard for the broader Apple ecosystem for years. Flutter 3.41 had already encouraged plugin authors to adopt SwiftPM and shipped full UIScene lifecycle support; 3.44 completes the transition — SwiftPM is now the default, and CocoaPods support is on a path to being removed entirely.

The concrete benefits for app developers:

  • No Ruby toolchain. You no longer need a working Ruby/CocoaPods installation to build a Flutter iOS app.
  • Xcode-native dependency resolution. Packages resolve and build inside Xcode’s normal package workflow.
  • Faster design-system iteration. SwiftPM support feeds the broader modularization of the Flutter ecosystem (including the standalone Material and Cupertino packages in progress).

What happens automatically

The migration is handled by the Flutter CLI. When you build or run your app, the CLI updates your Xcode project to use SwiftPM — you don’t have to hand-edit project files. From the 3.44 release notes:

When you build or run your app, the CLI updates your Xcode project to use SwiftPM, removing the need to manage Ruby or CocoaPods installations!

Add-to-App got a new tool too: flutter build swift-package packages your Flutter app or add-to-app module as a Swift Package, so embedding it in an existing native iOS project is a standard package dependency instead of a bespoke integration.

flutter build swift-package

Check the add-to-app iOS project setup docs for the updated embedding flow.

What still needs your attention

Three things don’t migrate themselves.

1. Plugins that still require CocoaPods

If your dependency tree includes a plugin that hasn’t added SwiftPM support, the Flutter CLI prints a warning and temporarily falls back to CocoaPods for those dependencies. Your build keeps working, but this is a grace period, not a destination. The right fix is to open an issue or PR on the plugin repository asking for SwiftPM support — Flutter explicitly recommends this. As a signal of where the ecosystem is heading, packages with SwiftPM support now earn additional points in pub.dev scoring, so maintainers have a concrete incentive to migrate.

2. Your plugin packages (if you maintain them)

If you maintain an iOS or macOS plugin, adding SwiftPM support is now table stakes. The requirements: ship a Package.swift in your plugin, and if you migrated during the 2024 pilot, make sure FlutterFramework is listed as a dependency in that file. The full checklist lives in the SwiftPM docs for plugin authors.

3. The temporary opt-out

If SwiftPM genuinely breaks your project, you can disable it while you investigate:

# pubspec.yaml
flutter:
  enable-swift-package-manager: false

Use this as a stopgap and file a bug report on GitHub including your Xcode project files so the team can diagnose the issue. Flutter’s own guidance is explicit that this opt-out will eventually be removed — every release on the flag is borrowed time.

What the timeline looks like

Putting the pieces in order across recent releases:

  • Flutter 3.41 encouraged plugin adoption and shipped default UIScene lifecycle support, lining up with Apple’s requirements for upcoming iOS versions.
  • Flutter 3.44 flipped the default: SwiftPM for iOS and macOS, automatic CLI migration, CocoaPods fallback with a warning.
  • Beyond: CocoaPods support “will eventually be removed entirely” (3.44 release notes). No removal date has been published, but the direction is unambiguous — new work and new fixes flow to SwiftPM, and the fallback exists to protect stragglers, not to last forever.

Your migration checklist

For a typical app, this is the whole job:

  1. Upgrade to Flutter 3.44 or later (flutter upgrade).
  2. Build and run your app. The CLI migrates the Xcode project; watch for warnings about CocoaPods-dependent plugins.
  3. Deal with straggler plugins. For each warning, check for a SwiftPM-supporting version, file an upstream issue, or temporarily fork.
  4. Remove leftover CocoaPods artifacts once builds are clean — Podfile, Podfile.lock, and the Pods/ directory are no longer part of your project.
  5. Drop Ruby/CocoaPods from CI. Your iOS jobs no longer need pod install; if they still run it, delete that step.
  6. Keep the opt-out flag out of your repo. If you needed enable-swift-package-manager: false, treat removing it as a tracked task.
  7. If you ship a plugin, publish Package.swift — you get pub.dev scoring credit and you unblock every downstream app.

The CocoaPods era in Flutter was long and mostly painless, but it carried a Ruby toolchain and a dependency graph that Xcode didn’t natively understand. SwiftPM as the default removes both. The migration for most apps is literally: upgrade, run, and fix the warnings.

Sources

flutter ios swift-package-manager cocoapods