ネイティブアプリか、クロスプラットフォームアプリか？

ブダペストのソフトウェア開発会社であるMesterséges Intelligencia Központ Kft. の考えでは、アプリが端末を深く利用する場合はネイティブアプリが必要で、両プラットフォームで機能が同じなら、共通のコードベースのほうが保守は簡単です。

要点： 判断を左右するのは流行ではなく機能です。アプリが端末にどこまで深くアクセスする必要があるか、どれだけの性能が必要か、そして誰が何年にもわたって保守するかです。アプリストアでの公開と端末への深いアクセスが重要でなければ、ウェブアプリ（PWA）で足りる場合もあります。どの道を選ぶにしても、バックエンド、アプリストアのルール、そして定期的なOSのアップデートへの対応が、作業の大きな部分を占めます。

ネイティブアプリ、クロスプラットフォームアプリ、ウェブアプリとは何ですか？

モバイルアプリの作り方は3通りあります。プラットフォームごとに、そのプラットフォーム独自のツールで別々に作る方法、両プラットフォーム向けにコンパイルされる共通のコードベースから作る方法、そしてウェブ技術を使い、ブラウザー上で動かす方法です。3つの道のどれでも動作するアプリができます。違いは、アクセスできる範囲、保守、そしてアプリが誰のルールに合わせて更新されるかにあります。

ネイティブアプリ

ネイティブアプリでは、iOS版とAndroid版を、それぞれのプラットフォーム独自の言語とUIツールで別々に作ります。iOSでは現在、一般にSwift言語とSwiftUIを使います。Appleによれば、SwiftUIは宣言型の構文を使い、Swiftを基盤として、すべてのAppleプラットフォームでユーザーインターフェースを構築できるようにします（Apple: SwiftUI）。AndroidではKotlinとJetpack Composeです。GoogleはJetpack Composeを、ネイティブUIを構築するためのAndroid推奨のモダンなツールキットと位置づけており（Android Developers: Jetpack Compose）、新しいAndroidアプリはKotlinで始めることを推奨しています（Android Developers: Kotlin-first）。ネイティブの道の利点は、プラットフォームの新しい機能をすべて初日から直接利用できることです。欠点は、2つのコードベースを開発し、保守しなければならないことです。

クロスプラットフォームのフレームワーク

クロスプラットフォームのフレームワークでは、iOSアプリとAndroidアプリを共通の1つのコードベースから作ります。よく使われる4つのアプローチは次のとおりです：

Flutter： Dart言語を使うフレームワークです。ドキュメントによれば、Flutterはシステムのコントロールを使う代わりに、すべてのUIコントロールを独自に実装しており、描画にはImpellerというエンジンを使います。プラットフォーム独自のコードは、プラットフォームチャネルと呼ばれる仕組みを通じて呼び出せます（Flutter: Architectural overview）。
React Native： ReactとJavaScriptを基盤とします。プロジェクト自身の説明によれば、JavaScriptで記述しながらネイティブコードで描画されます。基本コンポーネントが、プラットフォームのネイティブUIの構成要素に対応づけられているからです（React Native）。バージョン0.76からは、いわゆる新アーキテクチャ（New Architecture）がデフォルトになり、非同期のブリッジがJavaScript Interface（JSI）に置き換えられました（React Native: New Architecture）。
Kotlin Multiplatform： JetBrainsのオープンソース技術で、Android、iOS、デスクトップ、ウェブ、サーバーの各ターゲットの間でコードを共有できます。ビジネスロジックだけを共有してUIはネイティブにすることも、Compose Multiplatformを使ってUIまで共有することもできます（Kotlin: Kotlin Multiplatform）。Kotlinのドキュメントによれば、Compose MultiplatformはiOSでも安定版（Stable）のレベルにあります（Kotlin: stability of supported platforms、2026年10月17日確認）。
.NET MAUI： C#とXAMLを使うMicrosoftのフレームワークで、Android、iOS、macOS、Windows向けのアプリを単一の共通コードベースから開発できます。Xamarin.Formsの後継にあたります。iOSアプリとmacOSアプリのビルドにはMacが必要です（Microsoft Learn: What is .NET MAUI?）。

プログレッシブウェブアプリ（PWA）

PWAはブラウザーで動作するウェブアプリで、ホーム画面にインストールでき、段階的に機能を拡張する手法（progressive enhancement）によって、より信頼性の高い体験を提供します。web.devのまとめによれば、プラットフォームアプリは機能の面で、ウェブアプリは到達範囲の面で最も優れており、1つのコードベースで、誰にでも、どの端末にでも届けられます（web.dev: Progressive Web Apps）。iOSとiPadOSでは、バージョン16.4以降、ホーム画面に追加したウェブアプリもプッシュ通知の許可を求められるようになりました（WebKit: Web Push for Web Apps）。重要な制約が1つあります。App Storeのガイドラインの4.2項によれば、アプリは再パッケージ化したウェブサイト以上のものを提供する必要があるため、ウェブサイトを単にアプリとして包んだだけのものをストアに出すのは得策ではありません（Apple: App Store Review Guidelines）。

一覧表での比較

観点	ネイティブ（Swift、Kotlin）	クロスプラットフォーム（Flutter、React Native、KMP、.NET MAUI）	PWA
性能	プラットフォームのツールで直接最適化できる	計算負荷の高い部分をネイティブコードに移せる	ブラウザーとウェブ技術によって決まる
端末へのアクセス	プラットフォームのすべての機能を初日から	フレームワークやプラグイン経由で、新機能は後から、または追加のネイティブコードで利用可能	ブラウザーが対応するウェブのインターフェースに限られる
見た目と操作感	プラットフォーム独自のコンポーネントそのもの	Flutterでは独自描画のコンポーネント、React Nativeではネイティブのコンポーネント	ウェブサイトに近く、ブラウザーに左右される
コードの共有	なし。2つの別々のコードベース	ロジックと、多くの場合UIも共通	すべての端末で1つのコードベース
チーム	iOSとAndroidの専門知識が別々に必要	1つのチームで足りるが、ネイティブのレイヤーの知識も必要	ウェブ開発のチーム
保守	2つのコードベースがプラットフォームの定期的な変更に追随	1つのコードベースに加え、フレームワーク自体のアップデート	ストアでのリリースはないが、ブラウザーの変化に追随する必要がある
アプリのサイズ	OS標準のライブラリを利用	フレームワークのエンジンもアプリに同梱される	インストールパッケージはなく、ブラウザーがキャッシュする
アプリストアでの公開	あり	あり	不要。ストア向けに包む場合は4.2項の制約が適用される

Flutterのドキュメントは、Flutterアプリのパッケージは自己完結型で、実行に必要なすべてのコードとアセットを含むため、そのサイズが考慮すべき点になり得ると明言しています（Flutter: Measuring your app's size）。実際にはこの違いが決め手になることはまれですが、対象ユーザーが古い端末や弱い回線でアプリを使う場合は、知っておく価値があります。

それぞれ、どのような場合に適していますか？

ネイティブが適している場合

アプリが端末を深く利用する場合（カメラ、センサー、Bluetooth、バックグラウンドのタスク）。
高い性能が求められる場合。たとえばリアルタイムの画像処理や音声処理、複雑なアニメーションです。
プラットフォームの最新機能をすぐに活用する必要がある場合。
一方のプラットフォーム向けのアプリだけが必要な場合、または2つのバージョンが大きく異なる場合。

クロスプラットフォームが適している場合

両プラットフォームで同じ機能が必要で、変更が両方に同時に反映されることが重要な場合。
アプリが主にフォーム、リスト、データ表示、通知で構成されている場合（ほとんどの業務アプリがこれに当たります）。
1つのチームが長期にわたってアプリを保守する場合。
企業がすでにフレームワークの言語を使っている場合。たとえばウェブでのReactの知識があればReact Native、.NETの経験があれば.NET MAUIが候補になります。

PWAまたはウェブアプリが適している場合

ユーザーがアプリストアでアプリを探すのではなく、リンクやウェブサイトから訪れる場合。
端末への深いアクセスが必要ない場合。
アプリがパソコンでもスマートフォンでも同じように動作する必要がある場合。
プラットフォームの機能よりも、ストアの審査を経ないすばやいアップデートのほうが重要な場合。

ここでも境界ははっきりしていません。たとえばKotlin Multiplatformでは、ビジネスロジックを共通にしながらUIはネイティブのままにでき、FlutterやReact Nativeでも、重要な部分をネイティブコードで書くことができます。当社のウェブサイトのゲームはウェブアプリとして動作しています。インストール不要でブラウザー上で動き、パソコンでもスマートフォンでも同じように使えます。ウェブという選択肢については、ウェブサイト制作とウェブアプリケーション開発のページでご説明しています。

バックエンドと管理画面

モバイルアプリが単独で完結することはまれです。ユーザーアカウント、共有データ、通知のいずれかがあれば、その裏側にサーバーが必要になります。アカウント、データ、権限はサーバー上にあり、通知もそこから送信されます。プッシュ通知は通常、バックエンドが専用のサービスを通じて送信します。たとえばFirebase Cloud Messagingはクロスプラットフォームのメッセージングソリューションで、信頼できるサーバー環境がメッセージを作成し、Apple、Android、ウェブの各アプリに送信します（Firebase: Cloud Messaging）。

管理画面はバックエンドの操作パネルです。ブラウザーからコンテンツを編集し、ユーザーと設定を管理できるため、日々の変更に開発者が不要になります。既存の企業システム（たとえばCRM、在庫管理システム、請求書発行ソフト）もここに連携させ、アプリが社内のほかの部分と同じデータで動作するようにします。そうしたシステムがまだない場合は、オーダーメイドのソフトウェアとして、それも構築します。ネイティブかクロスプラットフォームかの判断は、バックエンドには影響しません。同じサーバーが、ネイティブアプリにもFlutterで作ったアプリにもサービスを提供できます。

アプリストアでの公開：2026年10月時点で注意すべき点は何ですか？

アプリストアのルールは頻繁に変わるため、以下の内容には日付を付けています（2026年10月17日確認）。

App Store（Apple）

審査ガイドライン： App Store Review Guidelinesは、2026年10月16日に最後に更新されました。2.1項によれば、審査に出せる完成した完全なバージョンを提出する必要があります。アプリにログイン機能がある場合はデモアカウントを提供しなければならず、審査中もバックエンドが稼働している必要があります。5.1.1項によれば、すべてのアプリはプライバシーポリシーへのリンクを示す必要があり、アプリでアカウントを作成できる場合は、アカウントの削除もアプリ内で提供しなければなりません（Apple: App Store Review Guidelines）。
プライバシーに関する詳細情報： App Store Connectで、アプリのデータ取り扱いの方針を、組み込んだ外部のコード（たとえば分析用のSDK）の分も含めて申告する必要があります。これは新しいアプリの提出にもアップデートの提出にも必要です（Apple: App privacy details）。
開発ツールの要件： 2026年4月28日以降、App Store Connectにアップロードするアプリは、Xcode 26以降とiOS 26 SDKでビルドする必要があり、2026年9月9日以降、iOSアプリとiPadOSアプリはiOS 13以降をターゲットにする必要があります（Apple: Upcoming requirements）。
法人アカウント： 組織として登録するには、企業が法人格を持ち、D-U-N-S番号を取得している必要があります。また、登録者は企業を代表して法的な義務を負う権限を持っていなければなりません（Apple: Enrollment）。
EUにおけるトレーダー（事業者）ステータス： Appleは、開発者がEU法上のトレーダーに該当するかどうかを申告するよう求めています。トレーダーの連絡先は、EU域内ではアプリのプロダクトページに表示されます（Apple: Digital Services Act trader requirements）。

Google Play

ターゲットAPIレベル： 2026年8月31日以降、新しいアプリとアプリのアップデートは、スマートフォン向けにはAndroid 16（APIレベル36）以上をターゲットにする必要があります。既存のアプリは、新しいAndroidバージョンを搭載した端末で新規ユーザーが引き続き入手できるようにするには、Android 15（APIレベル35）以上をターゲットにする必要があります。Play Consoleで延長を申請した場合、期限は2026年11月1日です（Android Developers: Target API level）。
個人アカウントのテスト： 2023年11月13日より後に作成された個人のデベロッパーアカウントでは、製品版の公開前に、少なくとも14日間継続して参加しているテスターが12人以上いるクローズドテストを実施する必要があります（Play Console Help: testing requirements）。
組織アカウント： 組織のデベロッパーアカウントは、D-U-N-S番号がなければ作成できません（Play Console Help: creating an account）。
データセーフティフォーム： Google Playで公開するすべてのアプリについて、ユーザーデータを収集しないアプリであっても記入する必要があります（Play Console Help: Data safety）。
アカウントの削除： アプリ内でアカウントを作成できる場合は、アカウントと関連データの削除を、アプリ内とウェブのリンクの両方からリクエストできるようにする必要があります（Play Console Help: account deletion requirements）。

これらのルールは技術に関係なく適用されます。FlutterやReact Nativeで作ったアプリも、ネイティブアプリと同じターゲットAPIとSDKの要件を満たす必要があり、フレームワークのアップデートもこれに追随しなければなりません。開発者アカウントは発注者の企業のものにすることをお勧めします。そうすれば、アプリは御社の名前で公開され、ストアの掲載ページも御社のものとして残ります。

アクセシビリティ

どちらのプラットフォームにも、スクリーンリーダー（iOSではVoiceOver、AndroidではTalkBack）が標準で搭載されており、アプリがこれらの支援技術と連携するためのインターフェースが用意されています（React Native: Accessibility）。たとえばFlutterのドキュメントは、スクリーンリーダーがすべてのコントロールをわかりやすく説明できること、テキストと背景のコントラスト比を4.5:1以上にすること、タップできるすべての要素を48×48ピクセル以上にすることを推奨しています（Flutter: Accessibility）。Androidのドキュメントは、問題を見つけるために、Material Designのガイドライン、Accessibility Scannerツール、自動チェックを推奨しています（Android Developers: Accessibility）。

これは単なるグッドプラクティスではありません。指令（EU）2019/882により、加盟国は2025年6月28日から、消費者向けに提供されるEコマースサービス（モバイルアプリを通じて提供されるものを含む）にアクセシビリティ要件を適用しなければなりません（ハンガリーの規則はこの指令の国内法化に基づいています）。サービスを提供する零細企業は、適用除外としなければなりません（EUR-Lex：指令（EU）2019/882）。ECサイトに関する詳細は、ECサイト：レンタル型システムか、オーダーメイド開発か？の記事で取り上げています。

人工知能：端末上か、クラウドか？

モバイルアプリでは、AI機能を2つの場所で実行できます。スマートフォン本体の上か、バックエンドを通じたクラウド上の大規模言語モデルです。

端末上（Apple）： AppleのFoundation Modelsフレームワークは、iOS 26以降、Apple Intelligence向けに設計された、端末上およびPrivate Cloud Compute上で動作するモデルへのアクセスを提供します。テキスト生成、構造化出力、独自のツールの呼び出しにも使えますが、Apple Intelligenceに対応した端末でしか利用できません（Apple: Foundation Models）。
端末上（Android）： Gemini NanoはAndroidのシステムサービスであるAICoreの中で動作し、ML Kit GenAIのAPIを通じて、たとえば要約、文章の校正、書き換え、画像の説明に利用できます。Googleによれば、ネットワーク接続なしでも動作し、機密データは端末上にとどまりますが、モデルにはトークンの上限と端末のハードウェアによる制約があります（Android Developers: Gemini Nano）。
クラウド： OpenAI（ChatGPT）、Anthropic（Claude）、Google（Gemini）の大規模言語モデルは、より複雑なタスクに向いています。たとえば企業独自の資料をもとに回答するアシスタント、文書と画像の処理、要約です。AIサービスのアクセスキーは、スマートフォンではなくバックエンドに置きます。そのため、アプリから読み取られることはなく、利用状況はサーバー側で管理できます。

端末上で動作するモデルは、データ保護とオフラインでの動作の点で魅力的ですが、すべてのユーザーの端末で利用できるわけではないため、通常はクラウドによる代替手段（フォールバック）と組み合わせて設計することをお勧めします。モデルの組み込みについては、AI統合のページでご説明しています。

保守の手間は何によって決まりますか？

モバイルアプリは、引き渡した後も完成したわけではありません。アプリを取り巻く環境が絶えず変わるからです。保守作業を主に左右するのは、次の要素です：

OSとアプリストアの要件： Appleはアップロードに新しいXcodeとSDKのバージョンを、Google Playは新しいターゲットAPIレベルを求めます。上記の日付からわかるように、これらは定期的に引き上げられます。
アプリストアのガイドラインの変更： プライバシーに関する新しい申告、アカウント削除やテストに関するルール。
フレームワークのアップデート： クロスプラットフォームのアプリでは、Flutter、React Native、.NET MAUIのメジャーバージョンアップが、自社のコードにも、使用しているプラグインにも作業を生じさせることがあります。
外部のコンポーネント： 決済、地図、分析のSDK。これらにもそれぞれアップデートの要件があります。
バックエンドと連携： 接続している業務システムやAIサービスのインターフェースの変更。
コードベースの数： 2つのネイティブアプリでは、2か所で変更が必要になります。

よくある失敗

アプリの機能ではなく、チームの慣れによって技術が選ばれてしまいます。
画面のことだけを考え、バックエンドと管理画面が計画に入っていません。
ウェブサイトを単にアプリとして包んだだけで、ストアに却下されます。
開発者アカウントが開発会社の名義になっており、ストアの掲載ページを後から移管できません。
アカウントの削除、プライバシーに関する申告、デモアカウントを、提出の当日になって用意します。
引き渡し後のアップデートの責任者がおらず、ルールが変わった後、アプリが新規ユーザーから見えなくなります。

よくあるご質問

ネイティブとFlutter/React Native、どちらがよいですか？

アプリが端末を深く利用する場合（カメラ、センサー、バックグラウンド処理）や、高い性能が求められる場合は、ネイティブ開発のほうが確実な道です。両プラットフォームで同じ機能が必要なら、FlutterやReact Nativeで作った、共通のコードベースを持つアプリのほうが保守は簡単です。Kotlin Multiplatformを使えば、ビジネスロジックは共通にしてUIはネイティブにするという中間の道も選べます。初回のご相談で、具体的な機能をもとにご提案します。

ウェブアプリ（PWA）で足りるのはどのような場合ですか？

ユーザーがリンクやウェブサイトから訪れ、端末への深いアクセスが必要なく、パソコンでもスマートフォンでも同じように動作することが重要な場合です。PWAはホーム画面にインストールでき、iOSでもプッシュ通知を送れますが、アプリストアでの公開にはつながらず、利用できる端末の機能の範囲はブラウザーによって決まります。

バックエンドは必要ですか？

ほぼ必ず必要です。アプリにユーザーアカウント、共有データ、通知のいずれかがあれば、その裏側にサーバーが必要になります。例外は、端末内だけにデータを保存するアプリです。当社はバックエンドと管理画面も構築し、既存の企業システムと連携させます。

アプリストアへの登録は誰が行いますか？

公開の手続きは当社が行います。アプリストアの掲載ページ用の素材とプライバシーに関する申告を作成し、アプリを申請し、審査が終わるまでサポートします。開発者アカウントは御社のものにすることをお勧めします。組織アカウントには両ストアともD-U-N-S番号を求めるため、早めに取得しておくとよいでしょう。

保守の費用は何によって決まりますか？

保守するコードベースの数、OSとアプリストアの要件が変わる頻度、アプリが使用する外部のコンポーネントと連携の数、そして見込まれる追加開発の量によって決まります。開発の料金は機能規模から算出します。手法は料金の考え方のページでご説明しています。

当社がお手伝いできること

Mesterséges Intelligencia Központ Kft. は、iOS・Androidアプリを開発し、その裏側のバックエンドと管理画面を構築し、人工知能を組み込み、アプリストアでの公開まで一貫して対応します。ネイティブかクロスプラットフォームかの判断は、機能をもとに、お客様と一緒に行います。サービスの詳細はモバイルアプリのページでご説明しています。

開発の機能規模はCOSMICファンクションポイント（ISO/IEC 19761）で測定し、そこからお見積もりとスケジュールを作成します。初回のご相談は無料です。ご要望に応じて秘密保持契約（NDA）を締結します。引き渡し後の運用・保守もお引き受けします。ソースコードと利用権の扱いは、契約で定めます。アイデアを数行でお書きのうえ、ご連絡ください。