Daily-It

개발, AI, 인프라, 자동화와 일상 IT 제품 후기를 직접 써보며 정리하는 기술 블로그입니다.

React Native Nitro と TurboModule まとめ：新アーキテクチャでネイティブモジュールを選ぶ基準

概要

比較する React Native TurboModule および Nitro モジュール 現時点で、本当の問題は通常、「どのアップデートを行うか」ではなく、「その後のメンテナンスをより安定させるために、アプリまたはライブラリがネイティブモジュールの境界をどこに置くべきか」ということです。 TurboModule は、React Native New Architecture の公式ネイティブモジュール システムです。 Nitro Modules は、高速でタイプセーフなネイティブ バインディングとハイブリッド オブジェクトモデルを重視した JSI ベースのサードパーティ フレームワークです。

この記事では元記事の範囲を維持しつつ、 React Native New Architecture、JSI、Codegen、Nitro nitrogen コードジェネレーター、Swift/Kotlin/C++ のビルド要件、チームがインポートで行き詰まることが多い場所。レガシー ブリッジからNew Architectureに移行する前に、TurboModule を選択するか Nitro を評価するかを決定するのに適しています。

この記事の内容

背景

React Native を長く使っていると、JavaScript だけでは対応が難しい領域に遭遇します。代表的な例には、カメラ フレーム処理、暗号化、ローカルデータベース、センサー、BLE、画像/音声処理、プラットフォーム固有の SDK 統合などがあります。この時点で、React Native アプリは JavaScript からネイティブ API を呼び出す必要があります。

歴史的に、レガシー ネイティブモジュールは、JavaScript とネイティブ間の非同期ブリッジを介してデータをシリアル化し、交換していました。一般的なアプリの機能には十分ですが、大規模なバイナリ データや、非常に頻繁に呼び出されるネイティブ関数の場合は負担になります。新しい React Native アーキテクチャでは、この制限を軽減するために Fabric、TurboModule、Codegen、JSI などの基盤が導入されています。

韓国語原文は 2026 年 6 月 18 日に npm で確認されました react-native 最新バージョンは 0.86.0, React Native 公式ドキュメントにも、New Architecture は 0.76 からデフォルトで有効な方向に入ることが記載されています。 Nitro Modules がその時点で確認した npm の最新バージョンは、 react-native-nitro-modules@0.35.9。バージョンの移り変わりが激しい分野なので、実際に導入する前に現在のプロジェクトのReact Nativeのバージョンや使用するライブラリの要件などを確認しておいた方が安全です。

TurboModuleとは何ですか?

TurboModule は、React Native のNew Architectureでネイティブモジュールを作成する公式の方法です。主なポイントは 3 つあります。

1. TypeScript または Flow を使用して、ネイティブモジュールのインターフェイスを宣言します。 2. React Native Codegen はこの宣言を読み取り、Android/iOS 用のネイティブ インターフェイスを作成します。 3. 開発者は作成したインターフェースを実装し、型付き API のように JavaScript で呼び出します。

TurboModule を簡単に言うと、「React Native のコアによって提供される型ベースのネイティブモジュール システム」です。公式ドキュメントの例は次のとおりです NativeLocalStorage TypeScript仕様と同一のモジュールを宣言した後、Androidは SharedPreferences、iOSの場合 NSUserDefaults導入の流れを示します。

// NativeLocalStorage.ts 示例形态
import type {TurboModule} from 'react-native';
import {TurboModuleRegistry} from 'react-native';

export interface Spec extends TurboModule {
  getItem(key: string): string | null;
  setItem(value: string, key: string): void;
  removeItem(key: string): void;
  clear(): void;
}

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

TurboModule の利点は、公式サポートであることです。これは React Native コアの一部であるため、別のランタイム フレームワークに強く依存しません。New Architectureの方向性は明確であり、ライブラリの互換性に関する議論のほとんどは TurboModule/Fabric 上で行われています。

ただし、「正式な方法」は「最も簡単」という意味ではありません。 codegen 設定、Android/iOS ビルド設定、New Architectureが有効かどうか、および C++/Objective-C++/Java/Kotlin の境界が絡み合っている場合、最初の参入障壁が存在します。特に、これらの配布ライブラリは、以前のレガシー アーキテクチャをサポートするか、New Architectureのみをサポートするかを決定する必要があります。

Nitro Modulesとは何ですか?

Nitro Modules は、Margelo の Marc Rousavy によって作成された React Native モジュール フレームワークです。これは公式の React Native コア機能ではありませんが、JSI に基づいた高速でタイプセーフなネイティブ バインディングを提供することを目的としています。

ニトロの核となるコンセプトは、 Hybrid Object。 TurboModule は通常、個々のモジュールをシングルトン API として公開しますが、Nitro は、通常のオブジェクトのようなネイティブ オブジェクトを作成し、メソッドとプロパティを呼び出す JavaScript のモデルを重視しています。

// Math.nitro.ts 示例形态
import type {HybridObject} from 'react-native-nitro-modules';

export interface Math extends HybridObject<{ios: 'swift'; android: 'kotlin'}> {
  readonly pi: number;
  add(a: number, b: number): number;
}
import {NitroModules} from 'react-native-nitro-modules';
import type {Math} from './specs/Math.nitro';

const math = NitroModules.createHybridObject<Math>('Math');
const result = math.add(5, 3);

ニトロが合格する nitrogen TypeScript インターフェイスから C++、Swift、Kotlin バインディングを生成するコードジェネレーター。 iOS は Swift と C++ の相互運用を使用して Objective-C 経由のパスを減らし、Android は Kotlin/Java と C++ の相互運用をサポートします。

Nitro の公式ドキュメントには、単一のネイティブ メソッドを 100,000 回呼び出したベンチマークで、Nitro が TurboModule よりも高速な結果を示したと説明されています。ただし、この数値は「ネイティブ メソッド呼び出しのスループット」の極端な比較であり、実際のアプリのパフォーマンスは、レンダリング、ネットワーキング、データ構造、ディスク I/O、JS ロジックなどの他のボトルネックによって異なります。そのため、Nitro を選択するときは、ベンチマーク データだけを見るのではなく、まず「私のアプリは本当にネイティブ呼び出し境界でボトルネックになっているのか?」と自問する必要があります。

TurboModuleとニトロ

プロジェクト TurboModule Nitro Modules
位置 React Native 公式のNew Architecture コンポーネント JSIに基づくサードパーティフレームワーク
コード生成 React Native Codegen Nitrogen
APIモデル モジュール/関数指向、通常はシングルトンのように使用されます ハイブリッド オブジェクトを中心に、オブジェクトと属性のモデルを強調
iOSの実装 Objective-C/Objective-C++ に基づいた例が多数ありますが、Swift ではブリッジを個別に考慮する必要があります。 Swift 5.9+ と C++ の相互運用性を積極的に活用する
Androidの実装 Java/Kotlin/C++ が利用可能 Kotlin/Java/C++ が利用可能
強み 形式性、エコシステム標準、長期的な互換性 高性能呼び出し、オブジェクトモデル、タイプ セーフティ、Swift/Kotlin フレンドリーな設計
注意事項 Codegen とNew Architectureのセットアップは難しい場合があります 個々の依存関係、最小要件、急速に変化する API/ビルドの問題を確認する必要がある

TurboModule は React Native プロジェクトの基本的な方向性に準拠しています。 「ネイティブモジュールを作成する必要があるが、正式な方法で行きたい」という場合、最初に TurboModule に注目するのは自然です。

Nitro は、パフォーマンスとオブジェクトモデルが重要なライブラリにとって魅力的です。たとえば、Nitro のハイブリッド オブジェクトのアプローチは、画像オブジェクト、フレーム オブジェクト、データベース ハンドル、オーディオ バッファーなどの「JavaScript 側でネイティブ オブジェクトを継続的に搬送および操作する」モデルに適している可能性があります。

選択基準

アプリ内で軽くネイティブ API を呼ぶなら TurboModule から検討する

アプリが少数のプラットフォーム API のみを呼び出す場合、通常は TurboModule がより安全なデフォルトです。これは、React Native の公式ドキュメントとリリース ノートの変更が TurboModule に基づいて説明されており、New Architectureの一部であるためです。

たとえば、呼び出し頻度が高くなく、返されるデータが単純な場合（アプリ設定の保存、単純なデバイス情報のクエリ、内部 SDK の呼び出しなど）、多くの場合、TurboModule で十分です。

ライブラリ開発で高性能なオブジェクトモデルが必要なら Nitro を評価する

逆に、ライブラリ作成者がネイティブ オブジェクトを JavaScript に直接公開したい場合、またはネイティブ呼び出しが多すぎるとパフォーマンスのボトルネックになる場合は、Nitro を検討する価値があるかもしれません。 Nitro の開発経験は、Swift/Kotlin で最新のネイティブ コードを記述しようとしているチームにとって特に魅力的かもしれません。

ただし、Nitro は React Native の中核機能ではありません。したがって、ビルド環境の要件、バージョンの互換性、問題に対応するためにチームが負担する必要があるコストを合わせて考慮する必要があります。

Expo マネージド ワークフローのみを参考文献: 最初に互換性を確認してください

Expo アプリでもネイティブモジュールが必要になる場合がありますが、マネージド ワークフローへのネイティブ コードの追加は制限される場合があります。アクセスは、Expo Dev Client、構成プラグイン、またはプリビルドのいずれであるかによって異なります。 Nitro または TurboModule に基づくライブラリを使う場合は、まずライブラリが Expo 環境をどのようにサポートしているかを確認する必要があります。

よくある混乱と解決策

ケース 1. New Architecture を有効にしたのに TurboModule がロードされない

通常、症状は次のようになります。

TurboModuleRegistry.getEnforcing(...): 'NativeSomething' could not be found

この場合、まず「JavaScript 正規名」、「ネイティブモジュール名」、「Codegen 設定」 name/jsSrcsDir」と「パッケージ登録」で一致するか確認してください。

{
  "codegenConfig": {
    "name": "NativeLocalStorageSpec",
    "type": "modules",
    "jsSrcsDir": "specs",
    "android": {
      "javaPackageName": "com.nativelocalstorage"
    }
  }
}

ここでの一般的な問題点は、正規のファイルの場所とモジュール名です。 TurboModuleRegistry.getEnforcing&lt;Spec&gt;(&#x27;NativeLocalStorage&#x27;)で使用される文字列とネイティブ実装 NAME異なる場合、モジュールは実行時に見つかりません。多くの場合、生成されたコードを反映するには、各 Android/iOS のクリーン ビルドが必要です。

ケース 2. Codegen が TypeScript 型を処理できない

React Native GitHub の問題では、特定のインポートされた型、複雑な共用体、マップ/null を処理するときに、Codegen が予想とは異なる動作をする場合が依然としてあります。すべての TypeScript 式が自然にネイティブ バインディングに変換されるわけではありません。

この問題を解決するための最初のステップは、仕様を簡素化することです。

// 尽量避免：直接在 spec 中使用外部复杂类型
import type {ExternalComplexType} from './types';

export interface Spec extends TurboModule {
  save(value: ExternalComplexType): void;
}
// 更安全：把边界定义成 Codegen 更容易理解的结构
export type SavePayload = {
  id: string;
  name: string;
  count?: number;
};

export interface Spec extends TurboModule {
  save(value: SavePayload): void;
}

複雑なオブジェクトをそのまま渡すのではなく、ネイティブ境界で必要な値のみを明示的に定義することで、ビルド エラーやプラットフォーム固有の違いを減らすことができます。

ケース 3. Nitro 導入後に iOS/Android ビルドが失敗する

Nitro は、最新の JSI、C++、Swift/Kotlin、NDK/Xcode 環境に依存しています。公式ドキュメントによると、Nitro では React Native 0.75 以降、iOS では Xcode 16.4 以降と Swift 5.9 以降、Android では compileSdkVersion 34 以上および NDK 27 以上が必要です。

最初に実際のバージョンを確認します。

node -v
npm view react-native version
npm view react-native-nitro-modules version

アンドロイドで compileSdkVersion, ndkVersion、CMake/Gradle ログを確認すると、iOS では、Xcode Report Navigator の実際に失敗したコンパイル ログに最後のエラーが表示されるはずです。 「ビルド失敗」は単なるタイトルであり、理由ではありません。

特に、Nitro GitHub の問題を見ると、Swift C++ 相互運用性、生成されたヘッダーの競合、Android NDK/16KB ページ サイズなど、ネイティブ ビルド レイヤの問題が発生しています。この問題は、JavaScript コードを見るだけでは解決するのが困難です。最小要件を満たしてもまだ失敗する場合は、実際のエラー行と React Native/Nitro/Xcode/NDK のバージョンを整理して、問題を検索する方が早くなります。

ベストプラクティス

ネイティブ境界を小さく明確にする

TurboModule であっても Nitro であっても、JavaScript とネイティブの間の API は小さく、明確である必要があります。 JS オブジェクト全体を渡すのではなく、ネイティブで必要な値のみを渡す方が、デバッグと型の保守に有利です。

パフォーマンス問題は先に測定する

Nitro が高速ベンチマークを提供するからといって、すべてのアプリを Nitro に切り替える必要があるというわけではありません。まず、ネイティブ呼び出しがボトルネックなのか、レンダリングがボトルネックなのか、それとも DB クエリがボトルネックなのかを測定する必要があります。呼び出される頻度が低い関数の場合、TurboModule の形式性と保守性の方が大きな利点となる可能性があります。

ライブラリ選定時は New Architecture 対応状況を確認する

React Native 0.76 以降、New Architectureの基本的なアクティベーション プロセスが強化されているため、古いネイティブ ライブラリではビルド時または実行時に問題が発生する可能性があります。ライブラリを選択するときは、New Architectureのサポート、最新のリリース日、未解決の問題、RN バージョンの互換性範囲について README を確認する必要があります。

FAQ

TurboModule と Nitro は置き換え関係ですか？

まったく同じテクノロジー層ではありません。 TurboModule は React Native の公式ネイティブモジュール システムですが、Nitro は JSI 上で高速なオブジェクト指向バインディングを提供するスタンドアロン フレームワークです。 TurboModule は単純なアプリ内モジュールに適していますが、Nitro は高パフォーマンスのオブジェクトモデルを必要とするライブラリに適している可能性があります。

React Native New Architecture を無効にしても TurboModule は使えますか？

一般に、TurboModule をNew Architecture フローと合わせて検討するのは正しいことです。公式ドキュメントでは、New Architecture専用の Turbo Native Module サンプルと、古いアーキテクチャをサポートする別の互換性ガイドを区別しています。既存のアプリが両方をサポートする必要がある場合は、別の互換性レイヤーを設計する必要があります。

Nitro を使えばアプリは必ず速くなりますか？

いいえ、Nitro の強みは、ネイティブの呼び出し境界とオブジェクトモデルにあります。アプリのボトルネックがレンダリング、ネットワーキング、サーバー応答、DB 設計、または JS 状態管理である場合、Nitro を導入しても体感的なパフォーマンスは大きく変わらない可能性があります。

新規 React Native ライブラリでは何を選ぶべきですか？

公式エコシステムとの長期的な互換性が最優先事項である場合は、まず TurboModule を検討してください。一方、画像/ビデオ/オーディオ/フレーム処理などのネイティブ オブジェクトを継続的に処理し、頻繁に呼び出されるライブラリであれば、Nitro を選択する価値のあるライブラリです。ただし、チームは運用上の負担に対処するために、Swift C++ 相互運用機能、Android NDK、および CMake ログを表示できる必要があります。

結論

React Native では、TurboModule は「正式なNew Architectureのネイティブモジュール標準」に近く、Nitro Modules は「JSI に基づく高性能オブジェクト バインディング フレームワーク」に近いです。両者は橋梁時代の制約を緩和するという方向性は同じだが、選定基準が異なる。

アプリで単純なネイティブ API に接続している場合は、TurboModule から始める方が安全です。一方、JavaScript でネイティブ オブジェクトを長期間持ち運んで頻繁に呼び出す必要がある場合、またはライブラリ レベルのパフォーマンスと型安全性に対する強い要件がある場合は、Nitro を検討する価値があります。テクノロジーの名前だけに基づいて選択するのではなく、現在のプロジェクトの React Native バージョン、ビルド環境、チームのネイティブ デバッグ機能、実際のパフォーマンスのボトルネックにも基づいて選択することが重要です。

参考文献

韓国語原文：この記事は韓国語原文をもとに、日本語読者向けに用語、確認手順、注意点を整理しています。韓国語原文を見る。