Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 「公式SDK」と「公式サポートプラットフォーム」は別物である
タイムライン — ナイトリーから正式リリースまで
SwiftはAndroidでどう動くのか
3点セットをインストールする — ツールチェーン、SDK、NDK
- サイズの話 — 正直に読む
ビジョン文書が明記するnon-goal — UIは提供しない
まだできていないこと
とはいえ実験室のおもちゃではない
では、あなたは使うべきか
おわりに
参考資料

はじめに — 「公式SDK」と「公式サポートプラットフォーム」は別物である

2026年3月24日、Swift 6.3がリリースされました。リリースノートが前面に出す項目は4つです — より柔軟なC相互運用(@c属性)、クロスプラットフォームビルドツールの改善(SwiftPMへのSwift Build統合プレビュー)、組み込み環境の改善、そしてSwift SDK for Androidの初の公式リリースです。

最後の項目が本稿のテーマです。ただ、この一文は誤読されやすいものです。本ブログのモダンSwift 2026まとめの回でも、「実験的なツールチェーンが配布され、hello worldレベルはよく動く状態」「2027年ごろにはKotlin Multiplatformと競合できる選択肢になる可能性」と書いていましたが、その記事が公開された5月には、すでに公式SDKが出たあとでした。逆方向の誤解も同じくらいよくあります — 「これでSwiftでAndroidアプリを書けばいいのか」。

正確な状態は、その中間のどこかにあります。そしてその位置を一次資料で押さえてみると、かなりはっきりした像が見えてきます。

タイムライン — ナイトリーから正式リリースまで

日付の付いた事実だけを並べると、こうなります。

2025-06-02 — Swift Package IndexがAndroid・Wasmの互換性テストを追加。当時の計測では、約9,000件のインデックス済みパッケージのうち27.9%がAndroid向けにビルドでき、Wasmは18.9%でした(SPIブログ)。公式SDKより10か月前の数字であり、当時のコミュニティツールチェーン基準の数値だという点を踏まえて読む必要があります。以降、更新された数値は公開されていません。
2025-08-27 — Androidビジョン文書のPR(swift-evolution #2946)がオープンされます。
2025-10-24 — swift.orgがSwift SDK for Androidのナイトリープレビューを発表します。
2025-12-18 — ワークグループがSDKを解説する続報を投稿し、Swift 6.3 SDKのナイトリーCIが稼働を始めます。
2026-01-06 — Androidエミュレータでテストを走らせるCIワークフローがマージされます(swiftlang/github-workflows #215)。
2026-03-24 — Swift 6.3がリリース。Swift SDK for Androidの初の公式リリースを含む。(GitHubのswift-6.3-RELEASEタグは3月27日に公開。)

リリースノートの謝辞の段落が、この流れを要約しています — Androidワークグループの数か月にわたる取り組みが、SDKを「ナイトリープレビューからSwift 6.3の公式リリースへ」と移してきた、というものです。その手前には、2015年のソース公開直後から始まった10年分のコミュニティの作業が積み重なっています。

SwiftはAndroidでどう動くのか

ここが一番よく誤解されるポイントなので、ワークグループの説明をそのまま移します。

SwiftはAndroidでも、他のほとんどのプラットフォームと同じくネイティブ機械語へ直接コンパイルされます。NDKでビルドしたC/C++コードに近い性能を出しつつ、性能・安全性・使いやすさのあいだでより良いバランスを取る、というのがワークグループの説明です。これを可能にするため、AndroidのSwiftアプリはネイティブランタイムを一緒にバンドルします — 標準ライブラリと、DispatchやFoundationのようなコアライブラリがここに含まれます。

しかし、ほとんどのAndroid APIはJavaとKotlinにしか公開されていません。そのためSwiftはAndroidランタイム(ART)を呼び出す必要があり、その通路がJNIです。これを人手で書かずに済ませてくれるのが、swift-javaプロジェクトのjextractとwrap-javaツールです。双方向バインディングを自動生成してくれ、さらに低レベルが必要ならSwift Java JNI Coreを直接使います。

まとめると、次の図になります。

Swift ソース
  --(swiftc + Swift SDK for Android + NDK)--> アーキテクチャ別のネイティブ .so
                                              (Swift ランタイム/stdlib/Foundation をバンドル)
  APK の lib/<arch>/ に搭載
       ^
       | JNI (swift-java: jextract / wrap-java がバインディングを生成)
       v
Kotlin/Java アプリコード  --(Android SDK)--> Activity, View, Compose ...

つまりSwiftはAndroidにおいて、Kotlinの代替ではなくNDKの立ち位置の代替に近いのです。C++で書いていたロジック層をSwiftで書き、残りは依然としてKotlin/Javaが担います。

3点セットをインストールする — ツールチェーン、SDK、NDK

公式スタートガイドが要求するのは、クロスコンパイル構成の3点セットです。ホスト(macOS・Linux)でビルドし、ターゲット(Android)で動かす構造だからです。

Swiftツールチェーン — ホスト用コンパイラ。Xcode付属のswiftでは不可で、オープンソースのツールチェーンでなければならず、SDKのバージョンと正確に一致させる必要があります。swiftlyでの管理が推奨されます。
Swift SDK for Android — swift sdk install <URL> --checksum <チェックサム>でインストールするアーティファクトバンドル。
Android NDK — LTS r27d以上。SDKバンドルのディレクトリで./scripts/setup-android-sdk.shを実行して結び付けます。

ビルドはSDKトリプルを指定して行います。

$ swift build --swift-sdk aarch64-unknown-linux-android28 --static-swift-stdlib
$ swift build --swift-sdk x86_64-unknown-linux-android28 --static-swift-stdlib

トリプル末尾の28が重要です。プラットフォームサポートページの最小デプロイバージョン表にも、Androidは9(API 28)として載っています。つまりAndroid 9未満は対象外です。APIレベルの分岐はApple プラットフォームと同じ構文で行います。

@available(Android 33, *)
func backtrace() { /* ... */ }

if #available(Android 33, *) {
    // Android 33+ でのみ実行
    backtrace()
}

実行ファイルを作ったあとは、adb pushで送り込んで動かします。ただしAndroidアプリは通常、実行ファイルとして配布されないので、実際には Swiftモジュールをアーキテクチャ別の共有ライブラリとしてビルドし、APKのlib/<arch>に入れてJNI経由で呼び出します。

サイズの話 — 正直に読む

ガイドのhello world例の出力に、数字が1つ載っています。adb pushが報告したバイナリサイズは69,559,568バイト(約66.3 MiB)です。ここにNDKのlibc++_shared.so(1,794,776バイト、約1.71 MiB)も一緒に送る必要があります。

この数字を誤読しないでください。条件がすべて付いています — デバッグビルド、--static-swift-stdlib、そしてガイド自身がfile出力に記しているとおりwith debug_info, not strippedの状態です。リリースビルドでストリップまで行えば、桁が変わります。swift.orgはストリップ済みリリース基準の数値や、実際のAPKサイズの増加分を公開していないので、ここでその数字をでっち上げることはしません。

それでも、この出力が語る事実は1つはっきりしています — Swiftランタイムは借り物ではなく、アプリが自分で梱包して持ち運ぶということです。すでにART上にあるKotlinとは根本的に異なる点であり、APKサイズの予算が厳しいチームなら自分で実測すべき項目です。

ビジョン文書が明記するnon-goal — UIは提供しない

Androidワークグループのビジョン文書の草案には、独立した「Non-goals」節があります。この種の文書で一番正直な部分は、たいていここです。

SwiftUI/UIKitの全面移植 — 目標ではありません。文書の表現では、公式のSwift on Androidの取り組みは「言語とコアライブラリのサポートに集中し、独自のクロスプラットフォームUIフレームワークは作らない」とされています。
JVMバイトコードへのコンパイル — 当面の目標ではありません。Swiftのコンパイルモデルはネイティブ機械語をターゲットとし、NDKを通じてAndroidのネイティブ層に直接つなぐ道を選んだ、という説明です。

UI節の文章も明確です — 公式イニシアチブは単一のUIフレームワークを提供せず、複数のアプローチを認め・支援するだけです。実際の選択肢として文書が挙げるのは、Jetpack Compose(ブリッジングレイヤー経由)、既存のXMLベースのAndroid View、Flutterのようなサードパーティ、そしてSwiftUI風のコードをComposeに変換するSkip.toolsのようなブリッジングソリューションです。各プラットフォームでネイティブUIコンポーネントを使うSwiftCrossUIのようなコミュニティプロジェクトもあります。ワークグループは、個々のプロジェクトの主張を検証したわけではないと明記しています。

そのため、ワークグループが推す代表的なユースケースは明確です — コアとなるビジネスロジック、アルゴリズム、データモデルをアプリ間で共有することです。ビジョン文書は「完全なネイティブアプリ」をまるごと排除してはいませんが、そこにも「UIにはかなりの労力が必要だが」という留保が付いています。

ビジョン文書についてもう一点。このPRは2025年8月27日にオープンされ、今(2026年7月16日)なおdraft状態でマージされていません。 最終更新は2026年2月24日です。SDKが正式リリースに載ったあとも、方向性を定義する文書はまだ草案のままだということです。

まだできていないこと

ここが、ハイプと現実が分かれるところです。すべて確認可能な事実のみを書きます。

デバッグ。 2025年12月の記事でワークグループは、簡単なデバッグが「いまや我々にとって高い優先度」だと書きつつ、「小さな例では動作しうるが」、より拡張しやすく、テストしやすく、設定しやすくする必要があるとしています。その根拠としてリンクされているのがswiftlang/llvm-project #10831「Get this lldb working for Android debugging」で、2025年6月12日にオープンされ、今日まで開いたままです。プラットフォームサポートページのデバッガ・REPLサポート表にも、Androidの行はありません。

swift-javaがまだ0.x系である。 Android上でAndroid APIを呼ぶには必ず経由しなければならない相互運用レイヤーですが、最新リリースは0.4.2(2026-06-26)です。1.0未満であるということは、API安定性の約束がまだないということです。

IDE。 2026年4月のIDEサポート拡大の発表は、VS Code拡張機能のOpen VSX登録を告知し、「macOS、Linux、Windowsにおけるスムーズなクロスプラットフォーム開発」と述べています。Android Studio統合はビジョン文書の目標リストに載っているだけで、まだ発表されていません。

「公式サポートプラットフォーム」の階層。 ここが一番微妙な点です。Androidワークグループ憲章の主目標はいまも「Androidを Swift言語の公式サポートプラットフォームとして追加・維持すること」であり、詳細項目には「Platform Steering Groupと共にプラットフォームサポートレベルを一般的に定義し、その上でAndroidに対して特定レベルの公式サポートを達成するよう取り組む」とあります。つまりそれはまだ達成された状態ではなく、目標なのです。サポートするAPIレベルとアーキテクチャの範囲を「定める」ことも、依然として憲章のやることリストに載っています。プラットフォームサポートページのPlatform Owner表には、AppleプラットフォームとLinux、Windowsしかなく、Androidはありません。

公平を期すために、留保を一つ付けておくべきです — ワークグループ憲章のページの最終更新は2025年9月24日、プラットフォームサポートページは2025年10月31日です。どちらも6.3のリリースより前です。ですから、表からAndroidが抜けていることを「政策的な排除」と過度に読み取るべきではなく、文書がまだ追いついていないだけの可能性もあります。ただ、方向性ははっきりしています — 公式にビルド・配布されるSDKができたことと、Linux・Windowsと同じ層のサポートプラットフォームになったことは、まだ別の話です。

とはいえ実験室のおもちゃではない

バランスを取るべき反対側の話もあります。Swift on Androidは、公式SDKが出る前からすでにプロダクションで動いていました。ワークグループ自身が挙げる事例はこうです — ReaddleのメールクライアントSpark(iOS/Androidのモバイルと、macOS/Windowsのデスクトップ間でコードを共有)、ピアノ学習アプリflowkey(ほぼ10年間Swift for Androidを使用)、ヘルスケアアプリMediQuo、オーガニックマーケットのNaturitasです。これらはすべて自前のJava interopでそれをやり遂げており、swift.orgの表現では合わせて「数百万回のダウンロード」だとされています。(これはswift.org自身の記述であり、アプリ別の数値は示されていません。)

公式SDKの意味はまさにここにあります。できるかどうかを証明する段階はすでに過ぎ、そのために各自がフォークやカスタムツールチェーンを維持しなくてよい段階へと移ってきたのです。ビジョン文書の表現どおり、歴史的にSwift for Androidは非公式フォーク・カスタムツールチェーン・サードパーティソリューションに頼らざるを得ませんでした。

では、あなたは使うべきか

値する場合

iOSアプリがすでにSwiftで書かれていて、モデル・ネットワーク・ドメインロジックをAndroidと共有したい。これがワークグループが正面から狙っているユースケースです。
画像・音声処理のように性能が重要なモジュールを、NDKのC++の代わりにSwiftで書きたい。ビジョン文書が2番目に挙げる用途であり、Swiftが置き換わる場所はまさにここです。
複数のプラットフォームに同じAPI表面を出すライブラリ・SDKを作る。

過剰、あるいはまだ早い場合

Androidアプリを新規に書く。 ビジョン文書自身が「Kotlinは依然としてAndroid開発に推奨される言語」だと書いています。UIをSwiftで書く公式な経路は存在しません。
チームにSwift資産がない。 共有すべきSwiftコードがないのにSwift on Androidを導入するのは、得るものなくランタイムのバンドルとJNI境界だけを抱え込むことになります。
デバッグのしやすさが譲れない。 lldbのissueが開いたままの状態では、Android側のSwiftコードをデバッグする体験は、まだiOSと同じではありません。
APKサイズの予算が厳しい。 ランタイムを一緒に持ち運ぶ構造だという点を、まず実測してください。

Kotlin Multiplatformとの比較を期待されるでしょうが、ここで正直であろうとすればこう言うしかありません。KMPは同じ問題(ロジック共有)をさらに数年長く解いてきており、JetBrainsの支援を受けています。両陣営を並べて測った信頼できる公開ベンチマークや移行事例の比較は、私が確認できた範囲には見当たらず、そのためここで優劣をつけることはしません。実質的な判断基準は、たいていベンチマークではなく、あなたの既存資産がどちらの言語で書かれているかです。iOSのロジックがすでにSwiftなら、Swift SDKはそのコードをそのまま使う道であり、そうでなければKMPの方が近道です。

おわりに

まとめるとこうです。Swift 6.3(2026-03-24)はSwift SDK for Androidの初の公式リリースを収め、これは10年分のコミュニティの取り組みが公式配布の経路に乗った、本物の節目です。モデルは明確です — ネイティブ機械語へコンパイルし、ランタイムをバンドルし、Android APIはJNIで呼ぶ。Kotlinの座ではなく、NDKの座です。

同時に、欠けているものも明確です。UIはnon-goalであり、JVMバイトコードもnon-goalであり、ビジョン文書はまだ草案であり、lldbのissueは開いたままであり、swift-javaは0.4.x系であり、ワークグループ憲章が語る「公式サポートプラットフォーム」は依然として目標の時制で書かれています。

したがって、このリリースを読む正確な方法は、「Swiftで Androidアプリを書けるようになった」ではなく、「Swiftのロジックを Androidに載せることが、公式サポートのツールで可能になった」です。その二つの違いがあなたのプロジェクトにとって重要かどうかが、今これを取り入れるべきかを決めます。