Swift 官方发布 Android SDK | 肘子的 Swift 周报 #0108

在 weekly.fatbobman.com[1]订阅本周报的电子邮件版本。访问我的博客 肘子的 Swift 记事本[2]查看更多的文章。加入 Discord[3]社区，与 2000+ 中文开发者深入交流 Swift、SwiftUI 开发体验。

Swift 官方发布 Android SDK

10 月 24 日，Swift Android 工作组发布了 Swift SDK for Android 的 nightly 预览版本。这标志着该 SDK 从早期的内部测试阶段迈入了官方支持阶段，也意味着 Swift 在跨平台之路上又向前迈出了一大步。

从技术角度来看，Swift for Android 采用了交叉编译方案，核心由三个组件构成：主机工具链、Swift SDK for Android 和 Android NDK 27d。开发者可以将 Swift 代码编译为 Android 共享库，并通过 JNI 与 Java/Kotlin 实现互操作。换言之，Swift 代码已能在 Android 平台上以原生方式运行。

除了工具链的成熟，生态层面也出现了可喜进展。根据 Joannis Orlandos[4]在官方介绍文章[5]中的说明，目前 Swift Package Index 上已有超过 25% 的开源包完成了 Android 适配。这个比例虽然还不算大，但已足以显示社区对跨平台开发的积极响应。越来越多的开发者在构建第三方库时，已经开始为 Android 的兼容性预留空间。

当然，问题也随之而来：剩下的约 75% 包中，有多少只是尚未进行适配，有多少则因与苹果生态的深度绑定（例如依赖 UIKit、AppKit、Core Data 等框架）而暂时无解？这将决定 Swift 在 Android 生态中的上限所在。对逻辑层、网络层或数据模型层而言，适配相对简单；但在 UI 层与系统集成层，跨平台的难度仍相当高。

通过 Bruno Valente Pimentel[6]的分析文章[7]可以看出，目前在 Android 上使用 Swift 的路径已经相对清晰——无论是依托官方 SDK 进行交叉编译，借助 Skip.tools 实现 SwiftUI → Jetpack Compose 的转译，还是采用其他集成方案，开发者都能找到适合自身需求的切入点。虽然距离「开箱即用」的开发体验仍有差距，但生态的基础框架已然成形，Swift 在 Android 平台的可能性不再停留于概念阶段。

值得关注的是，Skip 的创始人 Marc Prud’hommeaux 亦是 Swift Android 工作组的核心成员之一。官方、商业与开源社区力量的多方联动，可能正是 Swift 生态日趋成熟的关键标志。与此同时，OpenSwiftUI 项目也已开始将其移植到 Android 平台[8]，为跨平台 UI 开发提供开源实现的另一种路径。未来，围绕这一方向，工具链增强、迁移服务、教育培训、以及针对跨平台性能优化的第三方库，都有望成为新的增长点。

Swift Android SDK 的发布，虽然仍处于 nightly 阶段，但它已为跨平台开发打开了一扇新的窗口。对 Swift 开发者而言，这不仅是新的可能性，更是一种邀请——让我们不止见证 Swift 的跨平台成长，更参与其中，成为生态的建设者。

前一期内容｜全部周报列表

欢迎 点赞 ♥️、 转发 👉

近期推荐

用 AsyncStream 重建 Combine 的多播机制 (Replacing Combine’s subjects with AsyncStream in Swift)[9]

AsyncStream 本质上是一对一的结构：当存在多个 for await循环时，它们会“竞争”同一个流中的值，而非各自完整接收全部数据，这与 Combine 的 Subject 能天然广播给多个订阅者的机制截然不同。Natascha Fadeeva[10]通过为每个订阅者创建独立的 AsyncStream 实例，并统一缓存所有 Continuation 进行广播，巧妙地复刻了 Combine 式的多播行为。这一实现既体现了 Swift Concurrency 的灵活性，也揭示了两种异步模型在设计哲学上的差异。

Swift Async Algorithms 提案中的 AsyncBroadcastSequence[11]正在标准化这一能力，提供更完善的特性，如历史值缓存、背压控制与可配置的生命周期管理。另一边，AsyncCombine[12]的 CurrentValueRelay 则采用类似思路，并补齐了 sink、assign等 Combine 风格操作符，开箱即用。

SwiftData 与 MVVM：真的不兼容吗？ (Is SwiftData incompatible with MVVM?)[13]

严格来说，本文并非真正讨论 MVVM 模式本身，而是探讨在使用 SwiftData 时，是否可以、以及如何将数据访问逻辑（对 ModelContext 的操作）从 View 层上移至 ViewModel 层。Matteo Manferdini[14]聚焦的是 SwiftUI 与 SwiftData 的集成边界，而非架构取舍。文章通过分析 @Query宏的展开方式与 DynamicProperty 协议机制，澄清了几个常见误解，并展示了如何通过自定义属性包装器在 SwiftUI 生命周期内安全地注入 ModelContext。结果表明，这种分层不仅可行，而且能够保持代码简洁、结构清晰。

从 iOS 开发者视角看 AI 编程代理的对比 (AI Agents Comparison from iOS Developer Perspective)[15]

在 AI 辅助编程领域，同一模型在不同工具中的表现差异巨大。Tomasz Lizer[16]以一个真实的 iOS 登录 bug 为基准，用统一提示词测试了 7 款 AI 编程代理，从速度、准确性与回归风险三个维度进行评分。测试结果指出：同样基于 Claude Sonnet 4.5 的模型，在 GitHub Copilot 中表现最差，却在 Claude Code 中表现最佳；Cursor 中也同样出色。这表明，上下文管理与提示工程的实现方式，往往比底层模型更决定实际效果。从 iOS 开发者的角度看，作者认为 Claude Code 是目前最易用且结果最平衡的选择，而 Copilot 的竞争力则已明显下滑。

在 SwiftUI 中打造可交互的渐变网格 (Crafting Interactive Tiles in SwiftUI)[17]

本文展示如何在 SwiftUI 中创建一个交互式渐变网格效果：用户触摸屏幕时，靠近触摸点的瓷砖圆角会变大，随着距离增加逐渐恢复方正。Uladzislau Volchyk[18]采用逐步构建的方式，从基础网格到手势交互、渐变上色，最后用 Metal shader 添加颗粒纹理。文章大量使用了近一两个版本才出现的新 API，包括 MeshGradient、visualEffect和 colorEffect，通过简洁的代码实现了专业级的视觉表现。

很难想象，在没有这些新 API 的支持下，要在 SwiftUI 中实现类似的效果需要编写多少代码。SwiftUI 仍是一个快速演进的框架，即便开发者无法全面掌握它的所有功能，也应该持续关注每个版本新增的关键能力——这些新特性往往能让开发过程事半功倍。

为闭源 SDK 添加 dSYM 符号文件 (Adding dSYMs from a closed-source Swift SDK to an App)[19]

dSYMs（Debug Symbol Files）是将崩溃时的内存地址翻译回源代码位置的符号文件，如果闭源 SDK 缺少它们，会导致生产环境的崩溃报告无法符号化，只能看到内存地址而非具体的函数名和行号，导致几乎无法调试。Daniel Saidi[20]在本文中介绍了对应的解决方案：SDK 作者应在构建 XCFramework 时添加 DEBUG_INFORMATION_FORMAT=dwarf-with-dsym，并随发布版本提供 dSYM；App 开发者则可在归档后手动将 SDK 的 dSYM 文件放入 .xcarchive的 dSYMs 文件夹，再上传至 App Store Connect。

在后台上传图片资源 (Uploading Asset Resources in the Background)[21]

对于具备云端同步大量图片功能的应用，经常会遇到一个痛点：数据只有在应用位于前台时才能同步。从 iOS 26.1 开始，PhotoKit 新增的 PHBackgroundResourceUploadExtension协议终于解决了这一限制——即便用户切换到其他应用或锁定屏幕，系统也能在后台持续上传资源到云端。该 API 还会自动处理网络连接、电源管理与任务调度，大幅提升云同步类应用的体验与可靠性。

有些遗憾，PHBackgroundResourceUploadExtension 并不是通用的后台上传接口，而是一个受系统托管、仅能操作 PhotoKit 资源的后台上传机制（虽然上传目标可以是任意服务器）。希望未来苹果能扩展这类能力，尤其是在 SwiftData 或 Core Data 的 CloudKit 同步中提供类似机制，让数据在后台也能无缝同步。这样用户在新设备上安装应用后，就无需再“盯着前台等待同步完成”了。

并发详解：协议一致性的陷阱与新解法 (Concurrency Step-by-Step: Conforming to Protocols)[22]

为降低并发特性的学习门槛并改善开发者体验，Swift 6.2 正式引入了 Approachable Concurrency概念。该模式下包含多项新的编译选项与默认行为（如 InferIsolatedConformances、NonisolatedNonsendingByDefault 等），不同组合会直接影响类型在并发语义下的表现。开发者会发现——在不同的编译配置中，为具备隔离语义的类型添加协议一致性的方式，会因编译配置而不同。Matt Massicotte[23]在本文中聚焦于这一主题，层层拆解了 Swift 6.2 的并发模型、编译器选项与协议一致性之间的关系，并总结了多种处理“隔离一致性冲突”的策略。

文末，Matt 还提出了他推崇的 “Non-Sendable First Design” 思想——通过将类型显式标注为 nonisolated，让其实例“被困”在创建它的隔离域内，以换取更清晰的并发边界与更高的安全性。

Android 不配拥有 Swift——但我们还是做到了 (Android Doesn’t Deserve Swift—But We Did It Anyway)[24]

在 NSSpain 大会上，Pierluigi Cifani[25]以电商应用 Nuras 的移植为例，展示了 Skip 工具链如何让小团队以纯 Swift 实现跨平台开发。团队仅用数周就完成了包含蓝牙通信在内的复杂功能移植，并实现了完整 SwiftUI 组件的共享，使 Android 版本的发布速度提升了两倍。Pierluigi 坦言过程并非一帆风顺，但收益巨大。他也向社区发出呼吁：Swift 可以并且应该成为构建跨平台应用的方式。"如果我们不成功,劣质的跨平台方案将被强加给我们。"

深入理解iOS CoreText API

CoreText 是一个强大但复杂的低级文本引擎，Apple 建议开发者优先使用更高级的框架（如 Text Kit、UIKit 组件），仅在它们无法满足需求时才考虑 CoreText。由于学习曲线陡峭，很多开发者在真正需要使用时往往感到无从下手。非专业程序员Ping[27]系统地介绍了 CoreText 的概念、API 与实现路径，从 CTFramesetter（文档）到 CTFrame（段落）、CTLine（行）、CTRun（字形）的层级结构讲起，涵盖了文本计算、排版、绘制、点击检测、图文混排等常见场景，并配有大量可运行示例。文章还特别指出了容易踩坑的技术细节，如 UTF-16 编码计算、点击检测的正确方式等，适合需要深度定制富文本渲染的开发者收藏。

工具

PureSQL - 从纯 SQL 生成类型安全的代码[28]

你是否也认为“SQL 本身已经足够强大，只是缺少类型安全”？如果你曾在 Go 中使用过 sqlc，或在 Android 开发中体验过 sqldelight，那么 Wes Wickwire[29]创建的 PureSQL 将是你一直在等待的工具。PureSQL 将“从纯 SQL 生成类型安全的代码”的理念带入了 Swift 生态。

PureSQL 内置了一个强大的编译器（通过 SPM 插件或命令行工具运行），它会在编译时解析并验证你的 SQL 文件，然后自动生成一套完整的、类型安全的 Swift 数据访问代码。这意味着你可以获得几乎完整的原生 SQL 能力和精确性，同时享受现代 Swift 带来的编译时安全检查和一流的 IDE 支持。对于追求极致性能、希望掌控原生 SQL 但又不愿放弃类型安全的开发者来说，PureSQL 提供了一个很好的平衡。

往期内容

#107 去 Apple Store 修手机

#106 高通收购 Arduino：历史的轮回

#105 Sora 2：好模型，但未必是好生意

THANK YOU

如果你觉得这份周报或者我的文章对你有所帮助，欢迎 点赞、赞赏，并将其 转发给更多的朋友。

参考资料

[1]

weekly.fatbobman.com: https://weekly.fatbobman.com

[2]

肘子的 Swift 记事本: https://fatbobman.com

[3]

Discord: https://t.ly/gzxeh

[4]

Joannis Orlandos: https://x.com/JoannisOrlandos

[5]

官方介绍文章: https://l.fatbobman.com/w0108-01

[6]

Bruno Valente Pimentel: https://www.linkedin.com/in/valentebruno/

[7]

分析文章: https://l.fatbobman.com/w0108-02

[8]

移植到 Android 平台: https://github.com/OpenSwiftUIProject/OpenSwiftUI/issues?q=is%3Aissue+label%3A%22platform%3A+Android%22

[9]

用 AsyncStream 重建 Combine 的多播机制 (Replacing Combine’s subjects with AsyncStream in Swift): https://l.fatbobman.com/w0108-03

[10]

Natascha Fadeeva: https://x.com/tanaschita

[11]

AsyncBroadcastSequence: https://forums.swift.org/t/swift-async-algorithms-proposal-broadcast-previously-shared/61210?utm_source=fatbobman%20weekly%20issue%20108&utm_medium=web

[12]

AsyncCombine: https://github.com/will-lumley/AsyncCombine?utm_source=fatbobman%20weekly%20issue%20108&utm_medium=web

[13]

SwiftData 与 MVVM：真的不兼容吗？ (Is SwiftData incompatible with MVVM?): https://l.fatbobman.com/w0108-04

[14]

Matteo Manferdini: https://x.com/MatManferdini

[15]

从 iOS 开发者视角看 AI 编程代理的对比 (AI Agents Comparison from iOS Developer Perspective): https://l.fatbobman.com/w0108-05

[16]

Tomasz Lizer: https://www.linkedin.com/in/tomasz-lizer/

[17]

在 SwiftUI 中打造可交互的渐变网格 (Crafting Interactive Tiles in SwiftUI): https://l.fatbobman.com/w0108-06

[18]

Uladzislau Volchyk: https://www.linkedin.com/in/uvolchyk/

[19]

为闭源 SDK 添加 dSYM 符号文件 (Adding dSYMs from a closed-source Swift SDK to an App): https://l.fatbobman.com/w0108-07

[20]

Daniel Saidi: https://x.com/danielsaidi

[21]

在后台上传图片资源 (Uploading Asset Resources in the Background): https://l.fatbobman.com/w0108-08

[22]

并发详解：协议一致性的陷阱与新解法 (Concurrency Step-by-Step: Conforming to Protocols): https://l.fatbobman.com/w0108-09

[23]

Matt Massicotte: https://mastodon.social/@mattiem

[24]

Android 不配拥有 Swift——但我们还是做到了 (Android Doesn’t Deserve Swift—But We Did It Anyway): https://l.fatbobman.com/w0108-10

[25]

Pierluigi Cifani: https://x.com/piercifani

[26]

深入理解iOS CoreText API: https://l.fatbobman.com/w0108-11

[27]

非专业程序员Ping: https://www.zhihu.com/people/husteryp

[28]

PureSQL - 从纯 SQL 生成类型安全的代码: https://l.fatbobman.com/w0108-12

[29]

Wes Wickwire: https://x.com/WesWickwire