Compose Multiplatform vs SwiftUI 比較

Kotlinから単一のUIコードベースでAndroid + iOS + Desktop + Webをカバー

VS
SwiftUI

Appleのネイティブな宣言的UIフレームワーク——プラットフォームファミリー全体の共通言語

21 分で読了Cross-Platform

クイック結論

強力なAndroid/Kotlinチームがあり、最小コストでiOSに展開したいならCompose Multiplatformは理にかなっている——iOSターゲットは2025年5月からStableだ。ただしiOSが製品の顔であり、Liquid Glassのような新機能(iOS 26+)を発表当日から使う必要がある製品では、SwiftUIを上回るのは難しい——公式ドキュメント自身もこの視覚言語にはネイティブSwiftUIシェルへの回帰を勧めている。サイズについては公式は約9MBとしているが、独立した1事例では12倍の差が報告されている。自分のプロトタイプを実機で計測すること。

Compose MultiplatformSwiftUI
結論をすべて読む

スコア比較

グラフを読み込み中...

詳細スコア

詳細スコア: Compose Multiplatform SwiftUI — カテゴリー別10点満点のスコア
カテゴリーCompose MultiplatformSwiftUI
パフォーマンス
7/10
9/10
学習のしやすさ
6/10
7/10
エコシステム
6/10
9/10
コミュニティ
6/10
9/10
求人市場
5/10
9/10
将来性
7/10
9/10

長所と短所

Compose Multiplatform

長所

  • AndroidとiOSの間でUIコードの大部分を共有できる——Respawnアプリは96%の共有率で本番稼働中
  • 単一のKotlinチームで、別途iOSチームを立てることなく両プラットフォームを同時に開発できる
  • iOSターゲットは2025年5月(1.8.0)以降、正式にStableかつ本番投入可能
  • VoiceOver、AssistiveTouch、Full Keyboard Accessが公式のファーストクラスサポートとして提供される
  • スクロールの物理挙動、テキスト選択、ナビゲーションジェスチャーはネイティブiOSの挙動に近づけられている
  • UIKitおよびSwiftUIとの相互運用が可能——既存のネイティブ画面を段階的にComposeへ接続できる
  • klibs.ioカタログとJetpackライブラリのマルチプラットフォーム対応が急速に拡大している
  • 同じコードベースからDesktop(Stable)とWeb(Kotlin/Wasm、Beta)ターゲットも展開できる

短所

  • ある独立開発者の事例では、アプリサイズがJetBrainsの主張する約9MBを大幅に上回った(2つの別アプリ間で最大12倍の差が報告されている)
  • システムレベルの視覚言語(iOS 26以降のLiquid Glassなど)については、公式ドキュメントがネイティブSwiftUIシェルへの回帰を推奨している
  • アクセシビリティはCompose semanticsからiOSオブジェクトへのマッピング層を経由する——SwiftUIのようにシステムと同一層にあるわけではない
  • Xcode Previewsに匹敵するライブプレビュー体験はない——Compose PreviewはAndroidターゲットを必要とし、iOS側のホットリロードは公式にはdesktop JVMでのみ対応している
  • チームがKotlinを知らない場合、学習コストとプラットフォーム間ブリッジ(expect/actual)が追加の複雑さをもたらす

最適な用途

すでに強力なAndroid/Composeチームを持ち、最小の追加コストでiOSに展開したい企業ビジネスロジックの大部分がすでにKotlinにあり、UIも共有したい中規模のプロダクトAndroid + iOS + Desktopを同時にターゲットとする社内ツールやB2Bアプリケーションデザインシステムがプラットフォーム間で一対一に一貫している必要があるプロダクト迅速なMVP/検証フェーズで、単一チームで両ストアに同時にリリースしたいチーム

SwiftUI

長所

  • iOSの新しいシステムコンポーネント(例:iOS 26/27のLiquid Glass)が登場したその日にネイティブアクセスできる
  • Xcode Previewsにより、数秒でフィードバックが得られるライブプレビュー体験を提供する
  • VoiceOverとアクセシビリティAPIの範囲は深く、公式に網羅的にドキュメント化されている
  • Apple自身のフレームワークであるため、App Store審査とHIG準拠に摩擦がない
  • iPhone、iPad、Mac、Apple Watch、Apple TV、Vision Proへ単一言語(Swift)で展開できる
  • スクロールの物理挙動、キーボードの動作、戻るジェスチャーはシステムと完全に同一——なぜならシステムそのものだから
  • 深いプラットフォームAPI(Core Animation、AVFoundation、Metal)へブリッジなしで直接アクセスできる
  • Appleの長期的かつ最優先の投資分野——WWDCで毎年大幅な拡張が行われる

短所

  • Appleプラットフォームでのみ動作する——Android側には別のチーム/コードベースが必要
  • Android+iOSの2プラットフォーム製品ではUIコードを共有できず、ビジネスロジックを別レイヤーに保つ必要がある
  • 一部の複雑なカスタムレイアウトや描画シナリオでは、依然としてUIKit/Core Graphicsに頼る必要がある場合がある
  • App Storeでアプリを配布する場合、Apple Developer Program(年間99米ドル)への登録が必須

最適な用途

iOSが製品の主要な顔であり、HIG準拠と新OS機能の即日利用が求められる企業Vision Pro/visionOS、watchOSなどUIKitが存在しないAppleプラットフォーム向けにリリースするアプリAppleエコシステムに深く依存する(ウィジェット、Live Activities、App Intentsなど)プロダクト小〜中規模のチームが迅速な反復で単一プラットフォーム(iOS)に集中するプロジェクト既存の大規模なSwiftUI/UIKitコードベースをそのまま拡張し続けるチーム

コード比較

Compose Multiplatform
// Compose Multiplatform - commonMain: 共有プロフィールカード
// (build.gradle.kts: kotlin { androidTarget(); iosArm64(); iosSimulatorArm64() })
import androidx.compose.foundation.layout.*
import androidx.compose.foundation.shape.CircleShape
import androidx.compose.material3.*
import androidx.compose.runtime.*
import androidx.compose.ui.*
import androidx.compose.ui.draw.clip
import androidx.compose.ui.unit.dp
import coil3.compose.AsyncImage

@Composable
fun ProfileCard(user: User, modifier: Modifier = Modifier) {
    var isFollowing by remember { mutableStateOf(false) }

    Row(
        modifier = modifier.fillMaxWidth().padding(16.dp),
        verticalAlignment = Alignment.CenterVertically
    ) {
        AsyncImage(
            model = user.avatarUrl,
            contentDescription = user.name,
            modifier = Modifier.size(64.dp).clip(CircleShape)
        )
        Spacer(Modifier.width(12.dp))
        Column(modifier = Modifier.weight(1f)) {
            Text(user.name, style = MaterialTheme.typography.titleMedium)
            Text(user.title, style = MaterialTheme.typography.bodySmall)
        }
        OutlinedButton(onClick = { isFollowing = !isFollowing }) {
            Text(if (isFollowing) "フォロー解除" else "フォロー")
        }
    }
}

// iosMain: CMPビューをUIViewControllerとして公開
fun MainViewController() = ComposeUIViewController { ProfileCard(user = sampleUser) }
SwiftUI
// SwiftUI - プロフィールカード
import SwiftUI

struct ProfileCard: View {
    let user: User
    @State private var isFollowing = false

    var body: some View {
        HStack(spacing: 12) {
            AsyncImage(url: user.avatarURL) { image in
                image.resizable().scaledToFill()
            } placeholder: {
                ProgressView()
            }
            .frame(width: 64, height: 64)
            .clipShape(Circle())

            VStack(alignment: .leading) {
                Text(user.name)
                    .font(.headline)
                Text(user.title)
                    .font(.subheadline)
                    .foregroundStyle(.secondary)
            }

            Spacer()

            Button(isFollowing ? "フォロー解除" : "フォロー") {
                withAnimation(.spring(response: 0.3)) {
                    isFollowing.toggle()
                }
            }
            .buttonStyle(.bordered)
        }
        .padding()
    }
}

#Preview {
    ProfileCard(user: .sample)
}

結論

強力なAndroid/Kotlinチームがあり、最小コストでiOSに展開したいならCompose Multiplatformは理にかなっている——iOSターゲットは2025年5月からStableだ。ただしiOSが製品の顔であり、Liquid Glassのような新機能(iOS 26+)を発表当日から使う必要がある製品では、SwiftUIを上回るのは難しい——公式ドキュメント自身もこの視覚言語にはネイティブSwiftUIシェルへの回帰を勧めている。サイズについては公式は約9MBとしているが、独立した1事例では12倍の差が報告されている。自分のプロトタイプを実機で計測すること。

無料相談を受ける
FAQ

よくある質問

はい——JetBrainsは2025年5月、CMP 1.8.0でiOSターゲットを正式にStableかつ本番投入可能と発表した。型安全なナビゲーション、ファーストクラスのVoiceOverサポート、SwiftUI/UIKitとの相互運用が完成している。ただし「対応している」ことがすべてのプロジェクトで正しい選択を意味するわけではない。2026年8月2日に公開された独立開発者の事例では、本番投入されたCMPアプリでサイズとネイティブな操作感について深刻なトレードオフが報告されている(単一の開発者の経験)。自分で計測せずに判断しないこと。

関連ブログ記事

すべての記事を見る
すべての比較