FlutterとReact Nativeの違いと選び方|2026年の判断基準
FlutterとReact Nativeは、どちらも1つのコードでiOSとAndroidのアプリを作るための道具です。ただし両者は同じ問題を別の方法で解いており、比べるべきポイントは機能の多さではありません。決定的に違うのは「画面のピクセルを誰が描くか」という1点で、言語の違いも、UIの再現性も、性能の議論も、すべてここから派生します。この記事では2026年7月時点の仕様を一次情報で確認したうえで、選定の判断基準までを整理します。
まとめ
React NativeはMetaが開発するフレームワークで、OSが持つネイティブUI部品をJavaScript側から操作します。FlutterはGoogleが開発し、自前のレンダリングエンジンImpellerで画面全体を描きます。この違いから、既存のWeb・Reactの資産とチームをそのまま生かしたいならReact Native、OS間で寸分違わぬ同一デザインを再現したいならFlutter。選定はここでほぼ決まります。
2026年に注意すべきなのは、数年前の比較記事がほぼ使えなくなっている点です。React Nativeは0.82でレガシーアーキテクチャへの後戻りができなくなり、公式は素のReact Nativeではなくフレームワーク経由での開始を推奨しています。Flutterは3.27以降Impellerが既定で、旧来の「Skiaのシェーダコンパイルによるカクつき」を前提とした議論が成り立ちません。
UIを誰が描くかという根本差:ネイティブ部品の操作か、自前描画か
まず両者の素性を押さえます。React Nativeは2015年3月にFacebook(現Meta)がオープンソース公開したフレームワークで、ライセンスはMITです。FlutterはGoogleが開発し、2018年12月に1.0が安定版となりました。ライセンスはBSD-3-Clauseです。どちらも企業が自社プロダクトで使い続けている点は後述します。
React Nativeの描画:OSのUI部品をJavaScriptから動かす
React Nativeで書いた<Text>や<View>は、実行時にiOSならUIView、Androidならandroid.view.View系の実物へ対応づけられます。画面に出ているのはOSが用意した本物のUI部品です。
この設計の利点は、OSがバージョンアップしてデザインや操作感を変えたとき、アプリ側が何もしなくても追随することにあります。文字選択の挙動、アクセシビリティ、日本語入力の変換候補の出方といった、自前で再実装すると必ず粗が出る領域をOSに任せられるわけです。裏返せば、iOSとAndroidで見た目が完全には揃いません。揃えたい場合はプラットフォームごとの分岐を書くことになります。
Flutterの描画:Impellerが全ピクセルを自前で描く
FlutterはOSのUI部品を使いません。キャンバスを1枚もらい、ボタンもテキストも自前で描きます。描画を担うのがImpellerで、Impellerの公式ドキュメントによればFlutter 3.27以降、iOSとAndroid API 29以上で既定のレンダリングエンジンです。iOSではImpellerのみが提供され、Skiaへの切り替えはできません。AndroidではAPI 29以上かつVulkan対応の端末でImpellerが動き、それ以外は従来のOpenGLレンダラへ自動的にフォールバックします。なおWeb向けビルドは現在もSkiaを使い、macOSはフラグ付きの提供です。
全部自前で描くので、iOSでもAndroidでも同じ見た目になります。デザイン確認をOSごとに二重で行う必要がなくなる点は、実務では相応に効いてきます。一方、OS側の新しいUI仕様に追随するのはFlutterチームの実装待ちです。
「FlutterはReactに似ている」と言われる理由と、似ていない部分
似ているのは記述モデルです。どちらも状態から画面を組み立てる宣言的UIで、小さな部品を入れ子にして画面を作ります。ReactのコンポーネントとFlutterのウィジェットは、役割としてはほぼ同じものだと考えて差し支えありません。最小のコードを並べると構造の近さが分かります。
// React Native
<View style={styles.box}>
<Text>Hello</Text>
</View>
// Flutter
Container(
child: Text('Hello'),
)
似ていないのは、その下の層です。Reactは「何を描くか」を宣言してレンダラ(DOMやネイティブ部品)に委ねますが、Flutterは宣言の下に描画エンジンまで自分で抱えています。前節の根本差がここに効いてきます。したがって「似ている」からといってReact Nativeの知見がFlutterへそのまま移るわけではありません。移るのは設計の考え方で、移らないのはライブラリ・ツール・デバッグ手法です。状態管理も別物で、Flutter側の定番はRiverpodをはじめとする状態管理ライブラリになります。
使用言語とReact資産の引き継ぎやすさ
React NativeのTypeScriptとFlutterのDart 3.12
React NativeはJavaScriptとTypeScriptで書きます。実務ではTypeScriptが標準で、@types配下の型定義もESLint設定もテストの書き方も、Web側で使っているものをほぼそのまま持ち込めます。FlutterはDart専用です。2026年7月20日にリリースされたFlutter 3.44.7に同梱されるのはDart 3.12.2で、Dartの習得自体はTypeScript経験者なら難所が少ない言語です。
差が出るのは言語の難易度ではありません。周辺資産の量です。npmのエコシステムをそのまま使えるReact Nativeに対し、Flutterはpub.devの世界で揃え直すことになります。社内にWebフロントエンドの蓄積があるほど、この差は移行コストとして効いてきます。
ReactとReact Nativeの違い:共通するのは記述モデルだけ
ReactとReact Nativeを同じものだと考えると見積もりを外します。共通なのはコンポーネント・フック・状態管理といった記述モデルで、画面を構成する部品は別物です。Webの<div>や<span>はReact Nativeには存在せず、<View>と<Text>に置き換わります。CSSも使えず、スタイルはJavaScriptのオブジェクトで書きます。
そのため、既存のReact WebアプリをReact Nativeへ持っていくとき、再利用できるのはビジネスロジック・API通信・状態管理・型定義までで、画面は作り直しです。逆にいえばロジック層の共通化には確かな効果があり、ここを設計で分離しておくかどうかが移植コストを大きく変えます。ロジックをWebと共通化しておくと、React Compilerによる自動メモ化のようなWeb側の最適化の知見もそのまま効いてきます。
2026年に古い比較記事が使えなくなった3つの変化
FlutterとReact Nativeの比較記事は数が多い一方、前提が古いまま残っているものが目立ちます。判断を誤らせやすい変化を3つ挙げます。
New Architecture必須化でBridgeの議論が終わった
React Nativeの弱点として長く語られてきたのが、JavaScript側とネイティブ側を非同期のJSONでやり取りする「Bridge」の存在でした。これはNew Architecture(JSI・TurboModules・Fabric)への移行で置き換え済みです。React Nativeの新アーキテクチャ作業部会のDiscussion #309によれば、0.82でnewArchEnabledをfalseにしても効果がなくなり、レガシーアーキテクチャへ戻す選択肢自体が消えました。0.83からはレガシーアーキテクチャのクラス削除も始まっています(既存ライブラリのためのinterop層は当面残ります)。
つまり「React NativeはBridgeがボトルネックだからFlutterが速い」という比較軸は、2026年時点では成立しません。この一文を根拠にしている比較記事は、それだけで内容が古いと判断してよい記述です。
React Nativeの標準的な始め方がフレームワーク前提になった
React Nativeの公式のGet Startedは、新規アプリを作る場合にフレームワークの利用を推奨しています。「フレームワークなしでも使えるが、新しいアプリを作るならフレームワークを推奨する」と明記され、フレームワークを使わない場合は中核機能を自作するか既存ライブラリを寄せ集めることになる、と理由まで書かれています。
実質的な標準はExpoです。したがって「React Nativeはビルド環境の構築が大変」という評価も現状に合いません。比較するなら素のReact NativeではなくExpoを含めた状態で見るべきで、バージョン対応関係はExpo SDK 56の新機能と変更点まとめが参考になります。ネイティブUIをそのまま描画するExpo UI(@expo/ui)のような選択肢も増えています。
Impeller既定化でシェーダジャンクの前提が変わった
Flutter側で古くなっているのは、Skia時代に起きていた初回アニメーション時のカクつき(シェーダコンパイルジャンク)を前提にした指摘です。Impellerはシェーダをビルド時に事前コンパイルする方式で、3.27以降は対象プラットフォームで既定になりました。対象端末がAndroid API 29以上かつVulkan対応であれば、「Flutterは初回だけ引っかかるので事前ウォームアップが必要」という運用ノウハウはもう必要ありません。
逆に、想定ユーザーの端末分布が古くVulkan非対応機が多く残る場合は、OpenGLへのフォールバックが働いて挙動が変わりえます。バージョンごとの改善内容はFlutter 3.41が2026年2月安定版で示した開発者体験の改善ポイントにまとめています。
選定の判断基準:Flutter vs React Nativeを決める条件
| 観点 | React Native | Flutter |
|---|---|---|
| 開発元 | Meta | |
| 画面の実体 | OSのネイティブUI部品 | Impellerによる自前描画 |
| 言語 | TypeScript / JavaScript | Dart 3.12.2 |
| OS間の見た目 | OSごとに差が出る | 実装どおりに統一できる |
| OS更新への追随 | 自動で追随 | Flutterの実装待ち |
| 既存Web資産 | npm・型定義を流用可 | pub.devで再構築 |
| 最新安定版 | 0.86.0(2026-06-11) | 3.44.7(2026-07-20) |
上から6行目までは独立した判断材料ではなく、上から順に効きます。画面の実体をどちらにするかを決めれば、残りはほぼ自動的に決まります。最終行は本記事の確認時点の版です。
React Nativeが有利な条件
社内にReactまたはTypeScriptの開発者がいる場合、React Nativeを選ぶ理由が最も強くなります。人を採り直さずに始められ、Web側のロジックとテスト資産を持ち込めるからです。加えて、フォームやリスト中心の業務アプリのようにOS標準の操作感をそのまま出したいアプリ、OSの新機能へ早く追随したいアプリもReact Native向きです。
Flutterが有利な条件
デザインの再現性が要件になっているなら、Flutterを選びます。ブランドのデザインシステムをiOSとAndroidで差なく出したい、あるいはアニメーションやカスタム描画が体験の中心にあるアプリでは、全ピクセルを自分で描ける利点が他の要素を上回るためです。設計方針はFlutterにおけるアーキテクチャ設計の基本と重要性で整理しています。
どちらも選ぶべきでない場面
次の条件に当てはまるなら、クロスプラットフォームは採用しないほうが結果的に安く済みます。
- 対応するのが片方のOSだけで、当面もう一方を出す予定がない
- カメラ・センサー・Bluetooth・バックグラウンド処理など、OS固有APIの深い制御がアプリの中心機能である
- OSのベータ版が出た初日に対応する必要がある
- アプリ本体が小さく、クロスプラットフォーム層の学習と保守コストのほうが実装量を上回る
特に1つ目は判断を誤りやすいところです。「将来Androidも出すかもしれない」という不確定な予定のためにクロスプラットフォームを選ぶと、結局iOSしか出さないまま抽象化のコストだけを払い続けることになります。もう一方のOSの計画が具体化していないなら、素直にネイティブで作るほうが速い。ここは要件定義の段階で潰しておくべき論点です。
FlutterとReact Nativeの弱点
Flutterの弱点:エンジン同梱によるサイズとOS追随の遅れ
最大の弱点は、OSのUI部品を使わないことの裏返しです。OSが新しいUIコンポーネントや挙動を追加したとき、Flutter側で再実装されるまで使えません。アプリサイズにも下限があります。Flutter公式FAQによれば、Materialコンポーネントを使わない最小構成のリリースAPKでARM32が約4.3MB、ARM64が約4.8MBで、うちコアエンジンがARM32で約3.4MBを占めます。iOSのIPAはダウンロードサイズ10.9MB(iPhone X、2021年3月の計測値)です。小さなユーティリティアプリではこの下限が相対的に重くなります。
Web向けビルドが今もSkiaを使う点にも注意が必要です。モバイルでの性能特性がそのままWebには当てはまりません。
React Nativeの弱点:UI分岐とバージョン追随の負荷
OS間でUIが揃わないため、両OSで同じデザインを厳密に求められると分岐コードが増えます。ネイティブモジュールに依存する箇所は結局SwiftやKotlinを書くことになり、チームに両OSの知識が要ります。
運用コストとして具体的に効くのはリリース間隔です。React Nativeのマイナー版は0.83.0が2025年12月10日、0.84.0が2026年2月11日、0.85.0が2026年4月8日、0.86.0が2026年6月11日と、おおむね2か月間隔で出ています。0.82・0.83で起きたアーキテクチャ変更のように、追随を怠ると後からまとめて負債を払う形になるため、四半期ごとにバージョンアップ工数を確保しておく前提で見積もるのが安全です。
将来性の判断材料
「React Nativeはオワコンか」「Flutterの将来性は」といった問いは、求人数のような外形的な数字で測ろうとすると当てになりません。数字の出どころが調査ごとに違い、時期によって逆転するためです。判断材料として確実なのは、開発体制と採用実績が実際に動いているかどうかです。
リリースの実績では、両者とも活発です。React Nativeは前述のとおり約2か月間隔でマイナー版を出し、New Architectureへの移行という数年がかりの作業を0.82・0.83で完了段階まで進めました。Flutterは3.44.7が2026年7月20日の安定版で、Impellerの適用範囲を広げ続けています。どちらも保守モードには入っていません。
採用実績も公式ショーケースで確認できます。React NativeのショーケースにはInstagram、Microsoft Office、Amazon Shopping、Shopifyが挙がり、FlutterのショーケースにはGoogle Pay、Google Earth、Toyota、BMW、Alibaba Group、Nubank、Supercellが並びます。開発元が自社の主力プロダクトで使っている点は、どちらにも共通します。数年で開発が止まる心配より、バージョン追随の運用体制を作れるかどうかのほうが現実的な課題です。
よくある質問
React NativeとFlutterの違いは何ですか?
開発元と描画方式が違います。React NativeはMetaが開発し、OSのネイティブUI部品をJavaScript/TypeScriptから操作します。FlutterはGoogleが開発し、Dartで書いたコードをImpellerという自前のレンダリングエンジンで描画します。ここから、React NativeはOS標準の見た目と挙動に自動で追随し、Flutterは両OSで同じ見た目を実装どおりに再現できる、という差が生まれます。
React Nativeで開発できる言語は何ですか?
アプリ本体はJavaScriptまたはTypeScriptで書きます。ただしカメラやBluetoothなどOS固有の機能を呼ぶネイティブモジュールを自作する場合は、iOS側でSwiftまたはObjective-C、Android側でKotlinまたはJavaを書くことになります。多くのアプリは既存ライブラリで足りるため、TypeScriptだけで完結することも十分あります。
Flutterの弱点は何ですか?
OSの新しいUI部品がFlutter側で再実装されるまで使えない点、描画エンジンを同梱するためアプリサイズに下限がある点(最小構成のAPKでARM32約4.3MB)、そしてWeb向けビルドが今もSkiaを使うためモバイルの性能特性がWebに当てはまらない点です。日本語の技術情報がReact系ほど蓄積されていないため、詰まったときは英語の公式ドキュメントやissueを読む前提になります。
既存のReact WebアプリをReact Nativeへ移植できますか?
画面部分はそのままでは動きません。<div>などのHTML要素とCSSがReact Nativeには存在しないためです。移植できるのはAPI通信・状態管理・バリデーション・型定義といったロジック層で、ここを画面から分離して書いてあるプロジェクトほど再利用率が上がります。移植計画を立てるときは、まずロジックと画面の結合度を確認してください。
FlutterのWeb対応はReactの代わりになりますか?
一般的なWebサイトの用途では代わりになりません。Flutter Webはキャンバスへ描画する方式で、通常のDOMを組み立てるReactとは出力が異なり、SEOや既存のWeb資産との相性で不利になります。社内管理画面やモバイルアプリと同一UIを配りたいケースなど、用途を限定すれば選択肢になります。Web中心のプロダクトであればReactを使うのが妥当です。
「Material UI」と「Dart」を比較する意味はありますか?
この2つは比較対象になりません。Material UI(MUI)はReact向けのWeb用UIコンポーネントライブラリで、Dartはプログラミング言語です。層が違います。比べるとすれば、言語同士ならDartとTypeScript、UI部品同士ならFlutterのMaterialウィジェットとMUIという組み合わせになります。FlutterはMaterial Designの実装を標準で内蔵しているため、MUIに相当するものを別途入れる必要はありません。
初心者が先に学ぶならどちらですか?
JavaScriptやReactに触れたことがあるならReact Nativeから始めるほうが立ち上がりが速く、公式が推奨するExpo経由なら環境構築でつまずきにくくなっています。プログラミング自体がはじめてで、モバイルアプリを作ること自体が目的ならFlutterを勧めます。Dartは型が明示的で、UIの組み立てからデバッグまでツールが一式そろっているため、学ぶ対象が分散しにくいためです。