Kotlin Multiplatform が『マルチプラットフォームの新本命』に
Kotlin Multiplatform（KMP）はJetBrainsが推進する『1つのKotlinコードでiOS/Android/Web/サーバを書く』戦略です。React Native/Flutterが『1コード=1UI』なのに対し、KMPは『ネイティブUI（SwiftUI + Jetpack Compose）+ 共通ビジネスロジック』というアプローチ。2023年に正式GA、2024〜2026年でNetflix・McDonald's・Philipsが本番採用、急速にエンタープライズ展開しています。
採用すべき5つのシグナル
- iOS/Android両プラットフォームでネイティブUIを維持したい
- ビジネスロジック・データ層を共通化したい
- Android（Kotlin）の知識を最大活用したい
- 長期保守・大規模アプリ前提
- サーバサイドKotlin（Spring等）と共通化したい
主要機能
- Common code: 共通ビジネスロジック・データ層
- Platform-specific code: 各プラットフォーム固有実装
- expect/actual: 共通インタフェース＋プラットフォーム実装
- Compose Multiplatform: UI も共通化可能（Optional）
- Ktor: マルチプラットフォームHTTPクライアント
- SQLDelight: マルチプラットフォームDB
React Native/Flutter/KMP比較
React Native: JS/TS・速い開発・UI共通・Webと親和性高い。
Flutter: Dart・UI完全共通・Material/Cupertino両対応・Web弱め。
KMP: Kotlin・ネイティブUI+共通ロジック・サーバとも共通化可能。
使い分け: UI共通化重視はFlutter/RN・ネイティブ品質+ロジック共通はKMP。
実装パターン
(1) 共通モジュール定義: shared/にKotlin Multiplatformコード
(2) iOSプロジェクト: XcodeでSwiftUI・shared frameworkインポート
(3) Androidプロジェクト: Jetpack Compose・shared moduleインポート
(4) expect/actual: プラットフォーム別実装定義
(5) テスト: 共通ロジックを1度のテストで両プラットフォーム検証
本番採用の判断基準
- 本番実績: Netflix・McDonald's・Philips・Cash App
- iOS開発者: SwiftUIをそのまま書ける・Kotlinの理解必要
- Android開発者: 既存Kotlin知識フル活用
- パフォーマンス: ネイティブUIなのでReact Nativeより速い
- 学習コスト: チームでiOS/Android両方の知識が必要
採用しない方が良いケース
- UI共通化で開発工数最小化したい → Flutter
- Web対応が中心 → React Native
- iOSメイン・Android少しだけ → SwiftUI直接
- 小規模プロトタイプ → React Native
- サーバサイドがKotlin/JVM以外 → メリット薄い
実装で詰まる3つの落とし穴
- iOS側のKotlin相互運用: Swift⇔ Kotlinの型変換で詰まる
- SDKバージョン管理: 共通モジュールと各プラットフォーム同期
- ビルド時間: 初回ビルドは長い・キャッシュ設定
30日学習プラン
- 1週目: KMPプロジェクト作成・Android/iOS両動作確認
- 2週目: expect/actual・カスタム実装パターン
- 3週目: Ktor・SQLDelightで共通データ層構築
- 4週目: 本番デプロイ・ビルド時間最適化
関連リンク
Expoは Expo SDK深掘り、Tauriは Tauri 2.0深掘り、モバイル全般は モバイル開発ツール選び方 を参照してください。