React Native 0.87 et SwiftPM en 2026 : Build iOS Moderne et Questions d'Entretien

React Native 0.87, publié le 11 août 2026, apporte le support expérimental de Swift Package Manager (SwiftPM) aux builds iOS, marquant la première étape vers l'élimination de CocoaPods des projets React Native. Cette version rend également l'API TypeScript Stricte par défaut, intègre Metro 0.87 avec une génération de source maps 2x plus rapide, et relève les exigences minimales de la chaîne d'outils à Node.js 22, Kotlin 2.0 et Android compileSdk 37.

Swift Package Manager Remplace CocoaPods pour les Dépendances iOS

Le support SwiftPM dans React Native 0.87 est opt-in et expérimental. CocoaPods reste le gestionnaire de dépendances par défaut pour les applications en production. Le chemin SwiftPM consomme les mêmes XCFrameworks pré-construits que React Native publie déjà, donc aucun téléchargement binaire supplémentaire n'est requis.

L'avantage clé : un projet basé sur SwiftPM n'a besoin que de Xcode. Ruby, Bundler et CocoaPods ne sont plus nécessaires sur les machines des développeurs ou les pipelines CI.

# ios-swiftpm-setup.sh
# Étape 1 : Naviguer vers le répertoire iOS
cd ios

# Étape 2 : Désintégrer CocoaPods et générer les références SwiftPM
npx react-native spm --deintegrate

# Étape 3 : Ouvrir le projet dans Xcode et compiler
open MyApp.xcworkspace

La commande spm --deintegrate injecte les références des packages Swift dans le .xcodeproj existant plutôt que de remplacer le fichier projet. Les paramètres de signature de code, les phases de build et les capabilities restent intacts. Pour annuler le changement, exécutez npx react-native spm deinit.

Fonctionnement de l'Autolinking SwiftPM Sans pod install

Après la configuration initiale, les modifications de dépendances déclenchent un relinking automatique. Installez ou supprimez un package natif avec npm ou yarn, puis compilez. Le projet détecte les changements et relance l'autolinking pendant la phase de build Xcode.

# dependency-workflow.sh
# Installer une dépendance native
npm install react-native-reanimated

# Le build déclenche le relinking automatique
npx react-native run-ios
# Pas de pod install requis

Pour les clones frais et les environnements CI, exécutez npx react-native spm une fois avant le premier build. Cela génère le fichier Package.swift et résout les dépendances des packages Swift.

Limitations de SwiftPM et Maturité Production

Le support SwiftPM dans 0.87 comporte des limitations importantes qui affectent les décisions d'adoption :

Pour les applications en production, CocoaPods reste la voie recommandée. Les équipes évaluant SwiftPM devraient prototyper sur une branche et tester leur arbre de dépendances complet avant de s'engager dans la migration.

Changement Majeur : Imports d'En-têtes iOS avec Namespace

React Native 0.87 livre de nouveaux XCFrameworks : ReactNativeHeaders.xcframework et ReactNativeDependenciesHeaders.xcframework. Les modules natifs utilisant des includes angle sous forme simple doivent ajouter le préfixe de namespace React/.

// Avant 0.87 - include simple
#import <RCTAppDelegate.h>
#import <RCTBridge.h>
#import <RCTRootView.h>

// Après 0.87 - include avec namespace
#import <React/RCTAppDelegate.h>
#import <React/RCTBridge.h>
#import <React/RCTRootView.h>

Ce changement s'applique aux builds CocoaPods et SwiftPM. Les projets avec des modules natifs personnalisés doivent mettre à jour tous les imports d'en-têtes avant la mise à niveau.

API TypeScript Stricte : La Nouvelle Interface JavaScript par Défaut

L'API TypeScript Stricte, prévisualisée dans 0.80, devient la valeur par défaut dans 0.87. Les types sont maintenant générés directement à partir du code source React Native, éliminant la dérive entre les définitions TypeScript et le comportement réel à l'exécution.

import { useRef } from 'react';
import { View, TextInput, ViewInstance, TextInputInstance } from 'react-native';

export function FormComponent() {
  // Nouveaux types de ref dédiés remplacent RefObject<T> générique
  const containerRef = useRef<ViewInstance>(null);
  const inputRef = useRef<TextInputInstance>(null);

  const focusInput = () => {
    // Accès aux méthodes type-safe
    inputRef.current?.focus();
  };

  return (
    <View ref={containerRef}>
      <TextInput ref={inputRef} placeholder="Email" />
    </View>
  );
}

Trois changements de types majeurs requièrent attention lors de la migration :

1. Imports profonds bloqués : Les chemins react-native/Libraries/* produisent maintenant des erreurs de type. Tous les exports doivent provenir du package racine react-native.

2. Mises à jour des types ref : ViewInstance et TextInputInstance remplacent les types ref génériques. Les alias de type *Properties sont supprimés au profit de *Props.

3. Changement useColorScheme : Retourne ColorSchemeName | null au lieu de la valeur string précédente 'unspecified'.

Désactiver le TypeScript Strict Pendant la Migration

Les équipes nécessitant plus de temps pour migrer peuvent restaurer les imports profonds legacy jusqu'à React Native 0.88 :

{
  "extends": "@react-native/typescript-config",
  "compilerOptions": {
    "customConditions": ["react-native", "react-native-legacy-deep-imports"]
  }
}

Cette échappatoire sera supprimée dans React Native 0.89. Les projets doivent prioriser la migration avant cette version.

Metro 0.87 : Source Maps 2x Plus Rapides et 50% Moins de Mémoire

La version 0.87 du bundler Metro apporte des améliorations de performance significatives qui affectent le workflow de développement et le temps de démarrage des React Native DevTools.

La génération de source maps est 2x plus rapide grâce à une gestion optimisée des chaînes. Les DevTools chargent maintenant plus rapidement car les source maps sont générées plus efficacement pendant les builds de développement.

L'utilisation mémoire diminue de 50% grâce à un stockage plus efficace des source maps. Cela compte pour les grandes bases de code où Metro consommait auparavant beaucoup de RAM pendant les longues sessions de développement.

Changements Metro supplémentaires :

• Support stable pour les fichiers de configuration TypeScript (metro.config.mts)
• Support des fichiers de config ESM aux côtés de CommonJS
• Auto-résolution des packages dans le resolver
• Abandon du support pour les extensions de fichier .es6 et les fichiers de configuration YAML

Exigences Minimales de la Chaîne d'Outils pour React Native 0.87

Cette version relève les exigences de version minimales dans toute la chaîne d'outils. Les pipelines CI et les environnements développeurs nécessitent des mises à jour avant la mise à niveau.

Pour les problèmes de compatibilité AGP 9, ajoutez des opt-outs dans android/gradle.properties :

# android/gradle.properties
# Opt-outs temporaires pour la migration AGP 9
android.builtInKotlin=false
android.newDsl=false

APIs Supprimées dans React Native 0.87

Plusieurs APIs dépréciées sont supprimées dans cette version. Les projets utilisant ces APIs nécessitent un refactoring avant la mise à niveau.

Les dépréciations supplémentaires ciblant une suppression future incluent ImageBackground (utiliser View avec Image positionné absolument), DrawerLayoutAndroid (utiliser react-native-drawer-layout), et react-native/Libraries/Core/InitializeCore (utiliser react-native/setup-env).

Questions d'Entretien React Native 0.87 pour Développeurs Seniors

Ces questions apparaissent dans les entretiens de développeurs mobile seniors suite aux versions majeures de React Native. Comprendre les décisions architecturales derrière le support SwiftPM et l'API TypeScript Stricte démontre une connaissance au niveau du framework.

Q : Pourquoi React Native 0.87 introduit SwiftPM comme expérimental plutôt que de remplacer CocoaPods immédiatement ?

Le support SwiftPM dépend des bibliothèques communautaires fournissant des fichiers Package.swift. Contrairement à CocoaPods où un registre central Podspec existe, SwiftPM requiert que chaque auteur de bibliothèque ajoute une configuration de package Swift natif. La phase expérimentale permet à l'écosystème d'adopter SwiftPM graduellement pendant que CocoaPods reste stable pour les apps en production. De plus, les commandes CLI et la structure de projet générée peuvent changer selon les retours des développeurs avant stabilisation.

Q : Quel problème l'API TypeScript Stricte résout-elle que les définitions de types maintenues manuellement ne pouvaient pas ?

Les définitions de types maintenues manuellement dérivent du comportement à l'exécution entre les versions. Les refactorings internes qui changent les signatures de fonctions ou ajoutent des paramètres peuvent ne pas être reflétés dans les types immédiatement, causant des crashs à l'exécution que TypeScript aurait dû attraper. L'API Stricte génère les types directement depuis le code source, rendant les types autoritatifs plutôt qu'aspirationnels. Elle bloque également les imports profonds qui accèdent aux APIs internes instables, prévenant les cassures quand ces internes changent.

Q : Comment l'autolinking SwiftPM diffère-t-il de l'autolinking CocoaPods dans React Native ?

L'autolinking CocoaPods s'exécute pendant pod install, que les développeurs doivent se souvenir d'exécuter après les changements de dépendances. L'autolinking SwiftPM s'exécute pendant la phase de build Xcode automatiquement. Le système de build détecte les changements de dépendances et régénère le manifeste du package sans intervention manuelle. Cela élimine une source commune de problèmes "ça marche sur ma machine" où les développeurs oublient d'exécuter pod install après avoir tiré des changements.

Pour une préparation supplémentaire aux entretiens React Native, consultez les banques de questions sur les modules natifs en profondeur et les stratégies de test.

Stratégie de Mise à Niveau pour les Projets React Native 0.87

Le React Native Upgrade Helper génère un diff entre le template de projet actuel et 0.87. Ce diff montre exactement quels fichiers nécessitent des modifications.

Priorisez ces étapes de migration :

1. Mettre à jour Node.js vers 22.13.0+ et vérifier que les environnements CI correspondent
2. Exécuter la compilation TypeScript pour identifier les violations d'imports profonds
3. Mettre à jour les types ref de génériques vers les types d'instance dédiés
4. Mettre à jour les imports d'en-têtes iOS vers le format avec namespace
5. Tester l'arbre complet de dépendances natives avant d'activer SwiftPM

Pour les projets Expo, React Native 0.87 est disponible dans les releases expo@canary. Les projets Expo en production devraient attendre la version SDK stable.

Ce que le Support SwiftPM 0.87 Signifie pour les Temps de Build iOS

SwiftPM élimine pod install du workflow de développement, mais la configuration initiale du projet nécessite plus de temps. La commande npx react-native spm résout les packages Swift depuis la source, ce qui prend plus de temps que le téléchargement de binaires CocoaPods pré-construits.

Les builds suivants bénéficient de la résolution incrémentale des packages de Xcode. Seuls les packages modifiés sont re-téléchargés. Pour les équipes avec des changements de dépendances fréquents, cette approche incrémentale peut être plus rapide que les cycles répétés de pod install.

L'optimisation CI diffère entre les deux approches. CocoaPods met en cache les répertoires Pods/ efficacement. SwiftPM met en cache via les derived data de Xcode, ce qui nécessite des stratégies de clés de cache différentes. Les équipes migrant les pipelines CI devraient benchmarker les deux approches avec leur ensemble de dépendances spécifique.

Pour les techniques d'optimisation de build iOS connexes, consultez le guide de la Nouvelle Architecture React Native couvrant les caractéristiques de performance de Hermes V1 et du mode bridgeless.