React Nativeは終わった？サポート終了？まったく違います。
今でも「React Nativeはサポートが終了した」「もう使われていない」「終わった技術だ」と思っている人をよく見かけます。
しかし、これは事実ではありません。実際、React Nativeは今でも継続的にアップデートされています。
えっ… まだReact Nativeがサポート終了だと思っている人がこんなに多いなんて…
なぜ「React Nativeは終わった」と言われるのか？
React Nativeを開発したMetaは、最近リリースしたアプリ「Threads」を主にネイティブ技術（Swift、Kotlin、Jetpack Compose）で構築しました。
このことから「MetaでさえReact Nativeを捨てた」という噂が広まり、そうした印象を持つ人が増えたのだと思われます。
ですが、これは半分だけ正しい話です。
Threadsアプリの主要な画面がネイティブで作られているのは事実です。
Emerge Toolsの分析によれば、ThreadsはiOSでSwift（および一部Objective-C）、AndroidでKotlinとJetpack Composeを使用しています。
アプリの大部分はネイティブで作られており、iOSではSwift（一部Objective-C）、AndroidではJetpack Compose（KotlinとJava）を使用している。
シンプルな体験向けに一部サーバーレンダリング画面が共有されているが、基本はネイティブである。
一部のコミュニティでは、Facebookアプリをデコンパイルした際に「React Nativeのコードがほとんどなく、ほぼネイティブで構成されている」という報告もあります。
しかしこれはFacebook公式の立場とは異なります。Metaの開発チームは、むしろReact Nativeを積極的に使用していると述べています。
実はMetaは今もReact Nativeを積極的に使っています
Instagramでも積極的に活用されています！
Instagramエンジニアリングブログによると、React Nativeの導入によって開発スピードが大幅に向上したと報告されています。
Instagramチームは2016年初頭からReact Nativeを導入し、iOSとAndroidで同じコードを再利用しながら機能を迅速にリリースできるかを実験しました。
当時のInstagramエンジニアリングチームは「既存のネイティブアプリにReact Nativeを統合するのは、新しいアプリを作るより難しい」と認めつつも、最も単純な画面である**プッシュ通知設定（Push Notification Settings）**から移行を始めました。
もともとこの画面はWebViewで実装されていたため、React Nativeを導入した際の性能改善を測定するには最適な対象でした。
その結果、InstagramチームはReact Nativeの多くの利点を直接確認しました：
-
ホットリロード（Hot Reloading） と ライブリロード（Live Reload） により、コンパイルや再インストールを行わずに即座に変更結果を確認できるようになりました。
-
共通コードの再利用率が非常に高く、iOSとAndroidで同時に機能をリリース可能になりました。
例えば以下の通りです：-
Post Promote: 99%
-
SMS Captcha Checkpoint: 97%
-
Comment Moderation: 85%
-
Lead Gen Ads: 87%
-
Push Notification Settings: 92%
→ 多くの機能で80%以上のコードを共有。
-
-
WebView時代と比べて**起動速度（start-up time）**が向上し、UXの品質も改善されました。
Instagramはその後も Edit Profile, Photos Of, Post Promote, Save, Comment Moderation, Lead Gen Ads などをReact Nativeで移植し、
ネイティブと見分けがつかない体験を維持しながら開発効率を大幅に高めたと報告しています。
Facebookでも積極的に使われています！
React Nativeは単なる実験的技術ではなく、Meta社内でも主要サービスに継続的に活用されている中核技術スタックです。
Meta公式ブログ Meet the Developers – React @ Meta Edition によると、
Facebook Marketplaceチームのフロントエンドエンジニア Blair Vanderhoof 氏は、過去7年間にわたりMarketplaceの多くの機能をReact Nativeで構築・改善してきたと述べています。
彼はこう語っています。
「私はFacebook Marketplaceで、セラーハブ画面（Seller Hub）、商品詳細ページのトランジションアニメーション、フィード項目UI、相手のプロフィール画面など、多くの機能をReact Nativeで開発しました。」
「私はJavaScriptでUIを完全に制御することを好むため、ネイティブコードをほとんど書かず、ほぼすべてをReactで構築しています。」
— Blair Vanderhoof, Frontend Engineer at Meta
つまりFacebook Marketplaceアプリは、React Nativeベースの画面と機能が広範囲に採用されているMetaを代表するプロダクトです。
MarketplaceチームはMeta内部のReact Nativeインフラチームと密接に協力し、
アニメーションやジェスチャー、画面遷移などの複雑なインタラクションをReact Native + PanResponder APIで実装しています。
特にBlair氏はこう強調しています。
「React NativeはFacebook Marketplaceの急速な成長を支え、
買い手と売り手双方のニーズを満たす豊富でインタラクティブなUIを素早く開発・デザインできるようにした。」
さらにMeta内部では、Marketplaceをはじめ多くのモバイル機能で標準技術スタックとしてReact Nativeが採用されており、
React Hooks、Context API、Relayなどの最新Reactエコシステムの要素もモバイル環境にそのまま適用されています。
つまり「MetaはReact Nativeを捨てた」という噂とは異なり、
Facebook Marketplaceをはじめ実際のプロダクションレベルのサービスで今も活発に利用されており、
Metaのエンジニアたちは現在もReact Nativeの改良・発展に貢献しているのです。
もちろん、世論と公式見解の差があるのは理解できます。Metaの技術だから、自社としてReact Nativeを推すのは当然ですからね😉
結論：MetaはReact Nativeを捨てていません
MetaはReact Nativeを完全に放棄したのではなく、製品の性質に応じて適切な技術を選択しているのです。
多くのエンジニアが「ネイティブ言語で書いたアプリが最も優れている」と同意するでしょう。
しかし、React Nativeはクロスプラットフォームを目的に設計されたフレームワークであり、1つのコードでiOSとAndroid両方を開発できるという点は依然として大きな強みです。
特に既にReactを使っているWeb開発者がモバイルアプリへ容易に拡張できる点、
つまり既存のエコシステムと学習コストをそのまま活用できることは大きなメリットです。
少人数・低予算でもMVPを迅速に構築したり、既存サービスをモバイル展開する際に、React Nativeはコスト効率の良い代替技術として非常に有用です。
実際、React Nativeは今も定期的にアップデートされており、
毎年開催されるReact関連カンファレンスでも継続的に紹介されています。
React Native Connection 2025
2025年4月3日（Reanimated Training）＋ 4日（Conference）– フランス・パリ
Website - X - Bluesky
React Native London Conf 2024
2024年11月14日＆15日 – イギリス・ロンドン（対面開催）
Website - Twitter
React Native EU 2023
2023年9月7日＆8日 – ポーランド・ヴロツワフ
Website - Twitter - Facebook
React Native EU 2022: Powered by callstack
2022年9月1〜2日 – オンライン開催
Website - Twitter - Linkedin - Facebook - Instagram
さて、クロスプラットフォームを実現するのはReact Nativeだけではありません。代表的な競合がFlutterです。
React Native vs Flutter
React NativeとFlutterは、React Nativeの評判が下がるまでは長い間ライバル関係にありました。
しかし近年のトレンドを見ると、Flutterが勢いを増しているのは事実です。
| 区分 | React Native | Flutter |
|---|---|---|
| 開発元 / 年 | Meta（Facebook）/ 2013年 | Google / 2017年 |
| 言語 | JavaScript + JSX | Dart |
| レンダリング方式 | JavaScript Bridgeを介してネイティブコンポーネントを呼び出す（Fluxアーキテクチャ） | Skia 2Dレンダリングエンジンによる独自UI描画 |
| UI構築方式 | ネイティブUI要素を呼び出して接続 | Flutterウィジェットシステムで完全に統一されたUIを構築 |
| ホットリロード | 対応（Live Reload含む） | 対応（より高速かつ安定） |
| 3Dグラフィック対応 | 比較的強い（ネイティブAPIにアクセス可能） | 限定的（2D中心のウィジェット） |
| パフォーマンス | JS Bridgeによる若干のオーバーヘッドあり | ネイティブ並みのパフォーマンス（ARMコードへ直接コンパイル） |
| エコシステム / コミュニティ | 非常に大規模で成熟（豊富なサードパーティライブラリ） | 成長中だがまだ規模は小さい |
| ドキュメント / 公式資料 | 公式は簡潔だがサードパーティ依存が高い | Google主導で体系的に整備された公式ドキュメント |
| インストール方法 | Node.js + npmで簡単に導入可能 | SDKダウンロード＋環境変数設定が必要（やや複雑） |
| テストツール | Detoxなど外部ツールが必要 | 統合テスト機能を標準搭載（Unit・Widget・Integration Test） |
| 学習難易度 | JavaScriptベースなので学びやすい | Dart言語習得が必要（追加の学習コスト） |
| 主な採用企業 | Meta（Facebook, Instagram）, Uber, Walmartなど | Google, Alibaba, BMW, eBayなど |
| 平均年収（米国） | 約 $93,000 / 年 | 約 $89,000 / 年 |
| 強みまとめ | ✅ JavaScript基盤で参入しやすい | |
| ✅ ネイティブUIを活用 | ||
| ✅ コミュニティが巨大 | ✅ UIの一貫性 | |
| ✅ 高性能レンダリング | ||
| ✅ テスト環境が充実 | ||
| 弱みまとめ | ❌ Bridgeによるパフォーマンス低下 | |
| ❌ 依存管理が複雑 | ||
| ❌ ドキュメントの統一性不足 | ❌ Dartの学習コスト | |
| ❌ アプリサイズが大きい | ||
| ❌ 一部ネイティブ機能に制限あり |
参考: React Native vs Flutter in 2025 - Make the RIGHT Choice (Difference Explained)
React Native vs Flutter どちらを選ぶべき？
React NativeとFlutterは異なる思想から生まれましたが、最終的な目的は同じです。
それは「1つのコードでAndroidとiOSの両方をカバーすること」。
どちらも高い生産性を誇りますが、チームの技術スタックとプロジェクト特性によって最適な選択は変わります。
✅ React Nativeを選ぶべきケース
-
JavaScriptやReactエコシステムに既に慣れているチーム
-
既存のWebコードを再利用したい、またはReact UIパターンをモバイルに拡張したい場合
-
大規模なコミュニティとオープンソース資源を活かしたい場合
✅ Flutterを選ぶべきケース
-
デザインの一貫性が重要、またはUIが複雑なアプリを開発する場合
-
Dartの習得コストはあるが、一度学べばAndroid・iOS・Web・デスクトップに展開可能
-
SkiaエンジンによるGPUアクセラレーションで滑らかなアニメーションを実現
-
高速な起動とモダンなUIが求められるアプリ（デザインツール、可視化アプリなど）に適しています。
2025年、"正解"はないが"戦略"はある
結局、React NativeとFlutterは「どちらが勝ち」ではありません。
React Nativeは成熟したエコシステムと豊富なプロジェクト経験により安定性を確保し、
Flutterは性能とUI一貫性の面で急速に進化しています。
React Nativeは今も「業界で最も広く使われるクロスプラットフォームフレームワーク」。
Flutterは「デザイン重視アプリのパフォーマンスリーダー」として確立されています。
プロジェクトの規模、チームのスキル、デプロイ環境、保守性を考