Qué hacer con los avisos de SwiftPM y Gradle al compilar Flutter

Desde hace unas semanas, compilar casi cualquier proyecto Flutter deja un rastro de avisos en la consola. En iOS hablan de Swift Package Manager y CocoaPods. En Android, de Gradle, del Android Gradle Plugin y del plugin de Kotlin. La app compila igual y se puede publicar, así que es fácil dejarlos para otro día.

Lo que pasa es que las herramientas que usa Flutter por debajo para gestionar las dependencias nativas están cambiando a la vez en las dos plataformas. Vuestro proyecto no tiene nada mal. Hoy son avisos y, a medida que salgan versiones nuevas, se irán convirtiendo en errores. Aquí explicamos qué cambia en cada plataforma, qué hay que tocar y dónde suele complicarse.

Desde Flutter 3.44, Swift Package Manager (SwiftPM) viene activado por defecto. Al actualizar Flutter y ejecutar la app, el proyecto de Xcode se migra solo y empieza a descargar los paquetes Swift de los que dependen vuestros plugins.

El lío está en los plugins que todavía no soportan SwiftPM. Para esos, Flutter muestra un aviso con la lista y sigue tirando de CocoaPods. De ahí sale buena parte de lo que veis en la consola. De momento funciona, pero tiene fecha. El registro de CocoaPods pasa a ser de solo lectura el 2 de diciembre de 2026 y a partir de entonces no habrá versiones nuevas de ningún pod. Firebase, que está en muchísimas apps, deja de publicar en CocoaPods este mes de octubre. Y la documentación de Flutter ya avisa de que desactivar SwiftPM dejará de estar permitido.

El orden razonable es actualizar Flutter, compilar, mirar qué plugins aparecen en el aviso y, para cada uno, actualizarlo, pedir soporte a quien lo mantiene o buscar una alternativa. Si en algún momento habíais desactivado SwiftPM, se vuelve a activar así:

flutter config --enable-swift-package-manager

Si la migración rompe el build y necesitáis sacar una versión, se puede desactivar solo en ese proyecto desde el pubspec.yaml. Sirve para salir del paso y ganar unos días, pero conviene quitarlo en cuanto se resuelva el plugin que falla:

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

Cuando todos los plugins soporten SwiftPM, ya se puede quitar CocoaPods del proyecto. Si habíais tocado el Podfile a mano para añadir otras dependencias, esos cambios hay que rehacerlos aparte.

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

Después conviene abrir ios/Flutter/Debug.xcconfig y Release.xcconfig y quitar cualquier #include que apunte a Pods.

Hay un error que sale bastante en esta migración. Algunos paquetes SwiftPM piden una versión mínima de iOS más alta que la del proyecto, y Xcode se queja de que el paquete requiere, por ejemplo, iOS 14 cuando el target soporta iOS 12. Se arregla subiendo el Minimum Deployments del target en Xcode y regenerando la configuración con flutter build ios --config-only. Antes de hacerlo vale la pena hablarlo con producto, porque subir el mínimo deja fuera a quien use dispositivos más antiguos.

En Android el cambio viene del Android Gradle Plugin 9. AGP 9 trae Kotlin integrado y deja de admitir que el plugin de Kotlin (KGP) se aplique por separado, que es justo como lo han hecho los proyectos Flutter hasta ahora.

Flutter 3.44 ya soporta AGP 9, pero con el Kotlin integrado desactivado. Para eso, el migrador de Flutter añade estas dos líneas a gradle.properties:

android.builtInKotlin=false
android.newDsl=false

Son un puente para que todo siga compilando mientras el ecosistema se pone al día. Para activar el Kotlin integrado hace falta Flutter 3.47 o superior y AGP 9. En android/app/build.gradle.kts, la migración consiste en quitar el plugin de Kotlin y el bloque kotlinOptions, y declarar el target de JVM en un bloque kotlin:

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

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

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

Y en gradle.properties se cambia el flag:

android.builtInKotlin=true

Si alguno de los plugins que usáis no está migrado, el build falla al activar el flag. Flutter recomienda avisar a quien mantiene el plugin y, mientras no haya versión nueva, dejar android.builtInKotlin=false. En proyectos add-to-app, donde Flutter va dentro de una app Android nativa, el proyecto anfitrión no se migra solo y las líneas de gradle.properties hay que añadirlas a mano.

Migrar vuestro propio código suele ser lo de menos. Son unos cuantos cambios en ficheros de configuración que, con la ayuda de vuestro agente de confianza, se resuelven en un momento. Lo que de verdad bloquea son los paquetes de terceros que no se han actualizado, y en una app con unos años encima es habitual encontrar alguno que lleva tiempo sin mantenimiento.

Por eso, antes de tocar nada, compensa hacer inventario de dependencias y comprobar una por una si soportan SwiftPM y AGP 9. Con esa lista ya se ve si la migración es un trámite o si toca sustituir algún plugin, y eso cambia bastante la planificación. Si además la app arrastra una versión de Flutter antigua, el trabajo se parece más a migrar un proyecto Flutter legacy y conviene plantearlo así desde el principio.

Sobre cuándo hacerlo, nosotros no esperaríamos. Con el requisito de páginas de memoria de 16 KB en Android pasó algo parecido: quien lo preparó con tiempo lo resolvió sin agobios, y quien esperó a que Google Play lo exigiera tuvo que hacerlo con prisas. Aquí puede pasar lo mismo el día que una versión nueva de Xcode, de Firebase o un requisito de las tiendas obligue a migrar.

Si tenéis una app Flutter que ya muestra estos avisos y no tenéis claro cuánto trabajo hay detrás, podemos revisarla. Miramos las dependencias, os decimos qué plugins están listos y cuáles no, y cuánto supone dejar el proyecto preparado para SwiftPM y AGP 9. Es parte de lo que hacemos en la solucion de mantenimiento y evolutivos y también lo podemos realizar como trabajo puntual.