如果五年前你告诉一位移动开发者，Swift将正式支持Android，他们很可能会笑出猪叫，并冲你甩了一个“鄙夷”的表情。长期以来，苹果的整个生态系统都被视为一个精心打磨、运行流畅且严格专属的 “围墙花园”。
但快进到 2025 年年中，苹果的主力编程语言突然以一种重大方式实现跨平台。
一个新成立的Swift Android工作组正在努力将Android打造成Swift的官方支持目标平台。
请仔细体会这几个关键词：
Swift、Android、官方、原生。
这是自 Flutter 和 Kotlin Multiplatform 成为头条新闻以来，移动开发领域最大的跨平台变革之一。
而且，这并非仅仅是 Swift 在 Android 上 “运行”—— 它关乎重新定义我们构建移动应用的方式、组建开发团队的架构，以及代码在不同平台间的共享机制。
下面我们逐一拆解。
为什么是现在？
这一变革源于开发者对维护两套分歧代码库的疲惫感与日俱增。两种语言（Swift 与 Kotlin）、两套架构、两拨独立的 Bug—— 简直一团乱麻。想象一下：只需用 Swift 编写一次应用核心逻辑，就能在 iOS 和 Android 上原生运行。这不仅是便利，更是生产力的革命。
Swift 自身也已足够成熟。自 2014 年为苹果平台诞生以来，它已全面开源并官方支持 Linux 和 Windows。如今，Swift 不仅驱动 iOS 应用，还支撑服务器后端、命令行工具，甚至 WebAssembly 实验。在此背景下，Android 成了最后一片未被征服的 “疆域”。而现在，通过社区驱动（而非企业强制）的努力，这片疆域正在被攻克。
核心要点：
- 效率痛点：维护独立的 iOS/Android 代码库消耗巨大
- 语言优势：Swift 现代、高性能且天然跨平台
- 工程价值：统一代码可共享业务逻辑，减少重复开发
- 社区驱动：开源生态的协作模式让 Android 支持更具生命力，而非自上而下的强制推行
为何这条新闻的重要性远超想象
因为它挑战了我们此前认为移动开发中 “理所当然” 的一切：
- 历史性转变：苹果向安卓敞开大门（即便间接敞开），这是前所未有的。世界不再是 “苹果专属” 的了。
- 打破拉锯战：像 Flutter 和 KMP 这类跨平台框架，曾试图搭建起 iOS 与安卓之间的桥梁。而现在，编程语言本身成为了桥梁。开发团队无需再执着于 “选 Swift 还是选 Kotlin” 。
- 更快、更省、更简洁：创业公司和独立开发团队可以 “一次开发，两处部署” 。网络通信、模型、数据格式化等代码都能共享，只有平台特定的 UI（Jetpack Compose 对应安卓，SwiftUI 对应 iOS ）需要重新编写。
- 全栈 Swift 愿景推进：Swift 早已能支撑服务端（比如借助 Vapor 框架 ），甚至能开发 WebAssembly 应用。随着对安卓的支持落地，“全栈 Swift”（后端 + iOS + 安卓 ）的愿景离现实更近一步。
- 语言胜过平台，成为主导力量：这传递出更深层的趋势：工程师会优先选择自己钟爱的工具，而非受限于厂商锁定。要是说 Flutter 实现了 UI 的跨平台编写，KMP 实现了逻辑的跨平台共享，那么 Swift 对安卓的支持，则实现了编程语言本身的跨平台突破。
Flutter 证明了 UI 可一次编写跨平台使用，KMP 证明了逻辑能跨平台共享，而 Swift 对安卓的支持，证明就连苹果的 “王牌” 编程语言，都能突破其诞生之初的生态边界实现演进。这传递出一个信号：移动开发的未来由编程语言和灵活性定义，而非企业生态的边界。
工作组具体在做什么？
这不是单个开发者的副业项目，而是在Swift.org上正式列出、有结构化组织且获社区支持的倡议行动。Swift 安卓工作组聚焦于以下工作：
- 将安卓纳入官方 Swift 工具链。
- 针对安卓，优化 Foundation 框架、Dispatch 库以及 Swift 并发模型。
- 明确支持的安卓 API 级别和架构。
- 提供持续集成（CI ）工具、Docker 镜像以及 Gradle 支持。
- 梳理 Java 原生接口（JNI ）交互的最佳实践并形成文档。
- 强化调试支持（比如安卓上的 LLDB 调试 ）。
- 制作入门文档和示例项目。
其使命不是 “凑合着把功能拼凑出来”，而是让安卓成为能与 Swift 原生适配的一流平台。
对开发者而言有哪些变化？
以下是这一进展为实际开发团队带来的新可能：
- 用 Swift 编写核心逻辑，在安卓和 iOS 两端共享。
- 借助 Swift 包管理器（SPM ）构建共享模块。
- 针对安卓用 Jetpack Compose、针对 iOS 用 SwiftUI，开发平台特定 UI。
- 避免模型、解析器、业务规则等代码重复编写。
- 利用共享的 XCTest 逻辑，提升跨平台测试覆盖率。
简而言之，开发团队可围绕共享层（逻辑、网络通信、业务领域等 ）进行组织架构调整，同时针对不同平台定制 UI 。
实现 Swift 与安卓的桥接：终于成为可能
这之所以可行，要归功于 Java 原生接口（JNI）。像 Skip、Readdle 的 Gradle 插件以及开源的 SwiftJava 项目这类工具，让以下操作成为可能：
-
从 Swift 直接调用安卓应用程序接口（APIs）。
-
使用
swift build为安卓编译 Swift 包。 -
通过 Gradle 将 Swift 逻辑导入安卓工作室（Android Studio）。
-
借助 Swift 包管理器（SPM）在不同平台间共享 Swift 模块。
-
根据需要混合使用 Swift 和 Kotlin 模块。
JNI 桥接代码负责处理桥接工作，而且部分工具可自动完成这种配置。
你不必局限于 “只用 Swift”，在合理的情况下，你可以混合搭配（不同语言和技术）。
目前效果如何？
以下是如今已能实现的情况：
- 构建与编译：像 Skip 这类工具，能让你为安卓 ARM 和 x86 目标设备编译 Swift 代码。
- 应用运行：用 Swift 编写的 “Hello World” 应用和逻辑模块，确实能在模拟器和真实安卓设备上运行。
- XCTest 支持：Swift 单元测试（包括苹果的 Swift 算法测试套件）已在安卓设备上成功运行。
- Gradle 支持：Readdle 的开源插件能让安卓工作室集成 Swift 库。
- 共享模块：为 iOS 编写的 Swift 包，现在也能为安卓编译，其中包括可复用的业务逻辑。
- 持续集成（CI）与 Docker 工具：社区成员已发布 GitHub Actions 和 Docker 配置，以简化交叉编译流程。
它完美吗？并不。但它真实可用吗？是的 —— 而且即便在当前这个早期阶段，它的能力也令人意外地强大。
哪些人已在使用？
尽管还处于早期阶段，但我们已看到以下群体在采用：
-
探索更精简跨平台解决方案的独立开发者。
-
以 iOS 开发为主的初创公司，拓展到安卓平台时无需用 Kotlin 重写逻辑。
-
为客户应用构建共享 Swift 软件开发工具包（SDKs）的代理公司。
-
开发插件、SDK 和文档原型的开源贡献者。
-
开发 Vapor/Swift 服务端的团队，在安卓上复用他们的 Swift 模型和逻辑。
它目前还不是主流 —— 但正在从 “我们能不能做” 转向 “我们能做到什么程度”。
未来面临的真正挑战
有一些实际存在的限制，你需要了解：
-
SwiftUI 在安卓上不可用 —— 目前只能共享逻辑。
-
工具尚不成熟 —— 目前还没有官方的安卓工作室集成。
-
调试靠手动操作 —— 需要用到 Docker、LLDB 和终端操作。
-
二进制文件体积大 ——Swift 的运行时会让安卓安装包（APKs）增加数十兆字节。
-
JNI 桥接如果手动管理，会很棘手且代码冗长。
-
文档很简略 —— 你得经常查看 GitHub 的问题列表和论坛帖子。
-
学习曲线陡峭 —— 安卓开发者必须学习 Swift，反之亦然。
但要记住：Flutter、React Native 和 Kotlin 多平台（Kotlin Multiplatform）最初也都很粗糙。现在 Swift 也有了成长的机会，而且在社区的助力下，它会不断发展。
这对开发者意味着什么
这种转变不只是技术层面的 —— 还涉及理念层面。
- 编写一次代码，在多处运行（配合合适的用户界面）。
- 选择你想用的语言 —— 而非受平台归属束缚。
- 复用模型、逻辑、测试和库。
- 赋予小团队和初创公司更大能力。
- 专注打造出色的产品，而非重复编写代码。
未来，移动开发可能会从 “以平台为先” 转变为 “以语言为先”，而 Swift 正在引领这场变革。
开发者们的反应如何
前期反响十分热烈：
- 开发者们正在 GitHub 上分享 Swift Android 的演示项目。
- 论坛帖子里满是实验报告、工具链更新和测试结果。
- 在安卓上运行 XCTest 让许多人感到惊讶 —— 这表明这项工作已经取得了很大进展。
- 像 “我以为这是个梗” 和 “这可能会取代我们的 KMP” 这样的评论频频出现。
势头正在形成，而且这是从社区自下而上推动的。
想亲自尝试吗？
以下是入门指南：
- 访问 Swift Android 工作组官网
- 使用 Skip 工具链 构建安卓版本
- 通过
swift package init命令创建 Swift 包 - 使用跨平台编译目标为安卓编译代码
- 借助 SwiftJava 或 Skip 工具添加 JNI 桥接
- 通过 ADB 推送 XCTest 二进制文件并在设备上运行
- 加入 Swift 论坛 和 Slack 社区提问或贡献代码
虽然尚处早期阶段，但如果你是乐于探索的开发者，这无疑是一片蓝海。
未来可能是什么样子
让我们畅想一下：
-
适用于安卓的 SwiftUI：一个可在两个平台上运行的声明式 UI 框架。
-
一键式 Swift 模块：能够原生构建和捆绑适用于安卓的 Swift 工具。
-
官方工具链：Swift.org分发适用于安卓的二进制文件和 SDK。
-
技术栈统一的团队：所有开发者都使用 Swift 编写后端、iOS 和安卓应用。
-
快速入门：新开发者学习一种语言，即可在所有平台上发布应用。
虽然现在还为时尚早，但这一切正在成为现实。几年后，我们可能会回顾过去，说：“还记得 Swift 只用于 iOS 的时候吗？”
最终思考
Swift 在 Android 上的应用不仅是一项技术实验，更是我们对移动开发认知的一次范式转变。
它关乎效率与灵活性，关乎打破技术孤岛；它意味着让编程语言而非厂商生态主导开发模式；最重要的是，它关乎开发者的选择权。
如果你厌倦了维护两个独立的开发世界，厌倦了重复编写业务逻辑，或者只是对未来技术好奇 —— 现在正是探索的最佳时机。
不妨尝试在 Android 上使用 Swift，持续关注技术动态，参与社区讨论。
因为当下发生的一切，可能正在重新定义我们构建未来应用的方式。
如果本文对你有所启发，别忘了关注、分享，并在评论区留下你的想法 —— 让我们共同塑造移动开发的未来。
