Compose MultiplatformとSwiftUIで作るハイブリッドモバイルアプリ（Part 1）：なぜハイブリッドなのか

この記事は KINTOテクノロジーズアドベントカレンダー2025 の19日目の記事です🎅🎄

はじめに

こんにちは、KINTOテクノロジーズ Mobile Assistanceマネージャー&KMPチームリードのYena Hwangです。

2025年9月にDroidKaigi 2025で「Compose MultiplatformとSwiftUIで作るハイブリッドモバイルアプリ」というテーマで登壇する機会をいただきました。本記事では、発表内容をもとに、私たちKMPチームがハイブリッド開発を導入した背景と実際の経験を共有したいと思います。

DroidKaigi 2025セッションページから発表動画をご覧いただけます。また、発表スライドも公開していますので、ぜひご参照ください。

本シリーズの構成

1. Part 1：なぜハイブリッドなのか ← 現在の記事
2. Part 2：実装ガイド（近日公開）
3. 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の設定など、具体的な実装方法を詳しく解説します。お楽しみに！