Faut-il migrer les dépendances iOS de Flutter 3.44 ? Guide de décision 2026

La migration des dépendances iOS de Flutter 3.44 se décide selon le type de projet : pour un nouveau projet, évaluez d’abord Swift Package Manager ; pour un projet existant, inventoriez les plugins et validez compilation, tests et signature sur Mac CI avant de migrer. Cette recommandation s’adresse aux équipes dont la chaîne iOS dépend de plugins ou d’intégrations natives, et non à celles qui ne font que mettre à jour l’interface Flutter.

Cet article est destiné aux développeurs qui maintiennent une application Flutter iOS, aux ingénieurs responsables des plugins et intégrations natives, ainsi qu’aux équipes qui exploitent une chaîne CI Apple.
La mise à jour des informations a été vérifiée le 4 novembre 2026 à partir de la documentation Flutter et de l’annonce officielle de CocoaPods ; les dates annoncées restent susceptibles d’évoluer.

Décider selon le type de projet, pas selon la date annoncée

La documentation Flutter indique qu’à partir de Flutter 3.44, Swift Package Manager devient le gestionnaire utilisé par défaut pour les dépendances iOS et macOS, tandis que CocoaPods entre en mode maintenance. Cela oriente le choix d’un nouveau projet, mais ne constitue pas une obligation de migration immédiate pour chaque application existante. La documentation Flutter sur l’intégration iOS précise ce changement de direction.

Par ailleurs, la date du 2 décembre 2026 mentionnée pour le passage du registre CocoaPods en lecture seule est un plan, pas la preuve que ce changement a déjà eu lieu. L’annonce de CocoaPods sur le calendrier envisagé pour son registre de spécifications précise le projet. Une mise en lecture seule du registre ne signifie pas, à elle seule, que les dépendances déjà installées ou verrouillées cessent de fonctionner à cette date.

Le choix doit donc répondre à une question plus concrète : votre combinaison de Flutter, de plugins, de dépendances natives et d’outils peut-elle être résolue, compilée et livrée dans un environnement reproductible ? Le statut général d’un gestionnaire ne répond pas à cette question pour votre dépôt.

La compatibilité des dépendances prime sur le gestionnaire choisi

Swift Package Manager n’est pas un simple changement de commande à appliquer à l’ensemble d’un dépôt. Une application Flutter iOS peut réunir des packages Dart, des plugins qui exposent du code natif, des bibliothèques iOS utilisées directement et des scripts ajoutés au projet au fil du temps. Ces couches ne changent pas forcément de gestionnaire ensemble.

La documentation Flutter consacrée au développement des packages et des plugins aide à distinguer la partie Flutter d’un package de son intégration sur une plateforme. Pour votre inventaire, ne vous limitez donc pas au fichier de dépendances Dart : un plugin peut être présent comme dépendance directe, ou être introduit indirectement par un autre plugin.

Première étape : séparer les dépendances directes des dépendances transitives

Relevez les plugins déclarés par l’application, puis comparez-les aux dépendances qui apparaissent dans les fichiers et journaux natifs. Pour chacun, consignez son rôle, sa source, son intégration iOS et son statut de maintenance connu. Une dépendance directe peut être remplacée ou isolée plus facilement qu’une dépendance transitive enfouie derrière un plugin que l’application utilise pour une fonction critique.

Cette distinction devient particulièrement importante si votre application utilise des fonctions audio ou vidéo, du traitement d’image ou une intégration de conception reposant sur du code natif. Une interface qui s’affiche correctement ne prouve pas que l’enregistrement audio, le décodage vidéo ou l’import de ressources fonctionne encore après un changement du mode d’intégration.

Deuxième étape : qualifier la compatibilité en trois niveaux

Ne consignez pas simplement « compatible » ou « incompatible ». Les résultats utiles se répartissent en trois niveaux :

• Résolution : les outils trouvent les packages et versions attendus dans un environnement propre.
• Compilation : Xcode compile l’application et ses composants natifs, avec les réglages réellement utilisés par le projet.
• Flux de livraison : les tests, la signature et l’archivage fonctionnent dans la chaîne prévue pour la publication.

Une résolution réussie n’établit pas que le code natif compile ; une compilation réussie ne prouve pas que la signature et l’archivage aboutissent. Ce sont des résultats différents, qui doivent rester distincts dans votre compte rendu.

Troisième étape : examiner les dépendances natives et les scripts

Pour une application qui utilise encore CocoaPods, relisez le Podfile et le fichier de verrouillage, mais aussi les scripts appelés par la compilation ou la CI. Certains dépôts modifient des réglages Xcode, copient des ressources ou exécutent des étapes propres à un plugin après l’installation des dépendances. La migration peut échouer même si les packages principaux ont un équivalent disponible dans Swift Package Manager.

Vérifiez auprès des responsables des plugins si leur prise en charge de Swift Package Manager est explicitement documentée et maintenue. Une annonce générale de Flutter ne permet pas de déduire que tous les plugins tiers ont déjà adapté leur intégration. La description officielle du format des packages Swift peut vous aider à comprendre les manifestes et les produits exposés, mais elle ne certifie pas la compatibilité d’un plugin donné avec votre application.

Si un composant indispensable n’est pas prêt, vous avez plusieurs options raisonnables : garder temporairement CocoaPods pour ce projet, remplacer le composant après une validation fonctionnelle, ou tester une organisation à deux voies dans une branche distincte. Une configuration mixte n’est pas une fin en soi : elle ajoute des conditions à documenter, et ne convient que si l’équipe sait quelle dépendance relève de quel mécanisme.

Le système de l’équipe fait partie du critère d’adaptation

Swift Package Manager peut être le choix le plus cohérent pour un nouveau dépôt, mais la qualité du choix dépend aussi des personnes qui devront le maintenir. Si l’équipe maîtrise déjà les manifestes Swift, les réglages de projet Xcode et la recherche de dépendances transitives, elle pourra diagnostiquer plus facilement les problèmes propres à l’intégration native. Si ces responsabilités sont concentrées chez une seule personne, la migration doit inclure une procédure de dépannage exploitable par le reste de l’équipe.

Faites aussi l’inventaire des environnements de développement et d’intégration continue. Une machine locale qui conserve des caches ou des dépendances résolues n’est pas une preuve suffisante. Le contrôle pertinent consiste à reconstruire depuis un état propre, en utilisant les fichiers suivis par le dépôt et les outils prévus pour la livraison. Si les développeurs et la CI utilisent des procédures différentes, vous risquez d’accepter une migration qui fonctionne seulement sur un poste déjà préparé.

Flutter rappelle que la création et la compilation d’applications iOS supposent un environnement Apple approprié. Consultez ses instructions officielles pour configurer le développement iOS avant d’interpréter un échec d’environnement comme un problème propre à Swift Package Manager. Pour les projets dont les configurations de livraison diffèrent selon le canal, la documentation Flutter sur les variantes iOS est également pertinente : vérifiez chaque variante réellement utilisée plutôt que de tester seulement la configuration par défaut.

Quatrième étape : choisir entre migration, validation parallèle et report

La migration directe convient surtout à un nouveau projet, ou à un dépôt existant dont les dépendances natives sont identifiées et dont l’équipe peut exécuter les contrôles de livraison. Le report est préférable lorsque des plugins critiques n’ont pas de prise en charge confirmée, que les scripts natifs sont mal documentés ou que la CI ne permet pas encore de reproduire un état propre.

La validation parallèle peut servir d’étape intermédiaire : vous comparez les résultats de l’ancienne chaîne et de la nouvelle sans basculer immédiatement la production. Toutefois, évitez de maintenir deux procédures silencieuses ou non documentées. Définissez clairement la branche de validation, les fichiers de verrouillage concernés, les critères d’acceptation et la personne chargée de traiter les écarts.

Les avantages d’une migration anticipée sont une meilleure adéquation avec la direction indiquée par Flutter et une occasion de rendre explicites des dépendances natives jusque-là implicites. Ses inconvénients sont le travail de qualification des plugins, les adaptations éventuelles de scripts et le risque de modifier en même temps plusieurs composants de livraison. À l’inverse, le maintien temporaire de CocoaPods protège une chaîne éprouvée, mais vous impose de surveiller les annonces officielles et de ne pas laisser votre procédure de récupération dépendre d’un état local impossible à reproduire.

Cinquième étape : valider sur Mac CI avant tout changement de production

Le Mac CI sert à mesurer le comportement de votre dépôt sur un environnement de construction adapté à iOS, et non à certifier tous les plugins Flutter disponibles. Son résultat ne vaut que pour le projet, les dépendances et les outils qui ont effectivement été testés.

Procédez dans un environnement isolé selon une séquence reproductible :

1. Créez une branche dédiée et notez la révision du dépôt, les réglages de compilation et les fichiers de verrouillage.
2. Lancez une exécution depuis un clone propre, sans vous appuyer sur les caches d’une machine de développement.
3. Vérifiez séparément la résolution des dépendances, puis consignez les journaux et les éventuels avertissements.
4. Compilez l’application avec les configurations iOS réellement utilisées ; incluez les variantes pertinentes plutôt que de supposer qu’un seul réglage couvre le projet.
5. Exécutez les tests disponibles, puis contrôlez la signature et l’archivage si ces opérations font partie de votre livraison.
6. Rejouez l’exécution après correction d’un échec et conservez les traces permettant à un autre membre de l’équipe de comparer les résultats.

Ne considérez pas un pipeline vert comme une garantie générale. Il établit seulement que la combinaison vérifiée a passé les étapes incluses dans ce pipeline. Un plugin non couvert par les tests, une variante de livraison absente ou une dépendance native non sollicitée par l’application peut encore révéler un problème plus tard.

Si vous ne disposez pas encore d’un environnement Mac dédié à cette vérification, lisez d’abord le guide sur la compilation et les tests Flutter iOS sur un Mac distant. Pour choisir un environnement d’essai plutôt que de changer immédiatement la machine de production, vous pouvez également examiner les critères de comparaison des solutions Mac. Dans les deux cas, l’acceptation doit se faire avec votre dépôt, vos dépendances et vos étapes de livraison, pas à partir d’une promesse de compatibilité générique.

FAQ : clarifier les cas qui bloquent la décision

Un nouveau projet iOS créé avec Flutter 3.44 doit-il encore utiliser CocoaPods ?

Pour un nouveau projet, évaluez d’abord le chemin Swift Package Manager documenté pour Flutter 3.44 : il correspond au mode de gestion par défaut annoncé pour les dépendances iOS et macOS. Vérifiez toutefois que chaque plugin et intégration native requis est compatible. Si un élément indispensable reste lié à CocoaPods, documentez cette exception et testez le projet avant de figer votre modèle.

Que risque un projet existant s’il conserve CocoaPods ?

Le passage prévu du registre CocoaPods en lecture seule ne signifie pas que les dépendances déjà résolues deviennent immédiatement indisponibles ni que chaque projet cesse de compiler à cette date. Le risque dépend de votre Podfile, du fichier de verrouillage, des scripts et de la capacité à récupérer les dépendances. Conservez un environnement reproductible et vérifiez les annonces officielles avant de changer votre chaîne.

Comment avancer si un plugin Flutter ne prend pas en charge Swift Package Manager ?

Identifiez d’abord si le plugin est direct ou transitif, puis vérifiez son état auprès de son responsable et les instructions d’intégration native. Pour une dépendance indispensable encore liée à CocoaPods, gardez temporairement le chemin existant ou testez une configuration à deux voies dans une branche isolée. Ne remplacez pas le plugin sans valider les fonctions natives réellement utilisées par l’application.

Quels contrôles effectuer dans Xcode CI après une migration iOS Flutter ?

Sur un environnement macOS et Xcode isolé, partez d’un clone propre et vérifiez la résolution des dépendances, la compilation, les tests, puis la signature et l’archivage si votre livraison les utilise. Gardez les journaux et les fichiers de verrouillage avec le résultat. Une réussite ne vaut que pour la combinaison de projet, plugins et outils effectivement testée.

Si votre équipe ne peut pas isoler un environnement macOS pour cette validation, un Mac distant loué peut éviter de modifier immédiatement les postes existants, tout en vous laissant tester la chaîne avec votre propre dépôt. Cette option ne remplace pas l’achat d’une machine lorsque vous avez besoin d’un hôte physique dédié à long terme ou d’interfaces locales particulières ; elle convient plutôt à une phase de qualification ou à un besoin temporaire. Vous pouvez consulter les environnements Mac proposés par VpsHold, puis décider à partir des journaux de votre projet si la migration est prête.

Questions fréquentes