目次
かつてのモバイルアプリ開発は、iOSとAndroidそれぞれに専用のコードを書くOSごとのネイティブ開発が主流でしたが、近年は1つのコードベースで両方に対応できる「クロスプラットフォーム開発」が一般的になっています。
2026年現在、クロスプラットフォーム開発の選択肢は大きく成熟し、主要な3つ(React Native + Expo、Flutter、Kotlin Multiplatform)がそれぞれ強みを持つ状況になっています。選択の際には「いずれかのフレームワークが唯一の正解」と考えるのではなく「どれが自分たちに合うか」をプロジェクトやチームのスキルセットに応じて判断することが大切です。
本記事では、特に近年「Expo」というツールチェーンの進化によってより魅力的になったReact Nativeを軸に、FlutterやKotlin Multiplatformとの比較も交えて、フレームワーク選定のポイントを解説します。
クロスプラットフォーム開発の現在地(2026年)
2026年のクロスプラットフォーム開発の主要な選択肢を整理します。
React Native + Expo: Metaが開発したReact Nativeは、JavaScript/TypeScriptでiOSとAndroidの両方に対応するフレームワークです。ExpoはReact Nativeの上に構築されたツールチェーンで、アプリ開発から公開まで一連の工程に必要な機能群が揃っているため、開発体験を大幅に向上させます。React Native単体でも開発は可能ですが、現在は公式ドキュメントでもExpoの使用が推奨されており、React Native開発においてExpoの利用はデファクトスタンダード(標準)となっています。
React NativeはプラットフォームネイティブのUIコンポーネントを使用するため、各OSのルック&フィールを活かした、自然な操作感のアプリが作りやすいのが特徴です。
Flutter: Googleが開発したFlutterは、Dart言語を用いてiOS、Android、Web、さらにはデスクトップアプリまで開発可能なフレームワークです。独自のレンダリングエンジン(Impeller)を搭載しており、全プラットフォームで一貫したデザインを再現しやすいのが大きな特徴です。
Flutterを用いるとどのOSでもUIとロジックの両方を共通化できるため、ブランド独自のUIを全プラットフォームで統一したい場合に適しています。
Kotlin Multiplatform (KMP): Kotlinを用いて、iOSとAndroidの両方でコードを共有できるフレームワークで、JetBrains社が開発しました。従来はUIまで共通化せず、ビジネスロジックのみを共有するスタイルが一般的でしたが、最近ではCompose Multiplatformの活用により、UIまで共通化するケースも増えています。
既存のAndroid資産を活かしてUIは各OSで最適化したい場合にはKMPが重要な選択肢になります。また、新規プロジェクトでも効率的に両OSでUIまで共有したい場合にはCompose Multiplatformを採用できるため、近年注目されつつあります。
市場データ(2026年時点)
プロジェクトの技術選定において重要な指標となる「市場のエンジニア需要」について、Flutter、React Native、Kotlinの3つの技術を国内外の統計を比較してみます。
- LinkedIn Japanの求人数ではFlutterが500件以上、React Nativeが400件以上となっており、Flutterのエンジニアの需要が高まっていることがわかります。
- 一方で、LinkedIn USの求人数ではFlutterが2,000件以上、React Nativeが4,000件以上となっており、React Nativeの方が需要が高いという結果になっています。
- Kotlinに関しては、ネイティブAndroidの開発や一部バックエンドの開発でも使用されるため、LinkedInの求人数を単純に比較することが難しいのですが、当社のプロジェクト相談時に候補に上がる頻度はFlutterやReact Nativeと比べるとまだ少ない印象です。
どのフレームワークであっても一定数の求人が存在しており、地域によって需要の傾向が異なることからも、それぞれのフレームワークが成熟しており、プロジェクトやチームの条件に応じて選択されていると考えられます。
Expoの進化が変えたReact Nativeの価値
まず代表的なフレームワークを紹介しましたが、ここからは近年のアップデートで進化した「React Native + Expoの開発体験」を具体的に見ていきましょう。
基盤面では、新アーキテクチャ(Fabric / TurboModules / JSI)がバージョン0.76でデフォルト化され、0.82で旧アーキテクチャが完全に削除されました。JSエンジンもHermes V1がデフォルトになることで、以前から指摘されていた、JSとネイティブコードの間のパフォーマンスに関わる構造的な課題が解消されました。これらの基盤の進化により、React Native自体の土台としての信頼性は2020年頃と比べて大きく高まっています。
その上で、私が実際にReact Native + Expoを使った開発を通して感じた良かったポイントを紹介します。
EAS Build + Development Buildによる開発体験の向上
Expo Application Services (EAS) のビルドサービスとDevelopment Buildの組み合わせにより、ホットリロードを活用しながら開発を進めることができるようになりました。わかりやすくいえば、修正内容が即座にスマホに反映される仕組みが整ったため、プレビューを見ながら効率よく開発が行えます。これにより、開発中のアプリビルドの回数も大幅に削減でき、ストレスなく開発に集中できるようになりました。
また、Dev Toolsも充実しており、アプリパフォーマンスの確認や、画面内のプロパティの詳細を簡単に確認できるようになったことでUIの調整が非常に楽になりました。
CNG によるネイティブコード連携のハードル低下
クロスプラットフォームの開発を行っていると、OS特有の調整を行うためにネイティブコードを触る必要がある場面がどうしても出てきます。以前は、Expoを使ったプロジェクトにネイティブコードを連携させたい時、一度ejectを行う必要がありました。これは、Expoの管理下から離れることで便利な機能が使えなくなるリスクを伴うものでしたが、現在はこの問題を解決するためのCNG(Continuous Native Generation)という概念が導入されています。
細かい説明は省略しますが、設定ファイルさえあれば「Expo Prebuild」が必要なファイルをその都度自動作成してくれるため、開発者が複雑なOS専用ファイルを直接管理し続ける必要がなくなりました。これにより、Expoの開発体験を維持したまま、ネイティブコードとの連携が安全かつ容易に行えるようになっています。
Reactを書く感覚でモバイルアプリが開発できる
React Nativeの強みはなんといっても、Reactの開発体験をモバイルアプリ開発に持ち込めることです。開発言語もJavaScript/TypeScriptで、Reactのコンポーネントベースの開発スタイルをそのまま活かせるため、Webエンジニアがモバイルアプリ開発に参入しやすい環境が整っています。
最近ではAIにコードを書かせることも多いと思いますが、React NativeはWeb共通のReact構文やTypeScriptをベースとしているため、AIが生成したコードの妥当性を人間(Webエンジニア)が判断しやすく、実装のパターンも把握しやすいという特性があります。
Web開発時の知見を活かすことができるため、AIが生成したコードの理解や修正・レビューも比較的スムーズに行えるのが大きなメリットだと感じました。実際に当社でも、WebエンジニアがReact Native + Expoのプロジェクトに参画し、その日のうちに簡単な機能を実装できたケースがありました。
React Native + Expoの課題と注意点
React Native + Expoの良い点から紹介しましたが、次に、実際に利用する中で感じた課題や注意点も紹介したいと思います。
EASの無料枠にある制約
アプリをビルドする際に使用するExpo Application Services (EAS) は完全無料のサービスではありません。無料枠も提供されていますが、月あたりのビルド回数に上限があり、待機時間が発生することもあります。チームでスムーズに開発を進め、商用アプリとして継続的に開発・リリースをする場合には、有料プランの利用が前提になるでしょう。EASを使わずローカルビルドに切り替えることも可能ですが、その場合はXcodeやAndroid Studioの環境構築や、ローカルビルド特有のトラブルシューティングが必要になります。
EASの有料プランを避けようとすると、結果として「ビルドを簡単に」というExpo採用のメリットは薄れてしまいます。
React NativeとExpoの二重構造
React NativeはMetaが開発している一方で、Expoは独立した組織が開発しており、両者の更新や対応状況が完全にシンクロしているわけではありません。特に新しいOSバージョンへの対応など、タイムリーなアップデートが必要な場面では、まずReact Nativeコアの更新を待ち、さらにExpoの追従を待つ、というリードタイムが発生することがあります。
Flutterの場合はGoogle一社が言語・SDK・主要ツールを統括しているため、OS更新への追従が一本化されており、ここは構造的な差が出やすい部分です。最新OS対応の期日が厳しいプロジェクトでは、このリードタイムをあらかじめスケジュールのバッファとして織り込んでおく必要があります。
Webエンジニアの経験がノイズになることがある
本来Webアプリとモバイルアプリは設計思想やアプリのライフサイクル、求められる機能やUXが大きく異なる部分が多々あります。React Nativeの良い点としてWeb開発の知見が活かせると紹介しましたが、逆にWeb開発の知見がモバイル開発の設計思想から乖離した判断を生み、コードの品質に影響を与えることがあります。
また、Web開発の知見に頼った設計を行うとモバイルアプリ特有の考慮事項が設計段階で見落とされることもあります。Webエンジニア主体でReact Nativeの開発を進める場合、モバイルアプリ開発経験者によるレビューや伴走体制を確保できるかどうかが、中長期の品質を大きく左右します。
npmエコシステムの質の問題
React NativeはJavaScript/TypeScriptで開発されているため、npmエコシステムのライブラリを利用することができます。Web開発で培われた膨大なプログラム資産には便利なライブラリも多いため、これらを活用できることは大きなメリットです。
しかし、ライブラリの中にはモバイル環境での動作保証が不十分なものや、個人の開発による品質のバラつきがあるものも多々あるため、長期的なメンテナンス性を考慮した技術選定が欠かせません。
Flutterの場合、pub.devはGoogle主導で品質ラベル(Verified Publisher等)があるため、長期運用を前提としたプロジェクトではライブラリ選定の安心感に差を感じることがあります。
React Native + Expoを採用する場合は、依存するライブラリのメンテナンス状況やコミット頻度を、選定段階でいつも以上に慎重に確認する運用が必要になります。
React Native / Flutter / KMP — 比較と選定のポイント
前章まではReact Native + Expoにフォーカスして進化と課題を見てきましたが、実際の技術選定ではFlutterやKotlin Multiplatformも含めた比較を行い、それぞれのメリット・デメリットを把握して判断することが重要になります。
5-1. 3フレームワークの比較
| 判断軸 | React Native + Expo | Flutter | KMP |
|---|---|---|---|
| 言語 | JavaScript / TypeScript | Dart | Kotlin |
| UI描画 | プラットフォームネイティブ | 独自エンジン(Impeller) | ネイティブ or Compose Multiplatform |
| アクセシビリティ対応 | ○(ネイティブUIのOS標準機能を活かしやすい) | △(独自描画のため一部OS標準機能と差が出る) | ○(ネイティブUI前提。Compose Multiplatformでは制限あり) |
| ビルド・配布の仕組み | ○(EASでクラウドビルド〜ストア提出まで一元化) | △(ローカルビルド中心、配布はサードパーティ) | ×(Gradle + Xcode を手動で組み合わせる) |
| OTAアップデート対応 | ○(EAS Updateで標準対応、ロールバック可) | △(公式非対応、Shorebird等サードパーティ) | ×(基本非対応、ネイティブリリースが必要) |
| ネイティブコード連携の敷居 | ○(CNG / Config Pluginsで設定ベース) | ○(Pluginシステムで標準化) | ◎(KotlinとSwift/Objective-Cの直接的な相互運用) |
| 開発体験の統一性 | △(React NativeコアとExpoで管轄が分散) | ○(Google一社が統一管理) | △(UIは各プラットフォーム別が従来型) |
| 学習コスト(Webエンジニア視点) | ○(React経験があれば低い) | △(Dart + Widget体系の習得が必要) | ×(モバイルネイティブ知識が前提) |
どういう場面で何を選ぶか
React Native + Expoが合うケース
- 社内にReact / TypeScript経験者がいて、既存人材で内製化を進めたい場合
- JavaScript / TypeScriptエコシステムの豊富さや、AI駆動開発との相性を活かしたい場合
- MVPを素早く出して、OTAで継続的に改善サイクルを回したい場合
Flutterが合うケース
- ブランド独自のUIをiOS / Androidを通じてピクセル単位で統一したい場合
- 言語・SDK・主要ツールが一社で統括された整理された開発体験を重視する場合
- チームにDart / Flutterの経験者がすでにおり、それを活かしたい場合
※行政系・公共性の高いアプリなど、アクセシビリティ要件が厳しい案件では、独自描画であるFlutterよりもネイティブUIを用いるReact Native/KMPの方がOS標準機能との親和性で有利になる場面があります。
KMP(Kotlin Multiplatform)が合うケース
- すでにAndroid / Kotlin資産があり、ロジック部分をiOSと共有したい場合
- UIは各OSのネイティブ(SwiftUI / Compose)で作り込み、プラットフォーム固有のUI/UXを活かしたい場合
- 新規プロジェクトで、Compose Multiplatformを使ってUIまでKotlinで統一することに挑戦したい場合(比較的新しい選択肢のため、情報や実績の蓄積は他2つに比べてまだ限定的です)
クロスプラットフォーム開発のご相談はNCDCへ
本記事では、FlutterやKotlin Multiplatformとの比較も交えて、React Native + Expo によるクロスプラットフォーム開発について説明しました。
冒頭の説明の繰り返しになりますが、最適な技術選定はフレームワークの特性だけでは決まらないということをあらためてお伝えします。技術選定の際には、チームのスキルセット、事業の方向性、中長期の運用体制まで含めた総合的な判断が求められます。
また、要件によってはクロスプラットフォームではなくOSごとのネイティブ開発(Swift + Kotlin)が最適なケースもあります。3Dや高度なグラフィック処理が中心のアプリ、プラットフォーム固有のUI/UXを極限まで追求したいアプリなどは、その代表例です。
NCDCではReact Native + Expo、Flutter、ネイティブ開発など、幅広いプロジェクトでの実績があります。「どのフレームワークを選ぶべきか」という段階からご相談いただくことで、プロジェクトの条件やチーム体制に合わせた最適な選択をご提案できます。クロスプラットフォーム開発やモバイルアプリの技術選定にお悩みの際は、ぜひお気軽にお問い合わせください。
















