Compose Multiplatformとは？KMPとの違いとiOS対応の現在地・採用判断を解説

Compose Multiplatformは、JetBrainsが提供する宣言的UIフレームワークです。AndroidのUIを書くJetpack Composeと同じ記述モデルのまま、iOS・デスクトップ・Webの画面まで共通のKotlinコードで書けます。2026年8月時点の最新は1.11.1系で、Android・iOS・デスクトップが安定版、Web（Kotlin/Wasm）はベータという段階です。この記事では、ロジックを共有するKotlin Multiplatformとの担当範囲の違い、SwiftUIやUIKitとの相互運用、Resクラスによるリソース管理、そしてUIまで共通化してよい案件の条件と見送るべき場面までを実装者の視点で整理しました。導入体験記が触れない版の要件と採用判断に踏み込みます。

まとめ：Compose Multiplatform採用の判断軸と対応状況

Compose Multiplatformは「UIまでKotlinで共通化する」枠組みです。判断の順序は3つに整理できます。第一に、Androidを主戦場にしていてKotlinの実装者が揃っているなら、iOS展開の第一候補になります。第二に、iOS側の見た目や操作感を個別に作り込む前提の案件では、共通化の利得が削れるため見送りが妥当です。第三に、Web対応が要件に入るなら、Web（Wasm）がベータである点を踏まえて対象ブラウザと退避策を先に決めてください。

版の前提も先に確認します。1.11.1系が求めるのはKotlin 2.1.0以上で、iOSやWebを対象にするならKotlin 2.2.20系が公式に推奨されています。対応するJetpack Composeは1.11.2です。ネイティブUIとの相互運用にはComposeUIViewControllerとUIKitViewという2方向の橋渡しが用意されており、地図や決済SDKの画面は包んだまま残せます。以降の章では、この対応状況・連携API・見積もりの判断基準を順に扱います。

Compose MultiplatformとKMPの担当範囲の違い

名前の似た枠組みが3つ並ぶため、最初に担当範囲を確定させます。ここを取り違えると、共通化できる割合の見積もりが最初から狂います。

Jetpack Composeを他のプラットフォームへ広げた構造

Jetpack ComposeはGoogleが提供するAndroid専用のUIツールキットです。Compose Multiplatformは、これをJetBrainsが拡張し、iOS・デスクトップ・Webを対象へ加えたものです。基礎は共有されており、共通のKotlinコードから同じAPIを呼べます。@Composable関数、rememberによる状態保持、TextやRowといったレイアウト部品、Modifier、アニメーションは書き方がそのまま通用します。

Android開発で身につけた記述の作法を、そのまま他のプラットフォームへ持ち込めます。土台となるAndroid側はJetpack Composeとは？宣言的UIの仕組みとBOM運用・採用判断で押さえておいてください。ただし、Android専用のコンポーネントは共通コードから呼べません。デスクトップ向けのウィンドウAPIやiOS向けのUIKit互換APIも、それぞれのプラットフォームでのみ使える形です。

ロジック共有のKotlin MultiplatformとUI共有の関係

Kotlin Multiplatform（KMP）は、通信処理やドメインロジック、データ層をAndroidとiOSで共通化する仕組みです。UIは各プラットフォームのネイティブ実装に任せる前提で設計されています。Compose Multiplatformは、そのKMPの上に載り、UI層まで共通化の対象を広げます。

この関係を押さえると、段階的な導入計画が引けます。まずKMPでロジックだけを共通化し、UIはJetpack ComposeとSwiftUIで別々に作る。運用が安定してから、画面単位でCompose Multiplatformへ寄せる。この順序なら、片方が失敗しても切り戻せます。土台の仕組みはKotlin Multiplatformとは？その利点と特徴で整理しています。

共通コードで書ける範囲とプラットフォーム固有で残す実装の線引き

共通化できる範囲は画面の描画だけではありません。Jetpackのライフサイクル、ViewModel、Navigation Composeは、いずれもCompose Multiplatformでサポートされています。状態保持と画面遷移の設計まで共通側に置けます。

逆に、共通側へ持ち込めないものも明確です。カメラや生体認証、プッシュ通知、課金といったOS機能は、各プラットフォームの実装が要ります。地図や動画プレーヤー、決済SDKの画面部品も同様で、後述する相互運用APIで包む形になります。見積もりの段階では、この「包む対象」を機能一覧から先に抜き出してください。

Compose Multiplatformの対応状況と動作要件の最小バージョン

採用判断で最初に確認するのは、対象プラットフォームの安定度と動作要件の下限です。ここは公式の記載が明確で、迷う余地がありません。

iOSとデスクトップが安定版・Webがベータという現在の対応状況

2026年8月時点の安定度は次の通りです。Android・iOS・デスクトップ（JVM）が安定版、Web（Kotlin/Wasm）がベータという段階になります。iOSが安定版になったのは1.8.0（2025年5月）、Webがベータへ上がったのは1.9.0（2025年9月）でした。

ベータの意味を実務へ翻訳しておきます。仕様変更が入る可能性があり、動くブラウザの範囲も限られます。社内ツールや検証用途なら踏み込んでよい一方、不特定多数へ配る本番のWebサイトを共通コードだけで賄う計画は、現時点では見送りが安全な判断です。

1.11系が要求するKotlinのバージョンと対応表の読み方

最新の1.11.1が求めるのはKotlin 2.1.0以上です。加えて公式は、iOSやWebのように変化が速い対象を扱う場合にKotlin 2.2.20を推奨しています。既存プロジェクトのKotlin版がこれを下回るなら、言語側の更新が前提工程として乗ります。

もう1つ確認するのが、対応するJetpack Composeの版です。両者は次のように紐づきます。

Android向けの記事やサンプルはJetpack Compose側の版で書かれているため、部品の挙動を調べるときはこの表で読み替えてください。番号がずれていると、あるはずのAPIが見つからない事態になります。

Android 5.0やiOS 14という各プラットフォームの下限

動作要件の下限は前掲の表の通りで、Androidは5.0（APIレベル21）、iOSは14です。デスクトップはmacOS 13 arm64、Windows 10、Ubuntu 20.04が基準になります。既存アプリの対象OSがこれを下回るケースは実務でほとんどなく、下限が採用の障害になる場面は限られます。

むしろ確認すべきはビルド環境です。iOSのビルドにはmacOSとXcodeが要るため、CIをLinuxだけで回している組織では基盤の用意が別工程になります。

iOSのネイティブUIとCompose画面をつなぐ相互運用の実装

共通UIだけで完結する案件はまれです。既存のiOSアプリへ段階的に入れる場合も、共通画面へネイティブ部品を差し込む場合も、標準の相互運用APIで橋渡しします。

ComposeUIViewControllerでSwiftUIへ画面を渡す手順

Compose側の画面をiOSアプリへ渡すときは、ComposeUIViewControllerでUIViewControllerとして書き出します。Kotlin側に返却用の関数を1つ用意し、Swift側ではUIViewControllerRepresentableに準拠した構造体で受け取る形です。SwiftUIの画面階層の一部として、Composeで書いた画面を配置できます。

UIKitベースのアプリでも考え方は同じで、UITabBarControllerやUINavigationControllerへ書き出したUIViewControllerを追加します。既存アプリを一気に置き換える必要はありません。1画面ずつ差し替えられるため、リスクの低い画面から順に移せます。

UIKitViewで地図やWebViewをCompose側へ埋め込む

逆に、共通のCompose画面の中へiOSのネイティブ部品を置く場合はUIKitViewを使います。factoryでMKMapViewやWKWebView、UITextFieldを生成し、updateで状態変化を反映させる書き方です。SwiftUIのビューを差し込みたいときは、UIHostingControllerで包んだうえでUIKitViewControllerへ渡します。

実装上の注意が2つあります。Kotlin/Nativeの相互運用APIに触れるため、多くの場面でExperimentalForeignApiのオプトインが必要です。Objective-Cのコールバックを受ける関数にはObjCActionの注釈も要ります。この定型が並ぶ箇所は共通化の対象外なので、iOS側を書ける実装者の稼働を見積もりへ入れてください。

Info.plistの設定漏れで実行時にクラッシュする代表的な失敗例

初回の統合で最も多い躓きがInfo.plistの設定漏れです。高いリフレッシュレートで描画するためにCADisableMinimumFrameDurationOnPhoneキーの追加が必須で、これがないと実行時にクラッシュします。ビルドは通るのに起動直後で落ちるため、原因の切り分けに時間を取られがちな箇所です。

カメラを扱う画面ではNSCameraUsageDescriptionも必要になります。いずれもKotlin側のコードを見ても原因が分からない種類の失敗で、統合の初日にまとめて設定するのが確実です。なお1.11.0では、iOS向けにUIViewベースの実験的なテキスト入力が入り、選択ハンドルやコンテキストメニューがネイティブの挙動へ寄りました。文字入力の操作感を理由に見送っていた案件は、再評価の余地があります。

ResクラスとNavigation 3で共通コードから扱う仕組み

UIの記述だけを共通化しても、リソースと画面遷移が各プラットフォームに散っていれば共通化率は上がりません。周辺の仕組みも共通側へ寄せられます。

AndroidのRクラスと異なるResクラスによるリソース管理

Androidでは画像や文字列をRクラス経由で参照しますが、これはAndroidのリソースシステムに依存した仕組みです。Compose Multiplatformでは専用のリソースライブラリが用意されており、生成されるResクラスから参照します。画像・文字列・フォントを共通ソースセットへ置けば、iOSでもデスクトップでも同じ記述で読み出せます。

既存のAndroidアプリから移す場合、RからResへの置き換えが機械的な作業として発生します。件数は多いものの難易度は低く、初期のまとまった工数として見込んでおけば計画は崩れません。翻訳運用がある組織では、正本の置き場所を移行前に決めてください。

Navigation 3とViewModelを共通側で動かす前提条件

Jetpack ViewModelとJetpack Navigation Composeは、いずれもCompose Multiplatformでサポートされています。画面遷移と状態保持をAndroid側の作法のまま共通コードへ持ち込めるため、Android開発の経験がそのまま設計へ効きます。

1.10.0では、Androidに限らない対象でNavigation 3が使えるようになりました。ナビゲーションのスタックを直接操作する設計で、遷移先の追加と削除が簡潔に書けます。既存のNavigation Composeで組んだ遷移をそのまま運ぶか、Navigation 3へ寄せるかは、画面数と遷移の複雑さで決めてください。

Compose Hot Reloadと共通@Previewが変える確認速度

開発体験の面では1.10.0の変更が効きます。それまで3種類に分かれていた@Preview注釈が1つへ統合され、commonMainソースセットで動くようになりました。共通側に書いた画面を、その場でプレビューできます。

Compose Hot Reloadも同じ版で安定版となり、Gradleプラグインへ同梱されて既定で有効になりました。追加設定なしで、コードの変更を実行中のアプリへ反映できます。iOSシミュレータの起動待ちが積み上がる開発では、この差が日々の手戻り時間に効きます。1.11.0ではAndroid以外の対象でComposeUiTestのv2 APIが使えるようになりました。旧APIは非推奨扱いのため、新規プロジェクトはv2で書き始めてください。

Compose Multiplatformを採用してよい条件と見送る場面

ここは条件付きで言い切ります。曖昧な結論は、技術選定でも見積もりでも使えません。

Android中心のチームがUIまで共通化して進めてよい条件

次の条件がそろうなら、Compose Multiplatformを選んでください。AndroidアプリをKotlinとJetpack Composeで作っている。Kotlin 2.1以上へ上げられる。iOS版の画面要件がAndroid版とほぼ同じで、独自の操作感を求められない。この3つが満たされる案件では、UI実装を二重に持つ理由がほとんど残りません。

デスクトップ版が要件にある案件も相性がよい領域です。Android・iOS・デスクトップの3つが安定版として並ぶため、店舗端末と管理用PCで同じ画面を出す構成が追加実装なしで組めます。Webも同じコードで出せますが、ベータ段階である点は計画へ明記してください。

iOS側の作り込みが必要な案件で見送る条件とFlutterとの比較

次に当てはまるなら見送りが妥当です。判断を先送りにしないでください。

• iOS版に独自のUI表現やAppleらしい操作感が求められ、画面ごとの作り込みが要件になっている
• チームにKotlinの実装者がおらず、SwiftとTypeScriptが中心の体制になっている
• 不特定多数向けのWeb版を同じコードで賄う前提で、退避策が用意できない
• iOS向けのビルドと配信を回す基盤がなく、macOSのCI環境を用意する計画も立っていない

代替との比較軸も置いておきましょう。既にDartやTypeScriptの資産があるチームなら、FlutterとReact Nativeの違いと選び方で整理した基準のほうが判断へ直結します。Compose Multiplatformの利点は「Androidの実装資産と人材をそのまま伸ばせる」点にあり、その前提が無い組織では優位が薄れます。逆にAndroid側が主戦場なら、他の枠組みへ移るより学習コストは小さく済むはずです。

受託開発でCompose Multiplatform案件を見積もる判断基準

技術判断と同じくらい、体制の判断が案件の成否を決めます。工数がずれる箇所は事前にほぼ特定できます。

UI共通化率の見積もりで外しやすい工数と過小評価が起きる3つの要因

過小評価の典型は「UIが共通化できるから工数が半分になる」という換算です。実際に削れるのは画面実装の一部で、削れない領域が3つ残る点を先に共有してください。第一にOS機能の実装で、カメラ・通知・課金・生体認証はプラットフォームごとに書きます。第二に相互運用の橋渡しで、地図や決済SDKをUIKitViewで包む部分は個別調査が要ります。第三にビルドと配信で、iOS向けの証明書や審査対応は共通化の対象外です。

初回案件では、リソースのRes移行やKotlin版の引き上げといった前提工程も乗ります。発注側と工程の全体像を揃えるなら、クロスプラットフォームアプリ開発とは｜メリット・デメリットと主要フレームワークの選び方を共通の下敷きにすると説明が短く済みます。数字を出すなら、機能一覧へ「共通・Android固有・iOS固有」の3列を足して積み上げるやり方が最も外れません。

Compose Multiplatformの保守範囲を内製と外注で分ける基準

分担は「更新頻度」で線を引いてください。共通のデザイン部品群とリソース基盤は、一度作ると変更が少なく、品質が全画面へ波及します。ここは外部の実装者が集中して作り切るほうが速い領域です。逆に、業務ロジックに密着した個別画面は仕様変更が続くため、内製側が持つと伝達のロスが減ります。

もう1つ、担当を明文化すべきなのが版の更新です。Compose MultiplatformとKotlinは同じ周期で動かないため、四半期に一度まとめて上げ、iOSとデスクトップの回帰を確認する担当を保守範囲へ明記してください。新規のマルチプラットフォーム開発や、既存Androidアプリからの展開の相談はスマホアプリ開発で受けています。対象OSと機能一覧、現在のKotlin版が分かれば、共通化できる範囲と概算の工程まで一度に示せます。

よくある質問

Compose Multiplatformの検討時に実務でよく挙がる質問を5つ整理しました。

Compose MultiplatformとKotlin Multiplatformは何が違いますか？

共通化する層が違います。Kotlin Multiplatformは通信やドメインロジック、データ層をKotlinで共通化する仕組みで、UIは各プラットフォームのネイティブ実装に任せる前提です。Compose Multiplatformは、そのKotlin Multiplatformの上に載り、UI層まで共通化の対象へ加えます。段階導入するなら、まずロジックだけを共通化し、運用が安定してから画面単位でUIを寄せる順序が扱いやすくなります。

iOSでも本番運用して大丈夫な段階ですか？

iOS向けは1.8.0（2025年5月）で安定版となり、本番投入できる段階です。動作要件の下限はiOS 14で、現在のアプリの対象OSが制約になる場面はほとんどありません。1.11.0ではiOS向けのネイティブテキスト入力が実験的に入り、並行レンダリングが既定で有効になりました。文字入力の操作感を理由に見送っていた案件は、いま一度試す価値があります。

Web対応は業務システムに使える水準ですか？

Web（Kotlin/Wasm）は2026年8月時点でベータです。仕様変更の可能性があり、動作するのはWasmGCに対応したブラウザに限られます。社内向けの管理画面や検証用途なら踏み込める一方、不特定多数へ配る本番サイトを共通コードだけで賄う計画は避けてください。要件にWebが含まれるなら、対象ブラウザの範囲を先に確定させる進め方が安全です。

既存のiOSアプリへ部分的に導入できますか？

できます。ComposeUIViewControllerでCompose側の画面をUIViewControllerとして書き出し、既存のUINavigationControllerやUITabBarControllerへ追加する形です。SwiftUIの画面階層へ差し込む場合はUIViewControllerRepresentableで受け取ります。1画面ずつ移せるため、全面書き直しの計画を立てる必要はありません。Info.plistへの設定追加だけは初回に忘れずに行ってください。

Kotlinのバージョンはどこまで上げる必要がありますか？

1.11.1系はKotlin 2.1.0以上が必須です。加えて公式は、iOSやWebを対象にする場合にKotlin 2.2.20を推奨しています。既存プロジェクトがこれを下回るなら、言語側の更新が前提工程として先に乗ります。依存ライブラリの対応状況を含めて確認する作業になるため、見積もりでは導入作業とは別枠の工数として計上してください。

関連記事

• Kotlinとは？Javaとの違いとK2コンパイラ・2.4系の現在地を実装者目線で解説：共通コードを書く言語側の前提が分かります。
• iOSアプリ開発とは？特徴・Swiftでの作り方・費用と外注判断を発注者視点で解説：iOS側の開発工程と費用感を比較できます。
• .NET MAUIの将来性は？サポート期限・Xamarin後継・Flutter比較から2026年の採用を判断する：別系統の共通UI基盤との比較材料になります。
• Lynxとは？ByteDance製クロスプラットフォーム開発フレームワークの特徴とReact Native・Flutterとの違い：新興の共通化フレームワークの動向が分かります。
• XCFrameworkとは何か？新しいマルチプラットフォーム対応フレームワーク形式の概要と基本を解説：iOS側へ成果物を配る形式の理解に役立ちます。