本文へスキップ
hdknr blog
戻る

Swift for Android vs Kotlin Multiplatform — マルチプラットフォーム時代の「Xbox vs PlayStation」

Swift for Android vs Kotlin Multiplatform — マルチプラットフォーム時代の「Xbox vs PlayStation」

Level Up Coding の記事(Jacob Bartlett 氏)が注目を集めています。同じローラーコースターアプリを Swift for Android と Kotlin Multiplatform(KMP)の両方で構築し、開発体験を徹底比較した実践レポートです。

著者はこの 2 つの技術を「Xbox vs PlayStation」に例えています。どちらも「ビジネスロジックを共有し、UI はネイティブで書く」という同じアーキテクチャ思想を持ちながら、アプローチが正反対です。iOS 開発者が Android に進出するか、Android 開発者が iOS に進出するか — その出発点の違いが設計全体に反映されています。

2 つのアプローチ — 同じ目的、逆の方向

両技術の根本的な違いは「どちらのプラットフォームを起点にするか」です。

Swift for Android:
  iOS (SwiftUI) ← Swift コア → Android (Jetpack Compose)
  "iOS ファーストの開発者が Android に展開"

Kotlin Multiplatform:
  Android (Jetpack Compose) ← Kotlin コア → iOS (SwiftUI)
  "Android ファーストの開発者が iOS に展開"
項目Swift for AndroidKotlin Multiplatform
共有言語SwiftKotlin
コンパイル方式Swift → ネイティブ .so(JNI 経由)Kotlin → ネイティブバイナリ(Obj-C ヘッダ生成)
Android 側 UIJetpack ComposeJetpack Compose
iOS 側 UISwiftUISwiftUI
境界技術JNI + swift-java 自動バインディングKotlin/Native + Obj-C 互換
開発開始年2025 年(プレビュー)2017 年

Swift for Android の仕組み — swift-java と JNI

Swift for Android は 2025 年 10 月に公式プレビューとしてリリースされました。Swift Android Workgroup が Swift.org の公式ワークグループとして設立され、Android を Swift の正式サポートプラットフォームにする取り組みが進行中です。

アーキテクチャ

Swift コードは Android 上でネイティブマシンコードに直接コンパイルされます。C/C++ の NDK と同等のパフォーマンスです。

Swift ソースコード
    ↓ コンパイル
ネイティブ .so ライブラリ
    ↓ JNI (Java Native Interface)
Android Runtime (ART)
    ↓ swift-java 自動バインディング
Kotlin/Java コード → Jetpack Compose UI

swift-java プロジェクトの jextractwrap-java ツールが、Swift と Java 間のバインディングを自動生成します。開発者は JNI のボイラープレートを手書きする必要がありません。

現在の制約

本番実績

プレビュー段階ながら、すでに本番環境で動作しているアプリがあります。

これらは合計で数百万ダウンロードを記録しています。

Kotlin Multiplatform の成熟度 — 8 年の蓄積

KMP は 2017 年から開発されており、8 年間の成熟期間を経ています。2025 年 5 月に Compose Multiplatform for iOS が安定版に到達し、エンタープライズ採用が加速しています。

2026 年の現在地

指標数値
採用率の変化7% → 23%(18 ヶ月で 3 倍)
Compose Multiplatform for iOS安定版(2025 年 5 月〜)
iOS での ProMotion120Hz 対応(Metal ハードウェアアクセラレーション)
典型的なコード共有率80-90%(ビジネスロジック + UI 共有時)

エンタープライズ採用事例

企業用途成果
Google WorkspaceGoogle Docs iOS アプリKMP を本番運用
Duolingoモバイルアプリ全体週次リリース・4,000 万以上のユーザー
AWSSDK300 以上のサービスに対応
Airbnb予約ロジック6 ヶ月で 95% コード共有・月次→週次リリース
Netflixモバイルアプリ数百万 DAU に KMP で提供

expect/actual パターン

KMP のプラットフォーム固有実装は expect/actual パターンで記述します。

// 共有コード(commonMain)
expect fun getPlatformName(): String

// Android 実装(androidMain)
actual fun getPlatformName(): String = "Android"

// iOS 実装(iosMain)
actual fun getPlatformName(): String = "iOS"

実装比較 — 同じアプリを両方で構築

Jacob Bartlett 氏は同じローラーコースターアプリを両技術で構築し、GitHub で公開しています。

データモデル

// Swift for Android
struct RollerCoaster: Codable {
    let name: String
    let thrillRating: Double
}
// Kotlin Multiplatform
@Serializable
data class RollerCoaster(
    val name: String,
    val thrillRating: Double
)

ネットワーキング

Swift のクロスプラットフォーム実装では、非 Darwin 環境向けに FoundationNetworking の条件付きインポートが必要です。KMP は Ktor HttpClient と suspend 関数で、プラットフォームを意識せずに記述できます。

セットアップの複雑さ

項目Swift for AndroidKMP
必要なツールチェーン3 つ(Swift 6.3-dev 含む)Java 21 + Gradle
Gradle 設定複雑(手動 .so 管理)比較的シンプル
Xcode 統合ネイティブビルドスクリプト設定
IDE 間の移動必要必要

モジュール境界の摩擦 — 両者共通の課題

どちらのアプローチも「シャープなモジュール境界」を生み出します。

共有コア ←── モジュール境界 ──→ プラットフォーム固有コード

     ここで摩擦が発生

以下のシステムフレームワーク統合は、両方とも手動でプラットフォーム固有のグルーコードが必要です。

Flutter や React Native はこれらの統合に統一的なブリッジを提供しますが、Swift for Android と KMP は「ビジネスロジック共有・UI ネイティブ」の思想を優先しているため、この摩擦を受け入れる設計になっています。

ViewModel の配置 — 50% vs 80% の選択

ViewModel を共有コードに含めると、コード共有率は約 50% から約 80% に跳ね上がります。しかし SwiftUI は @Observable パターンを、Jetpack Compose は StateFlow を好むため、境界に変換レイヤーが必要になります。

Bartlett 氏はこの複雑さを避けるため、ViewModel をネイティブ側に配置する選択をしました。「正しいものを共有する」という KMP コミュニティの教訓 — ビジネスロジックであって、UI ではない — がここでも効いています。

クロスプラットフォーム技術全体の位置づけ — 2026 年

フレームワークコード共有率UI アプローチパフォーマンス採用傾向
Swift for Android40-80%ネイティブ(SwiftUI + Compose)ネイティブ同等新規・成長中
KMP40-90%ネイティブ or Compose MPネイティブ同等急成長(23%)
Flutter~100%Skia/Impeller レンダリング高速(60fps 安定)成熟・広く普及
React Native80-90%ネイティブ UI ブリッジ改善中(New Architecture)最大エコシステム

「ビジネスロジック共有 + ネイティブ UI」派(Swift for Android, KMP)と「UI も含めて全共有」派(Flutter, React Native)の 2 つの哲学が併存しています。

現時点の結論 — 「今日なら KMP、明日は分からない」

Bartlett 氏の結論は明快です。

If you have to go multiplatform today, stick to KMP.

Swift for Android は SDK の安定化にもう数ヶ月必要です。ただし、開発チームの反復速度は速く、記事執筆中に async/await サポートが追加されるほどでした。

選択ガイド

状況推奨
今すぐ本番投入が必要KMP
iOS ネイティブチームが Android に展開したいSwift for Android(数ヶ月後に再評価)
UI も含めて最大限共有したいFlutter
JavaScript エコシステムを活用したいReact Native
実験プロジェクトで最先端を試したいSwift for Android

Swift for Android のロードマップ

項目状況
Swift 6.3 SDK ナイトリービルド提供中
swift-java JNI バインディング動作中
@available によるAPI レベル分岐最新プレビューで対応
IDE デバッグ統合(VS Code, Android Studio)開発中
Android エミュレータでのテスト実行開発中
Skip Tools 連携ワークグループメンバーに Skip 創設者

まとめ

参考



前の記事
「あなたは何者?」— 職能の境界が溶けた AI 時代に、認知パターンで自分を再定義する
次の記事
SBI北尾「新卒採用を大幅に減らすのは絶対命令」— AI による採用構造変化は景気回復しても戻らない