クロスプラットフォームとは？ネイティブ開発との違いと向かないケース

2026-01-16 2026-10-15

iOS向けとAndroid向けのアプリを、コードを共通化して作る。この作り方を「クロスプラットフォーム」と呼びます。

開発を相談されるとき、よく出てくる質問があります。1つのコードで作れば費用は半分で済むのか、という問いです。実際には、重複していた実装を減らせる部分と、共通化しても変わらない部分があります。

そして初期の費用に加えて、公開後に土台の変化へ追従する作業も判断材料になります。AppleやGoogleのOSだけでなく、アプリを作るために使った「共通化の仕組み」そのものの変化にも、対応し続ける必要があるためです。コードを共通化するには、FlutterやReact Nativeのようなフレームワークを使います。自社で書いたコードとOSのあいだに、他社が作って他社が更新するものが1つ入る形です。そのフレームワークが更新されたり、サポートが終わったりすれば、こちらも対応することになります。この点は見積もりの段階では見えにくく、相談の場で後から出てくることが多い論点です。

この記事では、ネイティブ開発との違いを作業量の面から整理したうえで、向かないケースと、土台が変わったときに何が起きるかまで書きます。どのフレームワークを選ぶかより前に決めることがある、という順番で並べています。

Enlyt（エンライト）では、コードを共通化して作る案件と、片方のOSだけを引き受ける案件の両方があります。そこで論点になることをもとにまとめました。

クロスプラットフォームとは

複数のOSや実行環境に対応するという意味

クロスプラットフォームは、複数のOSや実行環境に対応することを指す言葉です。アプリ開発の文脈では、コードを共通化して複数のOS向けに作る方法を指して使われます。

共通化の範囲は、全部か全部でないかの二択ではありません。画面まで共通にする方法もあれば、通信や保存といった処理だけ共通にして、画面はOSごとに作る方法もあります。Kotlin Multiplatformの公式ドキュメントには、ネットワークや保存のような部分だけ共通にして段階的に広げられる、という説明が書かれています。

この記事では、iOSとAndroid向けのストアアプリを中心に、何を共通化して何をOSごとに作るかという観点で整理します。

この記事で比べるもの

比較の相手として、OSごとに個別に実装する方法をネイティブ開発と呼びます。iOS向けをSwift、Android向けをKotlinのように、OSごとに別の言語で別に作る形です。

注意したいのは、クロスプラットフォームの側にも、OSが持っている画面の部品やAPIを使うものがあるという点です。「ネイティブ」という語は画面の作り方を指す場合と、OSごとに個別実装することを指す場合があります。この記事で「ネイティブ開発」と書いているのは後者です。

マルチプラットフォームとの呼び分け

似た言葉にマルチプラットフォームがあります。IT用語辞典のe-Wordsでは、マルチプラットフォームを「あるコンピュータプログラム（ソフトウェア）を、複数の異なる仕様の機種やオペレーティングシステム（OS）で同じように動作させられること」と説明しています。クロスプラットフォームについては、マルチプラットフォームの同義語とする場合と、異なるプラットフォーム向けの同じソフトウェア間で通信や連携ができることを指す場合があると、2つの用法が並べて書かれています。後者はゲーム業界で使われる用法で、アプリ開発の文脈で出てくるのは前者です。

実務でも厳密に使い分けられてはいません。Kotlin Multiplatformのように製品名側がマルチと名乗っているものもあります。打ち合わせで言葉が噛み合わないと感じたときは、名前ではなく「どのOS向けに出すのか」「どこまで同じコードを使うのか」を確認したほうが早くそろいます。

ネイティブ開発との違い

共通化によって減らせる作業

コードを共通化すると、両方のOSで重複していた作業を減らせます。

Enlytで公開している事例のうち、単語帳アプリの開発事例は、Flutterで1つのソースコードから2つのモバイルアプリを作ったものです。2か月以内にベータテストを開始する必要があった案件で、2本を別々に作るのではなく1つのコードで進めています。期間に制約があるときに効きやすい形です。

共通化しても残る作業

一方で、作り方を変えても残る作業があります。ここを見落とすと、費用が半分になる前提で計画してずれます。

OS固有の実装が残ることは、土台の側も前提にしています。React Nativeの公式ドキュメントには、OSを判定して処理を分ける方法と、ファイル名の末尾でiOS用とAndroid用を分ける方法が説明されています。共通化は、分かれる部分をなくす仕組みではなく、分かれる部分を切り出せる仕組みだと見たほうが実情に近いです。

減らせるのは主に実装と改修の部分です。案件全体のどのくらいを実装が占めるかで、効き方が変わります。画面数が多くて作る量が中心の案件では効きやすく、要件の調整や外部システムとの連携が重い案件では、比率としては小さくなります。

画面を共通化する場合の描画方式の違い

画面まで共通にする場合、その描き方で性質が変わります。規格として決まった分類ではありませんが、この記事では3つに分けて整理します。処理だけ共通にして画面をOSごとに作る方法は、この分類の外になります。

どの方式かによって、OSが新しくなったときの影響の受け方が変わります。ネイティブUI利用型はOS側の部品の変更がそのまま効き、独自レンダラ型は土台側の描画エンジンの変更が効きます。見た目をそろえたいのか、OSらしさを優先したいのかで、向く方式が変わります。

クロスプラットフォームが向かないケース

コードを共通化するほうが有利とは限りません。見送る、あるいは条件を確かめてからにしたほうがよい場面があります。

OS固有の機能をどう扱うか

土台側がまだ対応していない機能について、使えないのか、書けば使えるのかは分けて考える必要があります。主な土台には、OS固有のコードを呼び出す仕組みが用意されています。

Flutterには、Dartのコードから各OSのコードへメッセージを渡すプラットフォームチャネルという仕組みがあり、公式ドキュメントに書き方が説明されています。React Nativeにも、OSごとに処理やファイルを分ける方法と、OS側のコードをモジュールとして呼び出す仕組みがあります。

ただし、書けば使えることと、負担なく使えることは別です。OS固有のコードを書く部分が増えれば、共通化で減らせるはずだった分はその分だけ戻ります。どのくらいの範囲でそれが必要になるかを、見積もりの前に見ておく価値があります。

片方のOSだけで公開するという選択

両方のOS向けに出すことが前提になりがちですが、片方だけで公開する判断も実際にあります。利用者がどちらのOSに寄っているかが分かっている場合や、先に片方で出して反応を見る場合です。この場合、共通化する相手がないので、1つのコードにする利点は小さくなります。

これとは別に、すでに片方のOSで公開しているサービスに、もう片方を足すという場面もあります。Enlytで公開しているお天気アプリの開発事例は、Android版とWeb版がすでに提供されていたサービスで、iOSアプリの部分を引き受けたものです。言語はSwiftで、Android版のソースと仕様の資料をもとに同じように動くものを作る形でした。既存のアプリを残したまま、別の言語でもう片方を足すという進め方も成り立ちます。

ストアに出すアプリが必要なのか、LINEの中やWebで足りるのかという手前の判断は、LINEミニアプリ vs ネイティブアプリ vs Webアプリで扱っています。そこでストアアプリと決まったあとに、この記事の論点が出てきます。

主な土台と、いまの状況

よく候補に挙がる4つについて、公開されている情報から整理します。細かい比較は別記事に分けているので、ここでは性質の違いだけ並べます。

Kotlin Multiplatformの公式ドキュメントには、共通化の範囲を段階的に広げられると書かれています。画面はSwiftUIやUIKitで作る形も、画面まで共通にする形も選べる、という説明です。全部か全部でないかの二択ではない点は、設計の自由度として知っておく価値があります。

FlutterとReact Nativeの比較はReact Native vs Flutterの比較で、Flutter単体の特徴はFlutterとはで扱っています。

土台が変わったときに何が起きるか

クロスプラットフォームで作ると、OSと自社のコードのあいだに、もう1つ依存先が加わります。その土台が更新されたり、サポートが終わったりしたときに何が起きるのか。見積もりの段階では見えにくい部分なので、過去に起きたことを2つ挙げます。

サポートが終了した例

Microsoftが提供していたXamarinは、2024年5月1日にXamarin.Formsを含むすべてのXamarin SDKのサポートが終了しました。公式のサポートポリシーには、新しいAPIの予定はないと書かれています。Xamarin.Android、Xamarin.iOS、Xamarin.Macは、.NET 6以降の.NET for Android、.NET for iOS、.NET for Macとして.NET本体に統合されました。Xamarin.FormsからMicrosoftの後継技術へ移行する場合、.NET MAUIが選択肢になります。

移行の負担について、Microsoftの移行ガイドの概要ページは「プロジェクトを書き換える必要はありません」と明記しています。ただし同じガイドの中の手動アップグレードの手順ページには、カスタムレンダラーやエフェクト、カスタムレイアウトはコードの更新が必要で、XAMLの既定の名前空間は書き換えが必要だと書かれています。.NET MAUIに同等の機能がないと明記されている項目もあります。

読み取れるのは、全面的に作り直しになるわけではないが、画面まわりを独自に拡張していた部分ほど手が入る、という形です。標準の部品で素直に作っていたアプリと、作り込んでいたアプリで、移行の重さが変わります。

内部の作りが入れ替わった例

サポートが続いていても、土台の内部構造が入れ替わることがあります。React Nativeでは、内部の作りを刷新したNew Architectureへの切り替えが段階的に進められました。0.76で既定になり（2024年10月）、0.81が旧アーキテクチャを使える最後のバージョンと案内され、0.82で無効化の設定が無視されるようになり、0.84で旧アーキテクチャのコードがiOSのビルドに含まれなくなりました（2026年2月）。

公式のリリース一覧では、保守の対象は直近3つのマイナーバージョンに限られます。2026年10月の時点では、0.81から0.84までがすべてサポート対象外と表示されています。旧アーキテクチャのまま止まっているプロジェクトは、すでにサポートの外にいることになります。

この1年のあいだにも、既定のJavaScriptエンジン、アニメーションの実装、Androidのビルドツールや開発環境の最低要件が順に変わっています。使っている外部のライブラリがこれらに対応していなければ、そこも含めて確認が必要になります。

サポートされる期間が土台ごとに違う

公式に書かれているサポートの方針を並べると、土台ごとに考え方が違います。

React Nativeは直近3マイナーを保守すると明記されています。リリース間隔は公式に書かれていませんが、公開されているリリース一覧の日付では約2か月ごとで、実質的には半年前後と読めます。Flutterはstableチャンネルをおよそ3か月ごとに更新すると案内しています。

.NET MAUIについては、注意したい点があります。.NET本体のサポートポリシーでは、.NET 10はLTS（長期サポート）で2028年11月14日までとされています。一方で.NET MAUIのサポートポリシーは「後継のメジャーバージョンが出てから最低6か月」という方式で、.NET MAUI 10のサポート終了は2027年5月11日です。.NET MAUIは.NET本体とは異なるサポート期限を持つので、各バージョンの期限を確認して更新を計画する必要があります。

同じページのサポート対象外の一覧を見ると、.NET MAUI 9は2026年5月12日、8は2025年5月14日、7は2024年5月14日で終了しています。11月に次のメジャーバージョンが出て、その半年後の5月に前のバージョンが切れる形が続いています。

ネイティブ開発にも更新はある

ここまで土台の話を書きましたが、ネイティブ開発なら更新が要らないということではありません。OSのSDK、開発環境、使っているライブラリは、どちらの作り方でも更新されます。

違うのは、依存する層が1つ増えるかどうかです。ネイティブ開発ではOSとライブラリの更新に追従しますが、クロスプラットフォームではそこに土台の更新が加わります。比べるときは「更新作業があるかどうか」ではなく、追従する対象がどれだけ増えて、その更新がどのくらいの頻度で来るのかを見るほうが実態に合います。

発注の前に確認しておきたいこと

土台の変化に対して、どこまで決めておくかは案件の性質で変わります。相談を受けていて論点になるのは次のあたりです。

Enlytでは、こうした点を見積もりの前の整理のなかで確認しています。扱い方は案件の規模や社内の体制によって変わるので、一律の決め方はしていません。公開後の保守の考え方はアプリの維持費は開発費の15%が相場って本当？でも扱っています。

ストアの要件は、どちらで作っても同じようにかかる

共通化しても残る作業として、ストアへの対応があります。これはコードを共通化しても、OSごとに作っても、アプリ単位で課されます。

Google Playには、target API levelの要件があります。公式ページには、2026年8月31日から、新規のアプリとアプリの更新はAndroid 16（APIレベル36）以上を対象にしないとGoogle Playに提出できないと書かれています。既存のアプリについては、Android 15（APIレベル35）以上でないと、アプリの対象APIレベルより新しいAndroid OSの端末で新規のユーザーに配信されなくなる、という扱いです。すでに入れている人のアプリが消えるという書き方ではありません。期限に間に合わない場合は2026年11月1日までの延長を申請できるとされており、またWear OSやAndroid TVなど、モバイル以外には別の基準が設けられています。

App Storeの側では、2026年4月28日以降、App Store Connectにアップロードするアプリは Xcode 26以降で、iOS 26やiPadOS 26などのSDKを使ってビルドする必要があります。こちらはすでに適用されている要件です。

この手の要件は、繰り返し更新されてきました。Appleの要件一覧には、2023年4月のXcode 14.1、2024年4月のXcode 15、そして2026年4月のXcode 26と、過去の要件が並んでいます。

2027年分も、すでに告知が出ています。Appleは2026年9月の開発者向けニュースで、2027年4月からApp Store Connectにアップロードするアプリは iOS 27 と iPadOS 27 のSDK以降でビルドする必要があると案内しました。tvOS、visionOS、watchOSについても同じく27以降のSDKが挙げられています。一方のGoogle Playは、2026年10月の時点で2027年分の要件を公表していません。

注意したいのは、Appleの場合、確定した日付が要件一覧のページに載る前に開発者向けニュースで先に出る形があるという点です。要件一覧だけを見ていると、告知に気づかないことがあります。1年に1回は来るものとして、来たときに動ける状態にしておく、という性質の作業です。

提出の要件と、利用者の端末の最低OSは別の話

混ざりやすいので分けておきます。ストアに提出するために必要なSDKやtarget API levelと、利用者の端末で動作する最低OSは別の条件です。新しいSDKでビルドすることと、古いOSの端末を切り捨てることは同じではありません。

古い端末をどこまで対象にできるかは、土台や使っているライブラリが対応している範囲も含めて確認することになります。たとえば.NET MAUIの開発中の次期バージョンでは、対応する最低のAndroid APIレベルが21から24に上がると案内されています。これは2026年10月の時点ではプレビューと候補版の段階の情報ですが、土台側の都合で対象端末の下限が動くことがある、という例になります。

土台の側とストアの要件がつながっている部分もあります。Kotlin Multiplatformの互換性のページには、Kotlin Multiplatformプラグインのバージョンごとに対応するXcodeのバージョンが表で示されています。ストア側の要件を満たすために開発環境を上げると、土台の側も対応するバージョンに上げることになります。

なお、これらの要件がクロスプラットフォームの場合にどう適用されるかという説明は、ストア側の公式ページには書かれていません。要件の対象は「App Store Connectにアップロードされるアプリ」「Google Playにアップロードされるアプリ」という単位で書かれています。

見積もりを比べるときに分かれるところ

複数の会社から見積もりを取ったとき、同じようにコードを共通化する前提でも金額が開くことがあります。開く理由は、技術の差より、見積もりに入っている範囲の差であることが多いです。

総額だけを並べても、範囲が違えば比べられません。項目の立て方をそろえてから見ると、どこで差がついているかが見えます。

とくに土台のバージョン更新は、見積もりの段階では小さく見えて、公開後に効いてくる項目です。初期の開発費に含まれない作業として、どこかに置かれているかを確かめておく価値があります。

判断の材料になる開発事例

公開している事例から、作り方の判断に関係するものを挙げます。

• 単語帳アプリの開発事例　Flutterで1つのソースコードから2つのモバイルアプリを作った例。ベータテストの開始まで2か月という制約があった案件
• お天気アプリの開発事例　既存のAndroidアプリを残したまま、iOSをSwiftで追加した例
• 受験マッチングアプリの開発事例　Flutterでのアプリ実装と、既存のWebシステムとの会員情報の連携まで含めた例

どの事例も、作り方を先に決めてから要件を考えたわけではありません。出す範囲と時期、つなぐ先が決まった結果として作り方が決まっています。

そもそもストアに出すアプリが必要かという段階であれば、LINEミニアプリ vs ネイティブアプリ vs Webアプリのほうが近い内容です。この記事はストアアプリを作る前提で書いています。

よくある質問

クロスプラットフォームとマルチプラットフォームの違いは何ですか

厳密な使い分けはありません。IT用語辞典のe-Wordsでは、クロスプラットフォームはマルチプラットフォームの同義語として使う場合と、異なるプラットフォーム向けの同じソフトウェア間での通信や連携を指す場合があると説明されています。アプリ開発の文脈では前者の意味で使われます。製品名としてKotlin Multiplatformのようにマルチを使うものもあります。やりとりの場では、どのOS向けに出すのかとどこまで同じコードを使うのかを確認したほうが確実です。

あとからネイティブに作り直せますか

共通化していた範囲によって、必要な作業が変わります。画面まで共通にしていた場合、画面の実装は書き直しになります。サーバーとのやりとりやデータの持ち方といった部分は、設計を引き継げる場合があります。どこまで引き継げるかは既存のコードを見ないと判断できません。

片方のOSだけ先に出して、あとで両方にできますか

できます。ただし共通化する範囲によって、先に作ったコードの改修や再実装が必要になります。片方をネイティブで作ったあと画面まで共通にしようとすれば画面は作り直しになりますが、既存の画面を残して処理だけ段階的に共通化していく方法もあります。Kotlin Multiplatformのように、処理だけ共通にして画面はOSごとに持つ形を選べる土台もあります。公開を片方に絞ることと、作り方を片方に絞ることは別の判断です。

保守費用は、ネイティブで作るより安くなりますか

共通化した部分の改修は1か所で済むので、機能を追加していく部分は減りやすいです。一方で土台のバージョンを上げる作業が加わります。どちらが大きいかは、どのくらいの頻度で機能を追加するか、外部のライブラリにどこまで頼っているかで変わります。費用の構成はアプリの維持費は開発費の15%が相場って本当？で扱っています。

React Nativeを選ぶとき、Expoは使ったほうがよいのですか

React Nativeの公式ドキュメントでは、新しくアプリを作る場合はExpoのようなフレームワークを使うことを推奨すると書かれています。フレームワークなしでも作れるとされていますが、特殊な制約がある場合の選択肢という位置づけです。なおExpoのフレームワーク自体と、ビルドや配信などを支援するExpo Application Services（EAS）は別のものです。EASの利用は任意で、無料と有料のプランがあります。

ゲームも作れますか

描画や物理の処理が中心になるものは、ゲーム向けのエンジンのほうが向く場面になります。Unityもクロスプラットフォームに対応していて、公式サイトにはゲーム機やVR機器まで含めた対応プラットフォームが挙げられています。一般的なアプリ向けのフレームワークとは、得意な範囲が違うと見たほうが選びやすくなります。アプリの一部にゲーム的な要素を入れる程度であれば、通常の土台の中で収まることもあります。

Webアプリとの違いは何ですか

この記事はストアに出すアプリを前提にしています。ブラウザで動くWebアプリや、既存のサイトをアプリの形にする方法との違いはモバイルアプリとはで扱っています。

判断がつかない段階からの相談

Enlytでは、作り方が決まっていない段階からの相談を受けています。コードをどこまで共通化するかは、出す範囲と時期、つなぐ先、公開後に誰が面倒を見るかが見えてくると決まりやすくなります。

相談の段階では、どのOS向けに出す予定か、既存のシステムとつなぐ必要があるか、社内にアプリを見られる人がいるか、といったあたりをうかがっています。資料だけ先に見ておきたいという場合は、下の資料ダウンロードからお取りいただけます。

この記事で参照した資料

• Microsoft「Xamarin サポート ポリシー」（Xamarinのサポート終了日、.NETへの統合）
• Microsoft「Xamarin から .NET へのアップグレード」（書き換えは不要とされる範囲）
• Microsoft「Xamarin.Forms アプリを複数プロジェクトの .NET MAUI アプリに手動でアップグレードする」（手作業が必要な項目、同等の機能がないAPI）
• Microsoft「.NET MAUI Support Policy」（後継メジャーから最低6か月、各バージョンのサポート終了日）
• Microsoft「.NET and .NET Core Support Policy」（.NET 10のLTSとしてのサポート終了日）
• Microsoft「What’s new in .NET MAUI for .NET 11」（最低Android APIレベルの引き上げ。プレビューと候補版の段階の情報）
• Flutter「Security」（セキュリティ更新の対象はstableチャンネルのバージョン）
• Flutter「Upgrade Flutter」（stableチャンネルの更新頻度）
• Flutter「Supported platforms」（対応プラットフォームと対応区分）
• Flutter「Writing custom platform-specific code」（OS固有のコードを呼び出す仕組み）
• Flutter「Compatibility policy」（破壊的変更と非推奨の扱い）
• React Native「Releases Overview」（直近3マイナーを保守する方針、各バージョンのサポート状況）
• React Native「0.84 – Hermes V1 by Default」（旧アーキテクチャのコードの削除が既定になったこと）
• React Native「0.82 – A New Era」（新アーキテクチャのみになったこと）
• React Native「Platform-Specific Code」（OSごとに処理やファイルを分ける方法）
• React Native「Out-of-Tree Platforms」（本体が対象にするプラットフォームと、パートナー保守の区分）
• React Native「Get Started with React Native」（フレームワークの推奨、Expoの位置づけ）
• Expo「Pricing」（EASのプラン。無料プランの有無）
• JetBrains「What is Kotlin Multiplatform」（共通化の範囲を段階的に広げられること）
• JetBrains「Compatibility guide for Kotlin Multiplatform」（プラグインとXcodeのバージョンの対応表）
• Google「Google Play の target API level の要件を満たす」（2026年8月31日からの要件、既存アプリの扱い、延長の申請）
• Apple「Upcoming Requirements」（SDKの最低要件と、過去の要件の一覧）
• Apple「App Store submissions now open for the latest OS releases」（2027年4月からの最低要件。2026年9月9日）
• Unity「Multiplatform game development」（対応プラットフォームの一覧）
• IT用語辞典 e-Words「マルチプラットフォーム」（クロスプラットフォームとの呼び分け）

土台のバージョンやサポートの期限は変わります。この記事の内容は2026年10月時点で各提供元の公式ページに書かれていたものです。発注の判断に使う場合は、該当するページを直接ご確認ください。

金子 遼平

フィリピンの語学学校スタッフとして5年間勤務後、Enlytに参画。 現在はフィリピン在住で完全リモートにて、開発ディレクター・PM・デザイナーとして複数プロジェクトを担当。 UI/UX設計とプロジェクトマネジメントを横断できる点を強みとし、リモート環境下でも安定した品質とスピードを実現している。

View More