Dans une vraie app
Pour une app, le passage en bridgeless se voit surtout dans le code d’intégration natif. Sur iOS, l’AppDelegate moderne s’appuie sur RCTReactNativeFactory plutôt que sur RCTBridge ; sur Android, MainApplication expose un ReactHost via DefaultReactHost. Un projet dont l’AppDelegate.mm instancie encore RCTBridge à la main est un projet qui a sauté des étapes de l’upgrade helper, et ça finit par casser sur la version suivante.
Côté librairies, les symptômes de l’interop sont reconnaissables : un module qui appelle bridge.eventDispatcher ou RCTBridge.currentBridge reçoit un objet de compatibilité, et certains chemins (événements envoyés avant le chargement, UIManager custom) ne font plus rien. Les messages « Bridgeless mode is enabled » suivis d’un warning sur un module précis dans la console Metro sont la piste à suivre. Avec React Native 0.84 et suivants, une partie des classes du bridge est retirée du core à chaque release, donc une librairie non maintenue finit par ne plus compiler.
En audit, je cherche les imports de com.facebook.react.bridge.ReactContextBaseJavaModule sans équivalent Turbo, les RCT_EXPORT_MODULE sans spec associée, et je lis le changelog de chaque dépendance native pour la mention « bridgeless » ou « New Architecture ».
Termes liés
New Architecture
La réécriture du cœur de React Native (Fabric, Turbo Modules, JSI), activée par défaut depuis la 0.76 et seule architecture depuis la 0.82.
JSI (JavaScript Interface)
L’API C++ qui laisse JavaScript tenir des références directes sur des objets natifs, sans sérialisation : la fondation de la New Architecture.
Turbo Modules
Les modules natifs de la New Architecture : une spec TypeScript, du code généré par Codegen, et un chargement à la demande via JSI.
Fabric
Le renderer de la New Architecture : un cœur C++ partagé entre iOS et Android qui calcule le layout de façon synchrone.