Swift Officially Releases Android SDK
On October 24, the Swift Android Workgroup released the nightly preview version of the Swift SDK for Android. This marks the SDK’s transition from early internal testing to official support, representing a significant step forward in Swift’s cross-platform journey.
From a technical perspective, Swift for Android employs a cross-compilation approach built on three core components: the host toolchain, the Swift SDK for Android, and Android NDK 27d. Developers can compile Swift code into Android shared libraries and achieve interoperability with Java/Kotlin through JNI. In other words, Swift code can now run natively on the Android platform.
Beyond toolchain maturity, encouraging progress has emerged at the ecosystem level. According to Joannis Orlandos in the official announcement, over 25% of packages on the Swift Package Index have already completed Android adaptation. While this proportion may not seem large, it demonstrates the community’s positive response to cross-platform development. An increasing number of developers are proactively building Android compatibility into their third-party libraries.
Of course, questions remain: among the remaining 75% of packages, how many simply haven’t been adapted yet, and how many are temporarily incompatible due to deep integration with Apple’s ecosystem (such as dependencies on UIKit, AppKit, Core Data, and similar frameworks)? This will determine the ceiling for Swift in the Android ecosystem. For logic layers, networking layers, or data model layers, adaptation is relatively straightforward; however, cross-platform challenges remain considerable for UI layers and system integration layers.
As Bruno Valente Pimentel‘s analysis reveals, the pathways for using Swift on Android have become relatively clear—whether through cross-compilation with the official SDK, transpilation from SwiftUI to Jetpack Compose via Skip.tools, or other integration approaches, developers can find entry points suited to their needs. While there’s still distance to cover before achieving an “out-of-the-box” development experience, the ecosystem’s foundational framework has taken shape, and Swift’s potential on the Android platform is no longer merely conceptual.
Notably, Marc Prud’hommeaux, founder of Skip, is also a core member of the Swift Android Workgroup. This multi-directional collaboration between official bodies, commercial forces, and the open-source community may be a key indicator of Swift’s maturing ecosystem. Meanwhile, the OpenSwiftUI project has also begun porting to the Android platform, offering an alternative open-source path for cross-platform UI development. Looking ahead, enhanced toolchains, migration services, education and training, and third-party libraries optimized for cross-platform performance all represent potential growth areas in this direction.
While the Swift Android SDK release remains in its nightly phase, it has already opened a new window for cross-platform development. For Swift developers, this represents not only new possibilities but also an invitation—to not merely witness Swift’s cross-platform growth, but to actively participate and become builders of the ecosystem.
Previous Issue｜Newsletter Archive
📢 Sponsor Fatbobman’s Swift Weekly
Promote your product to Swift & iOS developers across:
- Blog: 70,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate
Perfect for developer tools, courses, and services.
Enjoyed this issue? Buy me a coffee ☕️
Recent Recommendations
Replacing Combine’s subjects with AsyncStream in Swift
AsyncStream is inherently a one-to-one structure — when multiple for await loops consume the same stream, they compete for values instead of each receiving the full sequence. This differs fundamentally from Combine’s Subjects, which naturally broadcast to multiple subscribers. Natascha Fadeeva demonstrates how to emulate Combine-style multicasting by creating an independent AsyncStream instance for each subscriber while maintaining a unified cache of Continuations for broadcasting. This solution not only highlights the flexibility of Swift Concurrency but also reveals a deeper philosophical difference between the two asynchronous models.
The AsyncBroadcastSequence proposal in Swift Async Algorithms aims to standardize this capability with built-in features like history caching, backpressure control, and configurable lifecycle management. Meanwhile, AsyncCombine’s CurrentValueRelay takes a similar approach, restoring familiar APIs such as
sink,assign, andstore(in:)— ready to use out of the box.
Is SwiftData incompatible with MVVM?
Strictly speaking, this article isn’t about MVVM itself — it explores whether, and how, SwiftData operations (those involving ModelContext) can be moved from the View layer to the ViewModel layer. Matteo Manferdini focuses on the integration boundary between SwiftUI and SwiftData rather than architectural dogma. By dissecting how the @Query macro expands and how it interacts with the DynamicProperty protocol, the article clarifies several common misconceptions and demonstrates how to inject ModelContext safely into the SwiftUI lifecycle using a custom property wrapper. The takeaway: this separation is not only possible but also keeps the codebase cleaner and more maintainable.
AI Agents Comparison from an iOS Developer’s Perspective
In AI-assisted programming, the same model can perform drastically differently across tools. Tomasz Lizer benchmarked seven AI coding agents against a real iOS login bug, using identical prompts to compare speed, accuracy, and regression risk. The results were surprising: even with the same underlying model (Claude Sonnet 4.5), GitHub Copilot performed worst, while Claude Code and Cursor produced the best results.
This shows that context management and prompt engineering implementations often matter more than the foundation model itself. From an iOS developer’s viewpoint, the author concludes that Claude Code currently offers the most balanced and reliable experience — while Copilot’s competitive edge has noticeably faded.
Crafting Interactive Tiles in SwiftUI
This tutorial demonstrates how to build an interactive gradient tile grid in SwiftUI — as users touch the screen, nearby tiles round their corners dynamically while distant ones remain square. Uladzislau Volchyk constructs the effect step by step: from the basic grid to gesture handling, gradient coloring, and finally adding a subtle grain texture using a Metal shader. The project makes heavy use of recently introduced APIs like MeshGradient, visualEffect, and colorEffect, achieving professional-grade visuals with minimal code.
It’s hard to imagine how much boilerplate would be needed to reproduce the same effect without these new APIs. SwiftUI continues to evolve rapidly — even if developers can’t master every new feature, staying up to date with each release’s key additions can dramatically boost productivity.
Adding dSYMs from a Closed-Source Swift SDK to an App
dSYMs (Debug Symbol Files) serve as a “translation guide” that maps compiled machine code back to source symbols. Closed-source SDKs often omit them, making production crash reports impossible to symbolize — you see memory addresses instead of readable function names and line numbers. Daniel Saidi outlines a practical fix: SDK authors should build their XCFrameworks with DEBUG_INFORMATION_FORMAT=dwarf-with-dsym and distribute the dSYM alongside each release. App developers can then manually place the SDK’s dSYM into the .xcarchive/dSYMs folder before uploading to App Store Connect.
Uploading Asset Resources in the Background
Apps that sync large photo libraries to the cloud often share the same pain point: uploads only work while the app stays in the foreground. Starting with iOS 26.1, PhotoKit introduces the PHBackgroundResourceUploadExtension protocol, which finally lifts this limitation — allowing the system to continue uploading assets in the background, even when users switch apps or lock their devices. The API also manages network connectivity, power usage, and scheduling automatically, greatly improving reliability and user experience.
Unfortunately,
PHBackgroundResourceUploadExtensionisn’t a general-purpose background upload interface — it’s a system-managed mechanism restricted to PhotoKit resources (though targets can be any server). Hopefully, Apple will extend similar capabilities to SwiftData or Core Data’s CloudKit syncing, enabling seamless background data synchronization. That would finally free users from having to “keep the app open and wait for sync to finish” on new devices.
Concurrency Step-by-Step: Conforming to Protocols
With Swift 6.2, Apple introduces the Approachable Concurrency model — a collection of compiler options and default behaviors such as InferIsolatedConformances and NonisolatedNonsendingByDefault. Different configurations directly affect how isolation semantics apply to protocol conformances. In this deep dive, Matt Massicotte dissects how these options influence concurrency behavior and walks through various ways to resolve “isolation mismatch” issues when adding protocol conformances to actor-isolated types.
He also introduces his preferred approach, Non-Sendable First Design — explicitly marking types as nonisolated to ensure their instances remain “trapped” within the isolation domain where they were created, leading to clearer concurrency boundaries and safer designs.
Android Doesn’t Deserve Swift — But We Did It Anyway
At NSSpain, Pierluigi Cifani shared how his small team used the Skip toolchain to bring pure Swift development to Android. Using their e-commerce app Nuras as a case study, they managed to port complex features — including Bluetooth communication — within weeks, while sharing complete SwiftUI components across platforms. The result: their Android release velocity doubled.
Pierluigi admitted the process was tough but ultimately transformative. He closed with a call to the community: “Swift can — and should — be the way we build cross-platform apps. If we don’t succeed, inferior cross-platform solutions will be forced upon us.”
Tools
PureSQL – Type-Safe Code Generation from Pure SQL
If you believe that “SQL is already powerful enough — it just lacks type safety”, Wes Wickwire’s PureSQL is the tool you’ve been waiting for. Inspired by tools like sqlc (Go) and sqldelight (Android), PureSQL brings “type-safe code generation from raw SQL” to the Swift ecosystem.
Built around a dedicated compiler (available as an SPM plugin or CLI tool), PureSQL parses and validates your SQL files at compile time, automatically generating type-safe Swift data-access code. You get the precision and performance of native SQL with the compile-time safety and IDE support of modern Swift. For developers seeking full control over SQL without sacrificing type safety, PureSQL strikes an elegant balance.
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 在官方介绍文章中的说明，目前 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 的跨平台成长，更参与其中，成为生态的建设者。
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 爱发电，Buy Me a Coffee 支持我的创作。
近期推荐
用 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 提供了一个很好的平衡。