What to do about SwiftPM and Gradle warnings when building Flutter

For a few weeks now, building almost any Flutter project leaves a trail of warnings in the console. On iOS they mention Swift Package Manager and CocoaPods. On Android, Gradle, the Android Gradle Plugin and the Kotlin plugin. The app still builds and ships, so it's easy to leave them for another day.

What's going on is that the tools Flutter relies on to manage native dependencies are changing on both platforms at the same time. Nothing is wrong with your project. Today they're warnings, and as new versions come out they'll gradually become errors. Below we go through what's changing on each platform, what needs touching and where it tends to get complicated.

Since Flutter 3.44, Swift Package Manager (SwiftPM) is on by default. When you upgrade Flutter and run the app, the Xcode project migrates itself and starts pulling the Swift packages your plugins depend on.

The trouble is plugins that don't support SwiftPM yet. For those, Flutter prints a warning with the list and keeps using CocoaPods. That's where a good chunk of what you're seeing in the console comes from. It works for now, but it has an end date. The CocoaPods registry becomes read-only on 2 December 2026, and after that no pod will get new versions. Firebase, which ships in a huge number of apps, stops publishing to CocoaPods this October. And the Flutter docs already say that turning SwiftPM off won't be allowed in the future.

The sensible order is to upgrade Flutter, build, check which plugins show up in the warning and, for each one, update it, ask the maintainer for support or find an alternative. If you turned SwiftPM off at some point, this turns it back on:

flutter config --enable-swift-package-manager

If the migration breaks the build and you need to get a release out, you can turn it off for that project only in pubspec.yaml. It buys you a few days, but it's worth removing as soon as the failing plugin is sorted:

flutter:
  config:
    enable-swift-package-manager: false

Once every plugin supports SwiftPM, you can remove CocoaPods from the project. If you'd edited the Podfile by hand to add other dependencies, those changes have to be redone separately.

cd ios
pod deintegrate
cd ..
# delete ios/Podfile, ios/Podfile.lock, ios/Pods/ and ios/.symlinks/
flutter clean
flutter pub get
flutter run

Then open ios/Flutter/Debug.xcconfig and Release.xcconfig and remove any #include pointing at Pods.

One error comes up a lot during this migration. Some SwiftPM packages require a higher minimum iOS version than the project, and Xcode complains that the package needs, say, iOS 14 while the target supports iOS 12. The fix is to raise the target's Minimum Deployments in Xcode and regenerate the config with flutter build ios --config-only. Talk it through with product first, because raising the minimum leaves out people on older devices.

On Android the change comes from Android Gradle Plugin 9. AGP 9 ships with Kotlin built in and no longer supports applying the Kotlin Gradle Plugin (KGP) separately, which is exactly how Flutter projects have done it until now.

Flutter 3.44 already supports AGP 9, but with built-in Kotlin turned off. To do that, Flutter's migrator adds these two lines to gradle.properties:

android.builtInKotlin=false
android.newDsl=false

They're a bridge to keep everything building while the ecosystem catches up. Turning built-in Kotlin on requires Flutter 3.47 or later and AGP 9. In android/app/build.gradle.kts, the migration means removing the Kotlin plugin and the kotlinOptions block, and declaring the JVM target in a kotlin block:

plugins {
    id("com.android.application")
    // id("kotlin-android")  ← remove
    id("dev.flutter.flutter-gradle-plugin")
}

android {
    // kotlinOptions { jvmTarget = JavaVersion.VERSION_17.toString() }  ← remove
}

kotlin {
    compilerOptions {
        jvmTarget = org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_17
    }
}

And in gradle.properties you flip the flag:

android.builtInKotlin=true

If any of your plugins hasn't been migrated, the build fails once the flag is on. Flutter recommends reporting it to the plugin's maintainer and keeping android.builtInKotlin=false until there's a new version. In add-to-app projects, where Flutter lives inside a native Android app, the host project isn't migrated automatically and the gradle.properties lines have to be added by hand.

Migrating your own code is usually the easy bit. It's a handful of changes to config files that, with the docs open, take an afternoon. What actually blocks you is third-party packages that haven't been updated, and in an app that's a few years old it's common to find one that hasn't been maintained in a while.

So before touching anything, it pays to list your dependencies and check one by one whether they support SwiftPM and AGP 9. That list tells you whether the migration is routine or whether you'll need to replace a plugin, which changes the planning quite a bit. If the app is also stuck on an old Flutter version, the job looks more like migrate a legacy Flutter project, and it's better to plan it that way from the start.

As for when, we wouldn't wait. Something similar happened with Android's 16 KB memory page requirement. Teams that prepared early dealt with it calmly, and those who waited for Google Play to enforce it had to rush. The same could happen here the day a new Xcode version, a Firebase update or a store requirement forces the migration.

If you have a Flutter app that's already showing these warnings and you're not sure how much work is behind them, we can take a look. We go through the dependencies, tell you which plugins are ready and which aren't, and what it takes to get the project ready for SwiftPM and AGP 9. It's part of our maintenance and evolution solution, and we also do it as a one-off job.