Pendant des années, CocoaPods a été l’un des outils incontournables du développement iOS.

Que l’on travaille sur une application native Swift / Objective-C, sur une application Flutter, React Native, Ionic, Capacitor ou Kotlin Multiplatform, il y a de grandes chances que CocoaPods ait déjà été présent quelque part dans la chaîne de build iOS.

Parfois visible.

Parfois caché dans un dossier ios.

Parfois découvert uniquement le jour où la CI décide de ne plus builder.

Bref, CocoaPods a longtemps été ce compagnon discret mais essentiel de l’écosystème Apple.

Mais cet écosystème est en train de changer.

À partir du 2 décembre 2026, CocoaPods Trunk doit passer en lecture seule. Cela signifie qu’il ne sera plus possible de publier de nouveaux pods ou de nouvelles versions via le dépôt central historique de CocoaPods.

Et même si cela ne va pas casser toutes les applications du jour au lendemain, c’est un signal très clair : les projets mobiles doivent progressivement préparer leur migration vers Swift Package Manager.

CocoaPods, c’est quoi exactement ?

CocoaPods est un gestionnaire de dépendances pour les projets iOS et macOS.

Son rôle est simple : permettre à une application d’intégrer facilement des librairies externes.

Par exemple :

  • un SDK de paiement ;
  • un SDK analytics ;
  • Firebase ;
  • un outil de crash reporting ;
  • une librairie UI ;
  • un plugin natif utilisé par Flutter ou React Native ;
  • une dépendance interne à une entreprise.

Dans un projet iOS, cela se matérialise généralement par un fichier Podfile, puis par une installation via la commande pod install.

CocoaPods va alors télécharger les dépendances, résoudre les versions compatibles, générer un workspace Xcode, et permettre au projet de compiler avec ces librairies.

Pendant longtemps, c’était quasiment un standard de fait.

Ce qui change en décembre 2026

Le point important à comprendre, c’est que CocoaPods ne disparaît pas brutalement.

Les dépendances déjà publiées resteront accessibles. Les projets existants ne devraient donc pas arrêter de compiler du jour au lendemain uniquement à cause de cette annonce.

En revanche, CocoaPods Trunk, le dépôt central qui permet aux mainteneurs de publier des pods, doit passer en lecture seule.

Concrètement :

  • les pods existants resteront disponibles ;
  • les versions déjà publiées resteront consultables ;
  • les nouveaux pods ne pourront plus être ajoutés via Trunk ;
  • les nouvelles versions de pods existants ne pourront plus être publiées via Trunk ;
  • les projets qui dépendent fortement de CocoaPods risquent progressivement de se retrouver figés sur certaines dépendances.

C’est là que le sujet devient intéressant.

Ce n’est pas une coupure nette.

C’est une obsolescence progressive.

Et dans le logiciel, c’est souvent ce genre d’évolution qui finit par coûter cher lorsqu’elle n’est pas anticipée.

Pourquoi Swift Package Manager devient la trajectoire naturelle

Swift Package Manager, ou SPM, est le gestionnaire de dépendances intégré à l’écosystème Swift et Xcode.

Il permet de déclarer, versionner et intégrer des packages directement dans un projet Apple, sans passer par Ruby, CocoaPods ou un workspace généré.

Son adoption progresse depuis plusieurs années, notamment parce qu’il est directement supporté par Apple et intégré dans Xcode.

Pour les nouveaux projets iOS natifs, la question se pose de moins en moins : SPM devient généralement le choix par défaut, sauf contrainte spécifique.

Cela ne veut pas dire que la migration est toujours automatique ou simple.

Certains SDK ne sont pas encore disponibles en SPM.

Certains projets ont des configurations complexes.

Certains environnements CI/CD reposent sur des scripts historiques autour de CocoaPods.

Mais la direction de l’écosystème est claire : CocoaPods passe en maintenance, SPM devient progressivement le standard.

Un impact qui dépasse les projets iOS natifs

On pourrait penser que ce sujet ne concerne que les développeurs iOS.

En réalité, ce n’est pas le cas.

Beaucoup de technologies cross-platform s’appuient sur la chaîne native iOS pour compiler l’application finale.

C’est le cas de Flutter, React Native, Ionic, Capacitor ou encore Kotlin Multiplatform.

Même si le code principal est écrit en Dart, JavaScript, TypeScript ou Kotlin, la partie iOS finit toujours par passer dans Xcode.

Et c’est souvent à cet endroit que CocoaPods intervient.

Dans un projet Flutter, par exemple, les plugins iOS peuvent être intégrés via CocoaPods. Flutter travaille déjà sur le support de Swift Package Manager, mais la migration est progressive. Certains plugins supporteront SPM rapidement. D’autres mettront plus de temps. Certains projets devront conserver CocoaPods temporairement.

Même logique côté React Native : une application peut très bien être développée majoritairement en JavaScript ou TypeScript, tout en reposant sur CocoaPods pour la gestion des dépendances natives iOS.

Résultat : ce sujet n’est pas uniquement une affaire de développeurs Swift.

C’est un sujet mobile au sens large.

Les risques à anticiper

Le risque principal n’est pas que l’application cesse de fonctionner le 2 décembre 2026.

Le vrai risque, c’est de découvrir trop tard que le projet dépend de librairies ou de workflows qui ne suivent plus l’évolution de l’écosystème.

Voici quelques exemples très concrets.

1. Des dépendances bloquées

Si une librairie reste uniquement distribuée via CocoaPods Trunk, elle pourra continuer à être utilisée dans sa version existante, mais les nouvelles versions ne pourront plus être publiées via ce canal.

À terme, cela peut bloquer :

  • une correction de bug ;
  • une montée de version iOS ;
  • une adaptation à une nouvelle version de Xcode ;
  • une correction de sécurité ;
  • une compatibilité avec une nouvelle version de Flutter ou React Native.

2. Des plugins cross-platform en retard

Dans les projets Flutter ou React Native, les dépendances natives sont parfois masquées derrière des plugins.

Le projet applicatif a l’air “simple”, jusqu’au moment où un plugin iOS pose problème.

Si un plugin critique ne supporte pas SPM, la migration peut devenir plus délicate.

Il faut alors attendre une mise à jour du mainteneur, contribuer au plugin, le forker, ou remplacer la dépendance.

Aucune de ces options n’est dramatique.

Mais aucune n’est gratuite non plus.

3. Des pipelines CI/CD fragiles

Beaucoup de pipelines iOS contiennent des étapes historiques :

  • installation de Ruby ;
  • installation de CocoaPods ;
  • pod install ;
  • cache des Pods ;
  • gestion spécifique du workspace Xcode ;
  • scripts custom autour du Podfile.

Lors d’une migration vers SPM, ces éléments doivent être revus.

Cela peut simplifier la chaîne à terme, mais il faut prendre le temps de tester proprement.

Une migration de dépendances n’est pas seulement une modification de configuration locale.

C’est aussi une modification de la manière dont l’application est construite, testée et livrée.

4. Une dette technique invisible

Le plus gros piège, c’est que CocoaPods est souvent devenu invisible.

Le projet build.

La CI passe.

Les développeurs n’y pensent plus.

Mais au moment d’une montée de version iOS, Xcode, Flutter, React Native ou d’un SDK métier, cette dépendance historique peut ressortir d’un coup.

Et généralement, elle ressort au pire moment : juste avant une livraison, une mise en production ou une validation App Store.

Que faut-il vérifier sur un projet mobile ?

Avant de parler de migration complète, la première étape est simple : faire un état des lieux.

Sur un projet iOS ou cross-platform, il est utile de regarder :

  • la présence d’un fichier Podfile ;
  • les dépendances listées dans Podfile.lock ;
  • les SDK critiques utilisés par l’application ;
  • la disponibilité de ces SDK via Swift Package Manager ;
  • les plugins Flutter ou React Native qui s’appuient encore sur CocoaPods ;
  • les scripts CI/CD liés à pod install ;
  • les éventuelles dépendances internes publiées sous forme de pods ;
  • les forks ou dépendances peu maintenues ;
  • les contraintes de version iOS minimale ;
  • les particularités Xcode du projet.

L’objectif n’est pas forcément de tout migrer immédiatement.

L’objectif est de savoir où l’on met les pieds.

Un projet qui utilise CocoaPods uniquement pour une ou deux dépendances bien maintenues ne présente pas le même risque qu’une application avec vingt pods, plusieurs SDK propriétaires, des scripts CI custom et des plugins cross-platform peu suivis.

Quelle stratégie de migration adopter ?

La bonne approche dépend du contexte.

Mais dans la plupart des cas, il vaut mieux éviter la migration “big bang”.

Une stratégie progressive est souvent plus saine.

Étape 1 : auditer les dépendances

On commence par identifier toutes les dépendances iOS du projet.

Il faut distinguer :

  • les dépendances directes ;
  • les dépendances transitives ;
  • les SDK critiques ;
  • les dépendances maintenues ;
  • les dépendances abandonnées ;
  • les dépendances déjà disponibles en SPM.

Cette étape permet de prioriser.

Étape 2 : traiter les dépendances critiques

Toutes les dépendances n’ont pas le même poids.

Un SDK de paiement, d’authentification, de notification push ou d’analytics critique doit être regardé en priorité.

Si ces SDK disposent déjà d’une intégration SPM officielle, la migration peut être planifiée plus sereinement.

S’ils ne l’ont pas, il faut regarder la roadmap de l’éditeur ou prévoir une alternative.

Étape 3 : tester SPM sur une branche dédiée

La migration doit être testée dans un environnement isolé.

Il faut vérifier :

  • la compilation locale ;
  • la compilation CI ;
  • les tests automatisés ;
  • les builds Debug et Release ;
  • les flavors ou schemes spécifiques ;
  • l’archivage pour l’App Store ;
  • les dépendances utilisées par des extensions iOS ;
  • les impacts sur les temps de build.

Étape 4 : adapter la CI/CD

Une fois les dépendances migrées, il faut nettoyer la chaîne de build.

Cela peut impliquer :

  • de retirer des étapes CocoaPods devenues inutiles ;
  • d’adapter le cache CI ;
  • de modifier les commandes de build ;
  • de revoir les chemins Xcode utilisés ;
  • de documenter les nouvelles étapes d’installation.

C’est souvent là que la migration devient vraiment concrète.

Étape 5 : documenter pour l’équipe

Une migration technique réussie, c’est aussi une migration comprise.

Il faut documenter :

  • comment installer le projet ;
  • comment ajouter une nouvelle dépendance ;
  • quelles dépendances restent encore sous CocoaPods si migration partielle ;
  • quelle stratégie adopter pour les futures librairies ;
  • quoi faire en cas de conflit Xcode ou SPM.

Cela évite que le projet reparte dans plusieurs directions au fil du temps.

Un sujet technique, mais aussi un sujet staffing

Ce changement a aussi un impact sur la manière de staffer les projets mobiles.

Un projet iOS moderne ne se limite pas à “savoir coder en Swift”.

Il faut aussi comprendre :

  • la gestion des dépendances ;
  • l’écosystème Xcode ;
  • les contraintes App Store ;
  • la CI/CD mobile ;
  • les interactions entre natif et cross-platform ;
  • les stratégies de migration progressive.

Sur un projet Flutter ou React Native, il peut être tentant de penser qu’un profil uniquement cross-platform suffit.

Dans beaucoup de cas, oui.

Mais dès que l’on touche à la partie iOS native, aux plugins, aux SDK ou à la CI, une compétence iOS devient très précieuse.

C’est un point important à garder en tête dans les équipes projets.

Le cross-platform accélère beaucoup de choses.

Mais il ne supprime pas les plateformes natives.

Il les abstrait.

Et parfois, l’abstraction fuit.

Un point d’attention en avant-vente et en audit

Ce sujet peut aussi devenir un bon angle d’analyse lors d’une reprise de projet, d’un audit technique ou d’une mission de cadrage.

Quelques questions simples peuvent déjà donner beaucoup d’informations :

  • Le projet utilise-t-il encore CocoaPods ?
  • Combien de dépendances iOS sont concernées ?
  • Les SDK critiques sont-ils compatibles Swift Package Manager ?
  • La CI dépend-elle fortement de CocoaPods ?
  • Les plugins cross-platform sont-ils maintenus ?
  • Le projet a-t-il une stratégie de montée de version Xcode / iOS ?
  • Existe-t-il une documentation d’installation fiable ?

Ces questions permettent d’identifier une dette technique potentielle.

Elles permettent aussi de rassurer un client : le sujet est connu, maîtrisé, anticipé.

Et c’est exactement ce qu’on attend d’un partenaire technique.

Pas seulement produire du code.

Mais sécuriser la trajectoire du produit.

Faut-il migrer tout de suite ?

Pas nécessairement.

Il ne faut pas transformer ce sujet en panique générale.

Si un projet fonctionne, que ses dépendances sont stables, que la CI est maîtrisée et que les SDK critiques sont maintenus, il n’y a pas forcément d’urgence absolue.

En revanche, il est risqué de ne rien regarder avant fin 2026.

La bonne posture, c’est l’anticipation.

Pas la panique.

Un audit léger aujourd’hui peut éviter une migration subie demain.

Et comme souvent dans le mobile, le vrai coût n’est pas dans la migration elle-même.

Le vrai coût, c’est de devoir migrer dans l’urgence, sous contrainte de livraison, avec une version Xcode qui bloque, un SDK client qui ne compile plus et une deadline App Store qui approche.

Ambiance sympathique, mais pas vraiment le meilleur moment pour découvrir le sujet.

Conclusion

Le passage de CocoaPods Trunk en lecture seule marque une évolution importante de l’écosystème mobile iOS.

Ce n’est pas une rupture brutale.

Mais c’est un signal fort.

Les projets iOS natifs et cross-platform doivent progressivement se préparer à un monde où Swift Package Manager devient la voie principale pour gérer les dépendances Apple.

Pour les équipes techniques, c’est le bon moment pour auditer les projets, identifier les dépendances critiques et planifier les migrations.

Pour les équipes projet, staffing et commerce, c’est aussi un point de vigilance à intégrer dans les reprises, audits et cadrages mobiles.

Chez Atecna, notre rôle est justement d’accompagner ces transitions sans panique, mais avec méthode.

Parce qu’un projet mobile durable, ce n’est pas seulement une application qui fonctionne aujourd’hui.

C’est une application qui pourra continuer à évoluer demain.