React Nativeは2015年3月にFacebook（現Meta）が公開したクロスプラットフォーム開発フレームワークで、Web向けライブラリReactで培われた宣言的UIの作法をそのままモバイルアプリへ持ち込みました。JavaScript（TypeScript）で書いたコンポーネントが、画面上ではiOSのUIView・AndroidのViewといった本物のネイティブUI部品にマッピングされる仕組みが特徴です。Instagram、Discord、Shopify、Microsoft Officeなど大規模アプリでの採用が続き、Web出身者が最初に選びがちな選択肢のひとつとして定着しています。
この記事の目次
- JSとネイティブUIの橋渡し
- 社内ツールから世界規模へ
- 現場での使われ方
- Flutter・ネイティブとの違い
- まとめ
JSとネイティブUIの橋渡し
React Nativeのコアは、JavaScriptで書いたコンポーネントツリーをネイティブUIへ反映する仕組みです。Reactと同じくuseStateやuseEffect、Hooksベースの設計を採用し、レンダリング結果として返されるViewやTextといった要素は、iOSではUIView、AndroidではViewGroup配下の本物のWidgetとして実体化されます。これにより、OS標準のスクロール挙動・アクセシビリティ・テキスト描画がそのまま手に入る点が、自前描画系のフレームワークと大きく異なります。
JavaScript側とネイティブ側のやり取りは、長らく非同期のJSONメッセージ「Bridge」で行われていましたが、近年は同期的にC++経由で呼び出せるJSI（JavaScript Interface）と、その上に乗る新アーキテクチャ「Fabric（UI層）」「TurboModules（モジュール層）」が段階的に既定となりつつあります。あわせて、軽量JSエンジンHermes（バイトコードプリコンパイル対応）も既定化され、起動時間とメモリ消費の改善が進みました。
社内ツールから世界規模へ
プロジェクトの原型は、2013年にFacebook社内のハッカソンで生まれた「ReactをiOSで動かす」実験でした。Web側のReactは2013年5月のJSConf USで発表され、社内で急速に普及。その流れでモバイルの世界にも持ち込もうとする取り組みが本格化し、2015年3月のF8カンファレンスで「React Native」としてOSS公開、2015年9月にAndroid版もリリースされ、Web・iOS・Androidが揃いました。
その後はBridgeのボトルネック解消を目指した長期プロジェクト「Fabric」「TurboModules」「Codegen」を含む新アーキテクチャの設計（2018年〜）、JavaScriptエンジンを既存のJavaScriptCoreからHermesへ置き換える流れ（2019年公開・2022年既定化）と進み、2024年リリースの0.76系で新アーキテクチャがデフォルトになりました。Meta自身もFacebook・Messenger・Instagram・Threads・Oculusの一部画面で運用しており、「自社で本気で使う」スタンスが世界中の採用判断を後押ししています。
現場での使われ方
現場で選ばれる典型シナリオは「Webチームがいる」「ネイティブエンジニアの採用が難しい」「OS標準UIに寄せたい」の三条件です。Reactを書ける人材は世界的に潤沢で、TypeScriptや状態管理の作法もWebと共通化できるため、組織横断のスキル流用が効きます。またShopifyのように、自社の管理画面アプリ全体をRNで再構築した事例もあり、業務系・C向け両方で実績があります。
もうひとつの利点が、既存のSwift/Kotlinアプリに対して「一部画面だけRN」と段階導入できる点です。全部を置き換えるのではなく、最初は通知設定画面やキャンペーン画面など差し替えが安全な部分から導入し、徐々にRN担当を増やすパターンが現実的です。Expoを併用すれば、Apple/Google審査を経ずにJSバンドルだけを差し替えるOTA配信（EAS Update）も可能になり、改修サイクルを短縮できます。
Flutter・ネイティブとの違い
Flutterと比較すると、React NativeはOS標準UI部品を直接使う方式のため、iOSとAndroidで自然と「らしさ」が出る一方、ピクセル単位でデザインを揃えたい場合は両OS分の調整が必要になります。Web資産（npmパッケージ、Reactの設計ノウハウ）の流用しやすさはRNが圧勝で、逆にデスクトップやWebでの完成度はFlutterの方が一歩進んでいます。
ネイティブ（Swift/Kotlin）との比較では、当然ながら最新OSのAPIに即対応できる点や、求人数の多さでネイティブが勝ります。RNは「JS側に書きたい部分」と「ネイティブで書かざるを得ない部分」を分けて運用する前提で、両方を書ける体制が理想です。プロダクトのライフサイクルやチーム構成を見て、Web人材を活かしてスピードを取るならRN、画面表現の独自性を取るならFlutter、最大性能や最新OS追随ならネイティブ、という棲み分けが現実的な解になっています。
まとめ
React Nativeは、Web開発者の作法をモバイルへ持ち込み、ネイティブUI部品との橋渡しに徹してきたフレームワークです。新アーキテクチャとHermesにより性能面の弱点が埋まり、Metaを含む大規模プロダクトで運用される実用ステージに到達しました。Web資産を活かしつつOSらしさも担保したい組織にとって、現実的な第一候補であり続けています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント