Swift 官方发布 Android SDK

📮 想持续关注 Swift 技术前沿？

每周一期《肘子的 Swift 周报》，为你精选本周最值得关注的 Swift、SwiftUI 技术文章、开源项目和社区动态。

📬 在 weekly.fatbobman.com 免费订阅

💬 加入 Discord 与中文 Swift 开发者深入交流

📚 访问 fatbobman.com 查看数百篇深度原创教程

一起构建更好的 Swift 应用！🚀

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 在官方介绍文章中的说明，目前 Swift Package Index 上已有超过 25% 的开源包完成了 Android 适配。这个比例虽然还不算大，但已足以显示社区对跨平台开发的积极响应。越来越多的开发者在构建第三方库时，已经开始为 Android 的兼容性预留空间。

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

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

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

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

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

近期推荐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

深入理解iOS CoreText API

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

工具

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

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

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

往期内容

THANK YOU

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

📮 想持续关注 Swift 技术前沿？

每周一期《肘子的 Swift 周报》，为你精选本周最值得关注的 Swift、SwiftUI 技术文章、开源项目和社区动态。

📬 在 weekly.fatbobman.com 免费订阅

💬 加入 Discord 与中文 Swift 开发者深入交流

📚 访问 fatbobman.com 查看数百篇深度原创教程

一起构建更好的 Swift 应用！🚀

《Swift 官方发布 Android SDK | 肘子的 Swift 周报 #0108》是转载文章，点击查看原文。