「Flutter とネイティブ、どっちで作るべきですか？」— モバイル開発の相談で、最もよく聞かれる質問です。
個人開発と受託・企業案件を合わせて、これまでに 11 本のモバイルアプリ をリリースしてきました。Kotlin・Swift によるネイティブ実装が大半、Flutter は 露出帳 の 1 本だけ。この比率自体が、私の判断軸の現実を反映しています。
この記事では、12 年のモバイル開発経験と 11 本の実プロダクトから導いた、Flutter とネイティブの具体的な使い分け基準をまとめます。「どちらが優れているか」ではなく、「どういう要件のときにどちらを選ぶか」の判断軸を、実例とともに公開します。
「Flutter vs ネイティブ」の議論は、たいてい的外れ
結論を先に言うと、「どちらが優れているか」という比較は、ほぼ意味がないと考えています。両方とも 2026 年現在、十分に成熟した技術です。Flutter は安定し、Native の開発体験も Compose / SwiftUI で劇的に良くなりました。
問題は、議論の前提が間違っていることです。本当に問うべきは：
- そのアプリが、何を中核に持っているか
- どのプラットフォームに、どこまで届かせたいか
- 誰が、何ヶ月で、いくらの予算で作るのか
これらが決まれば、Flutter と Native のどちらを選ぶかは、ほぼ自動的に決まります。以下、私が実際に使っている判断軸です。
ネイティブを選ぶべき 3 つの判断軸
1. オーディオ・DSP・低レベル処理が中核にある
これは即決でネイティブ。PocketTune は Game Boy DMG-01 互換のチップチューン音源エンジンを内蔵していて、4 チャンネルの矩形波・ノイズチャンネルを正確にエミュレートする必要がありました。
Flutter のオーディオプラグイン（just_audio など）は再生機能としては優秀ですが、サンプル単位での生成・低レイテンシーでのバッファ操作はサポート外です。Android なら AudioTrack、iOS なら AVAudioEngine でしか実現できない領域があります。
この種の要件で「Flutter で頑張って Platform Channel 経由でネイティブを呼ぶ」という選択肢もあり得ますが、それなら最初からネイティブで書く方が圧倒的に楽です。両プラットフォームで実質ネイティブのコードを書きつつ、間に Flutter という余計なレイヤーを挟むだけになります。
判断基準：オーディオ DSP、リアルタイム音声処理、画像処理、Bluetooth プロファイル制御、低遅延センサー処理 — これらの要素がアプリの「価値の中核」にあるなら、ネイティブ一択です。
2. プラットフォーム固有 API への深い依存
音声文字起こし・翻訳アプリ をエンタープライズ向けに開発したとき、要件には MDM（Mobile Device Management）経由の組織別配布、Managed Configurations による設定注入、iOS の Push Notification との連携、Android の WorkManager によるバックグラウンド同期、などが含まれていました。
これらは Flutter プラグインが存在する場合もありますが、カバー範囲がプラットフォーム最新仕様より遅れるのが現実です。エンタープライズ案件では、AppConfig コミュニティの仕様や iOS の最新 MDM API への即時対応が要求されることがあり、Flutter プラグインを待っていられません。
同じことが、HealthKit、HomeKit、CarPlay、Vision Pro 専用 API、Apple Pencil の高度な制御、Android の各種 Provider 連携、などにも言えます。プラットフォーム最新機能を「リリース直後から使いたい」要件があるなら、ネイティブが安全です。
3. ユーザーが「そのプラットフォームらしさ」に敏感な領域
MediWords は医療従事者向けの英単語学習アプリで、ユーザーは多忙な業務の合間にスキマ時間で使います。「迷わずサクッと使える」が至上命題でした。
このとき重要なのが、iOS ユーザーには iOS らしい操作感を、Android ユーザーには Android らしい操作感を提供すること。スワイプの挙動、戻るボタンの位置、リストのスクロール慣性、フォントの間隔 — これらはユーザーが意識せずに「当然そう動く」と思っている要素です。Flutter で Material と Cupertino を切り替えても、本当に「らしさ」を再現するのは難しい（特に細部）。
逆に言えば、ユーザーが UI の細部に敏感でない領域（電卓やツール、業務用フォームなど）では、この判断軸は弱くなります。
Flutter を選ぶべき 3 つの判断軸
1. Apple エコシステム全体（iPhone + iPad + Mac + visionOS）+ Android の同時展開
これが Flutter の最大の強み、と私は考えています。露出帳 を Flutter で実装した最大の理由がこれです。
露出帳は、フィルム写真家向けの露出計算アプリです。ターゲットユーザーは、撮影現場では iPhone を使い、自宅で現像を計算するときは Mac を使い、暗室で見るときは iPad を使う — そういう人たちです。「同じツールが、ユーザーの持っているすべてのデバイスで動く」ことが、製品価値の根幹でした。
Flutter なら、単一コードベースで iPhone・iPad・Mac (Apple Silicon)・visionOS・Android の 5 プラットフォームに展開できます。Mac Catalyst や Designed for iPad ではなく、本当の意味でネイティブとして各プラットフォームで動く。これをネイティブで実現するには、Swift で iOS / iPad / macOS / visionOS の各バリアントを書き、さらに Android 版を Kotlin で書く必要があります。個人開発の規模では現実的ではありません。
SwiftUI で iOS / iPad / Mac / visionOS を「ほぼ単一コード」で書けるという反論はあり得ますが、Android を別途 Kotlin で書く必要がある時点で、Flutter の単一コードベースの優位は変わりません。
2. UI とビジネスロジックがコア、プラットフォーム依存機能が薄い
計算系・ツール系・電卓系・スコア管理系・タスク管理系 — アプリの本質が「データを処理して、結果を見せる」ことにあり、プラットフォーム固有 API への依存が少ないジャンルです。露出帳も典型的にこのカテゴリでした（Sunny 16・相反則不軌・Push/Pull など、すべて純粋な計算ロジック）。
このパターンでは、Flutter の生産性が最大限活きます。1 つの計算エンジンを書けば、5 プラットフォームで動く。ネイティブで同じものを作ると、計算ロジックを 2 回（Kotlin と Swift で）書くことになります。
3. 個人・小規模チームで、複数プラットフォーム同時リリースが必要
これは技術選定というより、リソース制約からの逆算です。
個人開発で iOS と Android の両方を出すには、Kotlin と Swift の両方で同じものを書き、両方を維持しなければなりません。1 人で 2 つのコードベースを保守するのは、長期的に確実に破綻します（経験談）。
受託案件でも、「予算が限られていて iOS と Android 両方欲しい」という要望は頻出します。このとき Flutter は「2 倍のリーチを 1.3 倍くらいの開発工数で実現する」現実的な選択肢になります。
注意点：「Flutter なら工数が半分」というのは誇張です。実際は 1.2〜1.5 倍程度の工数で 2 プラットフォーム分、というのが私の感覚値。プラットフォーム固有の調整・テスト・ストア対応で、思っているより時間を使います。
実例：11 本のアプリの選定理由（一覧）
私が実際にリリースしてきたアプリと、その選定理由をまとめます：
| アプリ | スタック | 選定理由 |
|---|---|---|
| PocketTune | Kotlin + Swift | Game Boy DMG-01 互換音源 = オーディオ DSP がコア |
| MediWords | Kotlin + Swift | プラットフォームらしさ重視、オフライン優先設計 |
| 瞬トレ | Kotlin | 個人開発、Android 単独リリース |
| Dottie | Kotlin (Compose) | 個人開発、Android 単独、Canvas 描画性能優先 |
| Vietie | Kotlin | 個人開発、Android 単独 |
| ZenTimer | Kotlin | 個人開発、Android 単独、シンプル UI |
| TimeQuest | Kotlin | 個人開発、Android 単独 |
| Camelia（レトロカメラ） | Kotlin | カメラ API への深い依存 |
| 音声文字起こし・翻訳 | Kotlin + Swift | エンタープライズ要件、MDM 対応、リアルタイム音声 |
| 名刺スキャナ | Kotlin | ML Kit OCR、Google Sheets 連携、Android 業務用途 |
| 露出帳 | Flutter | 5 プラットフォーム同時展開、計算ロジックがコア |
見ての通り、私の場合は ネイティブが大多数、Flutter は「Apple エコシステム + Android」を全部取りたいときだけ、という配分になっています。これは「Flutter を避けている」のではなく、「Flutter が最適解だった案件が 1 件しかなかった」というのが正確な表現です。
私が使っている 5 つの質問フィルター
新規アプリの技術選定で、私は以下の 5 つの質問を順に投げかけます。最初の YES が出た時点で答えが決まります。
- オーディオ / DSP / 低レベル処理が中核にあるか？ → YES なら ネイティブ一択
- 最新のプラットフォーム固有 API への即時対応が必要か？（MDM、HealthKit、最新 Vision Pro API など） → YES なら ネイティブ
- Apple エコシステム全体（iPhone + iPad + Mac + visionOS）+ Android に同時展開したいか？ → YES なら Flutter が最有力
- 個人 or 小規模で、iOS + Android 両方が必須か？ → YES なら Flutter を検討（ただし最新 API 不要なことを確認）
- 上記すべて NO で、リソースに余裕があるか？ → ネイティブを推奨（長期的な変更容易性が高い）
この順序で考えると、迷いが消えます。シニアエンジニアの技術選定は、たいてい「迷わない理由」を言語化することに尽きると思っています。
よくある誤解 3 つ
誤解 1：「Flutter なら開発工数が半分になる」
これは営業トークで、現場の感覚とは違います。実際は 2 プラットフォーム分の工数の 1.2〜1.5 倍程度。「半分」というのはコード量の話で、開発全体（設計・テスト・ストア対応・プラットフォーム固有 QA）はそんなに減りません。
とはいえ、「1 プラットフォーム分の工数で 2 プラットフォーム展開できる」ようなネイティブ実装は存在しないので、相対的には Flutter は十分に効率的です。
誤解 2：「ネイティブは保守が大変」
Kotlin Multiplatform Mobile（KMP）を使えばロジック部分の共通化はできますし、ネイティブの保守コストは「OS バージョンアップごとの追随」がメインです。これは Flutter でも程度の差こそあれ同じ問題があります（Flutter 自体のメジャーアップグレード、プラグインの互換性問題、など）。
「ネイティブの保守は大変」というのは、コード量を見ての印象論。正しい保守設計をすれば、ネイティブの方が長期的には安定するケースも多いです（依存関係が少ないから）。
誤解 3：「Flutter は将来性が不安」
Google が開発を続けている限り（少なくとも 2026 年現在、続いています）、十分に成熟したフレームワークです。Adobe・トヨタ・BMW など大手も採用しています。
ただし、Google 製品の歴史（Inbox、Google+、Hangouts など）を考えると、長期的なリスクはゼロではありません。これは Flutter 固有の話というより、Google 全般に言える話。とはいえ、Flutter は OSS なので、Google が手を引いてもコミュニティで維持される可能性は高いと見ています。
まとめ：3 行で判断
- オーディオ DSP・プラットフォーム最新 API が要るなら ネイティブ
- Apple エコ全体 + Android を同時展開、計算/UI 中心なら Flutter
- 上記どちらでもなく、リソースに余裕があれば ネイティブ（保守容易性で勝つ）
「どちらが優れているか」という議論には、もう疲れたんじゃないかと思います。それぞれの強みを理解し、要件から逆算して選ぶ — これが 12 年と 11 本のアプリから導いた、私の結論です。
各アプリの技術選定の詳細は、ケーススタディで個別に解説しています。PocketTune（ネイティブ・オーディオ DSP）、露出帳（Flutter・5 プラットフォーム展開）、音声文字起こし（エンタープライズ・ネイティブ） などをご覧ください。
個別案件での技術選定のご相談は、お問い合わせ からどうぞ。要件をヒアリングして、最適な技術構成を提案します。
