Compose MultiplatformとSwiftUIで作るハイブリッドモバイルアプリ（Part 1）：なぜハイブリッドなのか
この記事は KINTOテクノロジーズアドベントカレンダー2025 の19日目の記事です🎅🎄
はじめに
こんにちは、KINTOテクノロジーズ Mobile Assistanceマネージャー&KMPチームリードのYena Hwangです。
2025年9月にDroidKaigi 2025で「Compose MultiplatformとSwiftUIで作るハイブリッドモバイルアプリ」というテーマで登壇する機会をいただきました。本記事では、発表内容をもとに、私たちKMPチームがハイブリッド開発を導入した背景と実際の経験を共有したいと思います。
DroidKaigi 2025セッションページから発表動画をご覧いただけます。また、発表スライドも公開していますので、ぜひご参照ください。
本シリーズの構成
- Part 1：なぜハイブリッドなのか ← 現在の記事
- Part 2：実装ガイド（近日公開）
- Part 3：SwiftUI連携と技術Tips（近日公開）
私たちのチーム紹介
Mobile KMPチームは元々Androidエンジニアのみで構成されたチームでした。しかし、Kotlin Multiplatform（以下KMP）とCompose Multiplatform（以下CMP）を導入することで、iOSアプリの開発まで担当できるチームへと進化しました。
これこそがハイブリッドアーキテクチャの大きなメリットの一つです。AndroidエンジニアがKotlinの知識をベースにiOS開発まで担当できるようになり、逆にiOSエンジニアもKotlinを習得することで共有コードの開発に参加できます。各OS専門のエンジニアを別々に確保するより、はるかに効率的なチーム運営が可能です。
チーム構成（3名）：
| メンバー | スキル拡張 |
|---|---|
| Yao Xie (Tech blog) | Android → KMP, CMP, iOS |
| Yonghui Chen (Tech blog) | iOS, Android → KMP, CMP |
| Garamoi Choi (Tech blog) | API, Android → KMP, CMP, iOS |
この3名のチームで、Androidアプリの開発に加え、iOSチームに提供する共有ライブラリ/SDKの開発も担当しています。KMP/CMPで作成したロジックやUIコンポーネントをライブラリ形態でiOS側に提供することで、iOSチームは共有モジュールを統合するだけで同じ機能を実現できます。
現在、私たちのチームはAndroid/iOSアプリで共通利用できるSDKの開発を担当しています。
なぜハイブリッド開発を選んだのか
現実的な制約条件
昨年（2024年）に、既存のコードベース（Jetpack Compose + SwiftUI）を活用して新しいプロダクトを開始することになりました。プロトタイプ段階から求められた条件は明確でした：
- High Speed：非常に短い期間
- Low Cost：少人数の開発チーム
- High Quality：ネイティブアプリレベルのUIパフォーマンス
しかし現実では、この3つを同時に達成することは「不可能な三角形」と呼ばれるほど難しいことです。通常は2つを選ぶと、残り1つを諦めなければなりません。
KMP + CMPという解答
すでにKMPでビジネスロジックを共有していた私たちにとって、2024年にCMPのiOSサポートがBetaになったことは、UIレイヤーまで共有する挑戦を始める絶好のタイミングでした。ロジックだけでなくUIまで共有することで、この「不可能な三角形」を破れると考えました。
このアプローチが約束すること：
- 少人数チームでも迅速なプロトタイプリリース
- ネイティブレベルのパフォーマンス
- 既存のJetpack Composeコンポーネント再利用
- ロジックとUIコード共有による効率最大化
- タイトなデッドライン達成
AndroidとiOSを別々のチームで開発していたら実現できなかった、不可能な三角形を破る実用的な方法でした。
KMPとCMPとは
本記事では以下の略称を使用します：
- KMP（Kotlin Multiplatform）：ビジネスロジックをAndroid/iOS/Desktop/Web間で共有
- CMP（Compose Multiplatform）：Jetpack ComposeベースのUIをプラットフォーム間で共有
KMPでロジック層を、CMPでUI層を共有することで、効率的なクロスプラットフォーム開発が可能になります。
ハイブリッドアーキテクチャとは
レイヤー別技術選択基準
私たちが確立した実用的なガイドラインです：
| レイヤー | 技術 | 適した領域 |
|---|---|---|
| KMP | Kotlin Shared | ビジネスロジック、APIサービス、データ管理 |
| CMP | Compose Multiplatform | リスト/カード/フォーム画面、データ中心の詳細画面 |
| Native | SwiftUI/UIKit | ナビゲーション/ジェスチャー、Map/Camera/Wallet、プラットフォーム固有スタイリング |
なぜ100% CMPではなくハイブリッドなのか
もちろん、100% CMPで構築することも可能です。しかし、私たちの場合は以下の理由でハイブリッドを選択しました。
Best of Both Worlds：
- プラットフォーム別UI/UXガイドライン準拠が可能
- ネイティブコンポーネント統合（Maps、Camera）
- 段階的マイグレーションパス確保
- チームの既存専門性活用
適したユースケース：
- 既存ネイティブアプリがある場合
- プラットフォーム別デザイン要件がある場合
- 複雑なネイティブ統合が必要な場合
以下は、私たちがPoCアプリで実際に使用したハイブリッドアーキテクチャです。
End-to-End Blueprint
ハイブリッドアーキテクチャを実現するための全体像です。
| 要素 | 説明 |
|---|---|
| Module layout | 共有コードとプラットフォーム固有コードを明確に分離 |
| Shared ViewModel | UIからロジックを切り離すための共通契約 |
| Bidirectional UI interop | CMPビューをネイティブ画面に埋め込む ネイティブコンポーネントをCMP画面に埋め込む |
| Navigation & State | プラットフォーム間で動作するナビゲーションと状態管理戦略 |
次回予告
Part 1では、ハイブリッド開発を選んだ背景とアーキテクチャの全体像を紹介しました。
Part 2：実装ガイドでは、実際のプロジェクト構造、ナビゲーション統合、Koin DIの設定など、具体的な実装方法を詳しく解説します。お楽しみに！
関連記事 | Related Posts
Compose MultiplatformとSwiftUIで作るハイブリッドモバイルアプリ（Part 2）：実装ガイド
Kotlin Multiplatform ハイブリッドモード：Compose Multiplatform が SwiftUI や Jetpack Compose と融合
Compose MultiplatformとSwiftUIで作るハイブリッドモバイルアプリ（Part 3）：SwiftUI連携と技術Tips
SwiftUIをCompose Multiplatformで使用する
既存のアプリへのKMPの適用：チームの経験と成果
Kotlin Multiplatform Hybrid Mode: Compose Multiplatform Meets SwiftUI and Jetpack Compose
We are hiring!
【オープンポジション】「気になる！」方はまずはこちらからご応募ください。／東京・名古屋・大阪・福岡
業務内容国内外のKINTOサービスや、トヨタグループの金融、モビリティサービスの内製開発組織である同社にて、ご経験・ご志向性に応じて配属を決定し、ご活躍いただきます。
生成AIエンジニア／AIファーストG／東京・名古屋・大阪・福岡
AIファーストGについて生成AIの活用を通じて、KINTO及びKINTOテクノロジーズへ事業貢献することをミッションに2024年1月に新設されたプロジェクトチームです。生成AI技術は生まれて日が浅く、その技術を業務活用する仕事には定説がありません。
