概要
開発手段の選定とは、iOSとAndroidに向けたアプリをどの技術基盤で構築するかを決める意思決定です。プロダクト開発を始めるときに最初に決める必要があり、その後の開発体制・採用・保守コストに影響します。 この意思決定は、Pure Native・Flutter・React Native・Kotlin Multiplatformといった選択肢を横並びに比較する問題として扱われがちです。しかし比較の前に決まっていなければならないことがあります。それは「何を共通化するか」です。 共通化の範囲が決まると、判断は一段下の階層に移ります。範囲を選ぶ段階では3つの分類の比較ですが、範囲が決まったあとは、その分類に属する技術どうしの比較になります。たとえばUIの実装まで共通化すると決めれば、次の問いはFlutterとReact Nativeのどちらを採用するかになります。範囲を決めないまま個別の技術を比較すると、前提の異なる選択肢を同じ土俵に並べることになります。 このページでは、共通化の範囲による3つの分類、分類を選ぶための4つの軸、そして各分類の中で候補が分かれる基準を解説します。最後に、組織とプロダクトの状況から判断の流れをたどる例を示します。特定の手段を推奨することはしません。この領域は変化が速いため、本ページの記述は2026年7月時点における各技術の公式な方針に基づきます。
何を共通化するか
開発手段は、共通化する範囲によって3つに分類できます。
「UIの実装まで共通化」で共通化されるのは、UIを構築するコードです。画面の見た目が両プラットフォームで一致することを意味しません。1つのコードから各OSのネイティブUIを組み立てる手段もあり、見た目をどこまで揃えるかは分類の中でさらに分かれます。
またいずれの分類でも、プラットフォーム固有のコードを部分的に書くことはあります。分類が示すのは共通化の範囲であり、共通化率が100%になることではありません。
注意すべきは、分類が技術の名前ではなく、その技術で何をするかという選択に付く点です。たとえばKotlin Multiplatformは、ネイティブUIを保つ構成なら「ロジックのみ共通化」ですが、JetBrainsのCompose Multiplatformを組み合わせると「UIの実装まで共通化」になります。
どの分類を選ぶかは、その分類を選べるかという制約と、選んだ後に引き受けるものの両方から判断します。
どの分類を選ぶか
軸に入る前に、候補が絞られる条件がないかを確認します。たとえば、決済端末や非接触ICカードの読み取りのように、ネイティブのみを対象とするベンダーSDKに依存し、その動作保証が要件になっている場合です。こうした条件に当てはまる手段は、技術的な優劣とは無関係に候補から外れます。 そのうえで、判断には次の4つの軸を使います。後半の2つは選んだ後に引き受けるものですが、決めてから判明するのではなく、選ぶ前に確認します。UIとデザインの工数
選べるかを決める制約。 UIを共通化しない選択は、画面の実装とデザインを2系統維持できるだけの人員を前提とします。
チームのスキル分布と人材流動性
選べるかを決める制約。 共通化の範囲が決まれば必要な言語もほぼ決まります。既存の強みと一致しなければ、その差が開発速度に表れます。
OSの変更への追従
選んだ後に引き受けるもの。 依存するレイヤが増えるほど、OS側の変更に追従するまでの待ち時間が生じます。
依存レイヤの数と問題調査
選んだ後に引き受けるもの。 依存レイヤを挟むと、問題がアプリケーションコードに起因するのか依存レイヤに起因するのかを判別する工程が加わります。
UIとデザインの工数
UIを共通化しない選択は、画面の実装とデザインを2系統維持できるだけの人員を前提とします。この前提が満たされない場合、Pure Nativeは技術的な優劣とは無関係に候補から外れます。 ここで効いてくるのが、UI実装とデザインの工数が2倍になるかどうかは、UIを共通化するか否かだけで決まり、ロジックを共通化するかどうかとは独立しているという点です。たとえばKotlin Multiplatformでビジネスロジックを共通化しても、画面はiOSとAndroidでそれぞれ実装します。UI実装の工数はPure Nativeと変わらず、デザインを2種類用意する工数も変わりません。削減されるのは共有レイヤに含めた部分の重複です。どこまでを含めるかは設計次第で、ビジネスロジックだけでなく画面の状態管理まで寄せる構成もあります。ただしいずれの場合も画面そのものは各プラットフォームで実装するため、UI実装とデザインの工数は変わりません。 この工数には、OSごとの標準UIの差異を設計で吸収する作業も含まれます。たとえば日本国内ではiOSの利用比率が高いと言われており、Pure Nativeを採用しながらAndroid側をiOSの見た目に寄せる運用が見られます。この場合、2系統を維持する工数を払いながら、成果物は統一UIに近づいていきます。チームのスキル分布と人材流動性
共通化の範囲が決まると、必要な言語とフレームワークもほぼ決まります。Pure Nativeでは各プラットフォームの専門性が必要になり、UIの実装まで共通化する手段では単一の言語・フレームワークの習熟が中心になります。すでに強みのある領域と一致する手段を選べば学習と採用のコストを抑えられ、一致しない手段を選べばその差が開発速度に表れます。 ここで効くのは採用市場の規模だけではありません。既存のWebフロントエンド開発者がモバイル開発に関与できるかという、組織内の人材流動性も判断材料になります。TypeScriptとReactを扱うチームが社内にある場合、React Nativeは新しい言語圏を増やさずに済む選択肢になります。 ただし流動性は無条件には成立しません。たとえばTypeScriptとReactに習熟していても、ストア申請、証明書と署名、プッシュ通知、バックグラウンド処理といったプラットフォーム固有の知識は別に必要になります。共通化によって減るのは実装の重複であり、プラットフォームの知識そのものではありません。 ここまでの2つが決めるのは、どの手段が優れているかではなく、どの手段が実現可能かです。OSの変更への追従
依存するレイヤ（FlutterやReact Nativeなど、共通化を担うフレームワーク）が増えるほど、OS側の変更に追従するまでの待ち時間が生じます。この待ち時間は性質の異なる2種類に分けて考えます。 1つ目は期限のある追従です。新しいOSバージョンへの必須対応、審査要件の変更、プライバシー関連要件などは、外部から期限が決まっています。依存レイヤの対応を待つ構造では、期限に対して自力で動ける範囲が狭まります。これは機能の有無ではなく、リリースを継続できるかというリスクの問題です。 2つ目は新デザインへの追従です。OSが新しいデザインを導入したとき、依存レイヤがそれに追従するかは、その設計方針に依存します。追従しなくてもアプリは動きますが、体験は徐々にOS標準から離れます。 Pure Nativeはこの待ち時間が構造的に発生しません。期限のある対応が頻繁に生じるプロダクトや、OSの新機能をプロダクトの中心に据えるプロダクトでPure Nativeが選ばれるのは、この性質によるものです。 共通化する手段を選ぶ場合、この待ち時間はゼロにはできませんが、必要に応じてプラットフォーム固有のコードを書くことで個別に回避できることがあります。したがって判断の材料になるのは、待ち時間が発生するかどうかではなく、回避策を書く頻度がどの程度になるかです。この頻度はプロダクトがOSの機能にどれだけ依存するかで決まります。依存レイヤの数と問題調査
依存するレイヤが増えると、問題発生時の切り分け工程が増えます。Pure Nativeでは各プラットフォームの公式ツールで直接調査できますが、依存レイヤを挟む場合は、問題がアプリケーションコードに起因するのか依存レイヤに起因するのかを判別する工程が加わります。 この差は日常的な開発では見えにくく、障害調査や性能改善のときに顕在化します。再現条件が片方のプラットフォームでしか成立しない場合や、依存レイヤの既知の問題に該当するかどうかを調べる必要がある場合に、調査時間が伸びます。条件から分類を判定する
4つの軸を判断に使うと、条件と分類は次のように対応します。挙げているのは典型例であり、網羅ではありません。
複数の条件が別々の分類を指すことは珍しくありません。その場合はまず、足切りとして働く条件がないかを見ます。回避策で吸収しきれないほどOSの新機能に依存するなら、依存レイヤを持つ手段は候補に残りません。そのうえで候補が複数残るなら、後から変更するコストが最も高い条件を優先します。UIの共通化方針は実装量に直結するため、途中での変更は他の条件より大きなコストを伴います。
選択肢
分類が決まると、次はその分類の中で手段を選びます。「共通化しない」を選んだ場合、手段はSwiftとKotlinに決まるため、ここで扱うのは残る2つの分類です。UIの実装まで共通化
この分類には複数の手段がありますが、ここではよく比較されるFlutterとReact Nativeを例に取ります。両者を分けるのは技術的な性能比較ではなく、UIデザインの統一をフレームワークの方針として持つかです。Flutterは自前描画により、OSをまたいだ統一を設計方針に掲げます。React Nativeは各OSの標準を正とし、統一が必要な場合はそれを担うUIライブラリを選んで実現します。
Flutterは、OSが提供するUI部品を使わず、すべてのUIコントロールを自前で描画します。公式のアーキテクチャ解説は、この方式の利点としてOSへの依存を切り離せることを挙げ、OSがコントロールの実装を変更してもアプリの見た目と操作感は同じままだと説明しています。つまりOSからの独立が、副作用ではなく設計目標として位置づけられています。
この方針は実際の開発体制にも表れています。2026年7月時点で、FlutterはiOSの新しいデザインへの対応と、AndroidのMaterial 3 Expressiveへの対応をいずれも保留しています。これは遅れではなく、設計を見直すための意図的な判断として公式に表明されています。
片方のプラットフォームだけが対象ではない点が重要です。Flutterはこの保留について、デザインシステムをどう統合するかという設計そのものを見直すためだと説明しており、特定のOSを軽視した結果ではありません。
React Nativeは逆に、各プラットフォームのネイティブUIを正とします。公式ドキュメントは、React NativeのコンポーネントがAndroidとiOSの同じビューに支えられているため、アプリが他のアプリと同じ見た目と操作感になると説明しています。OSのデザイン指針が変更された場合、その変更はネイティブUI側の更新として反映されるため、追従は相対的に早くなります。その代わり、両プラットフォームで統一された見た目を作りたい場合は、OSごとの差異を自分で吸収する必要があります。
各OSの標準を正とするのはフレームワークの方針であり、統一を選べないという意味ではありません。iOSとAndroidで見た目を揃えるためのUIライブラリがOSSとして揃っており、これを用いて統一デザインにしている事例は多くあります。その場合、統一を保つ責任はフレームワークではなく、ライブラリの選定と維持の側に移ります。
React Nativeを選ぶ場合、公式にはExpoと組み合わせる構成が推奨されています。React Nativeの公式ドキュメントはフレームワークの利用を推奨したうえでExpoを名指しし、公式ブログでも新規アプリで推奨される唯一のコミュニティフレームワークとして位置づけています。フレームワークを使わない構成も引き続きサポートされますが、既定の選択ではありません。
ロジックのみ共通化
ロジックのみを共通化すると決めた場合、Kotlin MultiplatformとSwift on Androidが候補になります。両者は技術的には鏡像の関係にありますが、組織にとっては非対称です。
Kotlin MultiplatformはKotlinを共通言語とするため、Android側の言語圏が中心になります。Swift on AndroidはSwiftを共通言語とするため、iOS側の言語圏が中心になります。どちらの言語圏を組織の中心に据えるかという選択であり、iOSに強いチームとAndroidに強いチームで最適解が入れ替わります。
成熟度には差があります。Kotlin Multiplatformは2017年に実験的機能として導入され、2023年に安定版となり、2024年にはGoogleがAndroidでのサポートを表明しました。Googleはこの表明の中で、UIから最も独立した部分であるビジネスロジックの共通化に支援の焦点を置くと述べています。複数の大規模サービスでの採用も公表されています。
一方でSwift on Androidは、2025年にプレビュー版が公開され、2026年3月に初の公式SDKがリリースされた段階です。公式ドキュメントはSwiftコードを共有ライブラリとして組み込み、UIはJavaまたはKotlinで実装する構成を示しており、ロジック共通化に位置づけられることが明示されています。歴史が浅く、公表された本番運用の事例は限られています。採用は、先行事例に頼らずに進める判断になります。
分類の境界は動く
ロジックのみを共通化する2つの言語圏には、いずれもUI共通化へ向かう動きがあります。Kotlin圏にはCompose Multiplatform、Swift圏にはSkipがあり、いずれもUIの共通化までを対象にします。どちらを採用しても、その構成は「UIの実装まで共通化」に当たります。判断の流れをたどる
ここまでの内容を、判断の流れとしてまとめます。分類の分岐は4つの軸から、手段の分岐は各分類の中で候補が分かれる基準から決まります。 次の3つは、組織とプロダクトの状況から分類と手段を決めた例です。挙げているのは典型例であり、同じ状況でも他の条件が優先されれば結論は変わります。各OSに専任者を置ける規模で、OSの新機能が中核にある場合
この場合はPure Nativeが適しています。 各OSに専任者を置ける規模なら、実装とデザインを2系統維持する工数を払えます。この前提が満たされているとき、判断の重心はOSの変更にどう追従するかに移ります。新機能が中核にあるほど、依存レイヤの対応を待つ構造が効いてくるため、待ち時間そのものを持たない構成を選びます。TypeScriptとReactのチームがあり、モバイル専任チームを新設しない場合
この場合はReact Nativeが適しています。 各OSに専任者を置かない以上、実装は1系統に収めるほかありません。そのうえで効くのが、既存のWebフロントエンドの人材が関与しやすいかどうかです。TypeScriptとReactを扱うチームがあるなら、新しい言語圏を増やさずにモバイル開発を始められます。デザインを各OSの標準に委ねる前提に立てば、統一した見た目を自前で設計する工数も抱えません。 ただしこれは、デザインの正を各OSに委ねることを引き受ける選択でもあります。統一された見た目を要件に加えるなら、それを担うUIライブラリの選定と維持が改めて必要になります。OSの新機能が中核にありながら、統一された見た目を動かせない場合
この場合はFlutterが適しています。 統一された見た目は「UIの実装まで共通化」を、OSの新機能への依存は「共通化しない」を指すため、2つの条件は別々の分類を指します。ここで先に固定するのは、後から覆すコストが高いほうです。UIの共通化方針は実装量に直結するため、これを先に決めます。 残るのはFlutterとReact Nativeのどちらを採るかです。分かれ目は、統一された見た目を誰が維持し続けるかにあります。React Nativeはネイティブビューを土台とするため、OSがデザインを変更するとその変更がアプリに届きます。標準に沿った見た目を保つときは利点ですが、統一を要件とする場合は逆に働き、OSの更新のたびにUIライブラリ側で差分を吸収する作業が生じます。Flutterは自前描画でOSから独立しているため、OSがデザインを変更しても見た目は変わりません。統一された見た目が動かせない要件であるほど、この差が効いてきます。 OSの新機能への追従は、回避策を書く頻度として引き受けることになります。Flutterという結論が成り立つのは、この頻度が想定に収まる範囲にあるときです。超えるなら、UIを共通化するという前提自体が崩れます。その場合の着地はPure Nativeであり、統一された見た目は2系統の工数を払い、設計で寄せて近づけることになります。関連ページ
データベースの選び方
データ側にある同じ形の判断。製品を比べる前に前提を決めます。
変更容易性
構造の選択の代償が、あとからどれだけ安く変えられるかとして現れる理由を扱います。
タスク分解
開発手段が決まったあと、単独でマージでき単独で戻せる単位に作業を分けます。