Turbo Modules

Dans un projet, un Turbo Module se repère à la clé codegenConfig de son package.json (avec type: "modules" et un jsSrcsDir) et à un fichier de spec dont le nom commence par Native, par exemple specs/NativeLocalStorage.ts. Côté iOS la classe est en .mm et adopte le protocole généré ; côté Android elle étend la classe abstraite générée et est enregistrée dans un BaseReactPackage. Codegen tourne à chaque build (tâche Gradle sur Android, phase de script au pod install sur iOS), donc une spec qui ne compile pas casse le build natif, pas l’app au runtime.

Le piège le plus courant : utiliser getEnforcing dans une librairie optionnelle. Si le module natif n’est pas linké (mauvais autolinking, monorepo mal configuré), l’app crashe au premier import avec un message peu parlant. get renvoie null et laisse le choix d’un fallback. Autre point, les types : une méthode qui renvoie Promise<Object> en spec devient un NSDictionary ou une WritableMap côté natif ; les types riches ne traversent pas tels quels.

Pour un nouveau module aujourd’hui, le choix se fait entre un Turbo Module « pur » (utile si vous avez du C++ à partager), l’Expo Modules API (DSL Swift/Kotlin, moins de boilerplate) et Nitro Modules (Swift/Kotlin natifs via JSI, le plus rapide sur les appels fréquents). Les trois reposent sur JSI ; la doc React Native recommande les Turbo Modules si vous comptez écrire du C++.