Flutter 3.44 iOS : faut-il migrer en 2026 ?

Flutter 3.44 iOS : faut-il migrer en 2026 ? Voici la règle à appliquer cette semaine : migrez immédiatement les nouveaux projets et les applications dont les plugins sont compatibles avec Swift Package Manager, mais gardez une branche de retour et une installation CocoaPods pour les projets complexes. Si votre application dépend de plugins non migrés, d’un Add-to-App ancien ou de plusieurs cibles natives, validez d’abord une double voie avant de supprimer quoi que ce soit.

Cette analyse s’adresse aux développeurs indépendants qui préparent une mise à niveau vers Flutter 3.44 sans savoir si leurs dépendances iOS sont prêtes. Elle concerne aussi les petites équipes qui entretiennent un Mac distant, des scripts de compilation automatique, plusieurs variantes d’application ou des extensions natives.

Dernière mise à jour : 14 août 2026. Les informations ont été vérifiées dans les annonces et documentations officielles de Flutter ainsi que dans le calendrier publié par CocoaPods.

01

Le changement concerne la gestion des dépendances, pas seulement la commande de mise à niveau

À partir de Flutter 3.44, Swift Package Manager devient le gestionnaire de dépendances par défaut pour les applications iOS et macOS. Flutter ajoute automatiquement l’intégration lors de l’exécution ou de la compilation du projet. Les plugins qui ne prennent pas encore en charge SwiftPM peuvent toutefois provoquer un retour temporaire vers CocoaPods. (annonce officielle de Flutter 3.44)

Cela crée quatre niveaux de validation distincts :

• les dépendances sont correctement résolues ;
• l’application se compile en mode Debug ;
• l’archive Release est générée ;
• la signature et la validation avant publication réussissent.

Le premier niveau ne prouve pas le quatrième. Une application peut ouvrir le simulateur tout en échouant lors de l’archivage, parce qu’une extension, une configuration de variante ou une phase de copie n’a pas reçu la même dépendance.

Le calendrier de CocoaPods renforce l’intérêt d’une migration progressive. Le registre Trunk doit devenir en lecture seule le 2 décembre 2026, mais l’équipe précise que cette échéance peut encore être ajustée. Cela ne signifie pas que les pods existants cesseront immédiatement de fonctionner, ni que toutes les applications doivent supprimer CocoaPods cette semaine. (calendrier officiel de CocoaPods)

Type de projet	Décision recommandée en août 2026	Niveau de risque
Nouveau projet Flutter 3.44	Conserver Swift Package Manager par défaut	Faible si les plugins sont compatibles
Application existante avec peu de code natif	Migrer sur une branche dédiée	Modéré
Projet avec nombreux plugins ou pods privés	Maintenir une double voie	Élevé
Add-to-App ou application avec plusieurs cibles	Valider séparément chaque cible	Élevé
Chaîne de compilation permanente	Migrer après archivage Release reproductible	Modéré à élevé

02

Les nouveaux projets doivent rester sur Swift Package Manager

Pour un nouveau projet, restaurer CocoaPods uniquement parce qu’un ancien tutoriel l’utilise est généralement une mauvaise décision. Vous partez sans ancien Podfile, sans scripts Ruby accumulés et sans réglages historiques qui pourraient masquer l’origine d’un échec.

Votre première vérification doit porter sur les plugins ajoutés au fichier de dépendances. Un plugin peut fonctionner parfaitement sur Android et ne pas avoir encore de description SwiftPM pour iOS. Consultez alors sa documentation, son dépôt source et les avertissements affichés par Flutter.

La documentation officielle indique que Flutter détecte les dépendances incompatibles et revient à CocoaPods lorsque cela est nécessaire. Cette situation intermédiaire est importante : un projet peut utiliser SwiftPM pour une partie de ses dépendances et CocoaPods pour une autre. La migration n’est donc pas considérée comme terminée simplement parce qu’un fichier de configuration ancien a disparu. (guide Flutter sur Swift Package Manager)

Pour un nouveau projet, vérifiez au minimum :

• l’ouverture du projet dans Xcode ;
• la résolution complète des paquets ;
• l’exécution avec flutter run ;
• la compilation en mode Release ;
• l’archivage avec la même variante que celle destinée à la publication.

Si vous développez une application de montage audio, de création vidéo ou de design, testez aussi les plugins qui manipulent des fichiers lourds, des extensions natives ou des frameworks multimédias. Ce sont souvent ces éléments qui révèlent une différence entre le simulateur et l’appareil physique.

03

Les applications existantes doivent migrer par comparaison, jamais par remplacement brutal

Pour une application déjà publiée, commencez par figer le dernier état connu comme publiable. Conservez le fichier de verrouillage, le Podfile, les scripts de compilation et la configuration du système d’intégration continue. Créez ensuite une branche dédiée à Flutter 3.44 et à Swift Package Manager.

Ne comparez pas uniquement le résultat de flutter run. Une migration utile doit comparer le même commit, la même variante, la même configuration de signature et le même type de sortie.

Contrôle	Avant migration	Après migration	Preuve à conserver
Résolution des dépendances	Succès avec l’ancien flux	Succès avec SwiftPM ou retour documenté à CocoaPods	Journal de résolution
Exécution Debug	Simulateur et appareil	Simulateur et appareil	Rapport de test
Compilation Release	Commande utilisée en production	Même commande sur la branche migrée	Journal Xcode ou ligne de commande
Archive	Archive lisible par Xcode	Archive générée sans dépendance manquante	Fichier d’archive et journal
Signature	Équipe, certificats, profils	Valeurs identiques ou changement justifié	Résultat de validation
Retour arrière	Branche et environnement disponibles	Retour testé	Procédure écrite

Une différence de signature ne vient pas forcément de SwiftPM lui-même. Elle peut apparaître parce qu’une cible n’a pas reçu le même framework, qu’une phase de compilation a changé ou qu’un script d’archivage ne s’exécute plus au bon moment. Il s’agit donc d’un problème d’intégration à diagnostiquer, pas d’une raison pour conclure trop vite que la migration est impossible.

Flutter documente notamment l’intégration de FlutterGeneratedPluginSwiftPackage, la phase préalable de préparation du framework et l’ajout de la dépendance à la bonne cible Xcode. Ces éléments doivent être vérifiés pour chaque variante qui possède son propre schéma. (documentation Flutter pour les applications)

04

Les plugins non compatibles imposent une stratégie à deux voies

Si Flutter signale qu’un plugin ne prend pas encore en charge Swift Package Manager, trois options sont réalistes.

La première consiste à rester temporairement avec CocoaPods pour la branche de publication. Cette solution convient lorsque l’application doit être envoyée rapidement et que le plugin est indispensable.

La deuxième consiste à remplacer le plugin. Cette option est pertinente lorsque le paquet n’est plus maintenu, qu’il ajoute une dépendance native limitée ou qu’une alternative fournit déjà une intégration SwiftPM stable.

La troisième consiste à aider à la migration du plugin. Pour un plugin interne ou un paquet dont vous êtes le mainteneur, vous devrez examiner Package.swift, les ressources natives, la version minimale de la plateforme et les cibles de test. La documentation Flutter destinée aux auteurs de plugins décrit aussi la coexistence temporaire avec les dépendances CocoaPods pour les utilisateurs qui n’ont pas encore migré.

Évitez deux erreurs fréquentes :

• supprimer toutes les références à CocoaPods avant d’avoir identifié le plugin qui en dépend ;
• considérer un avertissement de retour automatique comme une validation de production.

Dans un projet avec publicité native, paiement, audio, caméra ou traitement vidéo, l’inventaire doit inclure les frameworks réellement embarqués, les ressources copiées et les extensions éventuelles. Le nom du plugin ne suffit pas toujours à révéler toute la chaîne native.

Attention : la présence d’un dossier SwiftPM dans le projet ne prouve pas que chaque cible utilise le même graphe de dépendances. Vérifiez le schéma principal, les variantes, les tests natifs et les extensions avant de retirer l’ancien flux.

05

Add-to-App et cibles personnalisées demandent une vérification séparée

Les instructions d’un projet Flutter classique ne peuvent pas être appliquées mécaniquement à un module Add-to-App. Depuis Flutter 3.44, l’intégration SwiftPM d’un module Flutter dans une application iOS existante possède son propre parcours. Flutter demande notamment de retirer l’ancienne intégration CocoaPods ou les frameworks embarqués avant de suivre les nouvelles étapes. La documentation Add-to-App indique également un prérequis Xcode 15.0 ou ultérieur. (guide officiel Flutter Add-to-App)

Pour ce type de projet, vérifiez :

• le chemin relatif du module Flutter ;
• la façon dont le paquet est ajouté au projet hôte ;
• les configurations Debug, Release et de test ;
• les dépendances de chaque cible ;
• les scripts qui préparent les frameworks ;
• la signature de l’application hôte, et non seulement celle du module Flutter.

Les cibles personnalisées, comme une extension, un outil de test ou un produit framework, nécessitent la même prudence. L’intégration doit être ajoutée à la cible concernée, au lieu d’être limitée à la cible principale.

Si votre équipe utilise plusieurs variantes commerciales, créez une matrice simple : cible, schéma, dépendances, commande d’archive, certificat et résultat. Cela évite de déclarer la migration réussie parce que la variante gratuite compile alors que la variante entreprise échoue.

06

Première étape : préparer une migration réversible

Avant de modifier le projet, réunissez les éléments suivants :

• le commit actuellement utilisé pour publier ;
• le numéro de version de Flutter et de Xcode ;
• la liste des plugins et de leurs versions ;
• le Podfile et les fichiers de verrouillage ;
• les scripts de compilation ;
• les réglages de signature ;
• la liste des variantes et des extensions ;
• la commande exacte utilisée par votre système de compilation.

Les versions de Flutter et de Xcode doivent être enregistrées dans la documentation de l’équipe. La page officielle de configuration iOS rappelle que Xcode sert à compiler le code natif, à exécuter le simulateur et à déployer sur un appareil physique. Elle recommande également de tester sur un véritable appareil, même si le simulateur est plus rapide à préparer. (configuration iOS officielle de Flutter)

07

Deuxième étape : lancer la migration sur une branche isolée

Mettez Flutter à niveau dans cette branche, ouvrez le projet iOS, puis lancez une compilation sans modifier immédiatement les scripts de production. Notez si Flutter utilise SwiftPM seul ou s’il affiche un retour vers CocoaPods.

Ne supprimez pas les fichiers historiques pendant cette première passe. Votre objectif est de comprendre le graphe obtenu, pas de rendre le dépôt irréversible.

Si la migration automatique échoue, utilisez la procédure d’ajout manuel de la dépendance FlutterGeneratedPluginSwiftPackage et du script de préparation du framework. Les chemins et les schémas doivent être adaptés à votre projet, notamment lorsque vous utilisez une variante personnalisée.

08

Troisième étape : tester les quatre niveaux de réussite

Exécutez les contrôles dans cet ordre :

1. résolution des dépendances ;
2. compilation Debug ;
3. compilation et archive Release ;
4. validation de la signature et préparation de l’envoi.

Pour la compilation en ligne de commande, utilisez les mêmes variables d’environnement que dans votre système de compilation. Pour Xcode, ouvrez l’archive obtenue et vérifiez les applications embarquées, les extensions et les frameworks.

Un test réussi sur le simulateur ne remplace pas un test sur appareil. Les fonctions liées à la caméra, au microphone, au Bluetooth, aux notifications ou aux achats intégrés doivent être validées sur le matériel prévu par votre matrice de test.

09

Quatrième étape : comparer la signature et la publication

Comparez l’équipe de développement, les profils de provisioning, les droits associés et les identifiants de bundle entre l’ancienne et la nouvelle branche. Vérifiez ensuite l’archive avec les outils Apple prévus pour la validation et l’envoi.

La migration des dépendances ne doit pas vous conduire à afficher des certificats dans les journaux. Utilisez des variables secrètes dans le système d’intégration continue et masquez les identifiants sensibles.

Si la validation échoue, classez l’erreur avant de modifier le projet :

• paquet introuvable ;
• framework absent ;
• compilation native en échec ;
• ressource non copiée ;
• profil incorrect ;
• droit manquant ;
• problème d’envoi.

Cette classification vous évite de désactiver SwiftPM alors que le problème vient simplement d’une cible oubliée.

10

Cinquième étape : reproduire le résultat sur un Mac distant propre

Un Mac distant est utile lorsque votre ordinateur principal ne permet pas de séparer proprement l’ancien environnement du nouveau. La machine doit récupérer le dépôt et les dépendances comme si elle appartenait à un nouveau membre de l’équipe. Évitez de copier les caches Xcode ou les répertoires de dépendances depuis votre poste local.

La procédure recommandée est la suivante :

• préparer une machine macOS sans le projet déjà compilé ;
• installer les versions validées de Flutter et de Xcode ;
• récupérer le dépôt et sélectionner la branche de migration ;
• exécuter les commandes de résolution ;
• lancer une compilation Debug ;
• produire une archive Release ;
• effectuer la validation de signature ;
• conserver les journaux et la procédure de retour.

Pour une migration ponctuelle, vous pouvez utiliser un Mac distant pour tester une chaîne Flutter iOS sans transformer immédiatement votre poste principal en machine de transition. Si la compilation devient quotidienne, comparez cette approche avec une solution de Mac distant permanent, en tenant compte de la conservation des caches, de l’accès SSH, de la supervision et de la rotation des secrets.

Les développeurs qui publient régulièrement des applications audio, vidéo ou de design doivent également vérifier la disponibilité des simulateurs, l’accès aux fichiers de test et la stabilité des transferts d’artefacts. Un environnement distant peut accélérer la validation, mais il ne remplace pas les tests nécessitant un port USB, un appareil physique ou un périphérique spécialisé.

11

La liste de validation avant suppression de CocoaPods

• [ ] La liste des plugins natifs a été exportée et vérifiée.
• [ ] Chaque plugin indispensable possède une voie SwiftPM confirmée ou une justification documentée pour le maintien de CocoaPods.
• [ ] La branche de publication actuelle peut encore être restaurée.
• [ ] Le projet compile en Debug avec Flutter 3.44.
• [ ] Le projet compile en Release avec chaque variante importante.
• [ ] Une archive complète est produite par Xcode.
• [ ] Les extensions et cibles de test sont incluses dans la validation.
• [ ] La signature de l’archive est identique ou expliquée.
• [ ] La validation avant envoi réussit.
• [ ] Le même parcours fonctionne sur un Mac distant propre.
• [ ] La procédure de retour à CocoaPods a été testée.
• [ ] Les journaux ne contiennent aucun secret.

Si une seule case liée à l’archive, à la signature ou au retour arrière reste vide, ne supprimez pas encore l’ancien environnement.

12

Questions fréquentes sur Flutter 3.44 et les builds iOS

CocoaPods est-il encore nécessaire après Flutter 3.44 ?

Pas toujours. Swift Package Manager est désormais la voie par défaut, mais Flutter peut utiliser CocoaPods pour les plugins qui ne sont pas encore compatibles. La documentation de configuration iOS continue donc de mentionner CocoaPods pour les dépendances natives. Conservez-le tant que vos tests ne prouvent pas que toutes les cibles et tous les plugins fonctionnent sans ce gestionnaire.

Que faire avec un plugin Flutter non compatible avec Swift Package Manager ?

Ne retirez pas automatiquement le plugin. Vérifiez d’abord son importance pour la publication, sa maintenance et l’existence d’une alternative. Si le plugin est indispensable, gardez une branche CocoaPods pour les versions publiées et testez SwiftPM sur une branche parallèle. Si vous contrôlez le plugin, ajoutez sa structure SwiftPM et testez aussi les ressources natives et les cibles secondaires.

La migration peut-elle modifier la signature de votre application ?

Elle ne remplace pas directement vos certificats, mais elle peut changer la manière dont les frameworks et les scripts sont attachés aux cibles Xcode. Une cible mal configurée peut donc produire une archive différente ou invalide. Comparez toujours une archive Release, ses droits et sa validation avant de conclure que la signature est préservée.

Comment valider un build Flutter 3.44 sur un Mac distant ?

Reproduisez le parcours complet dans une machine propre : récupération du dépôt, résolution des dépendances, compilation Debug, archive Release, validation de signature et contrôle de l’artefact. Utilisez les mêmes versions d’outils que votre chaîne habituelle et conservez un journal par étape. Le but est de distinguer un problème de cache local d’un problème réel de configuration.

13

Verdict pour 2026

Vous pouvez migrer maintenant si vous démarrez un nouveau projet ou si votre application existante utilise principalement des plugins compatibles avec Swift Package Manager. Dans ce cas, gardez tout de même une branche de retour jusqu’à la réussite d’une archive Release et d’une validation de signature.

Vous devez rester en double voie si vous utilisez des plugins non migrés, des pods privés, plusieurs extensions, des variantes complexes ou une intégration Add-to-App. CocoaPods n’est pas annoncé comme inutilisable aujourd’hui ; son passage prévu en lecture seule le 2 décembre 2026 rend toutefois risqué le fait de repousser indéfiniment l’inventaire des dépendances. (calendrier officiel de CocoaPods)

Si votre ordinateur actuel ne peut pas fournir un environnement macOS séparé et réversible, un Mac distant pour une migration Flutter temporaire permet de comparer les deux chaînes sans perturber la machine qui publie déjà votre application. Cette option est moins adaptée à une charge lourde permanente nécessitant des périphériques physiques, mais elle est pertinente pour une validation, une reprise de version ou un test de chaîne de compilation.

Votre environnement actuel peut manquer d’isolement, conserver des caches invisibles et rendre le retour arrière incertain. Un Mac local acheté pour une seule migration immobilise aussi un budget et doit ensuite être entretenu. Pour une opération ponctuelle ou une période de transition, louer un Mac chez VpsMesh vous donne une machine macOS dédiée, avec accès distant et droits administrateur, afin de vérifier Flutter 3.44 avant de modifier votre infrastructure durable. Vous pourrez ensuite décider en connaissance de cause s’il faut conserver CocoaPods, passer entièrement à SwiftPM ou maintenir deux chaînes de publication.