Flutter / React Native / Kotlin Multiplatform（Compose Multiplatform）をどう選び、どう移行するか
はじめに
iOS / Android アプリ開発における技術選定は、ここ数年で複雑になりました。
ネイティブ開発が今も主流である一方、Flutter や React Native は十分に成熟し、さらに Kotlin Multiplatform と Compose Multiplatform が現実的な選択肢として見える位置まで来ています。
本記事では、
どの技術が優れているかを決めることではなく、
- 企業開発においてどのように選定すべきか
- 既存のネイティブ iOS / Android アプリにどう適応していくか
- 途中導入や撤退を含めた現実的な戦略は何か
という観点で整理します。
また、AI を前提とした開発が一般化しつつある今、
ドキュメントの構造や一次情報の扱いやすさも含めて考えます。
2025年時点のモバイル開発の全体像
現在のモバイルアプリ開発は、大きく次の4つに分けられます。
- ネイティブ開発（Swift / Kotlin）
- React Native
- Flutter
- Kotlin Multiplatform（以下 KMP） / Compose Multiplatform（以下 CMP）
まず前提として、ネイティブ開発は今も王道です。
- OS の最新機能への追随
- パフォーマンス
- セキュリティ要件
- その OS らしい UX
これらが重要なプロダクトでは、今後もネイティブが選ばれ続けます。
一方で、iOS / Android の二重実装や保守コストの増大が問題になり、
マルチプラットフォーム技術が検討される場面が増えています。
マルチプラットフォームは目的で選ぶ
マルチプラットフォームの議論が噛み合わない理由は、
どれが流行っているか、どれが最強かという話になりがちだからです。
企業開発で本当に重要なのは次のような問いです。
- 何を最適化したいのか
- どこまで既存資産を活かしたいのか
- 途中でやめられるか
- 長期運用に耐えるか
この視点で見ると、それぞれの技術の向き不向きがはっきりします。
Flutter 新規アプリを素早く作るなら非常に強い
新規アプリを短期間で作りたい場合、Flutter は非常に合理的です。
- UI とロジックを高い割合で共有できる
- Hot Reload による開発スピード
- 少人数でも進めやすい
- MVP や PoC に向いている
まず動くものを作り、市場や社内で検証したい場合には強力な選択肢です。
一方で、企業の中核プロダクトや長期運用を考えると、
後述するような懸念も現実的に出てきます。
React Native Web 資産を活かしたい場合の現実解
React Native は Web（React）資産を活かせる点が最大の強みです。
- Web エンジニアがモバイル開発に参加しやすい
- 既存の React コードや知見を流用できる
- 大規模サービスでの実績が多い
組織として Web 技術が主軸であれば、今も十分に合理的な選択肢です。
Flutter や React Native は途中導入できるのか
結論として、途中導入は可能です。
ただし、KMP と比べるとハードルは高くなりがちです。
Flutter や React Native は本質的に UI とロジックが一体のフレームワークです。
そのため途中導入は、ほぼ必ず UI から入る形になります。
既存ネイティブアプリに一部画面だけ導入すると、
- ナビゲーションの責務が分断される
- ライフサイクル管理が複雑になる
- ビルドやデバッグ経路が増える
- ネイティブ画面とクロスプラットフォーム画面が混在する
技術的には成立しても、運用コストが上がりやすい構造になります。
Flutter の現実的な懸念
Flutter を実務で使っていると、次のような場面に遭遇することがあります。
- 利用しているライブラリが更新されなくなる
- OS や Flutter 本体の更新に追従しない
- Fork するか、自前実装するかの判断を迫られる
Flutter では、ライブラリが UI とロジックの両方に絡むことが多く、
影響範囲が大きくなりがちです。
その結果、
やめたいと思ったときに UI とロジックを同時に書き直す必要が出やすく、
撤退戦略を描きにくいという弱点があります。
Kotlin Multiplatform が現実路線と感じる理由
KMP の最大の特徴は、ネイティブを捨てないことです。
- ビジネスロジックを Kotlin で共有する
- UI は SwiftUI / UIKit / Jetpack Compose などネイティブのまま
この構造により、
- 既存アプリに段階導入できる
- UX を壊さずに始められる
- 途中でやめやすい
という性質を持ちます。
企業開発では、この安心感が非常に重要です。
Compose Multiplatform が iOS 安定版になった意味
CMP が iOS 向けにも安定版になり、UI 共有も現実的になりました。
ただし重要なのは、
UI 共有は必須ではないという点です。
- UI はネイティブのまま
- 合う画面だけ CMP を使う
- 問題があれば戻す
この選択の自由度が、KMP/CMP を現実的にしています。
AI 時代との相性
KMP のもう一つの強みは、公式ドキュメントの構造です。
- ドキュメントが非常に充実している
- GitHub 上で管理されている
- バージョン差分が追いやすい
これは AI を使った開発と相性が良いです。
AI に古いブログや断片的な情報を参照させるのではなく、
一次情報をそのまま渡しやすい構造になっています。
iOS エンジニアが Kotlin / Compose を学べる価値
Kotlin は Swift と思想的に近く、
- null safety
- data class
- 非同期処理
など、多くの点で親和性があります。
Compose も SwiftUI と同じ宣言的 UI の思想を持ち、
iOS エンジニアにとって学習コストは比較的低いです。
これは、
iOS エンジニアが別分野に転向するのではなく、
同じ思想を横展開できるという意味を持ちます。
結果として、
- iOS / Android 間の認識差が減る
- ドメインや設計の共通理解が進む
- チームとして強くなる
という効果が期待できます。
企業が考えるべき選定軸
新規アプリか既存アプリか
新規アプリでスピード重視なら Flutter は有力です。
既存ネイティブアプリがある場合、全面置き換えはリスクが高く、
段階導入できる KMP が現実的になります。
UI をどこまで共通化したいか
UI まで共通化したいなら Flutter / React Native / CMP。
UX を優先し UI はネイティブに任せたいなら KMP が向いています。
撤退可能性
企業開発では、いざというときに戻れるかが重要です。
- Flutter / React Native は撤退時の影響が大きくなりがち
- KMP は UI を維持したまま縮退しやすい
KMP / CMP への移行戦略
フェーズ1 ロジックのみ共通化
まず UI に触れず、
- API 通信
- Repository
- ドメインモデル
- バリデーション
- 状態管理
を KMP で共通化します。
UX に影響がなく、リスクが低い段階です。
フェーズ2 新機能から適用
既存機能を無理に置き換えず、
新しい画面やフローから共通化します。
フェーズ3 合う画面だけ CMP
設定画面や管理画面など、
UX 要求が比較的低い画面から CMP を試します。
CMP で iOS らしさを保つ考え方
CMP で完全に SwiftUI を再現する必要はありません。
目指すのは違和感を作らないことです。
- Material をそのまま使わない
- iOS 向けテーマを定義する
- ナビゲーションやジェスチャーは SwiftUI に任せる
- CMP は部品として使う
SwiftUI を外枠、CMP を中身にする構成が現実的です。
撤退できる構造を保つためのルール
- ビジネスロジックは KMP に集約する
- CMP は UI のみ
- 状態は shared から供給
- ナビゲーションはネイティブ側で管理する
このルールを守れば、
CMP を外すときは UI を書き直すだけで済みます。
まとめ
- ネイティブ開発は今も主流
- 新規アプリを素早く作るなら Flutter
- Web 資産を活かすなら React Native
- 既存資産を活かしつつ段階導入するなら KMP
- CMP は UI 共通化の選択肢の一つ
- KMP/CMP は AI 開発とも相性が良い
- iOS エンジニアの学習投資としても価値がある
企業開発では導入のしやすさと撤退可能性が強い武器になります。
KMP と CMP は、その現実的なラインに立てる選択肢だと感じています。
参考資料
Kotlin Multiplatform / Compose Multiplatform
-
JetBrains 公式 Kotlin Multiplatform ドキュメント
Kotlin Multiplatform の設計思想、expect/actual、iOS 連携、段階導入の考え方
https://kotlinlang.org/docs/multiplatform.html -
JetBrains 公式 Compose Multiplatform ドキュメント
Compose Multiplatform の対応プラットフォーム、iOS Stable 化の位置付け
https://www.jetbrains.com/compose-multiplatform/ -
Compose Multiplatform GitHub Repository
ソースコード、Issue、リリース履歴
https://github.com/JetBrains/compose-multiplatform -
Kotlin Multiplatform Samples
実際の構成例、iOS / Android 連携の具体例
https://github.com/Kotlin/kmp-basic-sample -
JetBrains Blog
Kotlin Multiplatform の戦略、企業導入事例、ロードマップ
https://blog.jetbrains.com/kotlin/
企業での Kotlin Multiplatform 採用事例
-
Netflix Technology Blog
Kotlin Multiplatform を用いたモバイルアプリ開発事例
https://netflixtechblog.com/ -
Square / Cash App Engineering Blog
モバイル共通化戦略と Kotlin の活用
https://developer.squareup.com/blog/ -
McDonald’s Engineering Blog
モバイルアプリ基盤のモダナイゼーション事例
https://medium.com/mcdonalds-technical-blog
※ これらは「KMP を全面採用」ではなく、
段階導入・部分共通化 の文脈で紹介されている点が重要。
Flutter
-
Flutter Official Documentation
Flutter のアーキテクチャ、対応プラットフォーム
https://docs.flutter.dev/ -
Flutter GitHub Repository
フレームワーク本体、Issue、エコシステムの状況
https://github.com/flutter/flutter -
pub.dev
Flutter パッケージリポジトリ（エコシステムの広さ・更新状況の確認）
https://pub.dev/
React Native
-
React Native Official Documentation
https://reactnative.dev/ -
React Native GitHub Repository
https://github.com/facebook/react-native -
Meta Engineering Blog
React Native の内部構造・新アーキテクチャ（Fabric など）
https://engineering.fb.com/
宣言的 UI の思想（SwiftUI / Compose）
-
Apple SwiftUI Documentation
SwiftUI の宣言的 UI モデル
https://developer.apple.com/documentation/swiftui -
Android Jetpack Compose Documentation
Compose の設計思想と宣言的 UI
https://developer.android.com/compose
AI 活用・ドキュメントと開発プロセス
-
GitHub Docs
Markdown ベースドキュメントとリポジトリ管理
https://docs.github.com/ -
JetBrains の OSS ドキュメント運用方針
公式ドキュメントを GitHub 上で管理する思想
https://github.com/JetBrains/kotlin-web-site
本記事は、公式ドキュメントおよび各社エンジニアリングブログなどの一次情報をもとに、2025 年時点の状況を整理したものです。
特定の技術を推奨するものではなく、企業開発における現実的な選択肢を考えるための材料としてまとめています。