Flutter vs React Native 2026: Bundle Size & Performance
Flutter のビルドが完了します — リリース APK は 8.4 MB に落ち着きます。ブランチを切り替えて、Hermes を有効にした React Native で同じ機能セットを再構築すると、バンドルは 12.1 MB に膨らみます。どちらも動作します。どちらも本番環境に行きます。しかし、ドキュメントの約束と実際のデプロイログの間のギャップは、異なるストーリーを物語っています。4年間、両方のスタックで本番アプリをプッシュしてきました — いくつかは美しくスケーリングしましたが、他は午前2時の Slack アラートをトリガーして、すべてのアーキテクチャの決定を再考させました。これは機能リストの再ハッシュではありません。変更ログが警告してくれない、バンドルサイズのデルタ、フレームドロップのパターン、およびネイティブモジュールの落とし穴についてです。Flutter の compile-time の楽観性がどこで崩れるのか、React Native のブリッジオーバーヘッドがどこで最も厳しくバイトするのか、そして次の機能ロードマップなしで再度構築することなくどのフレームワークが生き残るのかを正確に示します。
クロスプラットフォームの環境は劇的に変わりました。React Native の New Architecture は現在デフォルトです。Flutter 3.x は本当に印象的なものに成熟しました。両方のフレームワークが歴史的な弱点に対処してきましたが、それは逆説的に選択をより簡単にするのではなく、より難しくしています。本番コードベースをこれらのいずれかにコミットするときに実際に重要な事項を分解しましょう。
目次
- 2026年のクロスプラットフォーム状況
- バンドルサイズ: 実際に出荷しているもの
- 重要なパフォーマンスベンチマーク
- ネイティブモジュールとプラットフォームアクセス
- 開発者体験と生産性
- エコシステムとコミュニティファクター
- 実際の本番トレードオフ
- Flutter を選ぶべき時
- React Native を選ぶべき時
- Web ストーリー: 面白くなるところ
- よくある質問
2026年のクロスプラットフォーム状況
両方のフレームワークは現在強い立場にあります。React Native の New Architecture — Fabric レンダラー、TurboModules、およびブリッジレスモード — はもう実験的ではありません。React Native 0.78+ 以降、新しいプロジェクトのデフォルトです。長年 React Native を悩ませていた JavaScript ブリッジのボトルネック? 消えました。JSI (JavaScript Interface) は、ネイティブコードへの同期的で直接的な呼び出しを提供します。
一方、Flutter はモバイルを超えた拡張を続けています。Impeller は iOS と Android の両方のデフォルトレンダリングエンジンで、オンデバイスレンダリングのために Skia を置き換えました。Flutter 3.27+ は、ネイティブ UI コンポーネントの埋め込みを苦痛にしていたジャンクを削減し、プラットフォームビューへの大幅な改善をもたらしました。
ここに誰もが声に出して言わないことがあります: 両方のフレームワークは優れた本番アプリを構築できます。問題は「どちらが良いか」ではなく、「あなたの特定の状況ではどちらが良いか」です。あなたのチームのスキル、あなたのアプリの要件、あなたのタイムライン、そしてあなたの長期的なメンテナンス戦略は、どんなベンチマークよりも重要です。
バンドルサイズ: 実際に出荷しているもの
バンドルサイズは重要です。ダウンロード速度に影響します。特に新興市場ではそうです。アプリストア最適化に影響します。そして、これらのフレームワーク間で最も測定可能な違いの1つです。
Flutter バンドルサイズ
最小限の Flutter アプリ — 基本的に「Hello World」— は Android で約 16-20 MB (APK)、iOS で約 40-50 MB (IPA) にコンパイルされます。これは空白アプリにとって怖く聞こえます。正直に言うと、ある種はそうです。理由は単純です: Flutter は独自のレンダリングエンジンをバンドルしています。すべての Flutter アプリは、Impeller エンジン、Dart ランタイム、およびフレームワーク自体と一緒に出荷されます。
良いニュースは? 追加機能の限界コストは低いです。エンジンを既に出荷しているので、画面とウィジェットを追加しても、期待するほどサイズが膨らみません。中程度の複雑さの Flutter アプリは、通常 Android で約 25-35 MB に落ち着きます。
Flutter の --split-debug-info と --obfuscate フラグは、Android の --split-per-abi と組み合わせて、アプリバンドル (AAB) の代わりにユニバーサル APK を使用するのに役立ちます。Google Play がデバイス固有のバイナリを配信するように設定すると、通常ダウンロードサイズが 30-40% 削減されます。
React Native バンドルサイズ
最小限の React Native アプリは、Android で約 8-12 MB、iOS で約 25-35 MB で、より小さく始まります。React Native はプラットフォームのネイティブレンダリングを使用するため、レンダリングエンジンを出荷していません。JavaScript バンドル自体 (Hermes 経由) は驚くほどコンパクトです。
Hermes バイトコードプリコンパイル (現在デフォルト) は、実際の違いを生みます。あなたの JS バンドルはソースではなくバイトコードとして出荷され、より小さく、より速くロードされます。中程度の複雑さの本番 React Native アプリは、通常 Android で約 15-25 MB の重さを持ちます。
しかし、ここに落とし穴があります: 追加する每一个ネイティブモジュールは、独自の重量を持ちます。react-native-maps、react-native-camera、または任何のブリッジヘビーライブラリのような重いことは、各 2-5 MB を追加できます。アプリがネイティブモジュール-heavy の場合、そのサイズの利点は急速に浸食できます。
バンドルサイズ比較表
| メトリック | Flutter (2026) | React Native (2026) |
|---|---|---|
| 最小限アプリ (Android APK) | 16-20 MB | 8-12 MB |
| 最小限アプリ (iOS IPA) | 40-50 MB | 25-35 MB |
| 中程度の複雑さのアプリ (Android) | 25-35 MB | 15-25 MB |
| 中程度の複雑さのアプリ (iOS) | 50-70 MB | 35-55 MB |
| 増分機能コスト | 低い | 変動する (ネイティブ dep に依存) |
| サイズ最適化ツール | Tree shaking、split-per-abi、deferred components | Hermes bytecode、ProGuard、Metro bundle splitting |
評決: React Native は初期バンドルサイズで勝ちます。Flutter のオーバーヘッドは一定ですが、アプリの複雑さを追加するにつれてギャップは狭まります。
重要なパフォーマンスベンチマーク
直接言いましょう: オンラインで見たほとんどのパフォーマンス比較は、ゴミです。彼らは「10,000 個のリスト項目をレンダリング」のようなことをベンチマークします。実際のアプリは行いません。あるいは、彼らはフラグシップ電話でテストします。これはすべてを高速にします。
本番環境で実際に重要なこと:
スタートアップ時間
Flutter の AOT (Ahead-of-Time) コンパイルは、優れたコールドスタート時間を提供します。mid-range Android デバイス (Samsung A54 を考える) では、中程度の複雑さの Flutter アプリは約 800-1200ms でコールドスタートします。
Hermes を備えた React Native は劇的に改善されました。同じクラスのアプリは約 900-1400ms でコールドスタートします。Hermes バイトコード読み込みは生の JavaScript よりも高速であり、React Native 0.78+ とブリッジレスモードは初期化オーバーヘッドを削減します。
違い? Flutter の利点で約 100-200ms。測定している場合に顕著ですが、あなたのユーザーはおそらく感じません。
UI パフォーマンス (60fps の質問)
これは Flutter のアーキテクチャが輝く場所です。Flutter がレンダリングパイプライン全体を所有しているため、より一貫して 60fps (または ProMotion ディスプレイで 120fps) を保証できます。ブリッジがありません。シリアライゼーションはありません。JS とネイティブの間を行き来することはありません。あなたの Dart コードは直接レンダリングエンジンに話しかけます。
React Native の New Architecture はこのギャップを大幅に閉じました。Fabric レンダラーは同期的なレイアウト測定を可能にし、JSI は非同期ブリッジのオーバーヘッドを排除します。最も実際の UI シナリオ — スクロールリスト、ページ遷移、フォーム相互作用 — React Native は最新デバイスで 60fps をうまく保持しています。
まだ違いが見られる場所: 複雑なアニメーション。あなたのアプリが重いカスタムアニメーション、パーティクルエフェクト、またはリアルタイムデータビジュアライゼーションを持っている場合、Flutter の直接レンダリングはそれにエッジを与えます。React Native の Reanimated 3 ライブラリは優れていますが、Flutter が持たない制約内で機能しています。
メモリ使用量
Flutter アプリはメモリベースラインをより多く使用する傾向があります。これは組み込みエンジンのため — 通常、同等の React Native アプリより 30-50 MB 多いです。8+ GB RAM のモダンフォンでは、これは無関係です。2-3 GB の予算デバイスの場合? 重要になる可能性があります。
React Native のメモリストーリーは、より予測不可能です。JavaScript ヒープはプロファイルしにくい方法で成長できます。JS レイヤーのメモリリークは、一般的な本番環境の問題です。Dart のガベージコレクターは、私の経験では、Hermes のものより予測可能です。
パフォーマンスの概要
| メトリック | Flutter | React Native |
|---|---|---|
| コールドスタート (mid-range デバイス) | 800-1200ms | 900-1400ms |
| 60fps 一貫性 | 優れた | 良い (Reanimated で優秀) |
| 複雑なアニメーション perf | 優秀 | 良い (注意事項付き) |
| メモリベースライン | より高い (~30-50 MB 多い) | より低いベースライン、より予測不可能 |
| 重いリストスクロール | 優れた | 優れた (FlashList) |
| CPU 集約的なタスク | 良い (Dart isolates) | 良い (JSI + native threads) |
ネイティブモジュールとプラットフォームアクセス
これは多くの本番アプリの実際が機能する場所です。プラットフォーム固有の API にどれだけ簡単にアクセスできますか?
React Native のネイティブモジュールストーリー
React Native の全体的な哲学は「一度学べば、どこでも書ける」です。あなたの UI は実際のプラットフォームコンポーネント (iOS の UIKit、Android の Android Views/Compose) を使用してレンダリングされます。これはプラットフォーム統合が本質的に自然であることを意味します。
TurboModules (New Architecture のモジュールシステム) ネイティブモジュール開発を大幅に改善しました。モジュールは遅延ロードされ、codegen 経由でタイプセーフで、同期的な必要があるときに同期的です。ネイティブ SDK を呼び出す必要がある場合 — たとえば、支払いプロセッサーの iOS SDK または Android ハードウェア API — TurboModule 仕様を書き、ネイティブに実装し、JavaScript から呼び出します。
エコシステムも役立ちます。Expo の expo-modules-api のようなライブラリは、ネイティブモジュールの記述をそれほど簡単にしているため、多くのチームは Xcode または Android Studio に直接触る必要がありません。
Flutter のプラットフォームチャネルストーリー
Flutter のアプローチは Platform Channels (または C/C++ ライブラリ用の新しい FFI) です。Dart でメソッドチャネルを定義し、ネイティブ側を Swift/Kotlin で実装し、メッセージを行き来で渡します。Pigeon コードジェネレーターは、この定型コードの多くを自動化します。
Flutter のプラグインエコシステムは広範です — ほとんどの一般的なネイティブ API のプラグインがあります。しかし、カスタムが必要な場合は、Swift/Kotlin/C++ コードを書いてシリアライゼーション自分で管理しています。それは機能しますが、React Native のアプローチより多くの式典があります。
Flutter の federated plugins アーキテクチャは、プラットフォーム固有の実装を維持するための良いパターンですが、プロジェクト構造に複雑さを追加します。
ネイティブアクセスの判定
React Native は構造的な利点を持っています。ネイティブコンポーネントでレンダリングするため、ネイティブ UI 要素 (マップ、ビデオプレーヤー、Web ビュー) の統合はより自然です。Flutter のプラットフォームビューは改善されていますが、Flutter のレンダリングパイプライン内にネイティブビューを埋め込むことは、特に z-order とジェスチャー処理の周りで、まだ粗い端があります。
アプリがネイティブ SDK 統合に多い場合、React Native はそれを簡単にします。期間。
開発者体験と生産性
Flutter DX
Flutter の開発者体験は驚くほど一貫しています。flutter CLI はすべてを処理します: プロジェクト作成、依存性管理、構築、テスト、さらにはアップグレード。flutter doctor は環境の問題があなたを咬む前に診断します。
Flutter のホットリロードは、金のスタンダードです。高速で、信頼でき、状態を保存します。私は全体の開発セッションなしに完全な再起動なしに行きました。これだけで1週間に何時間も価値があります。
Dart は JavaScript ではなく、それは長所と短所の両方です。それは強く入力された言語で、優れたnull安全性を持っています。学習曲線は実在しますが、管理可能です — 最も開発者はDartで1週間以内に生産的になります。言語自体は最も退屈な方法で退屈です。
Flutter のウィジェットシステムは、Web開発から来た場合、最初は奇妙です。レイアウト (Padding、Center、Column) を含むすべてがウィジェットです。「ウィジェットツリー」アプローチは、それがクリックすると使用に慣れているになります。UIを構成することは本当に速くなります。
React Native DX
React Native の DX はセットアップに大きく依存します。Expo を使用していますか? それは素晴らしいです — npx create-expo-app は数分以内にあなたを走らせます。Expo エコシステムはプラットフォームの複雑さのほとんどを処理します。Bare React Native? あなたはネイティブビルドツール設定に多くの時間を費やします。
2026年の Expo は本質的に React Native アプリを構築するための推奨方法になりました。ファイルベースのナビゲーション用の Expo Router、クラウドビルド用の EAS Build、カスタムネイティブコード用の expo-dev-client では、開発者体験は最高です。
React Native のホットリロード (Fast Refresh) もまた優れています — Flutter のほぼ同等です。React DevTools 統合は、Flutter の DevTools が一致しますが異なるアプローチする コンポーネント検査を提供します。
JavaScript/TypeScript エコシステムは祝福と呪い両方です。あなたは数千の npm パッケージへのアクセスを持っていますが、依存性の管理は苦しいことができます。競合する peer dependencies、ネイティブモジュール版の不一致、そして時折 node_modules の悪夢は取引の一部です。
DX 比較
| 要因 | Flutter | React Native (Expo) |
|---|---|---|
| プロジェクト設定時間 | 5 分 | 3 分 |
| ホットリロード品質 | 優れた | 優れた |
| タイプ安全性 | 組み込み (Dart) | TypeScript (opt-in ですが標準) |
| IDE サポート | VS Code、IntelliJ (素晴らしい) | VS Code (素晴らしい)、任意の JS IDE |
| テストツール | 組み込み (単位、ウィジェット、統合) | Jest + Testing Library + Detox |
| デバッグ | Dart DevTools | React DevTools + Flipper |
| 学習曲線 (Web から) | 中程度 (Dart + ウィジェットを学ぶ) | 低い (React を知っている場合) |
| 依存性管理 | pub.dev (安定) | npm (強力だが混沌とした) |
エコシステムとコミュニティファクター
2026年初頭の時点での数字:
- Flutter: ~167K GitHub スター、395K+ pub.dev パッケージ、強い Google バック
- React Native: ~121K GitHub スター、npm エコシステムへのアクセス、強い Meta バック
Flutter のコミュニティは特にアジアとヨーロッパで急速に成長しました。Google の投資は引き続き強力です — Flutter は Google Pay、Google Classroom、その他の製品で社内的に使用されています。
React Native はより広い React エコシステムの恩恵を受けます。あなたの会社が既に React Web 開発者を作成した場合、React Native への移行は Flutter/Dart を学ぶより大幅にスムーズです。これは多くの場合、Web に焦点を当てたチームの決定要因です。
Social Animal では、Next.js または Astro で Web プレゼンスを構築したチームと一緒に働くことがよくあります。それらのチームでは、メンタルモデルが直接キャリーオーバーされるため、React Native は通常、より自然なモバイル拡張です。
実際の本番トレードオフ
いくつかのトレードオフを共有してみましょう。機能比較マトリックスに表示されていません:
Flutter の隠れたコスト:
- Dart 開発者は JavaScript 開発者よりも雇用するのが難しいです。完全に。
- アプリがネイティブ iOS アプリのように見える必要がある場合、Flutter の Material-first デザインシステムと戦うでしょう。Cupertino ウィジェットは存在しますが、常にキャッチアップをプレイしています。
- iOS でのアプリサイズは、アプリストアのレビューでユーザーの苦情を定期的にトリガーします。
- Web サポートは機能的ですが、SEO またはパフォーマンスの実際の Web アプリと競争力がありません。Flutter Web が適切な Web ビルドを置き換えると誰かに言わせないでください。
React Native の隠れたコスト:
- 既存アプリの New Architecture マイグレーションは重要ではありません。レガシー RN コードベースを継承している場合、これの時間の予算を計画します。
- ネイティブビルド設定 (Gradle ファイル、Xcode プロジェクト設定) は最終的にネイティブ開発を理解する人を必要とします。
- JavaScript エコシステムは高速に移動します。依存性は廃止され、API は変更され、コアライブラリでのメジャーバージョンバンプはプロジェクト全体を通じてカスケードできます。
- パフォーマンスの問題が発生した場合、JS、ネイティブ、またはその間のブリッジから発生する可能性があるため、診断がより難しいです。
Flutter を選ぶべき時
Flutter を選択します:
- アプリに重いカスタム UI がある — アニメーション、カスタム描画、「ネイティブ」に見える必要のないブランド固有のデザイン言語。
- モバイルを超えてターゲットしている — デスクトップ (Windows、macOS、Linux) は、本当に良い結果で同じコードベースから。
- チームが新しく始まっている — 既存の JavaScript 専門知識はキャリーオーバーません。
- パフォーマンス予測可能性が重要です — 金融アプリ、リアルタイムダッシュボード、フレームドロップが容認できないメディア-heavy アプリ。
- ピクセルと同一の動作が必要な場合 — Flutter は Flutter が各ピクセルを所有しているため、iOS と Android 全体で同じようにレンダリングされます。
2026年に Flutter をうまく使用している企業: Google Pay、BMW、Toyota、Alibaba、Nubank (90M+ ユーザーに提供する世界最大のデジタル銀行の1つ)。
React Native を選ぶべき時
React Native を選択します:
- チームが React を知っている — 既知のパラダイムの生産性の利点は膨大です。
- ネイティブの外観と感覚が必要です — アプリは各プラットフォームに属しているように感じるべきで、プラットフォーム標準のコンポーネントを使用します。
- 重いネイティブ SDK を統合している — 支払いプロセッサー、AR フレームワーク、プラットフォーム固有の API。
- 既に Web アプリがある — Web とモバイルの間でビジネスロジック、タイプ、さらにいくつかのコンポーネントを共有することは React Native で実用的です。
- 採用とチーム スケーリングが重要です — JavaScript/TypeScript 開発者は豊富です。
2026年に React Native をうまく使用している企業: Meta (Instagram、Facebook)、Microsoft (Office、Teams、Xbox)、Shopify、Discord、Coinbase。
強い Web プレゼンスとモバイルアプリの両方が必要な製品を構築している場合、headless CMS のコンビネーション (両方に強力)、Next.js Web アプリ、および React Native モバイルアプリが証明されたアーキテクチャです。私たちはこのスタックを 複数回 構築しており、Web とモバイル間のコード共有は本当に価値があります。
Web ストーリー: 面白くなるところ
これは、2つのフレームワークが最も鋭く分岐する場所であるため、独自のセクションに値します。
Flutter Web はキャンバス要素にレンダリングされます。これは、Flutter アプリをブラウザで実行できることを意味しますが、従来の意味での「Web アプリ」ではありません。テキストはデフォルトで選択できません。SEO は非存在です。アクセシビリティはボルト留めされています。これは内部ツールとダッシュボードに役立ちますが、顧客向け Web サイトには使用しません。
React Native Web (react-native-web 経由) は実際の DOM 要素にレンダリングされます。完璧ではありません — すべての React Native コンポーネントは完全に変換されません — しかし、出力は検索エンジンがクロールできる実際の Web ページです。Meta は Facebook と Instagram の Web バージョンの部分にこのアプローチを使用しています。
あなたの戦略が Web でコンテンツを提供することを含める場合 (そしてそれがそうあるべき — Web はまだ最大のプラットフォームです)、React Native の物語は実質的に優れています。Web レイヤーと同様にモバイルアプリが必要なチームでは、Next.js または Astro のような専用フレームワークで Web レイヤーを構築し、React Native でビジネスロジックを共有することは最も実用的なアプローチです。
よくある質問
2026年は Flutter が React Native より速いですか? 合成ベンチマークでは、Flutter は直接レンダリングパイプラインのおかげでアニメーション-heavy テストで小さなマージンで勝つ傾向があります。実際の世界でのアプリ使用 — スクロール、ナビゲーション、フォーム入力 — 両方のフレームワークは最新デバイスで 60fps で実行されます。パフォーマンスの違いは、本番アプリの決定要因になることはめったにありません。
**どちらがより小さいアプリサイズを持っているか、Flutter または React Native? ** React Native は、より小さい初期バンドルを生成します — 最小 Android アプリの場合、Flutter の 16-20 MB に対して約 8-12 MB。ただし、Flask の機能を追加すると、Flutter のサイズがより遅く成長するため、レンダリングエンジンコストが固定されています。複雑なアプリでは、メガバイト差が、その差は狭まります。
React Native と Next.js Web アプリの間でコードを共有できますか? はい。これは React Native の最強の引数の1つです。React Native モバイルアプリと Next.js Web アプリの間で、モノレポ (Turborepo または Nx を使用) を使用して、ビジネスロジック、TypeScript タイプ、API クライアント、および状態管理コードを共有できます。UI コンポーネントはプラットフォーム固有の実装が必要ですが、共有ロジックは開発努力の 20-40% を保存できます。
Dart は JavaScript 開発者にとって難しいですか? Dart には学習曲線があります。ただし、ほとんどの開発者が期待するより優しくなっています。TypeScript を使用した場合、Dart の型システムは馴染み深く感じます。構文は Java または C# に近い JavaScriptより。ほとんどの有能な JS 開発者は 1-2 週間以内に Dart で生産的になります。ウィジェット構成パターンは言語自体よりも長くなるために長くなります。
2026年に Expo または Bare React Native を使用するべきですか?
Expo を使用します。2026年では、Expo はほぼすべての React Native プロジェクトに推奨されるアプローチです。「Expo」と「Bare React Native」の区別は大幅に解決されました — Expo の expo-dev-client を使用すると、Expo のツール利点を保ちながら、任意のカスタムネイティブコードを追加できます。Bare React Native から始まることは、ルールではなく、例外です。
開発者を採用する場合、どのフレームワークが優れていますか? React Native、大きなマージンで。JavaScript/TypeScript 開発者プールは、全世界で Dart 開発者プールより約 5-8 倍大きいです。チームが成長し、迅速に採用する必要がある場合、React Native はより多くの候補者を提供します。Flutter 開発者は熱心な専門家である傾向があります。これは保持が優れていますが、スケーリングが困難です。
Flutter はネイティブ iOS/Android アプリを完全に置き換えることができますか? ほとんどのアプリでは、はい。Nubank は 90+ 百万ユーザーに Flutter アプリを提供しています。Google Pay は Flutter を通じて数十億を処理します。ただし、プラットフォーム固有の機能 (特定の健康/フィットネス API、非常に特定の Bluetooth プロトコル、またはプラットフォーム排他的な UI パターン) と深く統合するアプリは、それらの特定の機能にネイティブ開発から恩恵を受ける可能性があります。
長期的なメンテナンスコストはどうですか? Flutter の単一コードベースは単一言語を持つ傾向があり、より低い長期メンテナンスオーバーヘッドを有する傾向があります — より少ない依存性の競合、シンプルなアップグレードパス。React Native のメンテナンスコストは、使用するネイティブモジュールの数と関連しています。より多くのネイティブ依存性は、アップグレード中に壊す可能性があります。どちらも、2つの別のネイティブコードベースを維持するよりも大幅に低価格です。
React Native から Flutter への移行 (またはその逆) に値しますか? ほぼ決して。マイグレーションコストは本質的に完全な書き直しです。現在のフレームワークが基本的な制限をブロックしている場合を除き、単なるマイナーな不便ではなく、実際のブロッカー — 書き直しコストが自分を正当化しません。その時間をあなたの既存のアプリの改善に投資してください。フレームワーク移行に 6-12 ヶ月を費やしたチームを見ました。ユーザー価値がゼロの結果。