Chaos and Order

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

引言 — 「官方 SDK」和「官方支持平台」不是一回事
时间线 — 从 nightly 到正式发布
Swift 在 Android 上究竟是怎么运行的
装三件套 — 工具链、SDK、NDK
- 关于体积 — 老老实实地读
愿景文档明确写下的 non-goal — 不提供 UI
还没做完的部分
但也不是实验室玩具
那么，你该不该用
结语
参考资料

引言 — 「官方 SDK」和「官方支持平台」不是一回事

2026 年 3 月 24 日，Swift 6.3 发布了。发布说明列出的重点有四项 — 更灵活的 C 互操作(@c 属性)、跨平台构建工具的改进(SwiftPM 中 Swift Build 集成的预览)、嵌入式环境的改进，以及 Swift SDK for Android 的首次官方发布。

最后一项就是本文的主题。但这句话很容易被误读。本博客自己的现代 Swift 2026 综述一篇里写过「实验性工具链已发布，hello world 级别运行良好」「到 2027 年左右可能成为能与 Kotlin Multiplatform 竞争的选项」，可那篇文章发布于 5 月，而那时官方 SDK 早已问世。反方向的误读也同样常见 — 「这下可以直接用 Swift 写 Android 应用了吧」。

准确的现状介于两者之间。而一旦用一手资料把这个位置钉死，图景就相当清晰了。

时间线 — 从 nightly 到正式发布

只罗列带日期的事实，是这样的。

2025-06-02 — Swift Package Index 新增了 Android、Wasm 的兼容性测试。按当时的测量，约 9,000 个已索引的包里，27.9% 能为 Android 构建，Wasm 则是 18.9%(SPI 博客)。这是早于官方 SDK 十个月的数字，读的时候要记得这是当时社区工具链标准下的数值 — 此后没有公开更新过的数据。
2025-08-27 — Android 愿景文档的 PR(swift-evolution #2946)被开启。
2025-10-24 — swift.org 宣布了 Swift SDK for Android 的 nightly 预览版。
2025-12-18 — 工作组发布了解释该 SDK 的后续文章，Swift 6.3 SDK 的 nightly 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 从「nightly 预览版」推进到了「Swift 6.3 中的官方发布版」。而在这之前，是从 2015 年源码公开后不久就开始的十年社区工作。

Swift 在 Android 上究竟是怎么运行的

这是最常被误解的地方，所以我原样搬运工作组自己的说法。

在 Android 上，Swift 同样 和绝大多数其他平台一样，直接编译为原生机器码。工作组的说法是，它能提供与用 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 ...

也就是说，在 Android 上，Swift 更接近于 取代 NDK 的位置，而不是取代 Kotlin。原本用 C++ 写的逻辑层改用 Swift 来写，其余部分依然由 Kotlin/Java 承担。

装三件套 — 工具链、SDK、NDK

官方入门指南要求准备好交叉编译所需的三件套，因为整个结构是：在主机(macOS、Linux)上构建，在目标端(Android)上运行。

Swift 工具链 — 主机端的编译器。Xcode 自带的 swift 不行，必须是开源工具链，并且 要与 SDK 版本精确匹配。推荐用 swiftly 来管理。
Swift SDK for Android — 用 swift sdk install <URL> --checksum <校验和> 安装的 artifact bundle。
Android NDK — LTS r27d 及以上版本。在 SDK bundle 目录下运行 ./scripts/setup-android-sdk.sh 来把它接上。

构建时要指定 SDK triple。

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

triple 末尾的 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 示例的输出中印着一个数字。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 状态。换成 release 构建再加上 strip，数量级就会不一样。swift.org 没有公开 strip 后的 release 数值，也没有公开实际的 APK 体积增量，所以我不会在这里凭空编一个数字出来。

不过这个输出至少说明了一件事 — 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 这类第三方方案，以及像 Skip.tools 这样把类 SwiftUI 代码转换成 Compose 的桥接方案。此外还有一些社区项目，比如在各平台上使用原生 UI 组件的 SwiftCrossUI。工作组特别声明，他们并没有验证过各个项目自己的说法。

因此，工作组主推的代表性用例很明确 — 在多个应用之间共享核心业务逻辑、算法和数据模型。愿景文档并没有完全排除「整个原生应用都用 Swift 写」这条路，但即便谈到这一点，也附带了「但 UI 部分需要相当大的工作量」这句限定语。

关于愿景文档还有一点值得一提。这个 PR 是在 2025 年 8 月 27 日开启的，而 直到现在(2026 年 7 月 16 日)仍然是未合并的 draft 状态。 最后一次更新是在 2026 年 2 月 24 日。也就是说，即便 SDK 已经搭上了正式发布，定义方向的文档却依然还是草案。

还没做完的部分

这里正是炒作和现实分道扬镳的地方。以下写的全是可核实的事实。

调试。 在 2025 年 12 月的文章里，工作组写道，简便的调试「现在对我们来说是高优先级」，同时也承认「在小例子上或许能用」，但需要让它扩展性更好、更容易测试和配置。作为依据被链接的 issue 是 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 同一层级的支持平台，依然是两码事。

但也不是实验室玩具

也有需要拿来平衡的另一面。在官方 SDK 出现之前，Swift on Android 早就已经在生产环境里跑起来了。工作组自己列出的案例是这些 — Readdle 的邮件客户端 Spark(在 iOS/Android 移动端与 macOS/Windows 桌面端之间共享代码)、钢琴学习应用 flowkey(使用 Swift for Android 已将近十年)、医疗健康应用 MediQuo，以及有机食品商 Naturitas。这些应用全都靠 自制的 Java interop 完成了这件事，用 swift.org 的说法，加起来是「数百万次下载」。(这是 swift.org 自己的表述，没有给出按应用拆分的数字。)

官方 SDK 的意义正在于此。证明「行不行得通」的阶段已经过去了，现在进入的是 不用再各自维护 fork 和自定义工具链就能做这件事 的阶段。正如愿景文档所说，历史上 Swift for Android 一直不得不依赖非官方分支、自定义工具链和第三方方案。

那么，你该不该用

用了值回成本的情况

iOS 应用已经用 Swift 写好了，你想把 模型、网络、领域逻辑与 Android 共享。这正是工作组精准瞄准的用例。
你想把图像、音频处理这类 对性能要求高的模块，从 NDK C++ 换成 Swift 来写。这是愿景文档提到的第二个用途，也正是 Swift 取代的位置。
你在构建面向多个平台、暴露同一套 API 表面的 库或 SDK。

属于过度，或者还为时过早的情况

从零开始写一个新的 Android 应用。 愿景文档自己写道，「Kotlin 依然是 Android 开发推荐使用的语言」。用 Swift 写 UI 并没有官方路径。
团队没有现成的 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 的首次官方发布，这是十年社区努力真正登上官方分发路径的一个里程碑。模型很清楚 — 编译为原生机器码，打包运行时，通过 JNI 调用 Android API。占的是 NDK 的位置，不是 Kotlin 的位置。

与此同时，缺的东西也同样清楚。UI 是 non-goal，JVM 字节码也是 non-goal，愿景文档还是草案，lldb 的 issue 还开着，swift-java 还在 0.4.x，工作组章程所说的「官方支持平台」依然是用未来时态写的目标。

所以，解读这次发布的准确方式，不是「现在可以用 Swift 写 Android 应用了」，而是 「让 Swift 逻辑跑在 Android 上，现在有了官方支持的工具，这件事本身变得可行了」。这两者的区别在你的项目里重不重要，决定了你现在要不要动用它。