Nitro Modules

Le framework de Margelo pour écrire des modules natifs en Swift, Kotlin ou C++ exposés à JavaScript via JSI, avec des bindings générés depuis TypeScript.

Mis à jour le 26 octobre 2026

Définition

Nitro Modules est un framework de Margelo pour écrire des modules natifs React Native en Swift, Kotlin ou C++. Un module Nitro contient des Hybrid Objects : des objets natifs dont les méthodes et propriétés sont exposées directement à JavaScript via JSI, en s’appuyant sur jsi::NativeState plutôt que sur un HostObject. L’interface TypeScript est la source de vérité : Nitrogen, le générateur de code, en produit les bindings natifs, et un code Swift ou Kotlin qui ne respecte pas les types déclarés ne compile pas. Nitro parle à Swift par l’interopérabilité Swift/C++ et à Kotlin via fbjni, sans Objective-C ni Java intermédiaire, ce qui explique l’écart de ses benchmarks avec les Turbo Modules (7,27 ms contre 115,86 ms pour 100 000 appels d’addition, un cas extrême selon la doc). Il demande React Native 0.75 ou plus, Xcode 16.4 et Swift 5.9 ou plus, compileSdk 34 et NDK 27. Vous le rencontrez dans des librairies récentes comme react-native-mmkv, ou quand un module maison doit être appelé très souvent.

Dans une vraie app

Un module Nitro se reconnaît à ses fichiers *.nitro.ts (les specs), à un nitro.json à la racine et à la commande npx nitrogen qui génère le code natif. Le projet consommateur installe react-native-nitro-modules comme dépendance, et chaque librairie Nitro en dépend aussi. Côté JavaScript, un Hybrid Object s’instancie avec NitroModules.createHybridObject<Type>("Nom"), et son cycle de vie est lié au ramasse-miettes de l’app.

Le choix se fait sur le profil d’appel. Pour une API appelée quelques fois par écran, l’Expo Modules API ou un Turbo Module font le même travail avec un outillage plus répandu. Nitro prend l’avantage quand les appels sont synchrones et fréquents (stockage clé-valeur lu à chaque rendu, traitement d’images, audio), ou quand le natif doit tenir des objets avec état et les renvoyer à JavaScript sans sérialisation. Le prix : une chaîne d’outils plus exigeante (versions d’Xcode et du NDK), du Swift et du Kotlin modernes obligatoires, et une base de contributeurs plus petite que celle d’Expo.

En audit, je regarde si les versions minimales sont respectées dans expo-build-properties ou dans le Podfile et build.gradle, si nitrogen est bien exécuté dans les scripts de build (ou si les fichiers générés sont committés, ce qui est acceptable), et si une librairie Nitro et une librairie Turbo ne se disputent pas la même ressource native.

Sources

Les 35 termes du glossaire

Dans une vraie app

Termes liés

Sources

Un de ces sujets bloque votre app ?