Swift Package Manager (SwiftPM)

Le gestionnaire de paquets officiel de Swift, intégré à Xcode, que React Native adopte en remplacement de CocoaPods (expérimental en 0.87 et 0.88).

Mis à jour le 26 octobre 2026

Définition

Swift Package Manager (SwiftPM) est le gestionnaire de dépendances et le système de build officiel du langage Swift, intégré à Xcode. Un paquet est décrit par un manifeste Package.swift qui déclare ses cibles, ses produits (librairies) et ses dépendances, et Xcode résout le graphe en écrivant un Package.resolved. Pour React Native, il représente la sortie de CocoaPods : React Native 0.87 a introduit un support expérimental et opt-in, où la commande npx react-native spm injecte des références de paquets dans le .xcodeproj existant et consomme les mêmes XCFrameworks précompilés que le cœur publie déjà, sans Ruby, Bundler ni pod install. La 0.88 a durci l’outillage (version iOS minimale lue depuis le deployment target, configuration swiftpmConfig dans package.json), et l’équipe vise SwiftPM par défaut en 0.89 avec repli sur CocoaPods, puis le retrait de CocoaPods dans une version ultérieure. Vous le rencontrez quand une librairie iOS n’est distribuée qu’en SwiftPM, ou en préparant la fin de CocoaPods.

Dans une vraie app

Concrètement, en 0.87 et 0.88 l’activation se fait depuis ios/ avec npx react-native spm --deintegrate, qui retire CocoaPods et ajoute les paquets ; npx react-native spm deinit revient en arrière. Après un clone frais ou en CI, npx react-native spm joue le rôle de pod install, mais il ne se relance pas à chaque changement de dépendance : le projet détecte le changement et refait l’autolinking. Une librairie doit fournir un Package.swift ; npx react-native spm scaffold en génère un depuis le podspec pour celles qui n’en ont pas. La doc est explicite : ne pas l’utiliser en production pour l’instant, commandes et layout générés peuvent encore changer.

Le changement visible pour les mainteneurs de librairies est l’arrivée de deux XCFrameworks d’en-têtes, ReactNativeHeaders et ReactNativeDependenciesHeaders, et la règle d’import #import <React/RCTAppDelegate.h> au lieu de la forme nue. Un podspec qui s’appuyait sur des chemins d’en-têtes internes doit être revu. Côté Expo, le SDK 58 a découpé ses sources iOS en cibles SwiftPM et propose un plugin d’autolinking en preview, mais CocoaPods reste le chemin par défaut et supporté.

Pour un projet d’app, ma recommandation en octobre 2026 : rester sur CocoaPods en production, tester SwiftPM sur une branche pour lister les librairies sans Package.swift, et remonter les blocages sur la RFC #0994. L’équipe vise la 0.89 pour en faire le défaut ; pas de bascule en production avant.

Sources

Les 35 termes du glossaire

Dans une vraie app

Termes liés

Sources

Un de ces sujets bloque votre app ?