Aller au contenu
useffect.sh
Planifier 30 min avec un senior
Natif

CocoaPods

Le gestionnaire de dépendances iOS historique de React Native (Podfile, pod install, .xcworkspace), en maintenance et en cours de remplacement par SwiftPM.

Définition

CocoaPods est le gestionnaire de dépendances pour projets Xcode que React Native utilise sur iOS depuis ses débuts. Les dépendances natives sont déclarées dans un Podfile, résolues par pod install qui écrit un Podfile.lock et génère un .xcworkspace à ouvrir à la place du .xcodeproj. Dans un projet React Native, le Podfile charge le script react_native_pods.rb et appelle use_native_modules!, ce qui linke automatiquement chaque librairie présente dans node_modules via son fichier .podspec. C’est aussi par des variables d’environnement lues au pod install que l’on règle l’architecture, Hermes V1 ou les binaires précompilés. CocoaPods est en mode maintenance : ses mainteneurs ont annoncé que Trunk, le registre central, cesse d’accepter de nouveaux podspecs le 2 décembre 2026, après une période de test du 1er au 7 novembre ; les specs existantes et le CDN restent disponibles. React Native 0.87 a introduit Swift Package Manager en expérimental, avec l’objectif de le rendre défaut en 0.89. Le dossier ios/Pods et le fichier Podfile.lock d’un projet viennent de lui.

Dans une vraie app

Dans un projet, la commande propre est bundle exec pod install depuis ios/, avec la version de CocoaPods épinglée dans Gemfile.lock ; pod install global avec une autre version est la première cause de « ça marche chez moi ». Les variables qui comptent se passent au même moment : RCT_NEW_ARCH_ENABLED (sans effet depuis la 0.82), RCT_USE_PREBUILT_RNCORE=0 pour compiler React Native depuis les sources, RCT_HERMES_V1_ENABLED=0 pour revenir à l’ancien Hermes. Sur Expo, le Podfile est généré par prebuild et se configure via expo-build-properties (useFrameworks, deploymentTarget), jamais à la main.

Les pannes classiques : un Podfile.lock en conflit après un merge (le régénérer plutôt que le résoudre ligne à ligne), un cache corrompu (pod deintegrate puis pod install), une librairie qui exige use_frameworks! :linkage => :static alors qu’une autre le refuse, et le fameux échec de téléchargement sur boost ou hermes-engine derrière un proxy d’entreprise.

Pour l’après-CocoaPods, le passage à Trunk en lecture seule ne casse pas les builds existants, mais les librairies ne recevront plus de mises à jour par ce canal. Pour un projet React Native, la trajectoire est fixée par le cœur : SwiftPM expérimental en 0.87 et 0.88 (npx react-native spm), défaut visé en 0.89 avec repli possible sur CocoaPods, et retrait de CocoaPods dans une version ultérieure. Expo SDK 58 a découpé ses sources iOS en cibles SwiftPM pour préparer ce passage.

Termes liés

Nos offres sur ce sujet

Sources

Les 35 termes du glossaire

Un de ces sujets bloque votre app ?

30 minutes avec un senior pour regarder le problème dans votre code. Gratuit.

Planifier 30 minRetour à l’accueil