New Architecture React Native: Guide 2…

Q: Puis-je désactiver la New Architecture si quelque chose casse ?

Oui, en repassant newArchEnabled=false sur Android et RCT_NEW_ARCH_ENABLED=0 sur iOS, puis en régénérant les pods. Attention : à partir de React Native 0.80 prévu pour fin 2026, l'option de désactivation sera retirée. C'est le moment de migrer.

Mis à jour : 31 mai 2026

Migrer vers la New Architecture en React Native (Fabric, TurboModules et mode Bridgeless) consiste à désactiver l'ancien pont JavaScript et à compiler votre app avec le moteur de rendu Fabric, les modules natifs typés générés par Codegen, et l'exécution sans pont (Bridgeless) activée par défaut depuis la version 0.76. En 2026, la New Architecture est le mode par défaut de tout nouveau projet créé avec npx @react-native-community/cli init ou Expo SDK 53+. Ce guide explique comment basculer un projet existant sans casser vos écrans en production.

La New Architecture est activée par défaut depuis React Native 0.76 et le mode Bridgeless depuis 0.77 ; en 2026 (0.79.x), c'est le chemin officiellement recommandé.
Trois composants à comprendre : Fabric (renderer C++), TurboModules (modules natifs paresseux) et Codegen (génération de types depuis vos spécifications JS/TS).
La couche d'interop permet d'exécuter la plupart des anciens modules paper sans modification, mais chaque librairie native doit être auditée.
Activez la New Arch avec newArchEnabled=true (Android) et RCT_NEW_ARCH_ENABLED=1 (iOS), ou via le plugin expo-build-properties.
Les régressions les plus fréquentes : mesures de layout sur les ScrollView nested, gestes Reanimated v3, et modules natifs custom non migrés.
Comptez 2 à 5 jours de travail pour une app moyenne, principalement passés à mettre à jour les dépendances et à corriger les modules custom.

Qu'est-ce que la New Architecture en React Native ?

La New Architecture est la refonte des fondations natives de React Native commencée en 2018 et finalisée en 2024 avec la version 0.76. Elle remplace le pont asynchrone JSON (le « bridge ») par JSI (JavaScript Interface), une couche C++ qui expose directement les objets natifs au moteur JavaScript Hermes. Concrètement, un appel JS vers un module natif n'est plus sérialisé en JSON : il devient un appel de fonction C++ synchrone, ce qui réduit la latence de plusieurs millisecondes par interaction et débloque des cas d'usage comme l'animation pilotée par le worklet UI.

Cette refonte s'articule autour de trois piliers : Fabric (le nouveau renderer), TurboModules (le nouveau système de modules natifs), et Codegen (l'outil qui génère du C++/Java/Objective-C typé à partir de vos spécifications TypeScript). En 2026, ces trois piliers sont matures et alimentent Meta Messenger, Microsoft Office Mobile, Shopify et la majorité des nouvelles apps Expo. J'ai migré quatre apps cette année, et le gain mesurable sur le temps de démarrage à froid tourne autour de 15 à 25 % selon la taille du bundle.

Fabric, TurboModules et Bridgeless : qui fait quoi ?

Comprendre ces trois briques évite de chercher le mauvais bug dans la mauvaise couche. Voici la répartition des responsabilités :

Brique	Rôle	Remplace	Statut 2026
Fabric	Renderer C++ partagé iOS/Android, mesure synchrone du layout via Yoga	UIManager + Paper renderer	Stable, par défaut depuis 0.76
TurboModules	Modules natifs chargés à la demande, accessibles via JSI	NativeModules basés sur le bridge	Stable, par défaut depuis 0.76
Codegen	Génère du code natif typé depuis les specs TypeScript	Wrappers manuels et casts dynamiques	Stable, requis pour TurboModules
Bridgeless	Supprime entièrement le pont legacy	BridgelessProxy / bridge wrappers	Par défaut depuis 0.77
Interop layer	Adaptateur qui fait tourner les anciens modules sous Fabric	—	Activé automatiquement, à auditer

L'erreur classique consiste à penser « j'ai activé la New Arch donc tout est TurboModule ». Faux : tant qu'une librairie n'a pas publié de spec Codegen, elle continue d'utiliser la couche d'interop, ce qui fonctionne mais sans gagner les performances JSI. Consultez le React Native Directory filtré sur New Architecture avant de planifier votre migration : il liste plus de 600 librairies compatibles avec un statut explicite.

Prérequis avant de migrer

Avant de toucher au moindre fichier de build, faites cet inventaire :

Version React Native : mettez-vous au minimum sur 0.76, idéalement 0.78 ou 0.79. En dessous, la New Arch existe mais reste expérimentale. Utilisez l'Upgrade Helper officiel pour suivre le diff exact entre votre version et la cible.
Hermes activé : JSC fonctionne encore, mais le couple New Arch + Hermes est le combo testé en priorité par l'équipe core. C'est l'option par défaut depuis 0.70.
Xcode 16+ et Android Gradle Plugin 8.6+ : requis pour la compilation C++ moderne et les nouveaux templates de Codegen.
Audit des modules natifs custom : listez tous vos modules dans android/app/src/main/java et ios/. Chacun devra être migré ou conservé via l'interop.
Suite de tests E2E : Maestro ou Detox. Sans cela, les régressions de layout passent inaperçues jusqu'au crash production.

Si vous démarrez un nouveau projet, ce travail est gratuit (la CLI génère déjà une app New Arch). Si vous partez d'un projet de 2022 sur 0.68, prévoyez deux jours rien que pour atteindre 0.76 avant de commencer la vraie migration. Mon conseil de pragmatique : faites les bumps de version un par un, validez chaque palier en CI, puis activez la New Arch en dernier.

Comment activer la New Architecture étape par étape

Sur un projet bare React Native ≥ 0.76, l'activation tient en deux flags. Sur Expo, en une ligne de config.

Pour un projet React Native CLI

Éditez android/gradle.properties :

# Activer Fabric, TurboModules et Bridgeless
newArchEnabled=true
hermesEnabled=true

Côté iOS, vous avez deux options. La plus simple en 2026 est de poser le flag dans ios/Podfile :

# ios/Podfile
ENV['RCT_NEW_ARCH_ENABLED'] = '1'

require Pod::Executable.execute_command('node', ['-p',
  'require.resolve("react-native/scripts/react_native_pods.rb", {paths: [process.argv[1]]})',
  __dir__]).strip

platform :ios, min_ios_version_supported
prepare_react_native_project!

Puis lancez la régénération des pods et la compilation :

cd ios && bundle exec pod install && cd ..
npx react-native run-ios
npx react-native run-android

Pour un projet Expo (SDK 53+)

La New Arch est déjà activée par défaut sur les nouveaux projets. Pour un projet existant, ajoutez le plugin expo-build-properties dans app.json :

{
  "expo": {
    "plugins": [
      ["expo-build-properties", {
        "android": { "newArchEnabled": true },
        "ios": { "newArchEnabled": true }
      }]
    ]
  }
}

Puis régénérez le projet natif avec npx expo prebuild --clean et reconstruisez via EAS Build. Si vous utilisez Expo Go pour le dev, sachez que depuis SDK 52 il tourne lui-même en New Arch, donc votre code JS y est déjà testé sous Fabric. Pour un guide détaillé sur l'écosystème Expo, voyez notre guide d'Expo Router v4.

Auditer vos dépendances et la couche d'interop

La couche d'interop est l'aspect le plus mal compris de la migration. Elle permet à un module écrit pour l'ancienne architecture (Paper) de tourner sous Fabric sans modification. C'est ce qui rend la migration faisable en quelques jours plutôt qu'en quelques mois, mais elle a des limites précises :

Les view managers legacy fonctionnent à condition que le module déclare RCT_EXPORT_VIEW_PROPERTY avec un type connu. Les types id opaques échouent silencieusement.
Les commandes impératives (ex. this._ref.scrollToIndex()) passent par un adaptateur qui ajoute un délai de un frame.
Les callbacks et promesses sont supportés, mais les modules qui appellent callback() plusieurs fois (anti-pattern legacy) lèvent une exception sous Bridgeless.

Pour auditer rapidement, lancez :

npx react-native config | jq '.dependencies | to_entries[] | {name: .key, platforms: .value.platforms | keys}'

Puis croisez la liste avec le React Native Directory. Toute librairie marquée « Untested » mérite une issue ouverte sur son repo avant la migration. Sur ma dernière app, deux libs sur quarante-trois étaient bloquantes : un SDK analytics maison et un wrapper de paiement. Le SDK analytics a été migré en une journée, le wrapper de paiement a été remplacé par la lib officielle du provider, qui supportait déjà la New Arch.

Migrer un module natif custom vers TurboModules

Si vous avez un module natif maison, voici le squelette minimal pour le convertir en TurboModule. Première étape : la spec TypeScript, qui sera la source de vérité pour Codegen.

// NativeAnalytics.ts
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  track(event: string, properties: Object): void;
  identify(userId: string): Promise<boolean>;
  getInstallationId(): string; // synchrone, possible avec JSI
}

export default TurboModuleRegistry.getEnforcing<Spec>('Analytics');

Dans package.json, déclarez la config Codegen :

{
  "codegenConfig": {
    "name": "AppSpecs",
    "type": "modules",
    "jsSrcsDir": "./src/specs"
  }
}

Côté Android (Kotlin), implémentez la classe abstraite générée :

// android/src/main/java/com/myapp/AnalyticsModule.kt
package com.myapp

import com.facebook.react.bridge.ReactApplicationContext
import com.appspecs.NativeAnalyticsSpec

class AnalyticsModule(reactContext: ReactApplicationContext)
  : NativeAnalyticsSpec(reactContext) {

  override fun getName() = "Analytics"

  override fun track(event: String, properties: ReadableMap) {
    AnalyticsSDK.track(event, properties.toHashMap())
  }

  override fun identify(userId: String, promise: Promise) {
    AnalyticsSDK.identify(userId) { success -> promise.resolve(success) }
  }

  override fun getInstallationId(): String = AnalyticsSDK.installationId
}

Le code Objective-C++/Swift pour iOS suit le même schéma. La grosse différence avec l'ancien système : les méthodes synchrones (comme getInstallationId) deviennent possibles. Avant, tout devait passer par une callback. Pour un projet avec une logique de secret stockée localement, ce point change le design (vous pouvez relire notre article sur l'authentification biométrique avec SecureStore) qui exploite déjà ce pattern.

Tester et déboguer après la migration

Une fois la New Arch active, le premier réflexe est de vérifier visuellement que l'app boot. C'est insuffisant. Voici la checklist que j'applique systématiquement :

Inspecter l'arbre de rendu avec React DevTools 6.x. Fabric expose les fibers exactement comme le web, ce qui aide à repérer les re-renders parasites.
Profiler le démarrage à froid via npx react-native profile-hermes. Comparez avant/après ; un écart de moins de 10 % en faveur de la New Arch indique un autre goulot d'étranglement.
Tester les gestes avec react-native-gesture-handler en mode strict. La New Arch utilise un système de hit-testing différent et certains PanGestureHandler imbriqués cessent de fonctionner sans configuration explicite des priorités.
Vérifier les modales et les portails. Les libs comme react-native-modal antérieures à la version 14 ne respectent pas la nouvelle API de ViewManager.
Activer LogBox en mode verbeux avec LogBox.ignoreLogs([]) commenté pendant la phase de test, pour voir tous les warnings de l'interop layer.

Pour mesurer l'impact sur le rendu, l'outil le plus utile en 2026 reste le tracé Perfetto recommandé par l'équipe React Native. Il montre la file d'attente JSI en temps réel et expose les ponts encore actifs si vous n'êtes pas réellement en mode Bridgeless.

Pièges fréquents et comment les éviter

Six migrations m'ont appris six leçons, justement. Voici les régressions qui reviennent le plus souvent :

Layout cassé sur les ScrollView avec contenu mesuré

Fabric mesure de façon synchrone, contrairement à Paper. Si votre code lit onLayout dans le premier render et déclenche un setState, vous risquez une boucle infinie ou un flash visuel. La fix : utilisez useLayoutEffect ou passez par la nouvelle API useEvent de Reanimated 4. Pour les listes lourdes, comparez avec notre benchmark FlatList vs FlashList vs LegendList. Toutes les trois ont des comportements spécifiques sous Fabric.

Animations Reanimated qui se figent

Sous Bridgeless, les worklets s'exécutent dans un runtime JSI dédié. Si vous capturez une référence à une closure JS depuis un worklet, vous obtenez l'erreur cryptique ReanimatedError: Tried to access a worklet from a different runtime. La solution est de marquer explicitement 'worklet' en première ligne de la fonction et d'utiliser runOnJS pour rappeler le thread JS.

Modules natifs qui appellent les callbacks deux fois

Pattern toléré en Paper, fatal en Bridgeless. Auditez vos modules avec grep -rn "callback(" android/app/src et garantissez un seul appel par chemin d'exécution. Préférez les promesses, qui sont rejetées si vous les résolvez deux fois.

Tailles de bundle qui explosent

Codegen génère du code natif pour chaque spec. Si vous déclarez dix specs mais n'en utilisez qu'une seule, vous embarquez tout. Découpez vos modules en packages npm distincts ou utilisez jsSrcsDir ciblé sur le minimum nécessaire.

Questions fréquentes

La New Architecture est-elle stable pour la production en 2026 ?

Oui. Depuis React Native 0.76 (octobre 2024), elle est activée par défaut et utilisée en production par Meta, Microsoft, Shopify et la plupart des nouvelles apps Expo. En 2026 sur la version 0.79, les régressions résiduelles concernent surtout les modules natifs custom mal migrés, pas le core lui-même.

Combien de temps prend une migration vers la New Architecture ?

Pour une app moyenne avec 30 à 50 dépendances natives, comptez 2 à 5 jours : un jour pour mettre à jour React Native, un à deux jours pour auditer et remplacer les libs incompatibles, et un jour de tests E2E. Les apps avec des modules natifs custom complexes peuvent demander une à deux semaines supplémentaires.

Puis-je désactiver la New Architecture si quelque chose casse ?

Oui, en repassant newArchEnabled=false sur Android et RCT_NEW_ARCH_ENABLED=0 sur iOS, puis en régénérant les pods. Attention : à partir de React Native 0.80 prévu pour fin 2026, l'option de désactivation sera retirée. C'est le moment de migrer.

Quelle est la différence entre Fabric et le mode Bridgeless ?

Fabric est le nouveau renderer (la couche qui dessine vos composants). Bridgeless est la suppression complète du pont legacy, y compris pour le démarrage et le chargement initial. On peut avoir Fabric sans Bridgeless, mais pas l'inverse. Depuis 0.77, les deux sont activés ensemble par défaut.

Quels modules natifs ne sont pas compatibles avec la New Architecture ?

En 2026, plus de 90 % des librairies populaires sont compatibles. Les exceptions notables sont certains SDK fermés (analytics propriétaires, paiements legacy) et des forks abandonnés. Consultez reactnative.directory pour le statut en temps réel.