CocoaPods en lecture seule : ce que ça change pour React Native et Expo

Le sujet revient avec une formulation souvent fausse : « CocoaPods s’arrête en décembre ». Ce n’est pas ce que dit CocoaPods. Ce guide reprend les sources primaires, sépare ce qui est livré de ce qui est annoncé, et détaille ce qu’une équipe React Native ou Expo peut faire dès maintenant.

Le calendrier

Le plan a été publié par Orta Therox le 30 novembre 2024 sous le titre CocoaPods Trunk Read-only Plan (nouvelle fenêtre), puis mis à jour en mai 2025. Il s’inscrit dans la suite du billet d’août 2024 sur la maintenance de CocoaPods (nouvelle fenêtre), qui annonçait déjà le projet en « maintenance mode » et écrivait, à propos de React Native, que la situation « could be fine as-is, as most of their libraries come via npm instead of the Trunk ».

Date	Événement	Source
30 novembre 2024	Publication du plan de passage en lecture seule	blog.cocoapods.org (nouvelle fenêtre)
Mai 2025	Les nouveaux pods utilisant prepare_command sont refusés ; les pods existants qui l’utilisent sont exemptés	blog.cocoapods.org (nouvelle fenêtre)
18 août 2025	Google Maps SDK for iOS : CocoaPods « in maintenance mode », plus de versions CocoaPods après le Q2 2026	Maps release notes (nouvelle fenêtre)
26 mai 2026	Firebase 12.14.0 : plus de nouvelles versions sur CocoaPods après octobre 2026	Firebase release notes (nouvelle fenêtre)
6 août 2026	Google Maps SDK for iOS 11.0.0 : « CocoaPods is deprecated as of version 11.0.0 »	Maps release notes (nouvelle fenêtre)
11 août 2026	React Native 0.87 : support SPM expérimental, npx react-native spm	reactnative.dev (nouvelle fenêtre)
9 septembre 2026	Firebase 12.19.0 : « the final scheduled release published to CocoaPods »	Firebase release notes (nouvelle fenêtre)
7 octobre 2026	Firebase 13.0.0 : distribué uniquement via SPM et binaires	Firebase release notes (nouvelle fenêtre)
15 octobre 2026	React Native 0.88.0 et Expo SDK 58	releases RN (nouvelle fenêtre), changelog Expo (nouvelle fenêtre)
19 octobre 2026	react-native-firebase 27.0.0 : Firebase via SPM uniquement	CHANGELOG RNFB (nouvelle fenêtre)
1er au 7 novembre 2026	Test grandeur nature du mode lecture seule : « I will trigger a test run, giving automation a chance to break early »	blog.cocoapods.org (nouvelle fenêtre)
2 décembre 2026	« I will switch trunk to not accept new Podspecs permanently » ; le dépôt CocoaPods/Specs doit ensuite être archivé sur GitHub	blog.cocoapods.org (nouvelle fenêtre)

Trois précisions sur ce calendrier.

Les dates restent modifiables. Le billet dit : « These dates are not set in stone », et l’auteur précise qu’il n’est pas enclin à avancer l’échéance mais qu’il y a de la place pour la reculer. Au 26 octobre 2026, le dépôt source du blog (nouvelle fenêtre) ne montre aucune modification du calendrier depuis mai 2025, et le seul billet plus récent est une note de sécurité du 18 février 2026 (nouvelle fenêtre).

Le dépôt CocoaPods/Specs (nouvelle fenêtre) n’est pas encore archivé : il recevait encore des pushes le 26 octobre 2026.

Le bandeau de cocoapods.org affiche un compte à rebours arrondi (« 2 months to go » au 26 octobre 2026). Fiez-vous aux dates du billet.

Ce qui continue de marcher, ce qui s’arrête

Le mécanisme décrit par CocoaPods est précis : toute soumission d’un nouveau podspec « will always be denied at the server level ». Rien d’autre n’est coupé. Le billet ajoute que l’infrastructure « like the Specs repo and the CDN would still operate as long as GitHub and jsDelivr continue to exist », et conclut : « This will keep all existing builds working. »

Opération	Après le 2 décembre 2026	Base
pod trunk push d’un nouveau pod ou d’une nouvelle version sur le trunk public	Refusé côté serveur	Billet CocoaPods (nouvelle fenêtre)
pod install résolvant des versions déjà publiées sur trunk, via le CDN	Continue tant que GitHub et jsDelivr existent	Billet CocoaPods (nouvelle fenêtre)
pod install --repo-update, pod repo update	Devrait réussir sans rien ramener de nouveau depuis trunk, puisque le dépôt Specs est gelé. CocoaPods ne le dit pas explicitement	Déduction
Dépôts de specs privés (source 'https://…/mes-specs.git'), pod repo push	Non concernés : « This shouldn’t affect people who use CocoaPods with their own specs repos »	Billet CocoaPods (nouvelle fenêtre)
Podspecs locaux via :path, ce que fait l’autolinking React Native depuis node_modules	Non concernés : le billet cite les dépendances « vendored (e.g. they all come from npm.) »	Billet CocoaPods (nouvelle fenêtre)
Téléchargement des sources d’un pod trunk existant (:git, :http chez l’éditeur)	Rien n’est garanti par CocoaPods : le trunk héberge des specs, pas du code. La disponibilité dépend de chaque éditeur	Déduction
Correctifs de sécurité d’un SDK natif distribué via trunk	N’atteignent plus les utilisateurs CocoaPods : « you’re not getting any more updates to dependencies which come though CocoaPods trunk » (la coquille est dans l’original)	Billet CocoaPods (nouvelle fenêtre)

Le CDN est la source par défaut depuis CocoaPods 1.8 (nouvelle fenêtre), en août 2019 : « CocoaPods 1.8 switches the CDN as the default spec repo source ». Un Podfile sans ligne source l’utilise déjà.

Le client CocoaPods, lui, reste maintenu, lentement. La 1.17.0 (nouvelle fenêtre) date du 6 juillet 2026. Ce rythme est une seconde source de risque, indépendante du trunk : voir la section sur Xcode 27 plus bas.

Où en est React Native

Le fil de discussion #587 (nouvelle fenêtre), ouvert le 24 janvier 2023, est toujours ouvert. La proposition formelle, RFC0994 (nouvelle fenêtre) de Christian Falch, a été ouverte le 21 avril 2026 et n’est pas fusionnée. Sa dernière révision, datée du 12 octobre 2026, se termine par « Aligned with React Native main; no deprecation date ».

Version par version :

Version	Date	Ce qui change	Statut
0.75	Août 2024	Le helper spm_dependency permet à un podspec de librairie de déclarer une dépendance SwiftPM (PR #44627 (nouvelle fenêtre), fusionnée le 25 juin 2024)	Livré, chemin CocoaPods
0.81	12 août 2025	Builds iOS précompilés expérimentaux (nouvelle fenêtre), opt-in via RCT_USE_RN_DEP=1 RCT_USE_PREBUILT_RNCORE=1, toujours intégrés par CocoaPods	Livré, expérimental
0.84	11 février 2026	« React Native 0.84 now ships precompiled binaries on iOS by default », téléchargés pendant pod install ; opt-out RCT_USE_PREBUILT_RNCORE=0 (blog 0.84 (nouvelle fenêtre))	Livré, par défaut, via CocoaPods
0.87	11 août 2026	« experimental support for Swift Package Manager as an alternative to CocoaPods on iOS. It is opt-in and additive; CocoaPods remains the default and the supported path » (blog 0.87 (nouvelle fenêtre))	Livré, expérimental
0.88	15 octobre 2026 (billet du 19)	« Swift Package Manager support remains experimental and opt-in in React Native 0.88, while CocoaPods remains fully supported » (blog 0.88 (nouvelle fenêtre))	Livré, expérimental
0.89	Non sortie	« Target Swift Package Manager as the default, with an opt-out to CocoaPods for apps that are still blocked » ; « We plan to remove CocoaPods support in a later release of React Native » (blog 0.88 (nouvelle fenêtre))	Plan annoncé, sans date

Deux confusions fréquentes méritent d’être levées.

Précompilé ne veut pas dire SPM. Les XCFrameworks de React Native sont le défaut depuis la 0.84, et ils sont intégrés par CocoaPods. Le chemin SwiftPM de la 0.87 « consumes the same prebuilt XCFrameworks React Native already publishes » : c’est un second pipeline d’intégration, pas un nouveau format de binaire.

spm_dependency ne rend pas une librairie « SPM native ». C’est un pont côté CocoaPods : le pod reste un pod, et la dépendance SwiftPM est attachée à sa cible dans le projet Pods. La PR #44627 (nouvelle fenêtre) précise que cela « only works USE_FRAMEWORKS=dynamic pod install » et qu’autrement « the linker fails », à cause du flag -ObjC et des symboles dupliqués. Un bug d’embarquement des frameworks dynamiques transitifs, qui faisait planter l’app au lancement avec Library not loaded: @rpath/..., a été corrigé par la PR #58781 (nouvelle fenêtre) le 1er octobre 2026 sur main. Le correctif n’est pas dans la 0.88.0.

Ce que fait concrètement npx react-native spm, d’après le billet 0.87 (nouvelle fenêtre) et la RFC :

• la commande injecte des références de packages Swift dans le .xcodeproj existant, sans le remplacer ; signing, capabilities et build phases restent intacts, et npx react-native spm deinit retire cette injection (après --deintegrate, restaurez le Podfile depuis git et relancez pod install pour revenir à CocoaPods) ;
• trois packages locaux sont référencés : ReactNative (XCFrameworks précompilés), React-GeneratedCode (codegen) et Autolinked (généré dans build/generated/autolinking/Package.swift) ;
• une librairie doit livrer un Package.swift, à sa racine ou dans ios/ ; sinon, npx react-native spm scaffold en génère un à partir du podspec ;
• après un clone, et en CI, on lance npx react-native spm une fois avant de builder, « the analog of pod install » ;
• « The commands, flags, and generated layout may change in later releases. Do not use it in production yet. »

La 0.88 a durci ce tooling (liste complète (nouvelle fenêtre)) : la version iOS minimale est lue depuis le deployment target de l’app au lieu d’un iOS 15 codé en dur, la configuration SwiftPM d’une librairie passe par la section swiftpmConfig de son package.json (le bloc équivalent dans react-native.config.js est déprécié), le scaffold prend le nom depuis le podspec, et les artefacts précompilés sont téléchargés d’abord depuis le miroir Maven de React Native.

Un point de design à connaître pour les discussions avec vos outils de crash reporting : les binaires runtime (React.framework, hermes-engine, ReactNativeDependencies, en variantes debug et release) sont liés par des build settings Xcode et non comme binaryTarget SwiftPM, parce que, selon la RFC, « SwiftPM binary targets cannot vary by build configuration ». La RFC liste d’ailleurs la distribution des dSYM pour Sentry et Crashlytics parmi les questions non résolues.

Où en est Expo

Expo suit le même chemin, avec une étape intermédiaire déjà en production.

SDK 56 (nouvelle fenêtre), 21 mai 2026 : « SDK 56 ships prebuilt XCFrameworks for our most complex Expo modules on iOS », activé par défaut, mesuré à environ une minute de gain (16 %) sur la médiane des builds iOS propres. Opt-out avec EXPO_USE_PRECOMPILED_MODULES=0. Ces XCFrameworks sont consommés par CocoaPods.

Le 11 juin 2026, Christian Falch écrit sur le blog Expo (nouvelle fenêtre) que « Expo, React Native, and most React Native libraries currently rely heavily on CocoaPods », que CocoaPods « will be deprecated eventually and will become read-only in December 2026 », et que « This transition will take time ».

SDK 58 (nouvelle fenêtre), 15 octobre 2026, passe sur React Native 0.88. Le changelog est explicite : « SDK 58 lays the groundwork for Expo apps to use it. Expo’s iOS sources have been restructured so their Swift, Objective-C, and C++ compile as separate SwiftPM targets […], and an Expo autolinking plugin for React Native’s npx react-native spm pipeline is available as a preview (#49823). CocoaPods remains the default and supported path, and precompiled Expo modules keep working there. » La PR #49823 (nouvelle fenêtre) a été fusionnée le 16 septembre 2026. Le changelog ne donne pas de procédure Expo spécifique pour activer la preview ; il renvoie au billet React Native 0.87.

Pour une app Expo sur SDK 58, le chemin supporté reste donc npx expo prebuild puis pod install. Le travail continue côté Expo (par exemple les PR #51661 (nouvelle fenêtre) et #51588 (nouvelle fenêtre), fusionnées, et #52077 (nouvelle fenêtre), ouverte), mais rien n’indique une bascule par défaut dans SDK 58.

Le support du chemin SPM par EAS Build n’a pas été vérifié pour ce guide.

L’exposition réelle : les SDK natifs tiers

Dans un projet React Native 0.88, les pods de React Native lui-même ne dépendent plus du trunk. Le Podfile.lock de RNTester (nouvelle fenêtre) à la version 0.88.0 ne liste qu’un seul pod sous SPEC REPOS: trunk:, OCMock, une dépendance de test. boost, DoubleConversion, fmt, glog, RCT-Folly et SocketRocket viennent de façades locales dans build/rndeps-facades/, et hermes-engine comme ReactNativeDependencies de podspecs locaux. Il est raisonnable d’en déduire qu’une app 0.88 typique est dans le même cas pour sa partie React Native ; vérifiez-le sur votre propre lock.

Ce qui dépend du trunk, ce sont les SDK natifs tiers que vos librairies React Native tirent par s.dependency. Et plusieurs éditeurs ont déjà arrêté de publier sur CocoaPods, avant même le 2 décembre.

Dépendance	État au 26 octobre 2026	Source
Firebase Apple SDK	13.0.0 (7 octobre 2026) : « Firebase 13.0.0 and later releases are distributed exclusively through Swift Package Manager and binary distributions. » 12.19.0 (9 septembre 2026) est « the final scheduled release published to CocoaPods ». La 12.19.3 (22 octobre 2026) est un correctif de sécurité Firestore « for apps using Firebase 12, including projects that depend on CocoaPods ».	Release notes (nouvelle fenêtre)
Firebase, guide de migration	« Firebase 12 is the final major version published to CocoaPods ». Les versions existantes restent disponibles ; Firebase n’assure pas de support pour une installation directe depuis le podspec. La page ne mentionne pas React Native.	cocoapods-deprecation (nouvelle fenêtre)
react-native-firebase	26.1.0 (3 août 2026) ajoute la résolution SPM à côté de CocoaPods. 27.0.0 (19 octobre 2026), breaking : « ios: drop CocoaPods Firebase matrix; SPM-only ». Le package RNFB s’installe toujours par CocoaPods ; seul le SDK Firebase vient de SPM, via spm_dependency. Prérequis : React Native 0.75 ou plus, et use_frameworks! :linkage => :dynamic.	CHANGELOG (nouvelle fenêtre), ios-spm (nouvelle fenêtre)
Google Maps SDK for iOS	Note du 18 août 2025 : « CocoaPods is in maintenance mode as of 8/18/2025 and we won’t release more versions of CocoaPods after Q2 2026. Use Swift Package Manager instead. » 11.0.0 (6 août 2026) : « CocoaPods is deprecated as of version 11.0.0. » La dernière version publiée sur trunk est la 10.15.0 (24 juin 2026).	Release notes (nouvelle fenêtre)
react-native-maps	L’issue #5700 (nouvelle fenêtre), ouverte le 19 août 2025, est toujours ouverte. Le mainteneur a indiqué en juin 2026 attendre que React Native fixe sa propre spécification de migration. Le podspec 1.29.11 (nouvelle fenêtre) détecte Google Maps via $PODS_ROOT/GoogleMaps, un chemin propre à CocoaPods.	GitHub, unpkg
Sentry Cocoa	« CocoaPods is no longer a supported installation method for the Sentry Apple SDK. We no longer publish to CocoaPods after v9.19.1. » Les versions antérieures restent disponibles, et la branche 8.x a encore reçu une version sur trunk, la 8.58.4, le 14 juillet 2026. Sentry recommande SPM ou le XCFramework des releases GitHub.	docs.sentry.io (nouvelle fenêtre)
@sentry/react-native	8.32.0 (22 octobre 2026) embarque un Package.swift à la racine du tarball npm. Nous avons seulement vérifié sa présence, pas son comportement sous npx react-native spm.	unpkg (nouvelle fenêtre)

Le cas Firebase illustre la tension technique de fond. spm_dependency impose des frameworks dynamiques. Or, selon un mainteneur Firebase dans le fil #587, « Anything that Firebase distributes as a binary is built for static linking ». react-native-firebase 27 absorbe cette contrainte dans son intégration, et sa documentation est nette : « Do not use RNFB’s SPM mode with use_frameworks! :linkage => :static ». Sur un projet Expo, cela passe par expo-build-properties et ios.useFrameworks: "dynamic", et en ne passant pas disableSPM: true au config plugin @react-native-firebase/app. Un Podfile sans use_frameworks! est en linkage statique, donc incompatible. Si votre app n’est pas en frameworks dynamiques aujourd’hui, la montée vers RNFB 27 est un changement de linkage de tout le projet iOS, pas un simple bump de version.

Auditer son Podfile.lock

Le Podfile.lock contient tout ce qu’il faut. Sa section SPEC REPOS liste, par source de specs, les pods résolus depuis un dépôt de specs ; sa section EXTERNAL SOURCES liste ceux qui viennent d’un :path, d’un :git ou d’un :podspec. Sur un projet Expo, générez d’abord le dossier natif avec npx expo prebuild si vous ne le versionnez pas.

Lister les pods résolus depuis un dépôt de specs, source par source :

awk '/^SPEC REPOS:/{f=1;next} /^[A-Z]/{f=0} f' ios/Podfile.lock

Sur RNTester 0.88.0, la sortie est :

  trunk:
    - OCMock

Ne garder que les pods du trunk, un par ligne :

awk '/^SPEC REPOS:/{f=1;next} /^[A-Z]/{f=0}
     f && /^  [^ ]/{src=$1}
     f && /^    - / && (src=="trunk:" || src ~ /CocoaPods\/Specs/){print $2}' ios/Podfile.lock

Compter les pods liés depuis un podspec local, ce qui couvre les librairies React Native et Expo de node_modules :

awk '/^EXTERNAL SOURCES:/{f=1;next} /^[A-Z]/{f=0} f' ios/Podfile.lock | grep -cE ':path|:podspec'

Une entrée rangée sous https://github.com/CocoaPods/Specs.git plutôt que trunk: vise le même dépôt public, atteint par Git : le awk ci-dessus la compte. Toute autre URL désigne un dépôt de specs privé ou maison, non concerné par le plan.

Ensuite, pour chaque pod listé sous trunk: :

1. Identifier l’éditeur et vérifier s’il a déjà cessé de publier sur CocoaPods (Firebase à partir de 13, Google Maps à partir de 11, Sentry après 9.19.1 pour la branche 9.x). La version que vous avez dans le lock restera installable ; c’est la suivante qui n’arrivera pas.
2. Vérifier s’il existe un package SwiftPM chez l’éditeur, et si le wrapper React Native que vous utilisez sait le consommer via spm_dependency, comme react-native-firebase 27.
3. Vérifier la contrainte de linkage : spm_dependency requiert use_frameworks! :linkage => :dynamic.
4. Repérer les SDK internes que votre entreprise publie elle-même par pod trunk push. C’est le seul cas où le 2 décembre bloque réellement un flux : ces specs doivent passer sur un dépôt de specs privé ou sur SPM avant cette date, et l’automatisation doit s’attendre à des refus pendant la semaine de test du 1er au 7 novembre.

Un grep sur votre CI retrouve vite ce dernier cas :

grep -rn "pod trunk push\|pod trunk register" .github fastlane bitrise.yml 2>/dev/null

Pour les auteurs de librairies

La RFC0994 (nouvelle fenêtre) demande de « Continue supporting podspec during the transition period ». La cible, pour une librairie publiée sur npm, est donc de livrer les deux : un podspec qui fonctionne aujourd’hui, et un Package.swift pour le chemin expérimental.

Consommer un SDK SPM-only depuis un podspec (chemin CocoaPods, React Native 0.75 et plus) :

spm_dependency(s,
  url: 'https://github.com/apple/swift-atomics.git',
  requirement: {kind: 'upToNextMajorVersion', minimumVersion: '1.1.0'},
  products: ['Atomics']
)

C’est l’exemple de la PR #44627 (nouvelle fenêtre). La signature, dans react_native_pods.rb (nouvelle fenêtre) à la 0.88.0, est spm_dependency(spec, url:, requirement:, products:). Rappel des limites : frameworks dynamiques obligatoires, et le correctif d’embarquement des frameworks transitifs (#58781 (nouvelle fenêtre)) n’est que sur main.

Préparer le chemin SwiftPM (React Native 0.87 et plus, expérimental) :

• livrer un Package.swift à la racine du package npm ou dans ios/ ; il est détecté automatiquement ;
• déclarer la configuration dans package.json, section swiftpmConfig (name, dependencies, autolinkingPlugin, scaffold), puisque le bloc de react-native.config.js est déprécié depuis la 0.88 ;
• déclarer explicitement dans swiftpmConfig.dependencies les dépendances natives vers d’autres librairies React Native, parce que, selon la RFC, « SwiftPM has no equivalent of a podspec’s s.dependency » ;
• ne pas compter sur swiftpmConfig.xcframework ni swiftpmConfig.source : la RFC indique que « The current prototype does not yet implement » ces champs. Le CLI npx react-native-prebuild pour librairies est une proposition.

État des librairies courantes, vérifié sur le tarball npm via unpkg le 26 octobre 2026. Nous avons vérifié la présence du fichier, pas qu’il builde sous npx react-native spm.

Package	Version	Package.swift dans le tarball
react-native-reanimated	4.7.1 (nouvelle fenêtre)	Oui, racine
react-native-worklets	0.13.0 (nouvelle fenêtre)	Oui, racine
react-native-gesture-handler	3.4.0 (nouvelle fenêtre)	Oui, racine
react-native-safe-area-context	5.10.1 (nouvelle fenêtre)	Oui, racine
@sentry/react-native	8.32.0 (nouvelle fenêtre)	Oui, racine
react-native-screens	4.30.0	Non dans le tarball ; présent sur la branche main GitHub
@react-native-firebase/app	27.1.0 (nouvelle fenêtre)	ios/RNFBFirebase/Package.swift, annoté « CI probe only » ; les podspecs livrés gardent spm_dependency
react-native-svg, async-storage, react-native-maps, react-native-mmkv, flash-list, stripe-react-native, react-native-purchases, react-native-vision-camera	branche par défaut	Aucun Package.swift hors exemples trouvé dans l’arbre du dépôt (vérification par listing, non exhaustive)

Côté outillage, create-react-native-library (nouvelle fenêtre) a une PR ouverte depuis le 5 octobre 2026 qui ajoute un flag --experimental-spm générant un Package.swift pour Turbo Modules et vues Fabric, en ciblant le support SPM de la 0.87. Elle n’est pas fusionnée. Pour Nitro Modules (nouvelle fenêtre), nous n’avons trouvé aucun package SwiftPM livré pour react-native-nitro-modules ; en juin 2025, son auteur citait les limites de SwiftPM sur l’interop Swift depuis C++ comme blocage, et la question technique n’est pas tranchée publiquement.

Tester avant que ça casse

Le passage en lecture seule ne se teste pas en local, mais ses effets de bord, oui.

Un job CI « clean install » sur un runner neuf, sans cache, qui reproduit ce qu’un nouveau développeur ou un runner éphémère fera après le 2 décembre :

rm -rf ~/Library/Caches/CocoaPods ~/Library/Caches/ReactNative ios/Pods
pod cache clean --all
cd ios && bundle exec pod install --repo-update

~/Library/Caches/ReactNative est le cache que React Native utilise pour les tarballs précompilés. Enchaînez avec une archive release et l’upload des dSYM vers votre crash reporter, puisque la RFC liste la distribution des dSYM comme question ouverte côté SPM.

Un essai SPM sur une branche jetable, à partir de React Native 0.87 :

cd ios
npx react-native spm --deintegrate   # retire CocoaPods du projet
# build dans Xcode ou xcodebuild
npx react-native spm deinit          # retire l’injection SPM seulement
git checkout -- Podfile && bundle exec pod install   # retour à CocoaPods

Vous verrez vite quelles librairies n’ont pas de Package.swift. npx react-native spm scaffold en génère un dans node_modules, à persister avec patch-package. Sur Expo SDK 58, le plugin d’autolinking est une preview sans procédure documentée dans le changelog ; traitez l’essai comme exploratoire.

Xcode 27, enfin. L’issue CocoaPods #12927 (nouvelle fenêtre), ouverte le 24 septembre 2026, rapporte qu’un projet créé avec le template par défaut de Xcode 27.0 a objectVersion = 110 et que pod install échoue avec « Unable to find compatibility version string for object version 110 ». Au 26 octobre 2026, l’issue est ouverte sans réponse de mainteneur, et la liste des releases Xcodeproj (nouvelle fenêtre) ne montre pas de version postérieure à la 1.28.1 du 6 juillet 2026. Nous n’avons pas vérifié si Xcode 27 réécrit l’objectVersion d’un projet React Native existant. Si vous passez sur Xcode 27, vérifiez cette valeur dans ios/*.xcodeproj/project.pbxproj avant de l’imputer au trunk.

Ce qu’on recommande

Dans l’ordre.

1. Lire la section SPEC REPOS de chaque Podfile.lock de l’organisation, et en sortir la liste des pods trunk:.
2. Pour chaque pod de cette liste, noter l’éditeur, la dernière version publiée sur CocoaPods, et l’existence d’un chemin SPM côté wrapper React Native.
3. Déplacer avant le 1er novembre 2026 toute spec interne publiée par pod trunk push vers un dépôt de specs privé, et adapter l’automatisation.
4. Mettre en place le job CI « clean install » décrit plus haut, et le garder.
5. Traiter Firebase, Google Maps et Sentry comme des migrations à part entière, avec la question du linkage dynamique posée avant la montée de version.
6. Rester sur CocoaPods en production pour React Native 0.87 et 0.88 et Expo SDK 58, conformément à ce que disent les deux équipes.
7. Faire l’essai npx react-native spm sur une branche, lister les librairies sans Package.swift, et ouvrir ou suivre les issues correspondantes.
8. Pour les librairies internes, livrer Package.swift et swiftpmConfig en plus du podspec, et déclarer les dépendances inter-librairies.
9. Réévaluer à la sortie de React Native 0.89, et à chaque révision de la RFC0994.

Le collectif réalise cet audit si vous préférez le déléguer.

Ce qu’on ne sait pas encore

• Si le second email de CocoaPods prévu pour septembre-octobre 2026 a été envoyé, et si le test du 1er au 7 novembre est maintenu. Aucun billet officiel postérieur à février 2026 ne le confirme.
• Ce que fait exactement le test : refus total pendant la semaine, ou intermittent. Le billet ne le précise pas.
• La date effective d’archivage de CocoaPods/Specs.
• La date de React Native 0.89, et si « SPM par défaut » tient le calendrier. La RFC0994 n’est pas fusionnée et sa dernière révision écrit « no deprecation date ».
• Le comportement de npx react-native spm dans un projet piloté uniquement par Expo CLI, au-delà du plugin en preview.
• Le support du chemin SPM par EAS Build.
• La feuille de route SPM de Nitro Modules.
• Si les Package.swift de reanimated, gesture-handler, safe-area-context et Sentry visent bien le pipeline spm de React Native ou un autre usage.
• La fin du support CocoaPods de reCAPTCHA Enterprise. Un mainteneur Google l’a annoncée dans le fil #587 pour la 18.9.0 ; nous ne l’avons pas retrouvée sur une page éditeur.
• Si Xcode 27 fait passer les projets existants en objectVersion = 110.

Ce guide sera mis à jour quand ces points seront tranchés. La date de dernière révision figure en tête de page.

Sources

• CocoaPods Trunk Read-only Plan (nouvelle fenêtre), 30 novembre 2024, mis à jour mai 2025
• CocoaPods Support & Maintenance Plans (nouvelle fenêtre), 13 août 2024
• CocoaPods Trunk: Minor security updates (nouvelle fenêtre), 18 février 2026
• CocoaPods 1.8 Beta (nouvelle fenêtre), 5 août 2019
• CocoaPods 1.17.0 (nouvelle fenêtre), 6 juillet 2026
• CocoaPods issue #12927 (nouvelle fenêtre), 24 septembre 2026
• React Native 0.81 (nouvelle fenêtre), 0.84 (nouvelle fenêtre), 0.87 (nouvelle fenêtre), 0.88 (nouvelle fenêtre)
• RFC0994 (nouvelle fenêtre) et discussion #587 (nouvelle fenêtre)
• PR #44627 (nouvelle fenêtre), PR #58781 (nouvelle fenêtre), Podfile.lock de RNTester 0.88.0 (nouvelle fenêtre)
• Expo SDK 56 (nouvelle fenêtre), SDK 58 (nouvelle fenêtre), Faster iOS Builds with Precompiled XCFrameworks (nouvelle fenêtre), PR expo/expo #49823 (nouvelle fenêtre)
• Firebase Apple SDK release notes (nouvelle fenêtre), Firebase CocoaPods deprecation (nouvelle fenêtre)
• react-native-firebase CHANGELOG (nouvelle fenêtre), rnfirebase.io/ios-spm (nouvelle fenêtre)
• Google Maps SDK for iOS release notes (nouvelle fenêtre), react-native-maps #5700 (nouvelle fenêtre)
• Sentry Apple SDK, CocoaPods (nouvelle fenêtre)
• react-native-builder-bob PR #955 (nouvelle fenêtre)