Flutter 3.47 CI iOS : comment valider SwiftPM ? Liste 2026

Point de repère : Flutter indique que Swift Package Manager est devenu le mode de gestion des dépendances iOS et macOS par défaut à partir de Flutter 3.44 ; cette évolution est documentée dans son guide SwiftPM pour les développeurs d’applications. Pour Flutter 3.47, vérifiez toutefois la configuration réelle du projet et les plugins utilisés : procédez par scénario, puis validez la résolution, la compilation et l’archive sur un Mac propre avant d’étendre la migration. Une compilation réussie sur le poste d’un développeur ne suffit pas.

Pour qui : responsables d’applications Flutter iOS qui préparent une mise à niveau et doivent contrôler leurs dépendances natives.
Ingénieurs CI qui valident la résolution SwiftPM, l’archivage et la signature sur Mac.
Mainteneurs de plugins Flutter qui doivent établir la compatibilité SwiftPM ou documenter un recours à CocoaPods.

Dernière mise à jour : 31 octobre 2026. Informations vérifiées à partir des notes de version Flutter, de la documentation officielle SwiftPM de Flutter et des consignes d’intégration continue d’Apple.

Vérifier le mode de dépendances de l’application

La version de Flutter ne prouve pas, à elle seule, que le projet a terminé sa migration vers SwiftPM. Le mode effectivement utilisé dépend de la configuration du projet, de ses dépendances et des opérations exécutées par les outils Flutter. Il faut donc distinguer le comportement par défaut annoncé par la documentation des changements déjà appliqués dans le dépôt.

Les notes de version officielles classent Flutter 3.47 dans la branche stable ; elles permettent de vérifier la version et son statut sans se fier à une capture d’écran ni à une version installée sur un poste isolé (notes de version Flutter). Le guide destiné aux applications décrit la prise en charge de SwiftPM et le comportement de migration. Consultez-le en parallèle des fichiers du projet et des journaux de CI : une mise à niveau du SDK n’implique pas que l’ensemble des dépendances natives ait été converti automatiquement.

Flutter 3.47 utilise-t-il SwiftPM par défaut pour tous les projets iOS ? La documentation présente SwiftPM comme le mode par défaut depuis Flutter 3.44, mais cela ne signifie pas que chaque application est déjà entièrement passée à SwiftPM. Contrôlez le dépôt, le résultat des commandes Flutter et le journal de résolution des dépendances ; ne déduisez pas le mode actif du seul numéro de version.

Pour établir un état de référence, conservez la révision du dépôt, la version du SDK Flutter, l’environnement Xcode disponible sur le nœud et les fichiers de configuration concernés. Relevez aussi les modifications locales qui ne sont pas encore commitées : elles pourraient expliquer pourquoi une machine construit le projet alors qu’un clone propre échoue. La documentation de déploiement iOS de Flutter complète ces contrôles en décrivant le processus de compilation et de livraison.

Séparez ensuite les opérations automatiques des décisions de l’équipe. Une migration proposée ou effectuée par un outil n’équivaut pas à une validation des plugins, des scripts de publication et des cibles de CI. Si un fichier a été généré, modifié ou supprimé pendant la migration, examinez la différence dans le dépôt et consignez la décision de l’équipe plutôt que de supposer que l’outil a traité tous les cas particuliers.

Contrôler les plugins déjà compatibles avec SwiftPM

La présence d’une prise en charge SwiftPM dans un plugin doit être vérifiée pour la version effectivement résolue par le projet. La fiche d’un plugin, une ancienne branche ou une déclaration générale de compatibilité ne garantissent pas que la révision utilisée par la CI expose les métadonnées nécessaires ni que ses dépendances puissent être récupérées dans l’environnement de publication.

Pour chaque plugin qui fournit du code iOS natif, consignez le nom du paquet, la version ou la révision résolue, la déclaration SwiftPM attendue et le résultat d’une compilation propre. La documentation de Flutter destinée aux auteurs de plugins explique les adaptations à prévoir lors de la prise en charge de SwiftPM. Les règles générales de création de paquets Flutter se trouvent dans la documentation sur le développement des plugins et des paquets.

La liste de vérification doit suivre les fichiers réellement produits par l’intégration du projet. Vérifiez que le manifeste du plugin est présent dans la révision récupérée, que les dépendances transitives sont résolues et que les fichiers de verrouillage pertinents sont suivis par Git conformément à la structure du projet. Ne présumez pas qu’un fichier de verrouillage est identique d’un projet à l’autre : relevez celui qui est généré par la chaîne d’outils utilisée et vérifiez qu’il représente bien les dépendances testées.

Comment confirmer que les paquets Swift se résolvent sur une machine propre ? Lancez la vérification sur un agent Mac qui clone le dépôt dans un espace de travail neuf, sans réutiliser les répertoires de compilation ou les caches de dépendances du développeur. Réinstallez les outils selon la procédure d’équipe, lancez la résolution des dépendances prévue par le projet, puis conservez les journaux et le résultat du build avec la révision testée. Si la résolution ne fonctionne qu’après restauration d’un cache personnel, considérez la validation comme échouée jusqu’à ce que la dépendance manquante soit explicitée et récupérable.

Une configuration réussie sur un poste déjà utilisé peut masquer un manifeste absent, une version transitivement sélectionnée auparavant ou des identifiants disponibles uniquement dans la session du développeur. Le test de clone propre vise précisément ces écarts. Pour rendre le résultat réutilisable, consignez le statut de chaque plugin et indiquez si l’échec provient de la récupération, de la résolution, de la compilation native ou d’une étape postérieure.

Traiter les plugins qui nécessitent encore CocoaPods

SwiftPM par défaut ne signifie pas que tous les plugins Flutter sont immédiatement compatibles. La documentation Flutter mentionne un recours à CocoaPods pour les plugins qui ne prennent pas en charge SwiftPM. Ce mécanisme doit être observé dans le projet et dans les journaux : sa disponibilité ne constitue pas une garantie universelle de compatibilité pour tous les plugins, toutes les versions ou toutes les configurations.

Que se passe-t-il si un plugin n’est pas compatible avec SwiftPM ? Selon la documentation Flutter, la chaîne peut utiliser CocoaPods comme solution de repli pour les plugins concernés. L’équipe doit toutefois vérifier que ce repli a bien été détecté ou exécuté, que les dépendances sont installées sur l’agent et que le projet produit toujours le résultat attendu. Un build qui passe ne permet pas, à lui seul, d’identifier le chemin suivi.

Pour chaque dépendance concernée, notez les indices présents dans la sortie de la CLI Flutter, les journaux d’installation et les étapes de génération du projet iOS. Confirmez que le plugin documente ce mode de fonctionnement et vérifiez sa version exacte. Si les journaux sont ambigus, reproduisez le build dans un espace propre, en désactivant temporairement les caches qui pourraient dissimuler l’origine d’un artefact déjà installé.

Le repli doit rester visible dans la documentation de l’équipe : quels plugins l’exigent, quels agents savent installer leurs dépendances et quel résultat permet de reconnaître un passage effectif par CocoaPods. Sans cette trace, une future mise à jour pourrait supprimer ou modifier un élément de configuration encore nécessaire, ou donner l’impression trompeuse que le projet a entièrement migré.

Flutter indique que le dépôt CocoaPods doit passer en lecture seule le 2 décembre 2026, une échéance future à la date de mise à jour de cet article. Il s’agit d’un calendrier annoncé par la documentation, et non d’un changement déjà appliqué. Les équipes qui dépendent encore de CocoaPods devraient vérifier les consignes officielles avant cette date et planifier leur propre transition ; elles ne doivent pas présenter l’état futur du dépôt comme une restriction déjà en vigueur.

Valider séparément les projets add-to-app

Une application Flutter iOS autonome et un projet natif qui intègre un module Flutter ne suivent pas nécessairement les mêmes chemins de construction. Un résultat positif sur une application autonome ne valide donc pas automatiquement l’intégration dans une application hôte existante : le projet hôte, la résolution des paquets et l’entrée de compilation doivent être examinés dans leur propre contexte.

La documentation officielle de Flutter sur la configuration iOS add-to-app décrit l’intégration d’un module Flutter dans un projet iOS existant. Servez-vous-en pour vérifier comment l’hôte référence le module et comment les deux parties sont construites. Comparez ces consignes au dépôt réel, notamment si le projet a été créé sous une ancienne méthode basée sur CocoaPods.

Lors d’une migration, identifiez d’abord les éléments de l’ancienne intégration qui doivent être conservés, remplacés ou supprimés selon le guide officiel. Ne supprimez pas en bloc des réglages simplement parce qu’ils semblent associés à l’ancien gestionnaire : les scripts de l’hôte, les configurations de compilation et les étapes de livraison peuvent encore les utiliser. Après le nettoyage, faites une validation distincte de l’application hôte, du module Flutter et de l’archive finale.

Le rapport de CI doit indiquer quel projet Xcode a été compilé, quelle cible a servi à produire l’application et si le résultat inclut effectivement le module attendu. Cette précision est utile lorsqu’un dépôt contient plusieurs applications ou cibles : un succès de compilation d’une cible secondaire ne prouve pas que le produit livré par le pipeline a été correctement migré.

Vérifier la compilation, l’archive et la signature sur Mac

Une résolution correcte des paquets ne valide ni la compilation complète ni la livraison iOS. La chaîne doit également réussir les tests du projet, la création d’une archive et les contrôles de signature dans l’environnement utilisé pour publier. Apple documente les principes de compilation d’applications et de paquets Swift dans ses consignes d’intégration continue pour Swift Package Manager.

Organisez le pipeline de manière à rendre chaque étape observable. Conservez les journaux de récupération et de résolution des dépendances, ceux des tests et de la compilation, ainsi que les résultats de l’archivage et de l’export. Pour la signature, vérifiez que la configuration attendue est utilisée et que le produit livré peut être inspecté après l’export. Le simple code de sortie d’une commande ne démontre pas que l’archive correspond à la bonne cible ni qu’elle a été signée avec les éléments prévus.

Les dépendances privées et les dépôts Git authentifiés méritent un contrôle séparé. Apple recommande de traiter les informations d’authentification et la configuration des outils Git comme des éléments de la chaîne CI. Vérifiez que l’agent dispose des accès nécessaires au moment de la récupération, mais n’inscrivez ni jeton ni clé dans les journaux ou dans les artefacts publiés. Une erreur de récupération due à des droits d’accès ne doit pas être confondue avec une incompatibilité SwiftPM.

Pour qu’une équipe puisse reproduire le résultat, attachez à chaque validation la révision testée, la version Flutter, l’environnement Xcode utilisé, les états des dépendances et le résultat de l’archive. Si un secret est injecté par le gestionnaire de la CI, les journaux doivent montrer que l’étape a réussi sans en révéler la valeur. Cette séparation facilite aussi le diagnostic lorsqu’une compilation fonctionne localement, mais échoue sur un agent qui n’a pas les mêmes accès.

Comment valider une archive IPA après migration depuis CocoaPods ? Reproduisez le processus de livraison de la CI plutôt que de vous limiter à une compilation locale : restaurez les dépendances, exécutez les tests, créez l’archive avec la cible de publication, puis exportez le produit et inspectez le résultat et sa signature. Conservez les journaux qui relient l’archive à la révision testée ; si le pipeline n’exporte pas d’IPA dans sa configuration, documentez le produit réellement livré au lieu de déclarer une validation IPA.

Les équipes qui n’ont pas encore de machine Mac disponible pour ce contrôle peuvent comparer les besoins ponctuels d’une validation à leur organisation actuelle. La présentation de RUVCLOUD décrit l’accès à un Mac distant ; la page des tarifs permet d’examiner l’option de location en fonction de la durée d’utilisation prévue. Cela ne dispense pas de conserver les mêmes contrôles de dépôt, d’accès et de signature que sur un agent géré en interne.

Choisir le périmètre de migration selon les résultats

La décision doit être prise à partir des preuves disponibles pour chaque scénario, et non à partir d’un succès isolé. Une équipe peut avoir des plugins compatibles avec SwiftPM, d’autres encore tributaires de CocoaPods, et un projet add-to-app dont l’hôte n’a pas été validé. Traitez ces situations comme des résultats distincts afin de choisir un périmètre réaliste.

• Si le plugin expose la configuration SwiftPM attendue, que ses dépendances se résolvent sur un clone propre et que l’archive signée est vérifiée dans la CI, basculez ce projet vers SwiftPM et conservez ses résultats de validation.
• Si un plugin n’est pas prêt pour SwiftPM, mais que le repli CocoaPods est documenté et confirmé dans les journaux, gardez temporairement ce repli pour les dépendances concernées et consignez une date ou une condition de réexamen.
• Si la résolution échoue sur une machine propre, si les accès aux paquets privés ne sont pas maîtrisés ou si la signature de l’archive n’est pas prouvée, reportez l’extension de la migration et corrigez le point non validé avant le déploiement.
• Si le projet intègre un module Flutter dans une application native, validez d’abord le chemin add-to-app séparément ; ne généralisez pas le résultat d’une application Flutter autonome à l’hôte natif.

Avant de fermer le changement, faites relire les preuves par les personnes responsables du code natif, de la CI et de la publication. Elles doivent pouvoir relier le résultat aux fichiers commitées et identifier les dépendances qui empruntent encore le chemin CocoaPods. La revue doit également tenir compte du calendrier annoncé concernant le dépôt CocoaPods : au 31 octobre 2026, le passage en lecture seule prévu pour le 2 décembre 2026 reste à venir et doit être traité comme une échéance à vérifier, non comme un état présent.

Si l’environnement actuel repose sur un poste personnel, il peut rendre les essais difficiles à reproduire, dépendre de caches qui ne sont pas partagés et laisser les accès de publication liés à une session locale. Un Mac dédié peut être plus approprié lorsque la charge est continue ou qu’un contrôle physique est nécessaire ; pour une campagne de migration ou un nœud de validation temporaire, la location d’un Mac distant auprès de RUVCLOUD permet d’éviter l’achat immédiat d’une machine, tout en gardant une vraie chaîne macOS pour les tests Xcode. Avant d’élargir le changement, faites passer un projet représentatif par la résolution, les tests et l’archive sur un Mac propre ; si l’équipe ne dispose pas de cet environnement, elle peut examiner les options de location de Mac et choisir une durée adaptée à la validation, sans remplacer les contrôles de reproductibilité et de signature.