Flutter CocoaPods to Swift Package Manager migration

Flutter CocoaPods to Swift Package Manager Migration Guide

A practical guide to migrating an existing Flutter iOS application from CocoaPods to Swift Package Manager.

12 min read

A practical guide to migrating an existing Flutter iOS application from CocoaPods to Swift Package Manager.

#Why Is This Migration Necessary?

For many years, CocoaPods has been the default dependency manager for iOS applications. Flutter also adopted CocoaPods as the standard mechanism for integrating native iOS dependencies.

That workflow is beginning to change.

The CocoaPods team has announced that the CocoaPods trunk will become read-only on December 2, 2026. Existing Pods will continue to work, but developers will no longer be able to publish new specifications to the central repository.

Firebase has also announced that new Firebase releases will no longer be published through CocoaPods after October 2026.

Existing Firebase integrations will continue to work, but future Firebase updates will require another installation method.

This does not mean that existing Flutter applications will suddenly stop working.

However, Flutter has already started moving toward Swift Package Manager, and this is a good time to begin planning the migration.

#What Is Swift Package Manager?

Swift Package Manager, commonly called SPM, is Apple's native dependency manager for Swift and Apple platform development.

Unlike CocoaPods, which depends on Ruby tooling and a separate dependency resolution process, Swift Package Manager is integrated directly into Xcode.

Packages can be added, resolved, and updated directly from Xcode without running pod install.

#Which Flutter Version Should You Use for Migration?

Before starting the migration, we evaluated multiple Flutter versions and found that Flutter 3.44.0 provides the best migration experience.

We made two important observations while evaluating the migration.

#Flutter 3.38.4 Still Depends on CocoaPods

In Flutter 3.38.4, Flutter dependencies are still resolved through CocoaPods.

Downstream dependencies also continue to follow the existing Podfile workflow.

Attempting to migrate an application while remaining on Flutter 3.38.4 would require manually translating Flutter's Pod-based integration into a corresponding Swift Package Manager configuration.

The migration effort would not stop with Flutter itself.

Every dependency that still depends on CocoaPods would also need to be evaluated and migrated individually.

#Flutter 3.44.0 Introduces Swift Package Manager by Default

Starting with Flutter 3.44.0, Swift Package Manager becomes the default dependency manager for Apple platform dependencies.

Flutter also continues to support CocoaPods as a fallback for dependencies that have not yet adopted Swift Package Manager.

Because of this change, we found that upgrading to Flutter 3.44.0 or later is the most practical and sustainable migration strategy. Flutter's Swift Package Manager guide for app developers is the reference point for this migration path.

By the end of this article, we are going to learn:

Let the coding begin..!

#1) Upgrade Flutter to Version 3.44.0 or Later

The first step is to verify the current Flutter version.

bash
flutter --version

If your project is still using an older version, upgrade Flutter.

bash
flutter upgrade

Verify the version again.

bash
flutter --version

If Swift Package Manager was previously disabled, enable it explicitly.

bash
flutter config --enable-swift-package-manager

A few things to notice:

Before continuing, make sure that:

#2) Review Existing CocoaPods Dependencies

Before deleting any CocoaPods files, review your current dependency configuration.

Inspect:

text
pubspec.yaml
ios/Podfile
ios/Podfile.lock

Separate dependencies into two categories.

#Flutter-managed dependencies

Dependencies introduced through Flutter plugins.

#Native iOS dependencies

Dependencies declared directly inside the Podfile.

Also inspect your Podfile for custom scripts.

ruby
post_install do |installer|
  ...
end

Search your project for references to:

text
Pods/
Pods-Runner
${PODS_ROOT}
${PODS_CONFIGURATION_BUILD_DIR}

A few things to notice:

#3) Let Flutter Perform the Swift Package Manager Migration

This step is different from a traditional native iOS migration.

Do not start with:

bash
pod deintegrate

Instead, allow Flutter to perform the migration automatically.

Run:

bash
flutter run

Flutter should automatically create:

text
FlutterGeneratedPluginSwiftPackage

Verify:

Flutter documents this automatic migration flow in the Swift Package Manager guide for app developers.

#4) Migrate Remaining Dependencies

After Flutter completes the migration, review any dependencies that still rely on CocoaPods.

Some projects may already be fully migrated.

Others may still depend on:

For dependencies that were manually added to the Podfile, verify whether the vendor provides official Swift Package Manager support.

#What if a Third-Party Library Does Not Support Swift Package Manager?

#Option 1: Keep CocoaPods Temporarily

Flutter continues to support CocoaPods as a fallback.

If the dependency is actively maintained, keeping CocoaPods temporarily is usually the safest option.

#Option 2: Upgrade the Dependency

Check whether a newer version of the library already supports Swift Package Manager.

Many libraries have added Package.swift support in recent releases. Upgrading the dependency may be enough to complete the migration.

#Option 3: Replace the Dependency

If the library is no longer maintained, consider replacing it with an alternative.

#Option 4: Integrate the Framework Manually

Some vendors distribute an XCFramework instead of providing a Swift package. Apple supports distributing binary frameworks as Swift packages for this case.

#Option 5: Self-host the Library or Convert It Into a Private Swift Package

If you are working with internal libraries, private frameworks, or unmaintained dependencies, another option is to convert them into private Swift packages.

The migration process usually involves:

  1. Creating a Package.swift manifest.
  2. Defining package products.
  3. Organizing the source files.
  4. Hosting the package in a private Git repository.
  5. Adding the package through Xcode.

The Swift Package Manager documentation is useful when you need to understand package layout and manifest behavior in more detail.

The goal is not to remove CocoaPods immediately.

#5) Remove CocoaPods and Verify the Migration

Once every dependency has been migrated successfully, CocoaPods can be removed from the project.

Before removing CocoaPods, create a new commit or branch.

Remove CocoaPods integration.

bash
pod deintegrate

Remove obsolete CocoaPods artifacts.

text
Podfile
Podfile.lock
Pods/

Verify the migration.

bash
flutter clean
flutter pub get
flutter run
flutter build ios

#6) Check the Minimum iOS Deployment Target

Some Swift packages require a newer iOS version than the one currently configured in the Flutter project.

If a package fails to resolve after migration, verify the package's minimum iOS requirement before increasing the deployment target.

If you decide to change the deployment target, regenerate Flutter's iOS configuration. Flutter calls this out in the Swift Package Manager guide for app developers.

bash
flutter build ios --config-only

#7) Add-to-App Projects Require a Different Migration Strategy

If Flutter is embedded inside an existing native iOS application, the migration process is different.

Flutter 3.44 introduces a Swift Package Manager integration through the generated FlutterNativeIntegration package.

Flutter can generate the package with:

bash
flutter build swift-package --platform ios

If you're using an Add-to-App architecture, follow Flutter's iOS Add-to-App setup documentation.

#Final Migration Checklist

#Preparation

#Flutter Migration

#Dependency Migration

#CocoaPods Removal

#Wrapup

Migrating from CocoaPods to Swift Package Manager in Flutter becomes much easier with Flutter 3.44 because Flutter performs most of the migration automatically.

Our recommendation is to upgrade Flutter first, allow Flutter to perform the migration, review the remaining dependencies, and remove CocoaPods only after the application has been fully verified.

Let's connect and you can find me on Twitter.