Flutter's Big Shift: Why Swift Package Manager Is Replacing CocoaPods
Starting with Flutter 3.44, the framework is officially switching to Swift Package Manager (SwiftPM) as the default dependency manager for iOS and macOS apps. This change simplifies development by eliminating the need for Ruby and CocoaPods installations. CocoaPods has entered maintenance mode, with its registry becoming read-only by December 2, 2026. While existing projects will still build, new updates and plugins won't be added after that date. This guide answers key questions about the migration process for app developers and plugin authors.
What is changing in Flutter's dependency management for iOS/macOS?
Flutter is replacing CocoaPods with Swift Package Manager (SwiftPM) as the default dependency manager for iOS and macOS apps, starting with the stable release 3.44. This means you no longer need to manage Ruby installations or CocoaPods configurations to run your app. The Flutter CLI now automatically updates your Xcode project to use Swift Package Manager when you build or run your app. For projects that rely on plugins not yet migrated, Flutter will temporarily fall back to CocoaPods, but this fallback will be removed entirely after CocoaPods becomes read-only.
Why is Flutter moving away from CocoaPods?
CocoaPods is officially in maintenance mode, meaning no new features will be added and only critical bug fixes may be released. More importantly, its registry will become permanently read-only on December 2, 2026. After that date, no new versions of existing pods or entirely new pods can be published. Flutter needs a dependency manager that continues to receive updates and integrates seamlessly with the broader Swift ecosystem. SwiftPM is Apple's supported solution, offering better performance, native integration with Xcode, and long-term support. Migrating now ensures your apps keep receiving dependency updates and access to the latest Swift packages.
When will CocoaPods become read-only, and what does that mean?
The CocoaPods registry will become read-only on December 2, 2026. After this date, you cannot publish new pods or new versions of existing pods to the trunk. However, existing builds will continue to work because they reference already published podspecs. The key risk is that if a plugin you depend on is still only available via CocoaPods and hasn't migrated to SwiftPM, you will not receive any future updates or security patches for that plugin. Additionally, once CocoaPods support is fully removed from Flutter (expected after the read-only date), any plugins not migrated will break your build. That's why Flutter is encouraging all plugin authors to adopt SwiftPM as early as possible.
How does this migration affect app developers?
For most app developers, the migration is automatic. When you run or build your iOS or macOS app with Flutter 3.44+, the CLI updates your Xcode project to use SwiftPM. If some plugins haven't migrated yet, Flutter prints a warning listing exactly which dependencies are unsupported. It then temporarily falls back to CocoaPods for those plugins only. However, you should track which plugins need attention and either contact the maintainers or find alternatives. If a plugin that hasn't migrated causes a build failure, you can temporarily opt out of SwiftPM by adding enable-swift-package-manager: false under flutter: config: in your pubspec.yaml. But this is only a stopgap—please file a bug report with Flutter so they can improve the transition before CocoaPods is completely removed.
What should I do if a plugin hasn't migrated to SwiftPM?
First, check the warning message Flutter prints—it lists every plugin that still requires CocoaPods. Then you have two options: file an issue with the plugin's maintainer requesting SwiftPM support, or find an alternative package that already supports SwiftPM. Currently, 61% of the top 100 iOS plugins have migrated, so many alternatives exist. If the plugin is critical and the maintainer is unresponsive, you can temporarily disable SwiftPM for your entire project using the enable-swift-package-manager: false flag in pubspec.yaml. But remember that this is a temporary workaround—CocoaPods support will be removed entirely, so plan to migrate fully before December 2026.
What new requirement do plugin developers need to follow?
Plugin authors who maintain iOS or macOS plugins must add Swift Package Manager support if they haven't already. If you already migrated during the 2025 pilot, there's one new step: you must add FlutterFramework as a dependency in your Package.swift file. For first-time migration, create a Package.swift file and move your source files to match the standard Swift package structure. Packages without SwiftPM support now receive lower pub.dev scores, which can affect discoverability. Migration may involve restructuring your code, but the Flutter migration docs provide detailed steps. Encouraging adoption is critical so that app developers aren't stuck with a deprecated tool.
How can I temporarily disable SwiftPM if something breaks?
If SwiftPM causes a breaking issue in your project, you can opt out by editing your pubspec.yaml file. Locate the flutter section and add a config block with enable-swift-package-manager: false, like this:
flutter:
config:
enable-swift-package-manager: falseThis will revert to using CocoaPods for all dependencies. However, this is a temporary measure—CocoaPods will no longer be supported in future Flutter versions. If you need to use this workaround, please file a bug report on the Flutter GitHub repository. Include error details, a list of your plugins and versions, and copies of your Xcode project files. This helps the Flutter team resolve issues before CocoaPods support is completely removed.
What are the consequences for plugins that don't migrate to SwiftPM?
Starting with Flutter 3.44, plugins without SwiftPM support receive lower pub.dev scores, making them less visible in package searches. After the CocoaPods registry becomes read-only in December 2026, any plugin that hasn't migrated will eventually cause build failures for apps that depend on it, because Flutter will no longer include the CocoaPods fallback. Plugin maintainers risk losing users to alternatives that support SwiftPM. The Flutter team strongly encourages all plugin authors to migrate now to ensure their packages remain functional and discoverable in the ecosystem.