モバイルアプリ開発の技術選定：Xamarin終了後の.NET MAUIとAndroidネイティブ（Kotlin/Jetpack Compose）の選び方

モバイルアプリ開発では「どのテンプレート／技術を選ぶか」で、開発スピードだけでなく、将来のOS更新やライブラリ更新に耐えられるかまで決まります。Xamarin / .NET MAUI / Androidネイティブの違いを、実務の保守コストとリスクの観点から整理し、要件別に迷いを減らす判断軸をまとめます。

結論：新規開発で迷ったら「Xamarinは除外」から始める

最初に押さえておきたいのは、新規開発でXamarinを選ぶのは基本的に非推奨だという点です。Xamarinはサポートが終了しており、今後のOS/SDK更新に追随し続ける前提で採用すると、途中から“更新できない”“ストアに出せない”といった形で詰むリスクが高まります。

一方で、iOSとAndroidの両方が必要で、同一コードベースで進めたいなら、Microsoft系の現行ルートは.NET MAUIです。

そして、Androidだけに集中するなら、通常はKotlin + Jetpack（例：Jetpack Compose）が王道です。GoogleはAndroid開発をKotlin-firstで進める方針を明示し、UIもComposeを推奨しています。

テンプレート選びが難しい理由：作るより「更新し続ける」方が難しい

モバイルは、リリースして終わりではありません。OSの年次メジャーアップデート、ストア審査ルールの変更、セキュリティ要件の強化、端末の多様化が継続的に発生します。つまりテンプレート選びは、UIの書きやすさや学習コストだけでなく、継続アップデートに耐える開発体制まで含めて考える必要があります。

実務で効いてくるのは次の3点です。

• 追随の速さ：新しいOS/SDKにどれだけ早く対応できるか（フレームワーク／IDE／ライブラリの更新速度）
• 詰まりポイントの少なさ：ビルドや署名、ストア提出で“謎エラー”に時間を溶かさないか
• 保守の見通し：2〜3年後に人が入れ替わっても運用できるか（採用しやすさ、情報量、コミュニティ）

選択肢の整理：Xamarin / .NET MAUI / Androidネイティブ

Xamarin：既存資産の維持はできるが、新規採用はリスクが高い

Xamarinは、かつてC#でiOS/Androidを同時に開発できる有力選択肢でした。しかし現在はサポートが終了しています。サポート終了後も既存アプリが即座に動かなくなるわけではありませんが、次のような問題が現実的に起こります。

• 新しいAndroid APIレベルやXcode/iOS SDKに追随できず、ストア公開・更新が難しくなる
• OS更新で不具合が出ても、公式の修正やセキュリティ更新が期待できない
• 依存ライブラリの更新が止まり、ビルドが通らない／互換性が崩れる

「既存Xamarinをどう延命するか」は別テーマとして重要ですが、新規で採用して将来も守るという意味では合理的に選びにくい状況です。

.NET MAUI：C#でiOS/Androidをまとめる“現行のMicrosoftルート”

.NET MAUIは、Xamarin.Formsの後継として位置づけられ、Android/iOS/macOS/WindowsをターゲットにできるクロスプラットフォームUIフレームワークです。

MAUIで押さえるべき現実は2つあります。

• 対応OSの最低要件がある（プロジェクトのMAUIバージョンにより変わる）
• 最新版追随が前提（“ずっと同じ環境で安定”という発想だと辛くなる）

対応OSの最低要件はMicrosoft Learnのドキュメントで明示されており、さらに「MAUI Blazor」の場合はWebView要件の関係で最低要件が上がります。

また、MAUIはサポートポリシー上、次のメジャーが出てから一定期間で前バージョンのサポートが切れる形です。つまり、最新のサービスレベルに追随する運用が前提になります。

MAUIが特に効くのは、次のようなケースです。

• .NET/C#人材や既存資産がある（サーバー・デスクトップ・業務システム含む）
• iOS/Android両対応が必須で、まずは機能を早く揃えたい
• 業務アプリ／社内アプリなど、フォーム中心・データ入力中心のUIが多い
• ネイティブAPIにアクセスしつつ、共通化できる部分（認証、通信、データ層）を大きくしたい

逆に、MAUIでつまずきやすいのはこんな領域です。

• “画面の作り込み”が競争力（アニメーション、ジェスチャー、細かな挙動までiOS/Android別最適が必要）
• 最新OS機能を即採用したい（新APIの追随待ちが発生する可能性）
• プラグイン依存が多い（更新停止で全体が止まる）

なお、Xamarin.Android / Xamarin.iOS といった「Xamarinの各SDK相当」は、.NET 6以降の“.NET for Android / iOS”として.NETに統合されています。Xamarinという名前は消えていきますが、C#でモバイルを作るルート自体が消えるわけではありません。

Androidネイティブ：Kotlin + Jetpack（Compose）が王道

Android専用に振り切れるなら、ネイティブ開発の強みが最大化します。ここでいう「ネイティブ」はKotlin/JavaでAndroid SDKを直接使うことが中心で、必要に応じてNDKでC/C++を併用する形が一般的です（“ネイティブ＝C++だけ”ではありません）。

GoogleはAndroid開発をKotlin-firstで進め、これから始めるならKotlin推奨と明記しています。

UIはJetpack Composeが「推奨されるモダンなツールキット」として公式に位置づけられています。

Androidネイティブの代表的なメリットは次の通りです。

• 最新APIへの追随が最速（新しい機能・権限・挙動変更に最短距離で対応できる）
• 情報量と人材が豊富（公式ドキュメント、事例、サンプル、採用市場）
• パフォーマンスとUI自由度（起動、スクロール、アニメーション、入力体験の詰めがしやすい）

一方のデメリットは、「iOSも必要になった瞬間にコードベースが増える」ことです。将来的にiOS版が必要になる可能性があるなら、早い段階で“二重開発の覚悟”を持つか、最初からクロスプラットフォームを選ぶかを決めておくとブレません。

比較表：実務目線で見るメリット・デメリット

観点	.NET MAUI	Androidネイティブ（Kotlin + Jetpack）	Xamarin
対象	iOS/Android/Windows/macOS（プロジェクト次第）	Android中心（必要なら別途iOS）	既存維持向け
新規採用の推奨度	高い（Microsoftの現行路線）	高い（Androidの王道）	低い（サポート終了）
チーム適性	C#/.NET経験者が多いほど有利	Kotlin/Android経験者が多いほど有利	既存Xamarinチーム以外は非推奨
UI/UXの作り込み	可能だが、深い最適化はプラットフォーム別対応が増えやすい	最もやりやすい（Compose + ネイティブAPI）	将来の追随が難しい
最新OS/SDK追随	.NET/MAUIのリリースに依存（追随は継続）	最速で追随しやすい	今後の追随が期待できない
保守・アップデート	最新版追随の運用が必須（年次で更新が発生しやすい）	Androidの流れに沿って更新しやすい	更新できないリスクが高い
採用・引き継ぎ	地域差あり（.NET人材の厚み次第）	比較的強い	難化傾向

「テンプレート」を具体的に選ぶ：スタート地点で迷わない

質問で迷いがちな「テンプレート」は、単に初期フォルダ構成の話ではありません。選んだテンプレートが、UI記述方法、テストのしやすさ、ビルド構成、依存関係の持ち方を決めていきます。実務では、次の“出発点”を選ぶと後がラクです。

目的	おすすめテンプレート/構成	理由
MAUIで一般的なアプリ（ネイティブUI）	.NET MAUI App（XAMLまたはC# UI）	標準的。画面や端末機能の扱いが素直で、情報も多い。
Web資産を活かして早く作りたい	.NET MAUI Blazor App	Razor/コンポーネント資産が使える。ただしWebView前提で、最低要件も上がる点に注意。
Android専用で最新UI	Android Studio：Empty Activity（Jetpack Compose）	Androidの王道ルート。新しいJetpackの恩恵を受けやすい。

.NET MAUIを選んだ後の分岐：XAMLか、Blazorか

.NET MAUIには大きく2系統のUIアプローチがあります。迷ったら「チームの強み」と「アプリのUI特性」で決めるのが現実的です。

XAML（またはC# UI）を選ぶと良いケース

• ネイティブUIに寄せたい（iOS/Androidの“らしさ”を作り込みたい）
• WebView依存を減らし、端末機能とUIの密結合が多い
• パフォーマンスや入力体験の詰めを重視したい

MAUI Blazorを選ぶと良いケース

• 既存のWebチーム（Razor/コンポーネント）が強い
• UIが業務画面寄りで、WebViewでも成立する
• “まず動くものを早く”というゴールが明確（社内PoCやMVP）

ただしMAUI BlazorはWebViewが絡むため、サポートプラットフォームの最低要件が上がる点、WebView固有の挙動差（戻る、キーボード、フォーカス、通信制御など）が出る点は先に理解しておくと安全です。

選定のチェックリスト：要件を質問に落とす

「何が正解か」を一発で決めるより、質問に分解して消去法＋重み付けをした方が失敗しにくいです。次の表を埋めるだけでも、判断がかなりクリアになります。

質問	YESなら強い選択肢	補足（実務の注意点）
iOSとAndroidを同時に出す必要がある？	.NET MAUI	iOSはビルド/署名にMacが必要。早めにCI環境も含めて準備する。
社内にC#/.NETの資産・人材が多い？	.NET MAUI	API連携や共通ロジックを厚くできる。逆にUI作り込みは要検証。
Androidだけでよい／まずAndroidで市場検証したい？	Androidネイティブ	将来iOS追加の可能性があるなら、共通化できる領域（仕様・API）を先に固める。
UI/体験そのものがプロダクト価値（アニメ・ジェスチャー重視）？	Androidネイティブ（またはプラットフォーム別最適）	クロスプラットフォームは“共通化”と引き換えに、最適化コストが別に出る。
端末機能を深く使う（BLE/位置情報/バックグラウンド処理など）？	Androidネイティブ（Android専用なら） / MAUI（両対応なら要検証）	プラグイン依存が増えるほど更新停止リスクが上がる。最重要機能は自前実装の余地を残す。
リリース頻度を高く保てる（継続的に更新できる）？	どちらでもOK	できない場合は“選択”より“体制”がボトルネックになり、結局どれでも辛い。

意思決定を見える化する：重み付けスコアリング（例）

チーム内の合意形成で強いのが、スコアリングです。全員が同じ言葉で話せないときほど、「重要度（重み）×評価」で数字にしてしまうと議論が進みます。

評価軸	重み（例）	.NET MAUI	Androidネイティブ
iOS/Android同時リリース	5	5	1
UI/UXの作り込み	4	3	5
既存資産の活用（C#/.NET）	4	5	2
採用・引き継ぎのしやすさ	3	3	4
最新OS/SDK追随の安心感	4	4	5
運用の再現性（CI/ビルドの安定）	3	3	4

この表は“正解”ではなく、自分たちの価値観を表に出す装置です。重みが高い項目ほど、後で「やっぱりこうすれば良かった」を減らせます。

よくあるパターン別のおすすめ

社内向けの業務アプリ（入力・一覧・承認・オフライン対応）

この領域は、機能の中心が「データ入力」「一覧」「ワークフロー」「権限」になりやすく、UIの最先端表現よりも安定運用と開発スピードが価値になります。社内に.NET資産があるなら、MAUIはかなり相性が良いです。特に、認証、API、既存のC#ライブラリ活用が効いてきます。

Android専用のB2Cアプリ（UXの作り込みが差別化要因）

Androidだけに集中できるなら、ネイティブが強い場面が多いです。ComposeはUIを宣言的に組めるため、画面構成の変更が頻繁でも追随しやすく、Androidの最新ガイドラインや新しいコンポーネントにも乗りやすいです。

「起動が遅い」「スクロールが引っかかる」「入力が重い」など、ユーザー体験の細部はストア評価に直結します。こうした“最後の1割”を詰めるなら、最短距離はネイティブです。

将来的にiOSも視野にあるが、まずはAndroidで検証したい

この場合は、技術よりも設計の分割がカギです。Androidネイティブで始めるとしても、次のように“二重開発になっても痛くない”構造を作っておくと、後で選択肢が広がります。

• 仕様・画面遷移・API設計を先に固め、プラットフォーム差分を最小化する
• ビジネスロジックをUIから切り離す（UseCase層、Domain層の分離）
• APIクライアント／データ永続化／ログなど、後で共通化しやすい領域を意識する

長期運用のコツ：3〜6か月ごとの更新を“前提化”する

モバイル運用でつらいのは、「しばらく放置した後にまとめて上げようとして爆発する」パターンです。依存関係が複雑なほど、更新をサボったツケは指数的に増えます。そこでおすすめは、小さく頻繁に追随する運用です。

運用タスク	おすすめ頻度	狙い
依存ライブラリ/NuGet/Gradleの更新チェック	毎月〜隔月	更新差分を小さくし、ビルド崩壊を局所化する
OSベータ／新APIレベルの事前検証	四半期ごと	年次OS更新での“急死”を避ける
ストア審査・ポリシー変更の確認	四半期ごと	提出時に弾かれてから慌てない
実機回帰テスト（主要端末/主要OS）	リリースごと	エミュレータだけでは拾えない不具合を早期発見
ビルド環境（JDK/Xcode/SDK）の更新	半年ごと目安	CIを含めた“再現性”を保つ

更新の頻度はプロダクト規模で変わりますが、ポイントは「更新を特別イベントにしない」ことです。小さく更新できる仕組み（自動テスト、CI、リリース手順の標準化）があるだけで、技術選定の失敗確率は大きく下がります。

サードパーティライブラリの地雷を避ける

クロスプラットフォームでもネイティブでも、モバイル開発では依存ライブラリの寿命がプロジェクト寿命を左右します。特に「端末機能系（カメラ、通知、BLE、課金など）」はOS側の変更を受けやすく、更新が止まると一気に詰みます。

採用前に最低限チェックしたい項目は次の通りです。

• 最終リリース日と更新頻度（直近6〜12か月で動いているか）
• Issue/PRの反応速度（放置されていないか）
• 対応しているOS/SDKの範囲（新しいAPIレベルに追随しているか）
• 代替手段の有無（公式APIで置き換え可能か、他ライブラリがあるか）
• “使わないと成立しない”依存になっていないか（コア機能ほど依存を薄く）

実務のコツとしては、依存を“直接使わない”ことです。例えば通知やストレージなどをアプリ内でインターフェース化し、ライブラリはその実装として差し替え可能にしておく。こうしておくと、突然ライブラリが止まっても、置き換えの影響範囲を限定できます。

先に検証すべき“詰まりポイント”チェック

技術選定で失敗する典型は、コア機能が“フレームワークの得意領域”とズレているのに、最後まで気づかないことです。次の要件がある場合は、採用前に小さくプロトタイプを作り、実機で検証するのがおすすめです。

• プッシュ通知（特にバックグラウンドでの扱い）
• ディープリンク／アプリ間連携
• バックグラウンド位置情報、BLE、センサー
• カメラ、画像編集、ファイル共有
• 課金（サブスク）
• WebViewの高度な制御（リクエスト監視、認証連携）

.NET MAUIは進化を続けており、最近の.NETではMAUIやモバイル向けの改善も継続しています（例：WebViewやMediaPickerなどの改善、Android APIレベル対応など）。ただし「自分の要件が、その改善点に含まれるか」は別問題なので、プロトタイプで現物確認するのが最短です。

Xamarinからの移行戦略：最短でリスクを下げる手順

既存がXamarinの場合、現実的には「いつまでに何を守る必要があるか」で戦略が分かれます。サポート終了の事実を前提に、移行をプロジェクトとして扱うのが安全です。

まずは棚卸し（ここを飛ばすと高確率で炎上）

• 対象：Xamarin.Formsなのか、Xamarin.Android/iOSなのか
• 依存：使っているプラグイン／ライブラリの一覧と代替候補
• OS要件：最低OS、ターゲットAPI、利用している端末機能
• リリース要件：ストア更新の期限、顧客契約、端末入れ替え時期

移行ルートの考え方

ルート	向いている状況	注意点
段階移行（共通ロジック→UI）	機能追加も並行したい／止められない	一時的に複雑になる。移行範囲の境界を明確にする。
ビッグバン移行（まとめて置き換え）	画面数が少ない／短期で終えたい	リリース直前に問題が出ると逃げ場がない。バッファ必須。
作り直し（設計刷新）	負債が大きい／UIも変えたい	“移行”ではなく新規開発。要件凍結とスコープ管理が重要。

移行先がMAUIの場合、MAUI自体も.NETのリリースに合わせて更新されます。プロジェクト開始時点での推奨バージョン（LTSなど）を採用し、更新計画までセットにしておくと後でラクになります。MAUIのサポートポリシー上、最新版追随は現実的な前提です。

「結局どれが実務的におすすめ？」への答え方

最終的なおすすめは、要件を次の2つに圧縮すると決めやすいです。

• 両OS必須か？（YESならMAUIが有力、NOならネイティブ検討価値が高い）
• 運用を回す体制があるか？（YESなら選択肢が増える、NOなら何を選んでも苦しくなる）

具体的な目安としては、次のように考えるとブレにくいです。

• iOS/Android両対応＋.NET資産/人材がある → .NET MAUI
• Android専用で最新のAndroid体験を優先 → Kotlin + Jetpack（Compose）
• 既存Xamarinを抱えている → “延命”ではなく移行計画を立て、MAUIまたはネイティブへ段階的に整理

最後にもう一度強調すると、モバイルは「作る」より「更新し続ける」方が難しい領域です。テンプレート選びに迷ったら、フレームワークの新しさよりも、あなたのチームが3〜6か月ごとに更新を回せるか、そして依存ライブラリの寿命を管理できるかを基準にすると、現場での後悔が減ります。