Què fer amb els avisos de SwiftPM i Gradle en compilar Flutter

Fa unes setmanes que compilar gairebé qualsevol projecte Flutter deixa un rastre d'avisos a la consola. A iOS parlen de Swift Package Manager i CocoaPods. A Android, de Gradle, de l'Android Gradle Plugin i del plugin de Kotlin. L'app compila igual i es pot publicar, així que és fàcil deixar-los per un altre dia.

El que passa és que les eines que Flutter fa servir per sota per gestionar les dependències natives estan canviant alhora a les dues plataformes. El vostre projecte no té res malament. Avui són avisos i, a mesura que surtin versions noves, s'aniran convertint en errors. Aquí expliquem què canvia a cada plataforma, què cal tocar i on se sol complicar.

Des de Flutter 3.44, Swift Package Manager (SwiftPM) ve activat per defecte. Quan actualitzeu Flutter i executeu l'app, el projecte d'Xcode es migra sol i comença a descarregar els paquets Swift dels quals depenen els vostres plugins.

El problema són els plugins que encara no suporten SwiftPM. Per a aquests, Flutter mostra un avís amb la llista i continua tirant de CocoaPods. D'aquí surt bona part del que veieu a la consola. De moment funciona, però té data. El registre de CocoaPods passa a ser només de lectura el 2 de desembre de 2026 i a partir de llavors no hi haurà versions noves de cap pod. Firebase, que és a moltíssimes apps, deixa de publicar a CocoaPods aquest mes d'octubre. I la documentació de Flutter ja avisa que desactivar SwiftPM deixarà d'estar permès.

L'ordre raonable és actualitzar Flutter, compilar, mirar quins plugins apareixen a l'avís i, per a cadascun, actualitzar-lo, demanar suport a qui el manté o buscar una alternativa. Si en algun moment havíeu desactivat SwiftPM, es torna a activar així:

flutter config --enable-swift-package-manager

Si la migració trenca el build i necessiteu treure una versió, es pot desactivar només en aquell projecte des del pubspec.yaml. Serveix per sortir del pas i guanyar uns dies, però convé treure-ho tan bon punt es resolgui el plugin que falla:

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

Quan tots els plugins suportin SwiftPM, ja es pot treure CocoaPods del projecte. Si havíeu tocat el Podfile a mà per afegir altres dependències, aquests canvis s'han de refer a part.

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

Després convé obrir ios/Flutter/Debug.xcconfig i Release.xcconfig i treure qualsevol #include que apunti a Pods.

Hi ha un error que surt força en aquesta migració. Alguns paquets SwiftPM demanen una versió mínima d'iOS més alta que la del projecte, i Xcode es queixa que el paquet requereix, per exemple, iOS 14 quan el target suporta iOS 12. Es resol pujant el Minimum Deployments del target a Xcode i regenerant la configuració amb flutter build ios --config-only. Abans de fer-ho val la pena parlar-ho amb producte, perquè pujar el mínim deixa fora qui faci servir dispositius més antics.

A Android el canvi ve de l'Android Gradle Plugin 9. AGP 9 porta Kotlin integrat i deixa d'admetre que el plugin de Kotlin (KGP) s'apliqui per separat, que és justament com ho han fet els projectes Flutter fins ara.

Flutter 3.44 ja suporta AGP 9, però amb el Kotlin integrat desactivat. Per fer-ho, el migrador de Flutter afegeix aquestes dues línies a gradle.properties:

android.builtInKotlin=false
android.newDsl=false

Són un pont perquè tot continuï compilant mentre l'ecosistema es posa al dia. Per activar el Kotlin integrat cal Flutter 3.47 o superior i AGP 9. A android/app/build.gradle.kts, la migració consisteix a treure el plugin de Kotlin i el bloc kotlinOptions, i declarar el target de JVM en un bloc kotlin:

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

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

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

I a gradle.properties es canvia el flag:

android.builtInKotlin=true

Si algun dels plugins que feu servir no està migrat, el build falla en activar el flag. Flutter recomana avisar qui manté el plugin i, mentre no hi hagi versió nova, deixar android.builtInKotlin=false. En projectes add-to-app, on Flutter va dins d'una app Android nativa, el projecte amfitrió no es migra sol i les línies de gradle.properties s'han d'afegir a mà.

Migrar el vostre propi codi sol ser el de menys. Són uns quants canvis en fitxers de configuració que, amb l'ajuda del vostre agent de confiança, es resolen en un moment. El que de debò bloqueja són els paquets de tercers que no s'han actualitzat, i en una app amb uns quants anys a sobre és habitual trobar-ne algun que fa temps que no té manteniment.

Per això, abans de tocar res, compensa fer inventari de dependències i comprovar una per una si suporten SwiftPM i AGP 9. Amb aquesta llista ja es veu si la migració és un tràmit o si toca substituir algun plugin, i això canvia força la planificació. Si a més l'app arrossega una versió de Flutter antiga, la feina s'assembla més a migrar un projecte Flutter legacy i convé plantejar-ho així des del principi.

Sobre quan fer-ho, nosaltres no esperaríem. Amb el requisit de pàgines de memòria de 16 KB a Android va passar una cosa semblant: qui ho va preparar amb temps ho va resoldre sense neguits, i qui va esperar que Google Play ho exigís ho va haver de fer amb presses. Aquí pot passar el mateix el dia que una versió nova d'Xcode, de Firebase o un requisit de les botigues obligui a migrar.

Si teniu una app Flutter que ja mostra aquests avisos i no teniu clar quanta feina hi ha darrere, la podem revisar. Mirem les dependències, us diem quins plugins estan a punt i quins no, i què suposa deixar el projecte preparat per a SwiftPM i AGP 9. És part del que fem a la solució de manteniment i evolutius, i també ho podem realitzar com a feina puntual.