First Impressions of WWDC 2026: In Line with Expectations, but More Pragmatic

Read on web →

Like many developers, I cared more this year about improvements in stability and efficiency, and I also deliberately lowered my expectations for “surprising new features.” With that mindset, after quickly going through several topics from the first day of WWDC 2026 that I personally care about, my initial impression of this year’s event is: it was in line with expectations, and quite pragmatic.

AI

Although Foundation Models was introduced last year, the capabilities it offered at the time were still not compelling enough for many developers. This year’s changes are clearly more practical: the APIs have been further integrated; image input is now supported; developers can choose between on-device models, Private Cloud Compute, or third-party server models depending on the task; and eligible developers can use Apple Foundation Models running on Private Cloud Compute for free. At the same time, the system is also gaining stronger view awareness, better understanding of app context, and the ability to bring users back into apps through App Intents.

These improvements significantly increase the practicality and appeal of Foundation Models. It is no longer merely a framework that is “worth trying”; it is beginning to have the foundation needed to enter real product workflows. Unsurprisingly, more developers will likely be willing to experiment with this system this year and gradually incorporate it as one of the core capabilities of their apps.

SwiftUI

For me, the biggest change in SwiftUI comes from its comprehensive support for document-based apps. It not only adds a large number of new APIs, but also shifts the mental model toward “observable document objects + asynchronous snapshots + dedicated readers / writers.” This is clearly better suited to complex document apps, and it also aligns more closely with the overall evolution of modern Swift around Observation and Concurrency.

The sessions also mentioned that SwiftUI continues to optimize layout- and container-related implementations, bringing noticeable performance improvements in some scenarios. This is an improvement developers have urgently needed. However, SwiftUI still does not provide the ability to create custom Lazy containers, which remains a clear disappointment. reorderable and swipeActions are no longer limited to specific containers. This is not merely an expansion of their applicable scope; it also reflects further integration of the underlying interaction logic. Perhaps the benefits of this integration will become more apparent in next year’s APIs.

@State now supports lazy initialization, text selection on iOS has been enhanced, and alert / confirmationDialog now provide Binding<T?> support. These are all welcome improvements, though they do feel like they arrived a little late. AnyNavigationTransition appears in the interface, but there is still no public support for custom transitions. For now, developers can only choose between the system-provided zoom and crossFade transitions.

The new DataDetection framework gives Text better content recognition capabilities; toolbars also gain more control. These changes also show Apple’s continued emphasis on using SwiftUI to build macOS apps. Overall, SwiftUI this year does not rely on a single standout API to create surprise. Instead, through a set of additions and integrations, it moves closer to the everyday needs of complex apps.

SwiftData

Compared with @Query gaining support for section fetches, and ResultsObserver enabling observation of query result changes outside views, I am more interested in @Attribute(.codable). It provides a clearer storage intent and gives developers a way to avoid falling into the black box of composition.

Of course, @Attribute(.codable) is not a silver bullet. It is more like a clearly defined escape hatch SwiftData provides for opaque Codable types: suitable for storing external types that you cannot model yourself, but still genuinely need to persist. The cost is that this content cannot participate in SwiftData’s predicate, sort, or migration awareness. Precisely for this reason, its value lies not in being “more powerful,” but in being “more explicit.”

However, SwiftData still does not provide cloud syncing for public / shared data, nor have I seen a clearer signal of performance improvements. These issues will continue to limit its adoption. For many developers, SwiftData this year feels more like it is filling key gaps rather than making a leap significant enough to fundamentally change confidence in it.

Xcode

Over the past six months, my development workflow has basically been Codex App / Claude App + Xcode, with Xcode appearing significantly less often than the former two. After briefly trying Xcode 27, I expect Xcode’s presence in my workflow to increase noticeably. I am especially looking forward to the changes Xcode’s built-in AI workflows may bring in areas such as fine-tuning UI, improving performance, and validating previews.

Device Hub is undoubtedly a major surprise. It integrates simulators, physical device management, system state testing, and dynamic size adjustment into a new workflow. Its impact on day-to-day development experience may be more direct than that of many individual APIs. That said, iPhone apps now also support dynamic size adjustment, which will bring new challenges for developers, especially in terms of data and state organization. Adapting to different sizes is not something that can be solved merely by relying on dynamic layout containers. In many scenarios, large and small sizes correspond to very different navigation logic.

This year, I probably won’t rush to write articles about the new SwiftUI and SwiftData APIs. Instead of introducing new interfaces one by one, I would rather spend some time systematically digesting these changes and sorting out the implicit logic behind them: how Apple is reorganizing the relationship between SwiftUI, SwiftData, Foundation Models, and Xcode’s AI workflow — and how these changes will ultimately affect the way we build apps.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Original

Core Data + Observation: From Property-Level Reactivity to a Freer Mental Model

The introduction of the Observation framework refined SwiftUI’s state-driven updates from object-level observation to property-level observation, significantly reducing many unnecessary refreshes caused by coarse-grained observation. More importantly, it makes the declarative logic of state management feel natural again: a view only needs to read the properties it truly depends on, and the framework can establish the corresponding reactive relationships from there. To bring the conveniences of modern Swift features to Core Data, a long-standing persistence framework, I recently explored and implemented Observation support in Core Data Evolution (CDE), giving NSManagedObject precise property-level observation capabilities. This article discusses the motivation behind this feature, how to use it, the implementation approach, engineering challenges, and some of the trade-offs made during development.

Recent Recommendations

Bringing Goodnotes to the Web with Swift and WebAssembly

As a well-known note-taking app in the Apple ecosystem, Goodnotes did not choose to completely rewrite its product when moving to the Web. Instead, it brought years of accumulated Swift code into the browser environment through WebAssembly. In this article, Yuta Saito explains how Goodnotes maintains the same ink rendering, document synchronization, CRDT-based conflict resolution, search indexing, and interaction experience on the Web as in the native app. The Swift codebase for Goodnotes Web is about 2.2 million lines of code, of which 1.47 million lines are shared code; the final generated WebAssembly binary is about 50 MB, compressed to around 12 MB with Brotli. The significance of this article is not merely that it shows Swift can run on the Web, but that it presents how a real, large-scale Swift application can use WebAssembly to extend core capabilities originally deeply rooted in Apple platforms to more platforms.

Yuta’s iOS Conf 2026 talk, Swift at Scale: Where Performance Really Comes From, is also worth watching. Compared with the official article’s overview of the overall Goodnotes Web architecture, this talk focuses more on a real Swift performance case: the Goodnotes team found that an Update value type used to aggregate partial UI updates had grown to about 6 KB as features accumulated, and it contained many non-trivial members. Even though most updates only used one or two fields, the hot path still paid the cost of copying and reference counting. The team eventually refactored the data structure through a hot-cold split, keeping frequently accessed fields in the main struct while moving infrequent updates into separate storage. This reduced the type size from about 6 KB to around 300 bytes and brought about a 42% improvement in CPU time.

Announcing the Networking Workgroup

Swift’s networking APIs are not lacking in choices; rather, there are too many choices with overlapping responsibilities. From URLSession and Network.framework on Apple platforms, to SwiftNIO and AsyncHTTPClient in the server-side ecosystem, and further down to lower-level HTTP representation types, developers often have to deal with inconsistent models and migration costs across different platforms and abstraction layers. More importantly, many of these APIs appeared before modern Swift capabilities such as async/await, structured concurrency, actors, and Sendable had matured, making it difficult for them to naturally reflect Swift’s current strengths in concurrency, safety, and cross-platform development. These issues are discussed more systematically in A Vision for Networking in Swift, while the Swift HTTP API Proposal can be seen as an early exploration in this direction.

The official establishment of the Networking Workgroup sends an important signal: the Swift ecosystem is beginning to treat networking as cross-platform infrastructure that requires long-term governance, rather than simply allowing individual frameworks and packages to evolve independently within their own domains. The goal of the workgroup is not to simply replace existing solutions, but to promote clearer layering, more consistent types, better interoperability, and stronger observability, so that Swift can have a more unified, modern, and sustainable networking foundation across Apple platforms, server-side development, CLI tools, WebAssembly, Android, Windows, and even Embedded Swift.

WWDC 2026 Wish Lists

Michael Tsai collected wish lists from several Apple developers ahead of WWDC 2026. Similar to the expectations I shared in the previous issue of the weekly newsletter, most developers are calling for a Snow Leopard-style quality-focused release: rethinking the usability of Liquid Glass on the Mac, reducing instability at the system and framework levels, and fixing long-standing issues that affect daily development, such as iCloud sync, Spotlight, System Settings, error messages, SwiftUI, Xcode, Simulator, indexing, and previews. Many developers also hope that this year will not introduce another wave of “busywork” caused by adapting to new designs, new frameworks, or new review requirements, but instead give the existing platforms more time for refinement.

Another clear theme is how Apple’s developer tools should evolve in the age of AI agents. Several authors mention that they hope Apple will provide more official Agent Skills, MCP support, CLI tools, and automation interfaces, allowing AI to more reliably read documentation, operate Xcode, manage App Store Connect, modify project settings, run builds, control Simulator, and even understand UI hierarchies in a more structured way, rather than relying on screenshots or fragile Accessibility information.

Adapting to the AI era and improving system stability are indeed becoming shared expectations among more Apple developers. By the time you read this issue, WWDC 2026 has already begun. After reading these wish lists and then watching this year’s announcements, I wonder whether everyone has found the answers they were hoping for.

Apple-like

Around WWDC 2026, discussions about Apple’s future direction have become noticeably more frequent. Many people expect Apple to “return to its roots” or rediscover its former state, but in this article, David Smith chooses a more constructive question: what does it mean to be Apple-like? As a long-time Apple platform developer, he summarizes this quality into several directions: The Best, and then Better; Excellence for Everyone; and Beneficial and Brilliant. In other words, continuously pursuing high quality, and not spending down user expectations even after getting ahead; making excellent experiences available to as many people as possible through pricing, accessibility, and design; and avoiding manipulative ways of chasing short-term metrics, instead solving users’ problems in ways that are genuinely beneficial and delightful.

When we expect Apple to improve system stability, developer tools, and platform experience, this article also reminds us that independent developers and app teams can examine their own products through similar standards.

Tools

MarkdownPDF: A Markdown-to-PDF Engine Written Entirely in Swift

MarkdownPDF is an open-source Markdown-to-PDF engine written entirely in Swift by Mihaela Mihaljević. It does not depend on platform or system capabilities such as PDFKit, CoreGraphics, WebKit, Chromium, LaTeX, or C-based PDF/Markdown libraries. Markdown parsing, layout, and PDF serialization are all implemented in Swift. Precisely because its core is pure and its dependencies are restrained, the project has strong cross-platform potential. It can target WebAssembly/WASI and generate PDFs from Markdown locally in the browser. The Playground provided by the author demonstrates this capability.

Goodnotes shows the engineering practice of migrating a large Swift application to the Web, while MarkdownPDF offers another perspective: when the core logic is pure enough and the dependencies are restrained enough, Swift tools themselves can also adapt naturally to the WebAssembly runtime environment. Swift’s move toward the Web is evolving from a proof of concept into an increasingly concrete engineering choice.

AdaEngine: A Swift-first Open Source Game Engine

AdaEngine is an open-source Swift-first game engine and application framework created by Vladislav Prusakov, which recently released its first public milestone, 0.1.0. The project is designed for cross-platform development. Apple platforms are currently the most mature, while support for Windows, Linux, Android, and WebAssembly/WebGPU is also being developed.

With a data-driven ECS at its core, AdaEngine combines Swift macros, a plugin-based architecture, SwiftUI-like AdaUI, asset hot reloading, a scene system, 2D physics, audio, input, and Metal / WebGPU rendering backends. It aims to let Swift serve not only Apple platform app development, but also games, interactive tools, and creative software.

Vladislav gives a more complete introduction to the project in Introducing AdaEngine 0.1.0.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

WWDC 2026 初印象：符合预期，但更务实

网页版

和很多开发者一样，我今年更看重稳定性与效率方面的改善，也主动降低了对“惊喜型新功能”的期待。带着这样的预期，快速浏览了 WWDC 2026 第一天中几个我比较关心的主题后，本届活动给我的初步印象是：符合预期，而且相当务实。

AI

尽管 Foundation Models 在去年已经推出，但当时提供的能力，对很多开发者来说仍不足以构成足够强的吸引力。今年的变化则明显更务实：API 进一步整合，支持图像输入，可以根据任务选择设备端模型、私有云计算或第三方服务器模型；满足条件的开发者还可以免费使用运行在私有云计算上的 Apple 基础模型。与此同时，系统也开始具备更强的视图感知、App 上下文理解，以及通过 App Intents 将用户重新带回应用的能力。

这些改进大幅提升了 Foundation Models 的实用性和吸引力。它不再只是一个“可以试试”的框架，而是开始具备进入真实产品流程的基础。不出意外，今年会有更多开发者愿意尝试这套系统，并逐步将其纳入应用的核心能力之一。

SwiftUI

对我来说，SwiftUI 最大的变化来自对文档类应用的全面支持。它不仅增加了大量新 API，也将心智模型调整为“可观察文档对象 + 异步快照 + 专用 reader / writer”。这显然更适合复杂文档 App，也更符合现代 Swift 在 Observation 和 Concurrency 方向上的整体演进。

Session 中也提到，SwiftUI 在布局与容器相关实现上继续优化，部分场景下的性能会有明显提升。这是开发者迫切需要的改进。不过，SwiftUI 仍未提供自定义 Lazy 容器的能力，这无疑是一个遗憾。reorderable 和 swipeActions 不再局限于特定容器，这不只是适用范围的扩大，也体现了底层交互逻辑的进一步整合。或许这些整合带来的收益，会在明年的 API 中呈现得更加明显。

@State 支持惰性初始化，iOS 上的 text selection 得到增强，alert / confirmationDialog 提供了 Binding<T?> 支持，这些都很好，只是感觉来得稍晚了一些。interface 中出现了 AnyNavigationTransition，但目前仍没有开放自定义 transition 的能力，只能在系统预设的 zoom 和 crossFade 中切换。

新的 DataDetection 框架为 Text 提供了更好的内容识别能力；toolbar 获得了更多控制力，也能看出 Apple 对使用 SwiftUI 开发 macOS 应用的重视。整体来看，今年的 SwiftUI 并不是靠某个单点 API 带来惊喜，而是通过一组补齐和整合，让它更接近复杂 App 的日常需求。

SwiftData

相较于 @Query 支持 section fetch，以及 ResultsObserver 提供视图外观察查询结果变化的能力，我更看重 @Attribute(.codable)。它提供了更明确的存储意图，也给了开发者一个避免陷入 composition 黑盒的渠道。

当然，@Attribute(.codable) 并不是银弹。它更像是 SwiftData 为不透明 Codable 类型提供的明确出口：适合存储你无法建模、但又确实需要持久化的外部类型；代价则是这部分内容无法参与 SwiftData 的 predicate、sort 和 migration 感知。正因如此，它的价值不在于“更强”，而在于“更明确”。

不过，SwiftData 仍没有提供 public / shared 数据的云端同步能力，也没有看到更明确的性能改善信号。这些问题仍会限制它的采纳率。对许多开发者来说，SwiftData 今年更像是在补齐关键缺口，而不是完成一次足以改变信心的跃迁。

Xcode

过去半年中，我的开发模式基本是 Codex App / Claude App + Xcode，其中 Xcode 的出场时间明显少于前两者。在简单使用 Xcode 27 后，我预计接下来它的出场时间会明显增加。我尤其期待在 UI 精细调整、性能改善、预览验证等方面，Xcode 内置 AI 流程能带来的变化。

Device Hub 无疑是一个巨大惊喜。它将模拟器、实体设备管理、系统状态测试和动态尺寸调整整合到一个新的工作流中，这对日常开发体验的影响可能比很多单个 API 更直接。不过，iPhone 应用也开始支持动态尺寸调整，这会给开发者带来新的挑战，尤其是在数据和状态组织层面。针对不同尺寸的适配，并不是只靠动态布局容器就能解决的。很多场景下，大尺寸和小尺寸对应的导航逻辑会有很大差异。

今年我应该不会第一时间围绕 SwiftUI、SwiftData 的新 API 写文章。相比逐条介绍新增接口，我更想花一些时间系统消化这些变化，梳理它们背后的隐含逻辑：Apple 正在怎样重新组织 SwiftUI、SwiftData、Foundation Models 与 Xcode AI 工作流之间的关系，以及这些变化最终会如何影响我们构建 App 的方式。

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

原创

Core Data + Observation：从属性级响应到心智解放

Observation 框架的推出，让 SwiftUI 的状态响应从对象级进一步细化到属性级，显著缓解了许多由粗粒度观察带来的无效刷新问题。更重要的是，它让状态管理的声明式逻辑重新变得自然：视图只需要读取自己真正依赖的属性，框架便能据此建立响应关系。为了让 Core Data 这个老牌持久化框架也能享受到现代 Swift 特性的便利，我近期在 Core Data Evolution（CDE）中探索并实现了对 Observation 的支持，赋予 NSManagedObject 属性级的精确观察能力。本文将围绕这一能力的动因、使用方式、实现思路、工程挑战以及开发过程中的一些取舍展开讨论。

近期推荐

用 Swift 和 WebAssembly 把 Goodnotes 带到 Web (Bringing Goodnotes to the web with Swift and WebAssembly)

作为苹果生态中著名的笔记应用，Goodnotes 在走向 Web 平台时，并没有选择完全重写，而是把多年积累的 Swift 代码通过 WebAssembly 带到浏览器环境里。Yuta Saito 在本文中介绍了 Goodnotes 如何在 Web 端保持与原生 App 一致的墨迹渲染、文档同步、CRDT 冲突处理、搜索索引与交互体验。Goodnotes Web 的 Swift 代码规模约 220 万行，其中 147 万行是共享代码；最终生成的 WebAssembly 二进制约 50 MB，经 Brotli 压缩后约 12 MB。这篇文章的意义不只是展示 Swift 可以运行在 Web 上，而是呈现了一个真实的大型 Swift 应用如何借助 WebAssembly，把原本深植于苹果平台的核心能力延展到更多平台。

Yuta 在 iOS Conf 2026 的演讲 Swift at Scale: Where Performance Really Comes From 也很值得观看。相比官方文章对 Goodnotes Web 整体架构的介绍，这场演讲更聚焦一个真实的 Swift 性能案例：Goodnotes 团队发现，一个用于聚合 UI 局部更新的 Update 值类型随着功能增长膨胀到约 6 KB，并包含大量 non-trivial 成员。即使大多数更新只使用一两个字段，热路径中仍要为复制和引用计数成本付费。团队最终通过 hot-cold split 重构数据结构，将高频字段保留在主结构体中，把低频更新移入单独存储，使类型大小从约 6 KB 降到约 300 bytes，并带来约 42% 的 CPU 时间改善。

Swift 官方成立网络工作组 (Announcing the Networking Workgroup)

Swift 现在的网络 API 并不是缺少选择，而是选择过多且存在重叠：从 Apple 平台上的 URLSession、Network.framework，到服务端生态中的 SwiftNIO、AsyncHTTPClient，再到更底层的 HTTP 表示类型，开发者在不同平台、不同抽象层之间往往需要面对不一致的模型和迁移成本。更重要的是，很多 API 出现于 async/await、structured concurrency、actors、Sendable 等现代 Swift 能力成熟之前，因此很难自然地体现今天 Swift 在并发、安全性和跨平台方面的语言优势。这些问题在 A Vision for Networking in Swift 中有更系统的阐述，而 Swift HTTP API Proposal 则可以看作是对这一方向的早期探索。

本次 Swift 官方成立 Networking Workgroup，释放了一个很重要的信号：Swift 生态开始把网络能力作为一项需要长期治理的跨平台基础设施来推进，而不只是让各个框架和包在各自场景中独立演进。工作组的目标不是简单替代现有方案，而是推动更清晰的分层、更一致的类型、更好的互操作性和可观测性，让 Swift 在 Apple 平台、服务端、CLI、WebAssembly、Android、Windows 乃至 Embedded Swift 等场景中，都能拥有更统一、现代且可持续的网络基础设施。

WWDC 26 愿望单汇总 (WWDC 2026 Wish Lists)

Michael Tsai 汇总了多位 Apple 开发者在 WWDC 2026 前的愿望清单。和我在 上一期周报 中的期许类似，大多开发者在呼吁一次偏向 Snow Leopard 式的质量修复：重新审视 Liquid Glass 在 Mac 上的可用性，减少系统和框架层面的不稳定，修复 iCloud 同步、Spotlight、系统设置、错误提示、SwiftUI、Xcode、Simulator、索引和预览等长期影响日常开发体验的问题。也有不少开发者希望今年不要再引入大量为了适配新设计、新框架或新审核要求而产生的“忙碌工作”，而是给现有平台更多打磨时间。

另一个明显主题是 AI Agent 时代下的 Apple 开发工具应该如何演进。多位作者都提到，希望 Apple 提供更官方的 Agent Skills、MCP、CLI 和可自动化接口，让 AI 能更可靠地读取文档、操作 Xcode、管理 App Store Connect、修改项目配置、运行构建、控制 Simulator，甚至以更结构化的方式理解 UI 层级，而不是依赖截图或脆弱的 Accessibility 信息。

与 AI 时代的适配和系统稳定性，确实正在成为更多 Apple 开发者的共同期待。看到本期周报时，WWDC 2026 已经开幕，不知道读完这些愿望再看今年的发布会，大家是否找到了心中期待的答案。

Apple-like

在 WWDC 2026 前后，围绕 Apple 未来方向的讨论明显增多。很多人期待 Apple “回到根本”或重新找回过去的状态，但 David Smith 在这篇文章中选择了一个更有建设性的问题：什么才是 Apple-like？作为一名长期的 Apple 平台开发者，他将这种气质总结为几个方向：The Best, and then Better，Excellence for Everyone，以及 Beneficial and Brilliant。也就是持续追求高质量，即使已经领先也不能消耗用户期待；在价格、可访问性和设计上让优秀体验尽可能服务更多人；并且避免用操纵性的方式追逐短期指标，而是用真正有益、令人惊喜的方式解决用户的问题。

当我们期待 Apple 改善系统稳定性、开发工具和平台体验时，这篇文章也提醒我们，独立开发者和应用团队同样可以用类似的标准审视自己的产品。

工具

MarkdownPDF：纯 Swift 编写的 Markdown 转 PDF 引擎

MarkdownPDF 是 Mihaela Mihaljević 开源的纯 Swift Markdown 转 PDF 引擎。它不依赖 PDFKit、CoreGraphics、WebKit、Chromium、LaTeX、C PDF/Markdown 库等平台或系统能力，Markdown 解析、排版与 PDF 序列化都在 Swift 内完成。正因为核心足够纯净、依赖足够克制，项目具备良好的跨平台潜力，可以适配到 WebAssembly/WASI 运行目标，并在浏览器本地完成 Markdown 到 PDF 的生成。作者提供的 Playground 正是这一能力的演示。

Goodnotes 展示的是大型 Swift 应用迁移到 Web 的工程实践，MarkdownPDF 则提供了另一个角度：当核心逻辑足够纯净、依赖足够克制时，Swift 工具本身也可以自然适配到 WebAssembly 运行环境。Swift 走向 Web，正在从概念验证变成越来越具体的工程选择。

AdaEngine：Swift-first 开源游戏引擎

AdaEngine 是 Vladislav Prusakov 推出的开源 Swift-first 游戏引擎与应用框架，近期发布了第一个公开里程碑 0.1.0。项目面向跨平台而设计，目前 Apple 平台最成熟，并正在推进 Windows、Linux、Android 与 WebAssembly/WebGPU 等平台支持。

它以 data-driven ECS 为核心，结合 Swift 宏、插件化架构、类 SwiftUI 的 AdaUI、资产热重载、场景系统、2D 物理、音频、输入，以及 Metal / WebGPU 渲染后端等能力，试图让 Swift 不只服务于 Apple 平台应用，也能进入游戏、互动工具与创意软件开发场景。

Vladislav 在 Introducing AdaEngine 0.1.0 一文中对项目做了更完整的介绍。

Stability > New Features

Read on web →

Whether it is SwiftUI or SwiftData, these foundational frameworks, into which Apple poured so much hope, promised a bright future when they were first introduced. However, their actual trajectory seems to have diverged from the original blueprint. The deeper I dive into these frameworks, the more I marvel at their elegant architectural design—yet I also find myself speechless at their underwhelming implementation. Watching the halo around these designs gradually fade, I cannot help but feel a sense of wistfulness.

Rumor has it that in the upcoming operating systems to be released this year (including iOS 27 and macOS 27), Apple will adopt a refinement strategy similar to the Mac OS X Snow Leopard era. This means prioritizing system stability, performance optimization, clearing legacy code, and squashing bugs over introducing disruptive visual redesigns or a flurry of new low-level features. If this indeed turns out to be the case, it would be deeply reassuring. Looking back at Issue #006 of the weekly newsletter published more than two years ago, rumors also circulated back then that Apple would focus on fixing existing defects and improving performance. Yet, judging by the actual user experience over the past two years, that goal seems to have fallen short.

With WWDC 26 less than ten days away, rather than more flashy new features, what I look forward to most this year is Apple delivering a grounded, more stable experience for both developers and consumers.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Original

Taming Row Height and Spacing Jumps in SwiftUI List with a Custom Layout

In SwiftUI, adding animation to view state changes often takes very little code, but List does not always produce the kind of smooth transition we expect. This is especially noticeable when the height of content inside a row changes dynamically—for example, when a subtitle goes from empty to non-empty, or when updated text changes its line count. In these cases, the system’s default layout process can easily cause the row height to jump abruptly, leading to visible flickering, clipping, or sudden spacing changes. Starting from this common issue, this article gradually breaks down why dynamic row-height animations fail in List, and builds a solution entirely based on native SwiftUI capabilities through custom Layout, Animatable, LayoutValueKey, and state decoupling.

This is not an article primarily aimed at providing a ready-to-use component. Rather than focusing only on the final code, I hope to use this problem to outline a way of investigating SwiftUI layout issues: first understand why the framework “does not behave as expected,” then reorganize state, measurement, and layout along the grain of its mechanisms, so that the animation happens at the correct level.

Recent Recommendations

Stateless Actors

Actors are usually understood as tools for protecting mutable state, so an actor with no stored properties—a seemingly stateless actor—naturally raises the question: does it have any reason to exist? This article explores that question through examples such as NetworkClient, custom global actors, custom executors, and file-system access. It shows that stateless actors are not necessarily unreasonable, but they may introduce extra costs such as serialization, protocol-adaptation difficulties, and type-system propagation. The key question is what problem they are actually solving.

The most important point in the article is the “first rule of actors” proposed by Matt Massicotte: just like with any synchronization primitive, before using an actor, you should be able to clearly explain why it is necessary. A stateless actor is not necessarily wrong, but it may indicate that we are using an actor to solve a problem that does not actually require one. Only when it clearly takes on responsibilities such as isolation, serialization, executor adaptation, or protection of external state does it become a reasonable design.

Building a Custom Data Store in SwiftData

Many developers tend to think of SwiftData as Apple’s high-level wrapper around SQLite, but that underestimates its potential as a framework for object-graph management and persistence coordination. Whether we are talking about SwiftData or Core Data, their more important capability is not merely reading and writing a database for us, but keeping model objects, queries, context management, and the underlying storage clearly separated. As long as the underlying storage can exchange data in the way the framework expects, the data source does not have to be SQLite.

Mohammad Azam demonstrates this by implementing a JSON-file-based custom data store. The article shows that what SwiftData exchanges with the underlying store is not the live object marked with @Model, but a converted snapshot. Once you understand this, the responsibility boundaries of DataStoreConfiguration, DataStore, DefaultSnapshot, PersistentIdentifier, and fetch / save become much clearer: SwiftData is responsible for model objects, observation, change tracking, and SwiftUI integration, while the custom store is only responsible for reading and writing snapshots.

In Weekly Issue #127, I recommended DataStoreKit, a more engineering-oriented custom DataStore project. It does not simply replace SwiftData’s backend with JSON or file storage; instead, it attempts to reimplement a SwiftData-aware SQLite storage layer based on custom DataStore, with extensive work around predicate translation, inheritance, caching, persistent history, and background prefetching. Developers who want to explore this direction further can use it as an advanced reference.

Task Names in Swift Concurrency

GCD has queue labels, but tasks in Swift Concurrency long lacked a similar diagnostic identifier. With SE-0469 implemented in Swift 6.2, APIs such as Task, Task.detached, and task group addTask now support a name parameter. Developers can assign short, readable names to concurrent tasks, making it easier to locate specific execution units in LLDB, Instruments, and logs.

Artem Novichkov walks through the usage and limitations of task names, and reminds developers that a task name should be treated as diagnostic information, not as part of program logic. It is useful for debugging, performance analysis, and log investigation, but it should not carry business state.

UniqueBox, Ref, and MutableRef in Swift 6.4

Swift 6.4 continues the language’s evolution around ownership, borrow, noncopyable types, lifetime dependency, Span, and MutableSpan. Through the three types UniqueBox, Ref, and MutableRef, Artem Mirzabekian introduces Swift’s new expressive capabilities around storage location, ownership, and access lifetime. Their significance is not that ordinary business code should immediately start using these low-level building blocks, but that Swift is gradually elevating relationships that previously depended on class boxes, UnsafePointer, or compiler-internal reasoning into language models that can be written into API shapes and checked by the type system.

Specifically, UniqueBox expresses that “a value lives on the heap and is owned by a single owner,” while Ref and MutableRef correspond to shared reading and exclusive mutation within a given lifetime. In other words, these types do not merely add a convenient API for a specific business scenario; they provide a more precise low-level vocabulary for describing “where a value lives, who owns it, and who can access it.”

Clarification on Current CloudKit CKAsset File Size Limits

There has long been a confusing claim in the community around the file-size limit of CKAsset: some documentation has mentioned a 50 MB limit, but that mostly applies to CloudKit Web Services rather than CKAsset uploads through the native CloudKit framework on Apple platforms. This time, an Apple Frameworks Engineer gave a very clear answer on the developer forums: a single CKAsset supports up to 50 GB, assuming the user has enough remaining iCloud storage. Apps therefore need to correctly handle CKError.quotaExceeded.

I am introducing this Q&A in the weekly not just because it clarifies a number, but because it draws an important boundary: the fact that CKAsset supports large files does not mean large-file syncing is a simple or automatically reliable engineering problem. The follow-up discussion also mentions that large file transfers often need to consider background execution when an app is suspended or terminated, and can use long-lived CloudKit operations or schedule uploads through BGProcessingTask in BackgroundTasks. In other words, 50 GB answers the question “does CloudKit allow it?”; background transfer, failure recovery, quota handling, and user experience still need to be designed carefully by the app.

Providing Useful Debugging Information for Agents

As AI agents become increasingly involved in compiling, testing, and diagnosing Swift projects, a very practical problem has become more prominent: the output of xcodebuild is simply too long. If the complete log is handed directly to an agent, it not only consumes a large number of tokens, but also risks burying the useful information in noise. The Xcsift tool introduced by Lee young-jun in this article is designed precisely for this scenario. Unlike xcpretty, which is mainly aimed at human readability, Xcsift organizes xcodebuild / SwiftPM output into structured results that are more suitable for LLM consumption, including compile errors, warnings, test failures, coverage, and build timing.

One easily overlooked detail in AI-assisted development workflows is that we should not let agents “read everything and decide what matters by themselves.” Instead, we should try to perform filtering and structuring at the tool layer first. Xcsift is a practical solution built on top of existing xcodebuild output, while the Tuist team previously discussed structured build data beyond build logs in Teaching AI to Read Xcode Builds. Viewed together, they show two levels of build diagnosis in agentic coding: first reduce noise, then improve semantics.

The MiniSwift Story

I previously recommended MiniSwift in the weekly. At that time, the most fascinating part was that Ugur Toprakdeviren had implemented a Swift compiler frontend and WASM backend from scratch in C, without relying on LLVM, Clang, or Apple’s official toolchain. In this article, the author fills in the story behind the project: it did not begin as a “show-off compiler project,” but from a very specific question—could one get a more stable SwiftUI preview on canvas, free from the instability of WebView or Xcode Preview?

The reason MiniSwift is worth recommending again is that it has clearly taken a big step from an early compiler prototype toward its original goal. It no longer merely compiles Swift code to WASM; through a custom UIIR, canvas renderer, and diff engine, it can now render SwiftUI code directly into an interactive preview in the browser. Judging from the official demo, @State, basic layout, buttons, text, and some modifiers can already provide immediate feedback in the browser similar to SwiftUI Preview. In other words, the previously mentioned idea of a “SwiftUI browser preview that does not crash” is turning from a concept into a tool that can be experienced directly.

Tools

MistKit: Letting Server-Side Swift Access CloudKit

Developed by Leo G Dion, MistKit has a clear goal: to wrap Apple’s CloudKit Web Services REST API in a modern Swift interface, allowing server-side Swift, command-line tools, and environments such as Linux and Windows—where the native CloudKit framework is unavailable—to access the same CloudKit containers. It is not meant to replace the CloudKit framework on Apple platforms, but to fill the gap in scenarios where the native framework cannot be used directly.

The project builds its lower-level client on top of swift-openapi-generator, while providing higher-level capabilities such as async/await, type-safe CloudKit operations, structured errors, record querying and CRUD, record / zone changes, asset upload, and user-identity-related functionality. For authentication, it supports API Token, Web Auth Token, and Server-to-Server. Server-to-Server is mainly for the public database, while operations involving user context in private or shared databases require Web Auth Token. This makes it suitable for background tasks, CLIs, content catalogs, public database management, and data bridging between the web and Apple devices.

CloudKit is often seen as a “client-side service,” but MistKit makes it more natural for servers to participate in the CloudKit ecosystem. For example, a scheduled job could maintain a software version catalog, RSS aggregation content, or app asset packages in the public database; or, after user authorization, a backend could process data in a user’s private database. For apps already relying on CloudKit, it provides a path for extending data-processing capabilities beyond Apple platforms.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

稳定 > 新功能

网页版

无论是 SwiftUI 还是 SwiftData，这些苹果寄予厚望的基础框架，在推出时都描绘了充满光明的未来，但实际走势似乎都和最初的设定不太一样。当我越深入了解这些框架，就越对它们精妙的架构设计所折服，同时也对那些不尽如人意的实现感到无语。眼看着这些设计的光环逐渐褪去，心中不免唏嘘。

传闻苹果在今年即将发布的全新操作系统（包括 iOS 27 和 macOS 27）中，将采取类似于当年 Mac OS X Snow Leopard 时代的调整策略——将重心放在系统稳定性、性能优化、清理老旧代码和修复 Bug 上，而不是引入颠覆性的视觉设计或繁多的底层新功能。如果真能如此，那实在是令人欣慰。回看两年多前的 第六期周报，当时也传出过苹果要集中修复彼时存在的缺陷并提高软件性能，但至少从过去两年的实际使用体验来看，这个目标似乎未能达成。

距离 WWDC 26 已经不足十天了。相较于更多、更炫的新功能，我今年更期待苹果能给开发者和消费者带来一次脚踏实地、更加稳定的体验。

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

原创

用自定义 Layout 化解 SwiftUI List 的行高与间距跳变

在 SwiftUI 中，为视图状态变化添加动画往往只需要很少的代码，但 List 并不总能给出符合预期的过渡效果。尤其当 row 内部的内容高度发生变化时，例如副标题从无到有、文本行数因数据更新而改变，系统默认的布局过程很容易让行高直接硬切，进而带来闪烁、裁剪或 spacing 突变。本文从这一常见问题出发，逐步拆解 List 动态行高动画失效的原因，并通过自定义 Layout、Animatable、LayoutValueKey 与状态解耦，构建出一套完全基于 SwiftUI 原生能力的解决方案。

这并不是一篇以提供开箱即用组件为主要目标的文章。相比最终代码，我更希望借这个问题梳理一条 SwiftUI 布局问题的探查路径：先理解框架为什么“不按预期工作”，再顺着它的机制重新组织状态、测量与布局，让动画真正发生在正确的层级上。

近期推荐

无状态 actor (Stateless Actors)

Actor 通常被理解为“用来保护可变状态”的工具，因此一个没有存储属性、看似无状态的 actor 很容易让人疑惑：它到底有没有存在的必要？文章以 NetworkClient、自定义 global actor、custom executor 与文件系统访问等场景为例，说明无状态 actor 并非一定不合理，但也可能带来串行化、协议适配和类型系统传播等额外成本；关键在于它究竟是在解决什么问题。

这篇文章最值得关注的点，是 Matt Massicotte 提出的“actor 第一原则”：像使用任何同步原语一样，在使用 actor 之前，应该能清楚说明它为什么必要。无状态 actor 并不一定是错误，但它很可能意味着我们正在用 actor 解决一个并不需要 actor 的问题；只有当它确实承担了隔离、串行化、executor 适配或外部状态保护等明确职责时，才是合理的设计。

为 SwiftData 构建自定义存储格式 (Building a Custom Data Store in SwiftData)

很多开发者容易将 SwiftData 理解为苹果官方对 SQLite 的高层封装，但这其实低估了它作为对象图管理与持久化协调框架的潜力。无论是 SwiftData 还是 Core Data，更重要的能力都不只是替我们读写数据库，而是让模型对象、查询、上下文管理与底层存储之间保持清晰分工。只要底层存储能够按照框架要求完成数据交换，数据来源就不一定非得是 SQLite。

Mohammad Azam 通过实现一个基于 JSON 文件的 custom data store，展示了 SwiftData 与底层存储之间真正交换的并不是 @Model 标记的实时对象，而是经过转换后的 snapshot。理解这一点之后，DataStoreConfiguration、DataStore、DefaultSnapshot、PersistentIdentifier 以及 fetch / save 的职责边界都会变得清晰起来：SwiftData 负责模型对象、观察、变更追踪和 SwiftUI 集成，而自定义 store 只负责读取和写入快照。

在 #127 期周报中，我曾推荐过一个更工程化的自定义 DataStore 项目 DataStoreKit。它并不是简单地把 SwiftData 后端换成 JSON 或文件存储，而是尝试基于 custom DataStore 重新实现一套 SwiftData-aware 的 SQLite 存储层，并在 predicate 翻译、继承、缓存、历史追踪以及后台预取等方面做了大量扩展。想在此方向进一步研究的开发者，可以将它作为进阶参考。

给 Swift 并发任务命名 (Task Names in Swift Concurrency)

GCD 有 queue label，Swift Concurrency 的 task 却长期缺少类似的诊断标识。随着 SE-0469 在 Swift 6.2 中实现，Task、Task.detached、task group 的 addTask 等 API 开始支持 name 参数，开发者可以为并发任务添加简短、可读的名称，从而在 LLDB、Instruments 和日志中更容易定位具体执行单元。

Artem Novichkov 梳理了 task name 的用法与限制，并提醒开发者：task name 应只作为诊断信息，而不是程序逻辑的一部分。它适合辅助调试、性能分析和日志排查，但不应承载业务状态。

UniqueBox, Ref, and MutableRef in Swift 6.4

Swift 6.4 延续了近几年围绕 ownership、borrow、noncopyable type、lifetime dependency、Span 与 MutableSpan 等方向的演进。Artem Mirzabekian 通过 UniqueBox、Ref 和 MutableRef 这三个类型，介绍了 Swift 在存储位置、所有权与访问生命周期上的新表达能力。它们的意义并不是鼓励普通业务代码立刻改用这些底层构件，而是展示 Swift 正在把过去依赖 class box、UnsafePointer 或编译器内部推理的关系，逐步提升为可以写进 API 形状、并由类型系统检查的语言模型。

其中，UniqueBox 用来表达“一个值位于堆上，并由单一所有者持有”；Ref 和 MutableRef 则分别对应某段生命周期内的共享读取与独占修改。换句话说，这些类型补上的不是某个具体业务场景的便利 API，而是一套更精确描述“值在哪里、归谁所有、谁能访问”的底层词汇。

关于 CloudKit CKAsset 当前文件大小限制的澄清 (Clarification on Current CloudKit CKAsset File Size Limits)

关于 CKAsset 的文件大小上限，社区里长期存在一个容易混淆的说法：有些文档中提到过 50 MB 限制，但那更多对应 CloudKit Web Services，而不是 Apple 平台上通过原生 CloudKit framework 上传的 CKAsset。这次 Apple Frameworks Engineer 在开发者论坛中给出了一个非常明确的回答：单个 CKAsset 最高支持 50 GB，前提是用户仍有足够的 iCloud 存储空间，因此应用需要正确处理 CKError.quotaExceeded。

之所以在周报中介绍这个问答，并不只是因为它澄清了一个数字，而是因为它划清了一个重要边界：CKAsset 支持大文件，并不等于大文件同步就是简单可靠的工程问题。后续讨论也提到，大文件传输往往需要考虑应用挂起、终止后的后台执行能力，可以结合 long-lived CloudKit operations，或通过 BackgroundTasks 中的 BGProcessingTask 来安排上传任务。也就是说，50 GB 回答的是“CloudKit 是否允许”，而后台传输、失败恢复、配额处理和用户体验，仍然需要应用自己认真设计。

为 Agent 提供有效的调试信息 (Don’t allow the agent reading whole output of Xcodebuild)

随着 AI agent 越来越多地参与 Swift 项目的编译、测试和问题定位，一个很现实的问题开始变得突出：xcodebuild 的输出实在太长了。如果直接把完整日志交给 agent，不仅会消耗大量 token，也容易让真正有用的信息被淹没在噪声中。Lee young-jun 在本文中介绍的 Xcsift 正是为这个场景设计的工具：它不像 xcpretty 那样主要面向人类阅读，而是把 xcodebuild / SwiftPM 的输出整理成更适合 LLM 消费的结构化结果，例如编译错误、警告、测试失败、覆盖率和构建耗时等。

AI 辅助开发工作流中一个容易被忽略的细节是：我们不应该让 agent “读完所有内容再自己判断重点”，而应该尽量在工具层先完成信息筛选与结构化。Xcsift 是一个基于现有 xcodebuild 输出的实用方案，而 Tuist 团队此前在 Teaching AI to Read Xcode Builds 中则进一步讨论了构建日志之外的结构化 build data。两者放在一起看，正好体现了 agentic coding 在构建诊断上的两个层次：先减少噪声，再提升语义。

The MiniSwift Story

我在之前的周报中曾推荐过 MiniSwift，当时最吸引人的部分，是 Ugur Toprakdeviren 在不依赖 LLVM、Clang 或 Apple 官方工具链的情况下，用 C 从零实现了 Swift 编译器前端与 WASM 后端。而在这篇文章中，作者补全了项目背后的来龙去脉：它最初并不是为了“炫技式地写一个编译器”，而是源于一个很具体的问题——能不能摆脱 WebView 或 Xcode Preview 的不稳定，用 canvas 得到更稳定的 SwiftUI 预览。

这次值得再次推荐，是因为 MiniSwift 已经明显从早期 compiler prototype 向它最初的目标迈进了一大步。现在它不只是把 Swift 代码编译到 WASM，而是进一步通过自定义 UIIR、canvas renderer 和 diff engine，把 SwiftUI 代码直接渲染成浏览器中的可交互预览；从官网展示来看，@State、基础布局、按钮、文本和部分修饰器已经可以在网页中形成类似 SwiftUI Preview 的即时反馈。也就是说，之前提到的“不会崩溃的 SwiftUI 浏览器预览”，正在从设想变成一个可以直接体验的工具。

工具

MistKit：让服务端 Swift 访问 CloudKit

由 Leo G Dion 开发的 MistKit 目标很明确：把 Apple 的 CloudKit Web Services REST API 封装成现代 Swift 接口，让服务端 Swift、命令行工具，以及 Linux、Windows 等没有原生 CloudKit framework 的环境，也能访问同一套 CloudKit 容器。它并不是要替代 Apple 平台上的 CloudKit framework，而是补足那些无法直接使用原生框架的场景。

项目基于 swift-openapi-generator 构建底层客户端，上层提供 async/await、类型安全的 CloudKit 操作、结构化错误、record 查询与增删改、record / zone changes、asset upload 和用户身份相关能力。认证方面覆盖 API Token、Web Auth Token 与 Server-to-Server；其中 Server-to-Server 主要用于 public database，涉及 private 或 shared database 的用户上下文操作则需要 Web Auth Token。这使它适合后台任务、CLI、内容目录、公共数据库管理，以及 Web 与 Apple 设备之间的数据桥接。

CloudKit 常被视为“客户端服务”，但 MistKit 让服务端参与 CloudKit 生态变得更自然。例如，用定时任务维护 public database 中的软件版本目录、RSS 聚合内容、应用素材包；或在用户授权后，让后端处理 private database 中的数据。对已经依赖 CloudKit 的应用来说，它提供了一条在 Apple 平台之外扩展数据处理能力的路径。

From Community Guidepost to Ecosystem Cornerstone: Dave Verwer’s New Chapter

Read on web →

In issue 751 of iOS Dev Weekly, Dave Verwer announced that the newsletter, which has been running for nearly 15 years, will be handed over to a new team, while he will dedicate himself full-time to Swift Package Index. My own blog gained early attention thanks in part to recommendations from iOS Dev Weekly, and my commitment to writing a commentary for each issue of my newsletter was also greatly inspired by Dave Verwer. For many Apple platform developers, iOS Dev Weekly has long been more than a collection of links. It has been both a guidepost for the community and a long-term companion.

Rather than viewing this as “Dave leaving iOS Dev Weekly”, a phrase that inevitably carries a sense of farewell, I prefer to see it as a shift in focus: from curating the information flow of the Swift community to building infrastructure for the Swift ecosystem.

Swift Package Index was originally created by Dave Verwer and Sven A. Schmidt as the successor to, and a rewrite of, SwiftPM Library. When it first appeared, it was easy to understand it simply as a “website for finding Swift packages.” But after several years of development, SPI has clearly grown far beyond the scope of an ordinary index site. It not only records basic package information, but also uses real builds to verify compatibility across Swift versions and platforms, hosts DocC documentation, displays maintenance status, dependency relationships, licenses, tests, and package scores, and, through projects such as Ready for Swift 6, observes how the broader package ecosystem migrates toward new language features.

These capabilities may seem scattered, but in essence they all point to the same goal: making the Swift package ecosystem easier to evaluate, compare, and trust. For individual developers, choosing a dependency becomes a little less like opening a “blind box”. For teams, it becomes easier to assess risks before introducing third-party libraries. For package authors, SPI provides a public window for showcasing project health and documentation quality. A mature package ecosystem cannot exist on Package.swift alone. It also needs visible compatibility, continuous documentation, stable build verification, and a trust mechanism gradually built around all this information.

In Issue 135, I wrote that CocoaPods is on its way out, while SwiftPM has only just turned to its second chapter. With CocoaPods Trunk counting down toward becoming read-only, and ecosystems such as Flutter also moving toward SPM, the “unification” of dependency management on Apple platforms now seems increasingly close. But that does not mean SwiftPM has truly broken beyond its existing boundaries. It will certainly become the default answer on Apple platforms, but if Swift is to keep expanding into Linux, Android, Wasm, embedded systems, and other scenarios, SwiftPM will need to address more than just “whether dependencies can be installed.” The real question is whether the entire ecosystem is transparent, reliable, and sustainable enough.

In this regard, the value of SPI may be far greater than its name suggests. It can be an index, but also an ecosystem dashboard; it can be a documentation hosting platform, but also a compatibility lab. In the future, it may even take on a larger role in areas such as package collections, supply chain security, version immutability, and public registries. Dave has previously mentioned that SwiftPM registries could bring safer and faster distribution to Swift dependency management, while a public registry for open-source packages remains an important missing piece worth looking forward to.

iOS Dev Weekly records the weekly ripples of the Swift community, while Swift Package Index touches the waterline beneath those ripples. Dave’s shift may also suggest that the Swift ecosystem has entered a new stage: we still need excellent content curators, but we need even more infrastructure builders who can help the ecosystem continue running for the long term.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

Monads are Easy

Monad is probably one of the most infamous — and most intimidatingly explained — concepts in functional programming. But at its core, it really just solves one problem: how to safely and continuously compose computations around values that carry “context.” Krishna Kotecha explains Monad in a way that feels very approachable to Swift developers, using a warehouse book-scanning analogy: values are books, containers are boxes, map scans books one by one, while flatMap opens nested boxes and flattens everything back into a single box. Whether it’s Optional, Result, or Optional chaining, they all exhibit strong Monad-like behavior. In Swift, every ?. you write is essentially a flatMap disguised as syntax sugar.

Krishna Kotecha not only explains Monads in an intuitive way, but also includes excellent diagrams throughout the article. The “unboxing and repacking” visuals make the core idea behind flatMap remarkably easy to grasp.

Type-Driven Design in Swift: Better Money Formatting

For many Swift developers, Type-Driven Design often stops at “preventing invalid parameters from being passed around.” But in more complex domains — such as finance, state machines, permissions, or orders — types themselves can become part of the business rules and domain constraints. In this article, Uwais Alqadri uses the separation of “raw money value” and “display value” as a starting point to explain why fintech applications should never perform calculations directly on Double values or formatted display strings. Through a series of practical examples, the article demonstrates how locale differences, currency precision, and rounding rules can introduce subtle but serious bugs, while also highlighting the value of Type-Driven Design in domain modeling.

Is AndroidX ViewModel the best choice for KMP projects?

For Swift developers, a ViewModel is usually just an object that holds view state and interaction logic. In SwiftUI, it can be an @Observable type or simply a reference type organized around view state; task lifecycles are typically managed by .task, the view hierarchy, or other SwiftUI-native mechanisms. But when Swift developers enter the Kotlin Multiplatform or Android ecosystem, it’s easy to underestimate what AndroidX ViewModel is actually responsible for: it’s not only the “ViewModel” in MVVM, but also part of Android’s lifecycle management, ViewModelStore, and coroutine scope system.

Gustavo Fão Valvassori walks through the historical background of Android ViewModel, explaining why it became tightly coupled to Activity / Fragment recreation, configuration changes, and viewModelScope, and further explores the friction this model can introduce when brought into KMP projects targeting native iOS UI. For Swift developers, the most valuable aspect of the article is not whether AndroidX ViewModel should be adopted directly, but rather understanding that the term “ViewModel” can carry very different architectural responsibilities across platforms.

Deprecating your own convenience API

To support different OS versions — or provide a consistent experience across old and new systems — developers often create wrappers, compatibility layers, or custom modifiers to smooth over platform differences. But as deployment targets rise over time, much of that code quietly turns into “dead code” nobody dares to remove. Majid Jabrayilov demonstrates a very practical SwiftUI technique using @available(..., deprecated:, obsoleted:) to explicitly define the lifecycle of these transitional APIs. Once the minimum deployment target increases, the compiler can automatically surface warnings or even errors, reminding developers to finally remove obsolete compatibility layers.

In a sense, @available is not only about API availability — it’s also a way to manage the expiration date of technical debt.

Hiding SwiftUI Views from Screen Capture

SwiftUI has long lacked a capability that sounds deceptively simple, yet is actually quite low-level and highly practical: allowing a View to remain visible on screen while being excluded from screenshots, screen recordings, AirPlay, or other system capture pipelines. Public APIs mainly provide “capture state detection,” rather than true per-view capture privacy protection. Kyle Ye, the developer behind OpenSwiftUI, walks through the entire stack — from public APIs, secure UITextField tricks, and the private CALayer.disableUpdateMask behavior, all the way down to SwiftUI’s internal DisplayList and RendererEffect mechanisms — eventually implementing a genuinely SwiftUI-style view extension. Instead of moving SwiftUI content into a secure text field subtree, the approach directly leverages SwiftUI’s existing screencaptureProhibited rendering property to exclude the corresponding layer from capture output.

A Public Symbol Server for Swift on Windows

The Browser Company recently made its Swift on Windows Symbol Server publicly available. Through this service, developers can directly fetch PDB symbol files for the Swift runtime and standard library inside native Windows debugging tools such as WinDBG, Visual Studio, and Windows Performance Analyzer, enabling fully symbolicated stack traces and much clearer crash analysis.

What makes the article particularly interesting, however, is not just how to configure a Symbol Server, but the broader explanation of Swift’s debugging infrastructure across platforms: from object file formats like Mach-O, ELF, and PE/COFF, to DWARF versus PDB/CodeView debug information systems, and the very different ways Darwin, Linux, and Windows manage symbols. For developers who have only worked on Apple platforms, this article offers a surprisingly clear reminder that making Swift truly cross-platform involves far more than simply “being able to compile and run.”

Replacing Bash with Swift in an AI Harness

As AI Agent tooling evolves, “letting models execute code” is gradually becoming less of a terminal wrapper problem and more of a runtime design problem. This article documents a fascinating experiment: Alejandro Martinez replaces Bash inside an AI Harness with an embeddable Swift interpreter, allowing the model to generate and execute Swift directly instead of shell scripts. Combined with SwiftScript and ShellKit, the project demonstrates how embedded interpreters, controlled working directories, and sandboxing can provide a much more constrained and controllable Swift Runtime for LLMs.

SwiftScript is a particularly interesting experimental project created by Oliver Drobnik: a fully Swift-written, embeddable Swift interpreter. It parses and executes Swift ASTs directly using swift-syntax, rather than compiling binaries through swiftc, making it feel much closer to JavaScriptCore or a Python-style embedded scripting runtime.

Hanging on the Promise of SwiftUI

Seven years after SwiftUI’s introduction, we still seem to be in a strange in-between state: it has become too important for Apple platform developers to ignore, yet it still feels incomplete enough that many real-world applications eventually fall back to AppKit or UIKit. In this article, Patrick McConnell expresses his complicated relationship with SwiftUI: it is good enough to make developers want to invest deeply in it, but that also makes its recurring “almost, but not quite there” limitations in extensibility, completeness, and lower-level capabilities especially frustrating.

I’ve always felt that SwiftUI will only truly mature once Apple itself fully commits to using it at scale across first-party applications. Third-party developers should not be treated as framework beta testers — they should be the first to benefit from the convenience and stability the framework promises.

Tools

App Store & Google Play Screenshots Generator

App Store & Google Play Screenshots Generator is an AI coding agent–oriented screenshot generation skill created by Parth Jadhav. Rather than simply offering templates, it turns the entire screenshot workflow — collecting product information, organizing marketing copy, choosing visual styles, local editing, and exporting multiple sizes — into an executable process.

The project generates a local Next.js + ShadCN editor for the current directory, supporting drag-and-drop ordering, inline title editing, real screenshot uploads, iOS / Android device switching, and persistent project state stored in a versionable app-store-screenshots.json file. Its most valuable idea is treating store screenshots explicitly as advertising assets: each screenshot should communicate a single selling point, prioritizing user benefit, emotion, and pain points over mechanically showcasing UI.

For indie developers, tools like this are genuinely useful. They won’t replace final visual judgment or platform guideline reviews, but they can consolidate a large amount of repetitive and error-prone screenshot work into a much more agent-friendly local workflow.

Editorio: A Native macOS Markdown & Code Editor

Tired of bloated Electron editors and the ever-growing subscription culture around note-taking apps, Lovre Crncevic decided to build a lightweight, fully native Markdown and code editor for himself.

Editorio uses Swift + AppKit for its native interface and a Rust-powered text engine for performance optimization. It supports live Markdown preview, project sidebars, minimaps, themes, and syntax highlighting for many programming languages. According to the author, Editorio typically uses around 40MB of memory while maintaining near-instant startup and file loading times. In some ways, it feels like a return to the classic era of “small and fast” Mac applications.

Lovre has promised that the app will remain free forever, and mentioned in a Reddit discussion that once the codebase is cleaned up further, he plans to open source Editorio on GitHub.

Event

Swift Mentorship Program 2026

The Swift Mentorship Program is an official community initiative that has become a recurring part of the Swift ecosystem in recent years. Its goal is to help more developers meaningfully participate in Swift open source development through direct mentorship from experienced contributors. Over a 10-week period, mentees work alongside mentors to complete real open-source contributions — whether to the Swift compiler itself or any Swift-based open-source project. Compared to simply reading tutorials or browsing issue trackers, this “guided first contribution” model provides a much more authentic open-source collaboration experience.

The program was originally driven by the Swift Contributor Experience Workgroup and has gradually evolved into a stable community activity. Beyond technical learning, it also helps lower barriers to entry, cultivate new contributors, and strengthen community connections. The Swift team explicitly encourages participation from groups such as Women in Swift, Black in Swift, and Pride in Swift.

The 2026 program has already opened, with mentor and mentee sign-ups beginning in May and June respectively, followed by the official 10-week mentorship cycle starting in July.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

从社区路标到生态基石：Dave Verwer 的新篇章

网页版

Dave Verwer 在 iOS Dev Weekly 第 751 期宣布，这份已经持续近 15 年的周报将交由新的团队继续运营，而他自己接下来会全职投入 Swift Package Index。我的博客在早期获得关注，也曾得益于 iOS Dev Weekly 的推荐；而我在周报中坚持撰写每期周评，同样在很大程度上受到 Dave Verwer 的启发。对于很多 Apple 平台开发者来说，iOS Dev Weekly 早已不只是一份链接合集。它既是社区路标，也是长期陪伴。

不过，相较于“Dave 离开 iOS Dev Weekly”这个略带告别感的表述，我更愿意把这件事看作一次重心转移：从整理 Swift 社区的信息流，转向建设 Swift 生态的基础设施。

Swift Package Index 最初由 Dave Verwer 和 Sven A. Schmidt 共同创建，是 SwiftPM Library 的继承者与重构版。刚出现时，它很容易被理解为一个“找 Swift 包的网站”。但几年过去后，SPI 已经明显超出了普通索引站点的范畴。它不仅记录包的基本信息，也通过真实构建来验证不同 Swift 版本和平台的兼容性，托管 DocC 文档，展示维护状态、依赖关系、许可证、测试与质量评分，还通过 Ready for Swift 6 这样的项目，观察整个包生态向新语言特性迁移的进度。

这些能力看似分散，实际上指向的是同一件事：让 Swift 包生态变得更可判断、更可比较，也更可信。对于个人开发者来说，选择依赖时可以少一点“开盲盒”；对于团队来说，在引入第三方库前能更清楚地评估风险；对于包作者来说，也多了一个展示项目健康度和文档质量的公共窗口。一个成熟的包生态，不能只靠 Package.swift 存在。它还需要可见的兼容性、持续的文档、稳定的构建验证，以及围绕这些信息逐渐形成的信任机制。

我在 第 135 期 中提到：CocoaPods 正在退场，SwiftPM 才刚翻到第二章。随着 CocoaPods Trunk 进入只读倒计时，Flutter 等跨平台生态也开始转向 SPM，Apple 平台依赖管理的“大一统”看起来已经越来越接近。但这并不意味着 SwiftPM 已经完成了真正意义上的破圈。它当然会成为 Apple 平台的默认答案，可如果 Swift 想在 Linux、Android、Wasm、嵌入式等更多场景中继续扩展，SwiftPM 需要面对的就不只是“能不能安装依赖”，而是整个生态是否足够透明、可靠、可持续。

在这一点上，SPI 的价值可能比它的名字暗示的要大得多。它可以是索引，也可以是生态仪表盘；可以是文档托管平台，也可以是兼容性实验室；未来甚至有机会在包集合、供应链安全、版本不可变性、公共 registry 等方向上承担更多角色。Dave 此前也曾提到，SwiftPM registry 能为 Swift 依赖管理带来更安全、更快的分发方式，而公共开源 registry 仍是一个值得期待的空白。

iOS Dev Weekly 记录的是 Swift 社区每周的涟漪，而 Swift Package Index 触及的则是这些涟漪之下的水位。Dave 的转身，或许也说明 Swift 生态已经走到一个新阶段：我们仍然需要好的内容策展者，但更需要能让整个生态长期运转下去的基础设施建设者。

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

近期推荐

轻松理解 Monad (Monads are Easy)

Monad 可能是函数式编程中“名气最大、解释最吓人”的概念之一，但它真正解决的问题，其实只是如何在“带上下文”的值之间，安全、连续地组合计算。Krishna Kotecha 用 Swift 开发者容易理解的方式，通过“仓库扫描书籍”的类比，把 Monad 拆解成了一个极其具体的流程 —— 值是书、容器是箱子、map 是逐个扫描，而 flatMap 则负责拆开嵌套箱子并重新压平成一个统一的箱子。无论是 Optional、Result，还是链式 Optional chaining，本质上都带有明显的 Monad 风格。在 Swift 中，你写下的每一个 ?.，本质上都是一个伪装成语法糖的 flatMap。

Krishna Kotecha 不仅把 Monads 讲得十分直观，文章中的配图也相当出色。这些“拆箱再装箱”的流程图，把 flatMap 的核心思想展现得非常形象。

Swift 类型驱动设计：更好的金额格式化 (Type-Driven Design in Swift: Better Money Formatting)

对很多 Swift 开发者来说，Type-Driven Design 往往停留在“避免传错参数”的层面。但在涉及金额、状态机、权限、订单等复杂业务时，类型本身其实也可以成为业务规则与领域约束的一部分。Uwais Alqadri 在本文中，以“金额的原始值与展示值必须分离”为切入点，讨论了为什么金融类应用不应直接使用 Double 或格式化后的展示文本参与金额计算。文章不仅通过多个实际案例说明了不同 locale、货币精度与 rounding rule 带来的潜在问题，也进一步引出了 Type-Driven Design 在业务建模中的价值。

AndroidX ViewModel 是 KMP 项目的最佳选择吗？(Is AndroidX ViewModel the best choice for KMP projects?)

对于 Swift 开发者来说，ViewModel 通常只是一个承载视图状态与交互逻辑的对象。在 SwiftUI 中，它可以是一个 @Observable 类型，也可以只是一个围绕 View 状态组织起来的普通引用类型；任务生命周期往往交给 .task、视图层级或其他更贴近 SwiftUI 的机制处理。但当 Swift 开发者进入 Kotlin Multiplatform 或 Android 生态时，很容易低估 AndroidX ViewModel 所承担的职责：它不仅是 MVVM 中的“ViewModel”，同时也是 Android 生命周期、ViewModelStore 与 coroutine scope 的一部分。

Gustavo Fão Valvassori 从 Android ViewModel 的历史背景讲起，解释它为何会与 Activity / Fragment 的重建、配置变化和 viewModelScope 深度绑定，并进一步讨论当这一套机制被带入 KMP 项目后，在 iOS 原生 UI 中可能产生的摩擦。对于 Swift 开发者而言，文章最有价值的地方并不在于是否应该直接采用 AndroidX ViewModel，而是帮助我们理解：同样叫作 ViewModel，在不同平台上可能承载着完全不同的架构责任。

如何优雅地废弃自定义兼容 API (Deprecating your own convenience API)

为了兼容不同的系统版本，或为新旧系统提供一致的行为与体验，开发者通常会通过统一封装、为旧系统补齐兼容实现，或者用自定义 modifier 抹平不同系统之间的行为差异。但随着应用最低支持版本不断提高，其中很多代码最终都会悄悄变成没人敢删的“死代码”。Majid Jabrayilov 以一个非常典型的 SwiftUI 场景为例，利用 @available(..., deprecated:, obsoleted:) 标记这些“过渡 API”的生命周期。当最低部署版本提升后，编译器会自动将这些兼容层标记为 warning 甚至 error，从而提醒开发者及时移除。

某种意义上，@available 不仅是在管理 API 的可用性，也是在管理“技术债的保质期”。

让 SwiftUI View 在截图中隐藏

SwiftUI 一直缺少一个看似简单、但其实相当实用且底层的能力：让某个 View 在屏幕上正常显示，但在截图、录屏、投屏或其他系统捕获路径中被隐藏。公开 API 提供的更多是“捕获状态检测”，而不是真正意义上的捕获隐私保护。OpenSwiftUI 的开发者 Kyle Ye 从公开 API、secure UITextField 技巧、CALayer.disableUpdateMask 私有行为，一路分析到 SwiftUI 内部 DisplayList 与 RendererEffect 的工作机制，最终实现了一个真正 SwiftUI 风格的视图扩展。它不需要把 SwiftUI 内容塞进 secure text field subtree，而是直接利用 SwiftUI 内部已经存在的 screencaptureProhibited rendering property，将对应 layer 从 capture output 中移除。

Windows 平台 Swift 公共符号服务器上线 (A Public Symbol Server for Swift on Windows)

The Browser Company 近日公开了 Swift on Windows 的 Symbol Server。通过该服务，开发者可以在 WinDBG、Visual Studio、Windows Performance Analyzer 等 Windows 原生调试工具中，直接获取 Swift Runtime 与标准库的 PDB 符号文件，从而获得完整的符号化调用栈与更清晰的崩溃分析能力。

这篇文章真正有趣的地方，并不仅仅是如何配置 Symbol Server，而是它系统梳理了 Swift 在不同平台上的调试基础设施：从 Mach-O、ELF、PE/COFF 等对象文件格式，到 DWARF 与 PDB/CodeView 两套调试信息体系，再到 Darwin、Linux 与 Windows 在 symbol 管理上的不同设计。对于长期只在 Apple 平台开发的 Swift 开发者来说，这篇文章会让你第一次比较直观地意识到：Swift 想真正成为跨平台语言，仅仅“能够编译运行”远远不够，它还需要深入融入目标平台原生的调试体系与工具链生态。

在 AI 容器中用 Swift 替代 Bash (Replacing Bash with Swift in an AI Harness)

随着 AI Agent 工具的发展，“让模型执行代码”正在逐渐从简单的 terminal 调用演变成新的运行时设计问题。这篇文章记录了一个相当有趣的实验：Alejandro Martinez 尝试在 AI Harness 中，用可嵌入的 Swift 解释器替换 Bash，让模型不再生成 shell script，而是直接生成并执行 Swift 代码。结合 SwiftScript 与 ShellKit，展示了如何通过嵌入式解释器、受控工作目录与 sandbox，为 LLM 提供一个更可控的 Swift Runtime。

SwiftScript 是一个相当有意思的实验性项目，由 Oliver Drobnik 创建：一个完全由 Swift 编写、可嵌入应用的 Swift 解释器。它基于 swift-syntax 解析并直接执行 Swift AST，而不是通过 swiftc 编译生成二进制，因此更接近 JavaScriptCore 或 Python Runtime 这类“嵌入式脚本运行时”。

对 SwiftUI 的纠结与期许 (Hanging on the Promise of SwiftUI)

SwiftUI 发布七年后，我们似乎仍处于一种微妙的状态：它已经足够重要，重要到几乎所有 Apple 平台开发都无法绕开它；但它又依然不够完整，很多稍微复杂一点的真实应用，最终仍不得不重新回到 AppKit / UIKit。Patrick McConnell 在这篇文章中，集中表达了他对 SwiftUI 的复杂情绪：它很好，好到让人愿意持续投入；但也正因为如此，当它在扩展性、完整性与底层能力上始终“差一点”时，才会显得格外令人沮丧。

我一直觉得，只有苹果在第一方应用上真正全力、大规模地使用 SwiftUI，SwiftUI 才可能进入更快的成熟期。第三方开发者不应成为框架的小白鼠，而应该优先享受到框架带来的便利与稳定。

工具

App Store & Google Play Screenshots Generator

App Store & Google Play Screenshots Generator 是一个面向 AI coding agent 的商店截图生成 skill，由 Parth Jadhav 开发。它不是简单给你一套截图模板，而是把“收集产品信息 → 组织卖点文案 → 选择视觉风格 → 本地编辑 → 批量导出尺寸”的流程做成了一个可执行工作流。

项目会为当前目录生成一个 Next.js + ShadCN 的本地编辑器，支持拖拽排序、在线修改标题、上传真实截图、切换 iOS / Android 设备，并将项目状态保存为可版本化的 app-store-screenshots.json。它最值得借鉴的地方，是把商店截图明确视为广告素材：每张图只表达一个卖点，优先呈现用户收益、情绪和痛点，而不是机械展示 UI。

对独立开发者来说，这类工具很实用。它不能替代最终的审美判断和平台规则核对，但能把上架截图制作中大量重复、琐碎、容易出错的部分收拢到一个 agent 友好的本地流程里。

Editorio: macOS 原生 Markdown 与代码编辑器

Lovre Crncevic 因为不甘忍受 Electron 编辑器的臃肿，以及各类笔记软件泛滥的订阅制，决定为自己打造一款纯原生的轻量级 Markdown 与代码编辑器。

Editorio 使用 Swift + AppKit 构建原生界面，并使用 Rust 构建底层文本引擎以提升性能，支持 Markdown 实时预览、项目侧边栏、minimap、主题切换，以及多种编程语言的语法高亮。作者表示，Editorio 典型内存占用约 40MB，而冷启动与文件读取则保持在毫秒级响应。某种程度上，它让人重新想起了过去那些“小而快”的经典 Mac 应用。

Lovre 承诺，该应用永久免费，并在 Reddit 上的讨论中表示：等项目代码进一步整理后，他计划将 Editorio 在 GitHub 上开源。

5.1 版本对非英文的输入支持有问题，我已反馈作者。5.2 版本（审查中）中已解决。

活动

2026 年度 Swift 官方导师计划 (Swift Mentorship Program 2026)

Swift Mentorship Program 是 Swift 社区近年来持续举办的一项官方 Mentorship 活动，旨在帮助更多开发者真正参与 Swift 开源生态。项目通过导师配对的方式，让参与者在 10 周时间内，与经验丰富的 Swift 开发者共同完成一次真实的开源贡献：既可以是 Swift 编译器本身，也可以是任意使用 Swift 编写的开源项目。相比单纯的线上教程或 issue 列表，这种“带着新人真正完成一次贡献”的方式，显然更接近真实的开源协作体验。

该项目最早由 Swift Contributor Experience Workgroup 推动，近几年已经逐渐成为 Swift 社区固定活动之一。除了技术学习外，它也承担着降低社区参与门槛、培养新贡献者以及加强社区群体连接的作用。官方还特别鼓励 Women in Swift、Black in Swift 与 Pride in Swift 等社区成员参与其中。

2026 年度活动已经开启，Mentor 与 Mentee 的报名时间分别从 5 月与 6 月开始，7 月正式进入为期 10 周的 Mentorship 周期。

WWDC26 派对之夜：城市、场次和报名信息

WWDC26 主题演讲将于当地时间 06 月 08 日 10:00 在库比蒂诺举行。

作为连续多年入选 Apple 开发者网站 WWDC 社区活动的 WWDC.playground，由 SwiftGG 发起的 WWDC26.playground 线下观影派对将于北京时间 06 月 08 日晚间至 06 月 09 日凌晨，在北京、上海、广州、深圳、杭州和青岛等多座城市举办。

入场时间和报名费用等形式，在不同城市/场次间可能有所不同，请以实地情况为准。👉 各地报名方式

The Vanishing WWDC Wishlists

Read on web →

WWDC 2026 is just 20 days away. Every year around this time, I usually see many developers sharing their WWDC wishlists, jotting down their predictions and expectations. But this year, at least by the time I was putting together this issue, there seemed to be noticeably fewer such posts than around the same time last year. Has developers' anticipation for WWDC waned, or are more of us simply adopting the mindset of "keeping expectations low to be pleasantly surprised"?

Perhaps the issue isn’t a lack of anticipation, but rather that the traditional format of a wishlist is no longer quite sufficient. In the past, we looked forward to a specific API, framework, or feature. Now, however, as software development rapidly pivots toward the AI Agent era, our expectations themselves have become much harder to clearly articulate.

A year ago, few developers could have predicted that software development would enter the AI Agent era so swiftly. Even if we hoped for better AI support in Xcode, prior to the release of Xcode 26.3, we probably wouldn’t have imagined that Apple would provide such seamless Agent integration right within the IDE. Applications and APIs are no longer just interfaces for consumers or developers; they can now become objects for AI Agents to understand, invoke, and orchestrate. AI is no longer merely a development tool; it acts as a new participant, deeply involved in the very construction and utilization of software services.

I believe this perfectly captures why many developers feel a mix of anticipation and uncertainty heading into WWDC 2026. We hope to see updated features, more stable frameworks, and a clearer platform direction. Yet, at the same time, we are pondering how to maintain our uniqueness and indispensability as developers in this new paradigm, and how to build better services alongside AI.

Let’s wait and see just how many changes WWDC 2026 will bring.

BTW: Last week, I had the incredible honor of being featured in the recently announced Apple Developer Community Spotlight. As a content creator, receiving this recognition is both an encouragement and a driving force for me: a reminder to keep writing earnestly and continue delivering valuable content to all of you. A heartfelt thank you to everyone who has read, shared feedback, and supported me along the way.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

URLSession to Electrons: How Networking works on iOS

Most iOS developers know that a URLSessionDataTask does not actually begin until you call resume(). But what really happens after that? In this long-form article, Jacob Bartlett follows an ordinary network request all the way down the stack — from URLSession, CFNetwork, TCP/IP, and Wi-Fi to radio signals, antennas, and electromagnetic waves. Along the way, he connects concepts developers often use but rarely fully understand, including HTTP, DNS, TCP, QUIC, and IPv6, while also exploring Network.framework, the XNU TCP stack, Wi-Fi frame structures, and cellular scheduling mechanisms inside iOS.

A simple resume() call may sit atop decades of protocol and infrastructure evolution. Modern software exists on layers upon layers of abstraction, and most of the time, we are simply fortunate enough to live in an era where those abstractions remain stable.

When AI and Xcode Fight: I Built a Tool to Keep the Peace

Xcode’s build system was never truly designed for parallel development. When multiple tasks build simultaneously, DerivedData, ModuleCache, SwiftPM caches, and even Simulators can collide with one another — and this problem becomes dramatically worse in multi-agent AI workflows. In this article, Maples7 introduces his solution: VibeChard. Built on Git Worktree, it creates isolated build sandboxes for each AI agent while separating DerivedData, ModuleCache, SwiftPM caches, and Simulator environments. Most interestingly, it does not require developers to modify build commands directly. Instead, it transparently intercepts xcodebuild via a PATH shim, allowing the entire toolchain — including Tuist and Fastlane — to operate inside isolated environments automatically.

More than just a utility, this project highlights a deeper issue emerging in the age of AI coding: as code generation speeds accelerate dramatically, traditional development toolchains must also evolve their isolation and infrastructure capabilities.

Has Swift Really Become a Mess? Some Honest Thoughts After Years of Using It

Swift becoming increasingly complex is an undeniable reality. But does that mean Swift has become a bad language? In this article, 迷途酱 revisits Swift’s “expansion” through the lens of real-world language evolution constraints. The author argues that much of the complexity people complain about comes from Swift simultaneously serving multiple roles: an application language, a systems language, a DSL host, and even a server-side language. Concurrency safety and ownership models themselves also belong to the category of “hard complexity” inherent to computer science.

The article discusses rapidly growing concepts such as Sendable, actor isolation, borrowing, and ~Copyable, while also candidly criticizing Swift’s concurrency keywords, increasingly dense generics syntax, and the “magic” behind SwiftUI. One particularly thought-provoking point is the idea that Swift is effectively “multiple layers of a language.” Most developers building everyday apps do not actually need to carry the full weight of the language’s complexity, yet WWDC sessions and official documentation often present all of these features side by side.

Writing shell scripts for Xcode Cloud

Xcode Cloud is easy to get started with, but in real-world projects many automation workflows still rely on shell scripts. Using “automatically creating a GitHub Release after archiving” as an example, Amy Delves demonstrates how to leverage Xcode Cloud environment variables to determine whether a build originated from the main branch, extract version and build numbers from an archive, and create releases via the GitHub API.

The example itself is fairly straightforward, but it nicely illustrates that Xcode Cloud is more than just a “click a few buttons to run tests” service. With environment variables, script hooks, and external APIs, it can support much richer release automation workflows.

Why CloudKit is amazing and why we’re leaving it

This is a surprisingly candid and nuanced retrospective on migrating away from CloudKit. Rather than criticizing it outright, César Pinto Castillo first acknowledges that for small teams, CloudKit offers an almost unbelievable combination of features: free sync, automatic authentication, end-to-end encryption, serverless infrastructure, and built-in sharing across Apple platforms.

But as their product evolved, CloudKit’s limitations became increasingly apparent: limited server-side observability, manual schema deployment steps, long-standing synchronization edge cases across Apple platforms, heavy reliance on iCloud accounts, and most importantly, the inability to truly expand toward the Web and cross-platform ecosystems. Eventually, César’s team migrated to a Supabase/Postgres-based synchronization architecture.

CloudKit remains one of the strongest moats in Apple’s ecosystem. But as apps grow more complex, datasets larger, and user expectations around synchronization latency higher, its boundaries are becoming increasingly visible. In pursuing “invisible sync,” Apple may also need to seriously rethink this infrastructure layer that has seen relatively little evolution over the years.

Training an LLM in Swift, Part 1: Taking matrix multiplication from Gflop/s to Tflop/s

Training an LLM in Swift sounds somewhat absurd at first glance, but Matt Gallagher delivers an impressively deep performance exploration. Starting from handwritten matrix multiplication — without relying on existing ML frameworks — he gradually optimizes a basic Swift implementation from 2.8 Gflop/s to 1.1 Tflop/s. Through a complete optimization journey, the article reveals what high-performance Swift actually looks like in practice: Swift can absolutely be fast, but as you approach hardware limits, you inevitably enter a world of UnsafeBufferPointer, SIMD, concurrent slicing, memory layout tuning, and GPU tile optimization.

The article is not advocating for handwritten ML kernels in production. On the contrary, Matt repeatedly emphasizes that developers should prefer mature frameworks such as Accelerate, BNNS, Core ML, and MPSGraph whenever possible.

Once Swift is pushed close to C-level performance, can it still preserve the readability and elegance that originally made Swift appealing? This article offers a remarkably concrete — and honest — answer.

Swift Is Great for Apps, Not for Training ML Models

While the previous article demonstrated how handwritten Swift matrix multiplication could be optimized all the way to Tflop/s territory, this article pours some cold water on the idea from a different angle. Mohammad Azam argues that Swift and Core ML are excellent for deploying machine learning models, but poorly suited for modern machine learning training workflows. He points out that the majority of effort in ML development is rarely spent on training itself, but rather on data cleaning, feature engineering, normalization, pipeline composition, and iterative experimentation — areas where the Python ecosystem remains vastly more mature and ergonomic.

Swift is not incapable of reaching into the lower layers of machine learning. But once the problem shifts from “performance” to “data science workflows,” the differences in language priorities and ecosystem maturity quickly become obvious. It also highlights one of Swift’s current dilemmas: while the language itself is capable of expanding into many domains, its surrounding ecosystem still struggles to provide equally smooth experiences outside of application development.

Tools

Swift MarkdownEngine

MarkdownEngine is a native editor engine extracted and open-sourced by the team behind Nodes, their macOS Markdown application. It is neither an HTML renderer nor a WebView wrapper. Instead, it is a source-style Markdown editor built on TextKit 2 and AppKit, then bridged into SwiftUI. The editor preserves plain Markdown text while providing live styling similar to Obsidian Live Preview or iA Writer. Features include wiki links, image embedding, syntax highlighting, LaTeX, task lists, Writing Tools support, and suppression of spell-checking for code, formulas, and links.

TextKit 2 documentation remains sparse and full of behavioral quirks. By open-sourcing an editor stack already used in Nodes.app, this project offers valuable reference material for developers building writing, note-taking, or knowledge-management apps on macOS.

Harness: Let AI Test Your App Like a Real User

Harness is a native macOS developer tool created by Alan Wizemann that can drive iOS Simulators, macOS apps, and Web apps. You describe a goal in natural language, choose a persona, and Harness allows an LLM agent to observe the UI through screenshots, perform clicks and text input, then generate replayable execution paths, success or failure reports, and categorized UX friction logs. Rather than simply letting AI “operate an app,” it feels more like a developer-focused user testing workstation that combines AI agents, screenshots, event logs, credential redaction, replay systems, and friction analysis.

The project is still in alpha. Web support currently depends on WebKit, and Set-of-Mark targeting for iOS/macOS is still planned for the future. As a result, it is better suited for exploring ambiguous UX issues and hidden usability dead-ends than replacing deterministic regression testing. Still, from its use of Swift 6, SwiftUI, SwiftData, actor-based execution flows, JSONL run logs, and cross-provider abstractions for Anthropic/OpenAI/Gemini models, it is already far beyond a simple demo — and a fascinating example of an AI-native developer tool.

Traditional UI testing excels at validating predefined flows created by developers. Harness is attempting to answer a different question: can a real user, with a specific goal and persona, actually complete a task successfully inside your interface?

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

消失的 WWDC 愿望单

网页版

距离 WWDC 2026 只剩下 20 天了。每年到这个时候，我都会看到不少开发者分享自己的 WWDC 愿望单，写下预测与期许。但今年，至少到我汇总本期周报时，这类内容相较去年同期明显少了许多。究竟是开发者对 WWDC 的期待变淡了，还是更多人开始秉持“降低预期才能获得更多惊喜”的心理？

也许问题并不是开发者没有期待，而是旧有的愿望单形式已经不太够用了。过去，我们期待的是某个 API、某个框架、某项功能；而现在，当软件开发迅速向 AI Agent 时代靠拢时，很多期待本身也变得更难被清晰描述。

一年前，恐怕很少有开发者会预料到软件开发会如此迅速地进入 AI Agent 时代。即便我们期待 Xcode 提供更好的 AI 支持，在 Xcode 26.3 推出前，也未必会想到苹果会在 IDE 中提供与 Agent 如此紧密的集成。应用或 API 已不再只是面向消费者或开发者的接口，它们也可能成为 AI Agent 理解、调用和编排的对象。AI 不只是开发工具，也会作为新的参与者，深度进入软件服务的构建和使用过程。

我想，这也是不少开发者面对 WWDC 2026 时既期待又茫然的地方。我们希望看到更新的功能、更稳定的框架、更清晰的平台方向；同时也在思考，在这样的开发体系中，如何继续保持自己作为开发者的独特性与必要性，并与 AI 一起构建更好的服务。

WWDC 2026 究竟会带来多少变化，让我们拭目以待。

BTW：上周我非常有幸入选了苹果官方最新公布的 Apple Developer Community Spotlight。作为一名内容创作者，能够得到这样的认可，对我来说既是鼓励，也是鞭策：继续认真写下去，继续把有价值的内容带给大家。感谢每一位长期阅读、反馈和支持我的朋友。

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

近期推荐

从 URLSession 到电磁波：iOS 网络请求的底层原理 (URLSession to Electrons: How Networking works on iOS)

很多 iOS 开发者都知道：URLSessionDataTask 需要调用 resume() 才会真正开始请求。但在这之后究竟发生了什么？Jacob Bartlett 用一篇长文，带读者一路跟随一个普通的网络请求，从 URLSession、CFNetwork、TCP/IP、Wi-Fi，一直深入到无线电、天线与电磁波。Jacob 不仅串联起 HTTP、DNS、TCP、QUIC、IPv6 等开发者熟悉却未必真正理解的概念，也结合 iOS 内部实现介绍了 Network.framework、XNU 内核 TCP 栈、Wi-Fi 帧结构以及蜂窝网络的调度机制。

一个简单的 resume()，背后涉及的代码与协议演进跨度，可能超过十几甚至几十年。不得不感慨，现代软件世界建立在层层抽象之上，而绝大多数时候，我们其实只是幸运地生活在这些抽象足够稳定的年代。

当 AI 和 Xcode 打架时：我写了个工具来拉架

Xcode 的构建系统从未真正为“并行开发”设计过。多个任务同时构建时，DerivedData、ModuleCache、SwiftPM 缓存乃至 Simulator 都可能互相踩踏，而这一问题在 AI Agent 并行开发场景下被进一步放大。Maples7 在本文中介绍了他的解决方案：VibeChard。它基于 Git Worktree，为每个 AI Agent 创建独立的构建沙箱，并进一步隔离 DerivedData、ModuleCache、SwiftPM 缓存以及模拟器环境。最有意思的是，它并不要求开发者修改构建命令，而是通过 PATH shim 透明接管 xcodebuild，让包括 Tuist、Fastlane 在内的整条工具链都自动运行在隔离环境中。与其说这是一个单纯的辅助工具，不如说它揭示了 AI 编程时代一个更底层的问题：当代码生成速度大幅提升后，传统开发工具链的环境隔离能力也必须随之升级。

Swift 真的被搞得乱七八糟了吗？写了几年之后说点实话

Swift 变得越来越复杂，这是一个不争的事实。但这是否意味着 Swift 已经变成了一门糟糕的语言？迷途酱 从语言演进的现实约束出发，重新审视 Swift 这些年的“膨胀”。作者认为，许多被吐槽的复杂度，其实来自 Swift 同时承担应用层、系统级、DSL 宿主与服务端语言等多重目标，而并发安全与所有权模型本身，也属于计算机科学层面的“硬复杂度”。

文章既讨论了 Sendable、actor isolation、borrowing、~Copyable 等近年来快速增长的新概念，也坦率指出 Swift 在并发关键字、泛型语法以及 SwiftUI “魔法感”上的设计问题。尤其是“Swift 其实是一个语言的多个层级”这一观点，相当值得思考：绝大多数开发者日常写 App 时，其实并不需要承担全部复杂度，但 WWDC 与官方文档却经常把这些内容同时呈现在所有人面前。

Xcode Cloud 进阶：Shell 脚本自动化实战 (Writing shell scripts for Xcode Cloud)

Xcode Cloud 的上手体验已经足够简单，但在真实项目中，许多自动化需求仍然需要借助 shell scripts 完成。Amy Delves 以“在归档完成后自动创建 GitHub Release”为例，展示了如何结合 Xcode Cloud 提供的环境变量判断当前构建是否来自 main 分支的归档流程，如何读取 archive 中的版本号与构建号生成 tag，并通过 GitHub API 创建 release。虽然示例本身并不复杂，但它很好地说明了 Xcode Cloud 并不只是一个“点几下就能跑测试”的服务：借助环境变量、脚本钩子与外部 API，它同样可以承担更完整的发布自动化工作流。

我们为什么离开了很棒的 CloudKit (Why CloudKit is amazing and why we’re leaving it)

这是一篇相当少见、坦诚的 CloudKit 迁移复盘。César Pinto Castillo 并没有简单批评 CloudKit，恰恰相反，他首先承认：对于小团队来说，CloudKit 几乎提供了一套“不可思议”的能力组合——免费同步、自动身份认证、端到端加密、无服务器运维，以及跨 Apple 平台的共享能力。

但随着产品逐渐发展，CloudKit 的另一面也开始显现：缺乏服务端可观测性、Schema 发布依赖手动操作、不同 Apple 平台间长期存在的同步边缘问题、对 iCloud 账户的强依赖，以及最关键的——无法真正走向 Web 与跨平台生态。最终，César 所在的团队将数据迁移到了基于 Supabase/Postgres 的同步架构。

CloudKit 是苹果生态最重要的护城河之一。但在应用越来越复杂、数据规模越来越大、用户对同步实时性的要求越来越高的今天，它的能力边界也开始显现。在追求“无感同步”的同时，我想苹果也确实需要重新认真审视这个多年未发生明显演进的基础设施了。

用 Swift 手写 LLM 训练内核 (Training an LLM in Swift, Part 1: Taking matrix multiplication from Gflop/s to Tflop/s)

在 Swift 中训练 LLM 听起来多少有些“匪夷所思”，但 Matt Gallagher 做了一次非常硬核的性能探索：不依赖现成机器学习框架，而是从手写矩阵乘法开始，一步步将基础 Swift 实现从 2.8 Gflop/s 优化到 1.1 Tflop/s。文章通过一个完整的优化过程，展示了高性能 Swift 的现实面貌：Swift 并不是不能快，但当你逐渐逼近硬件能力时，也将不可避免地进入 UnsafeBufferPointer、SIMD、并发切片、内存布局与 GPU tile 优化的世界。

这篇文章的价值并不在于鼓励开发者手写机器学习内核。恰恰相反，作者反复强调，生产环境应该优先使用 Accelerate、BNNS、Core ML、MPSGraph 等成熟框架。

当 Swift 被优化到接近 C 的程度时，它还能否保持原本的可读性与优雅？这篇文章给出了一个非常具体，也很诚实的答案。

Swift 适合写 App，但不适合训练 ML 模型 (Swift Is Great for Apps, Not for Training ML Models)

上一篇文章还在展示如何将 Swift 手写矩阵乘法一路优化到 Tflop/s，这篇文章则从另一个角度泼了盆冷水：Mohammad Azam 认为，Swift 与 Core ML 非常适合“部署”机器学习模型，但并不适合承担现代机器学习训练流程本身。Mohammad 指出，真正耗费时间的往往不是模型训练，而是数据清洗、特征工程、归一化、Pipeline 组合与实验迭代，而这些恰恰是 Python 生态最成熟、最顺手的领域。

Swift 并非不能触碰机器学习底层，但当问题从“性能”转向“数据科学工作流”后，语言与生态的重心差异便会迅速显现。这也凸显了 Swift 当前的一个困境：它具备进入多个领域的语言能力，但在应用开发之外，配套生态仍不足以支撑同等顺畅的开发体验。

工具

Swift MarkdownEngine

MarkdownEngine 是 Nodes 团队从自家 macOS Markdown 应用中抽离并开源的原生编辑器引擎。它不是 HTML 渲染器，也不是 WebView 包装，而是基于 TextKit 2 与 AppKit 构建，并桥接到 SwiftUI 的 source-style Markdown 编辑器：文本仍保持纯 Markdown，但在编辑时提供类似 Obsidian Live Preview / iA Writer 的实时样式。项目支持 wiki link、图片嵌入、代码块高亮、LaTeX、任务列表、Writing Tools，以及针对代码、公式和链接的拼写检查抑制。

TextKit 2 文档稀薄、行为细节多，而这个项目把一套已在 Nodes.app 中使用的编辑器能力开源出来，对正在开发写作、笔记或知识管理类 macOS 应用的开发者很有参考价值。

Harness：让 AI 像真实用户一样测试你的 App

Harness 是由 Alan Wizemann 开发的一款原生 macOS 开发者工具，可以驱动 iOS Simulator、macOS App 和 Web App。你用自然语言写下目标，选择一个 persona，Harness 会让 LLM agent 基于截图观察界面、执行点击和输入，并生成可回放的运行路径、成功或失败结论，以及按类型记录的 UX friction。相比单纯让 AI “操作应用”，它更像是把 AI agent、截图、事件日志、凭证脱敏、运行回放和摩擦分类整合成了一套面向开发阶段的用户测试工作台。

目前项目仍处于 alpha 阶段，Web 端依赖 WebKit，iOS/macOS 的 Set-of-Mark 定位能力还在规划中，因此更适合用于探索产品体验中的模糊点和死角，而不是替代确定性的回归测试。不过从 Swift 6、SwiftUI、SwiftData、actor 化的执行流程、JSONL run log，以及跨 Anthropic/OpenAI/Gemini 的模型抽象来看，它已经不是一个简单 demo，而是一个很值得观察的 AI-native developer tool 样本。

传统 UI 测试更擅长验证开发者预设好的路径，而 Harness 试图回答另一个问题：一个带着具体目标和身份设定的真实用户，会不会在你的界面中顺利完成任务。

CocoaPods Is on Its Way Out, but SwiftPM’s Story Is Just Entering Chapter Two

Read on web →

Google recently announced that, starting with the next Flutter stable release, version 3.44, Swift Package Manager will replace CocoaPods in the default workflow and become the default dependency manager for iOS and macOS apps. CocoaPods’ Trunk repository will officially become read-only on December 2, 2026 — a date we already discussed in the 2024 issues of the newsletter. Still, when Flutter truly began replacing CocoaPods with SPM in its default path, it sparked widespread discussion across the community.

Many developers who have long been constrained by CocoaPods, especially those with a front-end background, greeted the news with great enthusiasm. After all, they can finally spend less time wrestling with gem install on M-series Macs, and they no longer have to face those mysterious Pods errors that always seem to appear from nowhere yet somehow manage to block the build process with surgical precision. The update even briefly turned into something of a “celebration of breaking free from Ruby.” However, because Flutter’s official switch came somewhat abruptly, many third-party plugin authors also felt anxious, as issues requesting Package.swift support quickly began pouring into numerous open-source projects.

Compared with the short-term adaptation pressure on plugin authors, the more lasting test brought by this transition lies in the reconstruction of CI/CD workflows for enterprise projects. For teams whose foundations still contain a large number of historical CocoaPods dependencies, switching to SPM smoothly and with as little pain as possible will become a major infrastructure-level challenge. Migration is not simply a matter of adding a Package.swift file locally. It means that build caches, private dependencies, binary frameworks, Xcode project generation, static and dynamic linking strategies, and multi-platform build scripts all need to be recalibrated.

This is not limited to Flutter. Given that CocoaPods has long acted as the “universal glue” between cross-platform frameworks and the native iOS ecosystem, communities such as React Native and KMP have also begun laying the groundwork for migration to SPM, while Unity-related iOS dependency resolution workflows have also started supporting SPM. Over the next period, cross-platform communities built around Apple platform build pipelines will very likely go through a painful “great migration.” It is fair to say that by 2027, SPM — a tool that has already been around for a decade — will most likely complete its “great unification” of the mainstream dependency management path across Apple platforms.

For SPM, this is undoubtedly a major victory. But we should also be clear-eyed about what this victory means. It does not mean that SPM has achieved a true breakthrough beyond its original circle. Rather, it looks more like an inward-facing victory within Apple’s native ecosystem: replacing an older solution from the Objective-C era with a modern toolchain that offers better Swift support and tighter integration with Xcode. As long as cross-platform frameworks want to deliver reliably on Apple platforms, they will ultimately find it difficult to bypass Apple’s native rules.

So where will SPM go in its next decade? Will it continue to serve as the “internal optimal solution” for Apple’s ecosystem, or will it truly step beyond the walls and compete on the same stage as tools like Cargo and npm? The answer probably does not lie in SPM itself, but in whether the Swift language can produce truly killer use cases in areas such as Linux, Android, and embedded systems.

Until that day arrives, there is one thing we can be certain of: CocoaPods’ exit is already irreversible, but SwiftPM’s story has only just turned to its second chapter.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

Deep Understanding while using LLMs

At the beginning of his SwiftUI workshops, Chris Eidhof tells attendees to put LLMs aside during the exercises. The reason is not that he is against AI, but that getting an answer quickly with an LLM is not the same as truly understanding the problem. The core of this article is an increasingly visible phenomenon in the age of AI-assisted programming: more and more developers are falling into “shallow thinking.” They keep prompting, patching, and pushing features forward, while gradually losing a real understanding of the system itself. Once project complexity increases, things start to spiral out of control.

The article’s subtitle, “Solve It in 20 Minutes — Or Actually Understand It,” is not only a description of the workshop setting, but also a choice that the AI programming era places in front of developers. LLMs do not replace engineering ability; they amplify the understanding and judgment that developers already have.

Installing Swift scripts as global commands with npm

More Swift developers are starting to use Swift to write CLI tools. But during development, having to recompile after every change, manually move the binary, or maintain shell aliases can easily interrupt the iteration flow. Cristian Felipe Patiño Rojas offers a creative solution: use npm’s bin mechanism to register a Swift script with a shebang as a global command. This allows the Swift script to be invoked just like a regular CLI tool, while npm only creates a global symlink and does not participate in building the Swift code.

Considering that launching a script through swift has a nontrivial cold-start cost, often taking several seconds, this approach is better suited to the development stage of Swift CLI tools. For small utilities like these, developers do not necessarily need to turn them into full Swift Packages from the very beginning. Starting with the lightest possible approach, then compiling and distributing the tool once it stabilizes, is often a better fit for real-world workflows.

WatchConnectivity was failing 40% of the time. So I stopped using it.

While building real-time communication for an Apple Watch app, Tarek Sabry ran into a very frustrating problem: Apple’s official WatchConnectivity framework was unstable, with a connection success rate of only around 60%. Eventually, Tarek stopped treating WatchConnectivity as the only reliable channel and introduced a parallel network transport path instead: BLE for service discovery, HTTP for data transfer, SSE for the push channel, plus frame IDs, ack confirmation, deduplication, and retransmission. This successfully raised the connection success rate from 60% to 99%, with an almost immediate effect.

The more interesting by-product of this approach is that, because it is entirely based on standard network protocols, the Watch does not know whether the other end is an iPhone, an Android phone, or any device with an IP address. According to the author, as of April 2026, this is the only publicly available Android ↔ Apple Watch communication solution. The solution has been open-sourced under the name WatchLink, supports Swift 6, and has no third-party dependencies.

Using SwiftUI to Build a Mac-assed App in 2026

The term “Mac-assed app” describes software that truly belongs on the Mac: it uses native system controls, deeply integrates with system features, and gets every interaction detail aligned with platform conventions. While building a macOS app entirely in SwiftUI, Paulo Andrade found that although SwiftUI provides enough APIs to cover simple scenarios, the framework itself often becomes an obstacle when developers try to reproduce the interaction conventions that Mac apps have accumulated over decades.

The article breaks down several clear shortcomings of SwiftUI on macOS today: custom lists struggle to fully reproduce the subtle differences between selection, loss of focus, and right-click context targets; there is no way to detect when a context menu is open, making it difficult to correctly highlight the object the menu applies to; visibility into drag state is almost nonexistent; keyboard navigation is easily “swallowed” once a TextField has focus; and toolbar layout control is far less precise than in AppKit. Paulo argues that SwiftUI still has not completed the handoff from AppKit.

Scheduling and handling background app refresh in SwiftUI

Background refresh in iOS may look simple at the API level, but it is easy to run into pitfalls in practice. In this article, Natalia Panferova demonstrates how to configure BGAppRefreshTaskRequest with the Background Tasks framework under the SwiftUI App lifecycle, and how to register the handling logic through the backgroundTask(_:action:) scene modifier. The article walks through the full basic flow of adding background refresh to a SwiftUI app, from enabling Background Modes and registering the task identifier in Info.plist, to submitting the background refresh request and handling the app when the system wakes it. The author also explains how to simulate a background task trigger on a physical device using an Xcode debugger command, making it easier to verify the logic during development.

It is worth noting that background refresh is not a precise scheduler. Even if earliestBeginDate is set, the system decides whether and when to wake the app based on factors such as battery level and user behavior. Therefore, critical logic should not depend on it running on time.

How to avoid Swift 6 concurrency crashes

Even with zero compile-time warnings under Swift 6 strict concurrency mode, runtime safety is not guaranteed. The compiler injects dynamic isolation assertions at actor and GCD boundaries, and if the execution path does not match the compiler’s assumptions, the app can still crash in production with _dispatch_assert_queue_fail or _swift_task_checkIsolatedSwift.

Khoa lists several common triggering scenarios: closures defined inside an @MainActor context inherit main actor isolation, and if they are later called on a background thread by old-style callback or queue-based APIs, a crash may occur; in Combine pipelines, the position of receive(on:) affects closure isolation inheritance; and if a delegate method inherits main actor isolation because the entire class is marked @MainActor, but the SDK actually calls it from an internal queue, it can also trigger a runtime assertion.

The approaches Khoa introduces in this article can help developers quickly locate and fix common runtime crash points when migrating old projects to Swift 6. However, if time and energy allow, the more ideal direction is still to reorganize feature code according to Swift 6’s modern concurrency model, make isolation boundaries explicit, and reduce reliance on local annotations and patch-style fixes.

Tools

SwiftMetalNumerics: A Swift-native GPU numerical computing library for Apple Silicon

When building real-time audio analysis or on-device signal modeling on Apple platforms, developers often get stuck in an awkward middle ground. High-level APIs such as SoundAnalysis and AVAudioEngine are convenient, but they often behave like black boxes that only provide processed results. Once you need to control STFT, frequency binning, matrix operations, or feed extracted features into custom neural network layers, you often have to bridge back and forth between Accelerate/vDSP and low-level Metal. CPU-side computation can be fast, but once the downstream computation enters the GPU pipeline, data movement and synchronization may become the bottleneck for real-time processing.

Bugra Acemoglu’s SwiftMetalNumerics is a new project aimed precisely at this middle ground. It tries to wrap Metal / MPS / MPSGraph and Accelerate / LAPACK on Apple Silicon behind Swift APIs, bringing matrix computation, FFT/STFT, convolution, and basic neural network layers into a unified numerical computing interface. What makes it interesting is not merely “GPU acceleration,” but its attempt to take advantage of the unified memory architecture to minimize back-and-forth copying between DSP, matrix computation, and lightweight ML pipelines.

SwiftMetalNumerics is not a full replacement for Accelerate. For small-scale, one-off computations, the CPU path is often still faster. But if your task is a longer real-time signal processing or on-device inference pipeline, SwiftMetalNumerics presents a direction worth watching: connecting low-level mathematical control with GPU computing power in a more Swift-native and Apple Silicon-native way.

SwiftUI Preview Runner: A SwiftUI preview engine for custom tools and AI workflows

SwiftUI Preview Runner is an inspiring experimental project developed by Aryan Rogye. It does not launch a simulator, nor does it replicate Xcode Preview’s XPC-based preview mechanism. Instead, it writes a piece of SwiftUI code into a temporary Swift Package, compiles it into a dynamic library, dynamically loads it with dlopen, and renders it inside a host macOS app using NSHostingView.

As a result, it feels more like a “SwiftUI Playground” that can be embedded into custom toolchains: you can connect an editor, AI generation, an MCP validator, or other automation workflows in front of it, allowing generated SwiftUI code to immediately enter a feedback loop of “can it compile, and can it render?”

Note that the project targets macOS SwiftUI rendering, not the iOS simulator; compilation introduces latency; and dynamically loading code also means the security boundary must be handled with great care. Even so, as an exploration of how AI-generated SwiftUI can receive real runtime feedback, it is worth paying attention to.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

CocoaPods 正在退场，SwiftPM 才刚到第二章

网页版

谷歌近期宣布，从下一个 Flutter 稳定版 3.44 开始，Swift Package Manager 将在默认路径上取代 CocoaPods，成为 iOS 和 macOS 应用的默认依赖管理器。CocoaPods 的 Trunk 仓库计划于 2026 年 12 月 2 日正式进入只读状态——这个时间点我们在 2024 年的周报中就讨论过了，但当 Flutter 真正开始在默认路径上用 SPM 替换 CocoaPods 时，还是引发了社区的广泛热议。

不少长期受制于 CocoaPods 的开发者，尤其是前端背景的开发者，对此表达了极大的喜悦。毕竟，他们终于可以少在 M 系列 Mac 上折腾 gem install，也不用再面对那些来路不明、却又总能精准卡住构建流程的 Pods 报错了。这场更新甚至一度演变成了一场“摆脱 Ruby 的狂欢”。不过，由于 Flutter 这次官方切换略显突然，不少第三方插件作者也感到了焦虑，要求适配 Package.swift 的 Issue 迅速涌入了不少开源库。

相较于插件作者的短期适配压力，本次切换更长期的考验其实在企业级项目的 CI/CD 重构上。对于那些底层仍带有大量 CocoaPods 历史依赖的团队来说，如何平滑、尽可能低痛地切换到 SPM，将成为基建层面的一项重大挑战。迁移并不是只在本地多写一个 Package.swift，而是意味着构建缓存、私有依赖、二进制框架、Xcode 工程生成、静态/动态链接策略以及多平台构建脚本都要跟着重新校准。

不仅是 Flutter，考虑到 CocoaPods 曾长期充当跨端框架与 iOS 原生生态之间的“万能胶水”，React Native、KMP 等社区也已经开始铺设向 SPM 迁移的路径，Unity 相关的 iOS 依赖解析链路也开始支持 SPM。接下来一段时间，围绕 Apple 平台构建链路的跨端社区，大概率会经历一场阵痛式的“大迁徙”。可以说，到 2027 年，SPM 这个已经面世十年的工具，将大概率完成对 Apple 平台主流依赖管理路径的“大一统”。

对于 SPM 而言，这无疑是一个巨大的胜利。但我们也必须看清，这并不代表 SPM 已经实现了真正意义上的“破圈”。它更像是苹果原生生态的一场“内卷式胜利”：用一套对 Swift 支持更完整、与 Xcode 集成更紧密的现代工具，替换掉了属于 Objective-C 时代的旧有方案。只要还想在 Apple 平台上稳定交付，跨平台框架最终都很难绕开苹果的原生规则。

那么，SPM 的下一个十年会走向哪里？是继续做苹果生态的“内部最优解”，还是真正走出围墙，和 Cargo、npm 这样的工具站到同一个竞争舞台上？答案恐怕并不在 SPM 自身，而在 Swift 语言能不能在 Linux、Android、嵌入式等场景里跑出真正的杀手级用例。

在那一天到来之前，我们能确定的只有一件事：CocoaPods 的退场已经不可逆，但 SwiftPM 的故事，才刚刚翻到第二章。

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

近期推荐

警惕 AI 编程时代的“浅层思考” (Deep Understanding while using LLMs)

Chris Eidhof 会在其 SwiftUI workshop 开始时告知学员，练习期间请暂时放下 LLM。原因并不是他反对 AI，而是通过 LLM 快速得到答案，并不等于真正理解问题。这篇文章讨论的核心，是当前 AI 编程时代一个越来越明显的现象：越来越多开发者开始陷入“浅层思考”。不断 prompt、不断修补、不断推进功能，却在不知不觉中失去对系统本身的真实理解。一旦项目复杂度上升，问题便开始失控。

本文的副标题 “Solve It in 20 Minutes — Or Actually Understand It”，不只是对 workshop 场景的描述，也像是 AI 编程时代摆在开发者面前的一道选择题。LLM 并不会替代工程能力，它只会放大开发者已有的理解与判断。

巧用 npm 全局安装 Swift 脚本 (Installing Swift scripts as global commands with npm)

越来越多 Swift 开发者开始用 Swift 编写 CLI 工具。但在开发过程中，每次修改后都需要重新编译、手动移动 binary，或维护 shell alias，很容易打断迭代节奏。Cristian Felipe Patiño Rojas 给出了一个很有创意的解决方案：借助 npm 的 bin 机制，将带有 shebang 的 Swift 脚本注册为全局命令。这样一来，Swift 脚本可以像普通 CLI 工具一样直接调用，而 npm 只负责创建全局软链接，并不参与 Swift 代码的构建过程。

考虑到通过 swift 启动脚本的冷启动开销并不小，通常可能需要数秒，该方案更适合用于 Swift CLI 的开发阶段。对于这类小工具，开发者并不一定要一开始就做成完整 Swift Package。先用最轻的方式跑起来，等工具稳定后再编译和分发，往往更加符合实际工作流。

弃用 WatchConnectivity：打造高可靠的 Watch 通信方案 (WatchConnectivity was failing 40% of the time. So I stopped using it.)

在为 Apple Watch app 构建实时通信能力时，Tarek Sabry 遇到了一个很令人头疼的问题：官方的 WatchConnectivity 并不稳定，连接成功率只有约 60%。最终，Tarek 选择不再把 WatchConnectivity 作为唯一可靠通道，而是引入一套并行的网络传输路径：用 BLE 做服务发现、HTTP 做数据传输、SSE 建立推送通道，再配合 frame ID、ack 确认、去重和重传机制。成功地将连接成功率从 60% 提升到 99%，效果几乎是立竿见影。

更有意思的是这个方案的副产品：由于完全基于标准网络协议，Watch 并不知道另一端是 iPhone、Android 手机，还是任意带 IP 地址的设备。据作者称，截至 2026 年 4 月，这是公开可用的唯一一个 Android ↔ Apple Watch 通信解决方案。该方案已开源，命名为 WatchLink，支持 Swift 6，无第三方依赖。

SwiftUI 离极致原生的 Mac 应用还有多远？ (Using SwiftUI to Build a Mac-assed App in 2026)

“Mac-assed app” 一词描述的是那种真正属于 Mac 的软件：使用系统原生控件、深度集成系统功能，每一个交互细节都符合平台惯例。Paulo Andrade 在使用纯 SwiftUI 开发 macOS 应用时发现，尽管 SwiftUI 提供了足以覆盖简单场景的 API，但当开发者试图还原 Mac 应用几十年积累下来的交互惯例时，框架本身反而常常成了阻碍。

文章拆解了当前 SwiftUI 在 macOS 上的几个明显短板：自定义列表难以完整还原选中、失焦与右键上下文目标之间的细微状态差异；右键菜单打开时无法感知，导致开发者难以正确高亮菜单作用对象；拖拽过程中的状态可见性几乎为零；键盘导航在 TextField 获焦后很容易被“吞掉”；工具栏的布局控制能力也远不及 AppKit 精细。Paulo 认为，SwiftUI 仍未完成对 AppKit 的交接。

SwiftUI 后台应用刷新的调度与处理指南 (Scheduling and handling background app refresh in SwiftUI)

iOS 中的后台刷新功能看似 API 简单，但实际很容易踩坑。Natalia Panferova 在本文中演示了如何在 SwiftUI App 生命周期下使用 Background Tasks framework 配置 BGAppRefreshTaskRequest，并通过 backgroundTask(_:action:) scene modifier 注册处理逻辑。文章从启用 Background Modes、在 Info.plist 中登记 task identifier，到提交后台刷新请求和处理系统唤醒，完整串起了 SwiftUI 应用接入后台刷新的基本流程。作者还介绍了如何通过 Xcode 调试器命令在真机上模拟后台任务触发，便于开发阶段验证逻辑。

值得注意的是，后台刷新并不是一个可精确调度的定时器。即使设置了 earliestBeginDate，系统也会根据电量、用户使用习惯等因素自行决定是否以及何时唤醒应用，因此关键逻辑不应依赖它准时执行。

Swift 6 并发运行时崩溃避坑指南 (How to avoid Swift 6 concurrency crashes)

Swift 6 严格并发模式下即便编译期零警告，也并不等于运行期安全。编译器会在 actor 边界和 GCD 边界注入动态隔离断言，一旦执行路径与编译器的假设不符，仍可能在生产环境中触发 _dispatch_assert_queue_fail 或 _swift_task_checkIsolatedSwift 崩溃。

Khoa 列举了几类常见触发场景：@MainActor 上下文中定义的闭包会继承主 actor 隔离，若随后被旧式 callback 或 queue API 在后台线程调用，便可能触发崩溃；Combine pipeline 中 receive(on:) 的位置顺序会影响闭包的隔离继承；delegate 方法若因整个类标注了 @MainActor 而继承主 actor 隔离，但 SDK 实际从内部队列回调，同样会触发运行时断言。

Khoa 在本文中介绍的方法，能帮助开发者快速定位并修复旧项目迁移 Swift 6 时常见的运行时崩溃点。不过，如果精力许可，更理想的方向仍然是按照 Swift 6 现代并发的构型重新组织功能代码，明确隔离边界，减少对局部标注和补丁式修复的依赖。

工具

SwiftMetalNumerics：面向 Apple Silicon 的 Swift 原生 GPU 数值计算库

在 Apple 平台上做实时音频分析或端侧信号建模时，开发者常会卡在一个尴尬位置：SoundAnalysis、AVAudioEngine 这类高层 API 足够方便，但很多时候像黑箱，只给整理好的结果；而当你需要自己控制 STFT、频率分桶、矩阵运算，甚至把特征继续送入自定义神经网络层时，又往往要回到 Accelerate/vDSP 和底层 Metal 之间来回衔接。CPU 侧计算很快，但一旦后续计算进入 GPU 管线，数据搬运和同步就可能成为实时处理的瓶颈。

Bugra Acemoglu 开发的 SwiftMetalNumerics 正是瞄准这个中间地带的一个新项目。它尝试用 Swift API 封装 Apple Silicon 上的 Metal / MPS / MPSGraph 与 Accelerate / LAPACK，把矩阵计算、FFT/STFT、卷积和基础神经网络层放进同一套数值计算接口中。它真正有意思的地方不只是“GPU 加速”，而是利用统一内存架构，尽量减少 DSP、矩阵计算和轻量 ML pipeline 之间的来回拷贝。

SwiftMetalNumerics 并不是 Accelerate 的全面替代品。小规模、单次计算，CPU 路径往往仍然更快；但如果你的任务是一条较长的实时信号处理或端侧推理管线，SwiftMetalNumerics 展示了一个值得关注的方向：用更 Swift、更 Apple Silicon-native 的方式，把原始数学控制权和 GPU 计算能力连接起来。

SwiftUI Preview Runner：面向自定义工具与 AI 工作流的 SwiftUI 预览引擎

SwiftUI Preview Runner 是一个很有启发性的实验项目，由 Aryan Rogye 开发。它并不是调用模拟器，也不是复刻 Xcode Preview 的 XPC 预览机制，而是把一段 SwiftUI 代码写入临时 Swift Package，编译成动态库，再通过 dlopen 动态加载，并在宿主 macOS App 中用 NSHostingView 渲染出来。

因此，它更像是一个可嵌入自有工具链的“SwiftUI Playground”：你可以把编辑器、AI 生成、MCP validator 或其他自动化流程接到它前面，让生成出来的 SwiftUI 代码立即进入“能否编译、能否渲染”的反馈环。

需要注意的是：该项目的渲染目标是 macOS SwiftUI，不是 iOS 模拟器；编译会带来延迟；动态加载代码也意味着安全边界必须非常谨慎。尽管如此，作为“如何让 AI 生成的 SwiftUI 获得真实运行反馈”的探索样本，它值得关注。

Getting AI from Handy to Heartfelt

Read on web →

It’s been three years since I started using AI tools in earnest. Over these three years, I’ve witnessed AI’s remarkable leaps in capability — and grown increasingly aware of its limits. By now, AI has firmly established itself as an excellent productivity tool. Yet getting it to produce code that truly feels “heartfelt” — code that aligns with my personal style, ideas, and design philosophy — remains a considerable challenge.

Even though mainstream models now routinely offer 1M-token context windows, the information they can carry still falls far short of a human developer’s holistic grasp of a project as it grows. Compounded by attention decay, the truly usable context is actually quite limited. This is why, over the past stretch of time, I’ve published fewer technical articles written for human readers — and produced quite a lot of documentation written for AI instead. Readers often write to ask why my blog has slowed down; this is the reason.

The point of writing all this dedicated documentation isn’t merely to give AI enough context to work with. More importantly, I’m exploring a SwiftUI state pattern of my own design — one that diverges significantly from the prevailing paradigm. This means AI’s vast trove of pretraining data often becomes noise, even active resistance: it keeps unconsciously pulling you back toward the most common conventions. The whole process therefore takes on a kind of tug-of-war rhythm. I use AI to validate ideas rapidly, turning vague intuitions into precise contracts and interfaces; in parallel, I keep refining the documentation, which in turn constrains the AI and steers it toward code that matches my intent.

There’s still some distance to the finish line, but as the code, structure, and documentation iterate together — and especially as my half-formed ideas gradually crystallize and land — I can feel a clear shift: the AI is becoming noticeably more fluent within this project, and its output is converging on what I have in mind.

There are countless ways to arrive at the same UI outcome. What I want is to use various constraints to make AI choose the specific path I’ve laid out. I’m not claiming my own code is flawless — only that I want AI’s output to feel familiar and within my grasp, so I can step in and maintain it without friction.

With clear goals and thorough guidance, AI now implements things tens or even hundreds of times faster than I can. When “efficiency” is no longer the bottleneck, the real question for the next stage is how to make this lightning-fast assistant more heartfelt — more in tune with us.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

Q&A: Swift Concurrency - Formatted

This is a transcript of a Swift Concurrency Q&A with Apple engineers, compiled by Anton Gubarenko. In the session, the engineers addressed many of the most commonly misunderstood aspects of Swift’s current concurrency model: from the behavior change behind nonisolated(nonsending), to the boundaries of @concurrent, to Task lifetime and cancellation. Rather than merely adding more knowledge, this feels more like a “semantic recalibration.”

One noteworthy signal is that Swift is moving from “async implies concurrency by default” toward a more conservative default, where concurrency is introduced explicitly only when needed.

Immediate tasks in Swift Concurrency explained

Swift 6.2 introduced a subtle but useful new feature: Task.immediate. Unlike a regular Task, an immediate task starts synchronously in the current execution context and continues running until the first actual suspension point. Antoine van der Lee offers a clear explanation of its behavior in this article.

This capability mainly fills a long-standing gap: calling async logic from a synchronous context while still preserving execution order, such as immediately updating state when the actor isolation is already correct. In these scenarios, Task.immediate can avoid the timing mismatch caused by scheduling delay.

Its risk is just as direct: if heavy synchronous work runs before the first suspension point, especially on the MainActor, it can block the current executor and cause visible UI hitches. Task.immediate only changes when a task starts executing, not the task’s overall lifecycle. In most cases, the regular Task scheduling behavior remains the safer choice.

Concurrency Step-by-Step: Designing Protocols

In this article, Matt Massicotte shares a more practically executable approach to protocol design in the context of Swift 6 strict concurrency.

In Swift 6, protocol design has become more difficult than ever. You are no longer just defining methods; you are also defining isolation boundaries. Should the protocol be marked @MainActor? Should it inherit from Sendable? Should its methods be async? Matt points out that many of the “waterfalls of concurrency errors” developers encounter when adopting Swift 6 may look like isolation-domain conflicts on the surface, but are often architectural problems caused by premature abstraction. If you try to design the perfect protocol before the requirements are clear, it is very easy to get “locked in” by concurrency rules.

Matt’s advice is to avoid starting with a protocol. Start with concrete types instead. Let the interface boundaries gradually emerge from real usage, and postpone abstractions that involve isolation domains or context-dependent capabilities. This approach helps avoid falling into the trap of fat protocols and excessive constraints in the concurrency era. Rather than a protocol design guide, it is more like a pragmatic “delay decisions” strategy for Swift 6.

Automating your Xcode Project

Xcode project files have long been a source of trouble in version control. Starting from this pain point, Leo G Dion introduces practical ways to generate Xcode projects using XcodeGen and Tuist, along with a fairly complete Tuist workflow. The article also walks through the key configuration required for a minimally shippable project: deployment target, App Icon, Privacy Manifest, signing information, and version management, forming a useful automation-oriented “project checklist.”

Although I am currently the only developer on my projects, I have also switched to generating Xcode projects with Tuist. On one hand, these tools provide a higher degree of engineering determinism. On the other hand, their value is further amplified in AI-assisted development: most agents support them well, and when files in the workspace are modified, they can automatically trigger generate when compilation requires it. Tools like Tuist and XcodeGen are gradually becoming more AI-friendly engineering infrastructure.

Appearance Mode Changer

Two days ago, Stewart Lynch celebrated his 75th birthday. In a post, he wrote: “75 years of patches, upgrades, bug fixes, deprecated habits, and surprisingly few fatal errors. Still compiling. Still shipping. Still learning.”

As a well-known video tutorial creator, Stewart has also recently restarted his blog, publishing short tips in written form. This article covers an implementation of appearance mode switching in SwiftUI.

For those of us working in a fast-moving industry that can easily trigger age anxiety, this may be one of the most enviable states a developer can reach. Happy birthday to Stewart, and I hope this “Still” spirit reaches everyone as well.

Six Years Perfecting Maps on watchOS

In this design diary, David Smith looks back on the six-year journey of building the Apple Watch mapping experience for Pedometer++.

The most valuable part of the article is not the implementation itself, but the series of trade-offs behind it: interactions on watchOS must be direct enough, complex configuration is almost unacceptable, and the relationship between map and data requires constant balancing between readability and information density. Even the base map is no longer an off-the-shelf dependency, but something specifically customized for Liquid Glass. His technical choice is also representative: even though MapKit has arrived on watchOS, he still chose a fully custom solution because its configurability and expressiveness remain limited. Behind this decision is not only technical capability, but also a clear sense of product-experience priorities.

This is a classic example of long-term product refinement.

Tools

Kadr: Describing Video Composition with a Swift DSL

Developed by Steliyan Hadzhidenev, Kadr is a Swift-native video composition library that uses a Result Builder DSL to organize AVFoundation’s otherwise scattered concepts — clips, transitions, multiple tracks, filters, overlays, audio, and export workflows — into a declarative API. What makes it worth following is not merely the cleaner syntax, but how it demonstrates the coordination of Swift 6 strict concurrency, Sendable, async/await, and time models such as CMTime in a real media-processing context.

Its companion project, KadrUI, provides a set of SwiftUI-side editing components, including VideoPreview, OverlayHost, multi-track TimelineView, InspectorPanel, and KeyframeEditor. This means the DSL is not limited to export workflows, but can also support core video-editor interactions such as previewing, dragging, trimming, keyframes, and overlay editing.

SwiftVLC: A Modern libVLC Wrapper for SwiftUI

Developed by Omar Albeik, SwiftVLC is a SwiftUI-oriented Swift wrapper around libVLC 4.0. Compared with the traditional VLCKit, it removes the Objective-C middle layer and directly provides an @Observable Player, AsyncStream event streams, typed throws, and a VideoView(player) that can be integrated in a single line. Its value is not just that it is “more Swift,” but that it offers a way to connect low-level multimedia capabilities with the modern Swift concurrency model. If your app needs to handle formats, subtitles, or complex network protocols that AVFoundation does not cover well, libVLC-based solutions remain hard to replace.

Of course, the limitations are equally clear: it requires relatively new system versions, and the underlying libVLC still requires attention to LGPL compliance.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

让 AI 从称手到称心

网页版

从开始深度使用 AI 工具至今已有三年。三年间，我亲历了 AI 能力的飞跃，也越来越清晰地触摸到它的边界。截至目前，AI 早已是非常出色的效率工具，但如何让它写出真正“称心”——符合我个人风格、想法与设计哲学——的代码，仍是一个不小的挑战。

即便主流模型已普遍提供 1M token 的上下文窗口，但随着项目规模扩大，它所能承载的信息依然远远落后于人类开发者的“全局观”；叠加注意力衰减问题，真正可用的上下文其实相当有限。这也是为什么最近一段时间，我减少了写给人类阅读的技术文章，却产出了不少写给 AI 看的文档——常有读者来信问我博客为何更新放缓，原因正在于此。

之所以要编写大量的专属文档，不仅仅是为了给 AI 提供足够的上下文指导，更重要的是，我正在探索一套自研的 SwiftUI 状态模式。它与当前主流的开发范式有很大区别——这意味着，AI 庞大的预训练数据在此时经常变成“噪音”甚至阻力，它总是不自觉地把你拉回最常见的写法。整个开发过程因此呈现出一种“拉锯”的节奏：我用 AI 快速验证，把模糊的想法落实为精准的合约与接口；同时不断完善文档，反过来约束 AI，让它写出更贴近我心意的代码。

尽管距离最终完成还有一段时间，但随着代码、结构、文档的持续迭代，尤其是那些尚未完全成型的想法逐渐清晰并落地之后，我能明显感觉到：当前的 AI 在这个项目中越来越顺手，它写出的代码正在逐渐向我的预期靠拢。

实现相同的界面结果可以有无数种方式，但我希望通过种种约束，让 AI 只选择我规划的那条路径。我并不是说自己写的代码有多完美，而是希望 AI 产出的东西能让我有熟悉感和掌控感，让我能毫无障碍地介入与维护。

在明确的目标与完善的指导下，AI 的实现速度已是我的几十上百倍。当”效率”不再是瓶颈，如何让这位极速的助手变得更“称心”、更默契，才是下一阶段真正值得投入的方向。

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

近期推荐

Swift 并发核心释疑 (Q&A: Swift Concurrency - Formatted)

这是一份来自 Apple 工程师的 Swift Concurrency Q&A 实录，由 Anton Gubarenko 整理。在活动中，工程师们针对当前并发模型中最容易产生误解的问题进行了集中解答。从 nonisolated(nonsending) 的行为变化，到 @concurrent 的使用边界，再到 Task 生命周期与取消机制。与其说这是一次知识补充，不如说是一次“语义校准”。

一个值得注意的信号是：Swift 正在从“async 默认并发”转向“默认保守，仅在需要时显式引入并发”。

解析 Task.immediate 的调度行为 (Immediate tasks in Swift Concurrency explained)

Swift 6.2 引入了一个相当“微妙但有用”的新特性：Task.immediate。与常规 Task 不同，immediate task 会在当前执行上下文中同步启动，并持续执行直到第一个真正的 suspension point。Antoine van der Lee 在本文中对其行为进行了清晰拆解。

这种能力主要用于弥合一个长期存在的空隙：在同步上下文中调用 async 逻辑，同时又希望保持执行顺序（例如在 actor 已正确隔离的前提下立即更新状态）。在这些场景中，Task.immediate 可以避免调度延迟带来的“时序错位”。

不过，它的风险同样直接——如果在第一个 suspension 之前执行了较重的同步工作（尤其是在 MainActor 上），就会阻塞当前执行器，带来明显的 UI 卡顿。Task.immediate 改变的只是“任务何时开始执行”，而不是任务的整体生命周期。在大多数情况下，常规 Task 的调度行为仍然是更安全的选择。

Swift 6 并发语境下的协议设计 (Concurrency Step-by-Step: Designing Protocols)

Matt Massicotte 在这篇文章中分享了一种在 Swift 6 严格并发语境下，更具“工程可执行性”的协议设计方法。

在 Swift 6 中，协议设计变得前所未有地困难——你不仅要定义方法，还要定义隔离边界（Isolation）。要不要加 @MainActor？要不要继承 Sendable？方法需不需要 async？Matt 强调，许多开发者在适配 Swift 6 时遇到的“并发报错瀑布”，表面上是隔离域冲突，本质上其实是过早抽象带来的架构问题。如果在需求不明时就试图设计出完美协议，极易被并发规则“锁死”。

Matt 建议：不要一开始就写 Protocol，而是从具体的实现（Concrete Types）出发。在真实使用场景中不断收敛接口边界，并将涉及隔离域和上下文相关的能力延后抽象。这种方式可以有效避免在并发时代陷入“胖协议”与过度约束的泥潭。与其说这是一种协议设计指南，不如说是 Swift 6 时代一种更务实的“延迟决策”策略。

Xcode 工程自动化构建实践 (Automating your Xcode Project)

Xcode 工程文件长期以来都是版本控制中的“问题源头”。Leo G Dion 从这一痛点出发，介绍了使用 XcodeGen 与 Tuist 自动生成工程的实践方式，并给出了较为完整的 Tuist 使用流程。文章还系统梳理了一个最小可发布工程所需的关键配置：deployment target、App Icon、Privacy Manifest、签名信息以及版本管理策略等，提供了一份适合自动化的“工程清单”。

尽管我的项目目前只有我一个开发者，我也已经切换到使用 Tuist 来生成 Xcode 工程。一方面，这类工具本身具备较高的工程确定性；另一方面，在 AI 辅助编程的场景下，它们的价值被进一步放大——各类 Agent 对其支持普遍较好，在修改工作区文件后如需编译会自动触发 generate。Tuist 和 XcodeGen 这类工具，正在逐渐成为 AI 时代更“友好”的工程基础设施。

SwiftUI 外观主题切换方案 (Appearance Mode Changer)

两天前，Stewart Lynch 迎来了他的 75 岁生日。他在推文上写道：“75 years of patches, upgrades, bug fixes, deprecated habits, and surprisingly few fatal errors. Still compiling. Still shipping. Still learning.”

作为知名的视频教程作者，Stewart 近期也重启了博客，将一些简短的技巧以文字形式整理发布，本文是关于 SwiftUI 外观模式切换的实现方案。

对于身处这个快速迭代、容易让人产生年龄焦虑的行业中的我们来说，这大概就是一位开发者最令人羡慕的理想状态。祝 Stewart 生日快乐，也把这份”Still”的精神分享给大家。

打磨 watchOS 地图体验的六年历程 (Six Years Perfecting Maps on watchOS)

David Smith 在这篇设计日志中回顾了他为 Pedometer++ 打造 Apple Watch 地图体验的六年历程。

文章最有价值的部分并不在具体实现，而在于一系列取舍：watchOS 上的交互必须足够直接，复杂配置几乎不可接受；地图与数据之间，需要在“可读性”与“信息密度”之间不断权衡；甚至连底图也不再依赖现成方案，而是专门为 Liquid Glass 定制。在技术选择上，他也给出了一个颇具代表性的判断：即便 MapKit 已经登陆 watchOS，在可定制性与表现力仍有限的情况下，依然选择完全自建方案。这背后体现的，不只是技术能力，更是对产品体验优先级的清晰判断。

这是一段典型的“长期打磨型”产品演进过程。

工具

Kadr：用 Swift DSL 描述视频合成

由 Steliyan Hadzhidenev 开发的 Kadr 是一个 Swift 原生的视频合成库，使用 Result Builder DSL 将 AVFoundation 中原本分散的剪辑、转场、多轨、滤镜、overlay、音频与导出流程组织为声明式 API。它值得关注的地方不只是语法层面的简化，而在于它展示了在真实媒体处理场景中，如何将 Swift 6 的 strict concurrency、Sendable、async/await 与 CMTime 这类时间模型协同起来。

其配套的 KadrUI 则提供了 SwiftUI 侧的一整套编辑界面组件，包括 VideoPreview、OverlayHost、多轨 TimelineView、InspectorPanel 与 KeyframeEditor，使这套 DSL 不仅可以用于导出流程，也具备支撑视频编辑器预览、拖拽、裁剪、关键帧和叠加层编辑等核心交互的能力。

SwiftVLC：面向 SwiftUI 的现代 libVLC 封装

由 Omar Albeik 开发的 SwiftVLC 是一个面向 SwiftUI 的 libVLC 4.0 Swift 封装。相比传统的 VLCKit，它去除了 Objective-C 中间层，直接提供基于 @Observable 的 Player、AsyncStream 事件流、typed throws，以及一行即可集成的 VideoView(player)。它的价值不仅在于“更 Swift”，还在于提供了一种将底层多媒体能力与现代 Swift 并发模型结合的实现方式。如果你的应用需要处理 AVFoundation 难以覆盖的格式、字幕或复杂网络协议，这类基于 libVLC 的方案依然具有不可替代性。

当然，限制也同样明确：对系统版本要求较高，同时底层 libVLC 仍需关注 LGPL 合规问题。

Swift Concurrency is Gaining Broader Adoption

Read on web →

It has been almost 5 years since Swift 5.5 introduced a new concurrency model aligned with modern programming paradigms. From 5.5 to the current 6.3, the Swift community has been actively advancing the evolution of concurrency APIs through small, iterative steps. However, this process hasn’t exactly been smooth sailing for developers, who had to grapple with a plethora of new keywords, complex isolation concepts, and some confusing “anti-patterns.”

As a newsletter editor, I’ve seen a massive amount of complaints and pleas for help over the past few years, but this sense of anxiety seems to have noticeably faded since the beginning of this year. In recent months, there have been more and more success stories shared within the community about migrating legacy projects to the new concurrency model. Although there are still a few scattered complaints, the prevailing attitude has shifted toward active embrace. Looking at the practical results, the new code—born from the growing pains of refactoring—has significantly reduced the cognitive load on developers when maintaining concurrency states.

Of course, behind this phenomenon, aside from developers becoming increasingly proficient with the new system, the maturity of the ecosystem also deserves a lot of credit. Over the past few years, both first-party and third-party frameworks and components have gradually completed their transition to the new concurrency implementations. This has greatly lowered the barrier to entry, allowing an increasing number of developers to immediately enjoy the convenience and data safety it brings.

There is also an interesting factor at play: thanks to the selfless sharing of many excellent content creators and open-source authors in the community, AI has accumulated a much richer corpus of Swift concurrency data over the past year or two. The new generation of large language models released in recent months clearly possesses a more accurate understanding of Swift’s concurrency rules, which has greatly accelerated developers’ mastery and application of the new concurrency.

Imperceptibly, the development of Swift’s new concurrency has entered a virtuous cycle. As can be seen from the new features in Swift 6.3, following the release of version 6.2, the evolution of Swift concurrency has largely entered a stable phase. Consequently, the community’s focus has shifted toward broader areas such as cross-platform and embedded development.

Perhaps the term “new concurrency model” in Swift can soon drop the “new” label and officially become part of the lifeblood of our daily development. Of course, it’s not entirely impossible that in another five to ten years, yet another “brand-new” concurrency model will arrive to amaze (or torture) us once again.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

The Flaky Test That Taught Me How Swift Concurrency Actually Works

Writing a test MockClock to support debounce behavior may not seem difficult for many Swift developers. But if you overlook differences in execution context — the executor — the result may be less deterministic than expected. Through the debugging process of a real-world case, Xiangyu reveals many details of modern Swift concurrency: nonisolated async functions hop away from the caller’s actor; Task.yield() only yields the current executor; and isolated parameters plus #isolation can let utility functions “run with the caller.” The value of this article is not in how to implement a test Clock, but in how clearly it shows the real relationship between tasks, actors, executors, and isolation in Swift Concurrency.

As Swift evolves, the behavior of nonisolated is no longer always equivalent to “necessarily hopping away from the current caller.” It can also be affected by the language mode and settings such as NonisolatedNonsendingByDefault. I ran into a similar issue, and solved it in the same way: with isolated + #isolation.

What’s that “structured” in Structured Concurrency?

Although Task has a handle and can be cancelled, making it look “more structured” than dispatch_async, its definition in Swift’s modern concurrency system is actually quite clear: Task is an unstructured top-level task. In this article, Max Seelemann explains what “structured” really means: the truly structured concurrency constructs are essentially async let and TaskGroup. What they share is an inescapable dependency relationship: the caller must wait for the subtasks to complete, and cancellation automatically propagates downward. Task, by contrast, is the opposite — it can be freely created and forgotten, with a lifecycle detached from the caller.

The article ends with a practical suggestion: use closures instead of Task whenever possible. Expressing a unit of work as () async -> Void is simpler, easier to test, and naturally inherits cancellation behavior from the calling context compared with passing around a Task object.

SwiftUI: Refreshable Task Cancellation

.refreshable accepts an async closure in which developers can fetch new data and update view state. But it has an easy-to-miss pitfall: if you modify the @State that drives the current view while the closure is running, the resulting redraw may cancel the refreshable task before it completes. In this article, Anton Gubarenko clearly explains this behavior: the lifecycle of .refreshable is tied to the view, and if a redraw is triggered during the refresh process, SwiftUI may terminate the task early — in other words, the task is cancelled by the very update it caused.

The author gives two possible fixes: either collect intermediate results in a local variable and update state once at the end, avoiding repeated redraws; or wrap the actual work in Task { }.value, allowing it to “detach” from the current refresh task and avoid being interrupted by the view lifecycle.

The issue faced by .refreshable also exists with .task. This is not a bug, but a concrete expression of SwiftUI’s structured concurrency model: async tasks are attached to the view lifecycle and are cancelled when that lifecycle ends. Without realizing this, it is easy to create a “self-cancellation” scenario between state updates and task execution.

Swift 6.3 experimentalCGen guide: SwiftPM natively supports C code generation

The experimentalCGen feature introduced in Swift 6.3 fills a long-standing gap in SwiftPM: C-family artifacts generated by Build Tool Plugins can finally participate directly in the compilation of C module targets, without relying on external scripts or precommitted generated files. This means the complete build graph can be closed within SwiftPM — local builds, CI, and Xcode can all use the same rules instead of each maintaining part of the build knowledge. In this article, Snow gives a detailed overview of the background, usage, and migration path for this feature.

experimentalCGen still has clear limitations. For example, each target can only have one generated module map, and headers referenced by that module map must be located in the same directory. As a result, it is better suited to code generation workflows with clear boundaries and stable outputs, rather than serving as a replacement for a full native build system.

How I migrated 300 screens to SwiftUI and what I learned

Migrating 300 screens to SwiftUI sounds like a complete transformation, but the strategy adopted by Artem Mirzabekian and his team was quite restrained: SwiftUI was responsible only for UI construction, while navigation remained in UIKit. This separation was not a compromise, but a deliberate choice — allowing the team to benefit from SwiftUI’s strengths in layout and component reuse while avoiding unnecessary risks around navigation, deep linking, and complex flows. The article records recurring issues during the migration: the team was used to imperative thinking and often wrote SwiftUI as “UIKit with different syntax”; side effects were placed inside body; onAppear was treated as viewDidLoad; nested ObservableObject structures led to unexpected state propagation problems. After continuous review and internal workshops, the team eventually settled on a clear architectural direction: MVVM + enum-driven state and interaction modeling + Use Cases for separating business logic.

Even outside migration projects, combining SwiftUI and UIKit is a realistic and effective choice. The two frameworks are not opposed to each other. Mixing them is not the hard part; the real challenge is writing code that fits each framework’s intended mental model.

Tools

Mini Swift: A Swift Compiler Written in Pure C

A fascinating project with a strong hacker spirit. Without using LLVM, Clang, or any official Apple toolchain, Ugur Toprakdeviren single-handedly wrote a lightweight Swift compiler in more than 70,000 lines of C. Starting from lexical analysis and the AST, he built the pipeline all the way to a backend that directly outputs WASM, bringing an astonishing sub-0.1 ms “instant compilation” experience to the web. In an era where pulling in hundreds of megabytes of dependencies is common, this zero-dependency act of “building the wheel by hand” feels almost romantically retro.

The project began with a simple goal: to build a SwiftUI browser preview that would not crash. The author also revealed that he is currently developing a layer called UIIR — a UI intermediate representation — with the eventual goal of mapping SwiftUI code into a platform-independent set of instructions that can render native-like results directly on the Web or even Android, fulfilling his original vision.

The compiler frontend’s core code — lexer, parser, and semantic analysis — is currently open source.

If combined with a terminal-based WASM runtime (such as Wasmtime), Mini Swift could significantly alleviate the current pain point of slow cold starts when writing terminal scripts in Swift, truly enhancing the Swift scripting experience. I am very much looking forward to seeing community explorations in this direction.

Yotei: A SwiftUI Calendar Component Library

Yotei is an iOS calendar component library by Mikalai Zmachynski. The project provides SwiftUI APIs while relying on UIKit to maintain scrolling performance in high-load scenarios such as schedule lists, pagination, and timelines. It includes components such as a date picker, day timeline, month grid, and schedule list, along with fairly detailed customization entry points.

Yotei demonstrates an increasingly common trade-off in complex SwiftUI components: SwiftUI handles composition, state binding, and extension points, while UIKit provides more mature and stable list and paging behavior.

Runtime Viewer

If you still remember RuntimeBrowser, then Runtime Viewer, developed by Mx-Iris, can be seen as a modern rewrite of that idea for today’s Apple platform context. It can browse not only Objective-C runtime information, but also Swift types, enum layouts, VTable offsets, and more, while offering a code-reading experience close to Xcode.

It is not merely a tool that “shows more interfaces.” Instead, it brings runtime inspection, cross-process communication, code injection, Bonjour device discovery, and even MCP integration into a single tool. For developers interested in reverse engineering, security research, learning system frameworks, or simply understanding the internal structure of a binary, it feels more like a runtime inspection workbench for modern Apple platforms.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

Swift 并发正被更广泛地接纳

网页版

从 Swift 5.5 引入符合现代编程思想的新并发模型算起，一转眼快 5 年了。从 5.5 到目前的 6.3，Swift 社区一直在采用小步迭代的方式，积极推进并发 API 的演进。但在应对过多的新关键字、复杂的隔离概念以及一些容易引发困扰的“反模式”时，这个过程对开发者来说并不算顺利。

作为一个周报编辑，我在过去几年间看到过大量的吐槽与求助，但这种焦虑感似乎从今年初开始明显转弱了。最近几个月，社区中出现了越来越多将旧项目迁移到新并发模型的成功分享。尽管其中仍夹杂着少量的抱怨，但主流态度已经展现出积极拥抱的态势。从实际的应用效果来看，经历过阵痛重构后的新代码，极大地降低了开发者在维护并发状态时的心智负担。

当然，这一现象的背后，除了开发者自身对新体系的掌握越来越熟练外，生态的成熟也功不可没。在过去的几年里，无论是第一方还是第三方框架与组件，都逐渐完成了向新并发实现的过渡。这大大降低了用户的使用门槛，让越来越多的开发者能在第一时间享受到新并发带来的便捷与数据安全。

此外还有一个有趣的因素：得益于社区众多优秀内容创作者、开源作者的无私分享，AI 在过去一两年中积累了更丰富的 Swift 并发语料。过去几个月间推出的新一代大语言模型，明显对 Swift 的并发规则有了更准确的理解，这也大大加快了开发者对新并发的掌握和应用。

在不知不觉中，Swift 新并发的发展已经进入了一个良性循环。从 Swift 6.3 的新功能就能看出，在经历了 6.2 版本之后，Swift 的并发演进已基本进入稳定期，社区的关注焦点也随之转移到了跨平台、嵌入式等更广阔的领域。

或许，Swift 的“新并发模型”这个称呼，很快就可以摘掉“新”的帽子，正式融入日常开发的血液中了。当然，也不排除再过个五到十年，又会有一个“全新”的并发模型再次惊艳（或折磨）我们。

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

近期推荐

一个偶发性测试失败，揭开了 Swift 并发调度的真相 (The Flaky Test That Taught Me How Swift Concurrency Actually Works)

为支持 debounce 行为编写一个测试用的 MockClock，对很多 Swift 开发者来说似乎并不复杂。但如果忽略了执行上下文（executor）的差异，结果可能就没有想象中那么确定。Xiangyu 通过一个实际案例的调试过程，揭示了 Swift 现代并发中的诸多细节：nonisolated async 函数会跳离调用者 actor；Task.yield() 只让出当前执行器；isolated 参数 + #isolation 可以让工具函数“随调用者运行”。本文的价值不在于如何实现一个测试用的 Clock，而在于它清晰地展示了 Swift Concurrency 中「任务、actor、executor、隔离」之间的真实关系。

随着 Swift 版本的发展，nonisolated 的行为也不再总是等同于“必然跳离当前调用者”，而会受到语言模式以及 NonisolatedNonsendingByDefault 等设置的影响。我也碰到过和本文类似的问题，同样也是通过 isolated + #isolation 来解决的。

「结构化并发」里的「结构化」究竟是什么意思？ (What’s that “structured” in Structured Concurrency?)

尽管 Task 有句柄、可取消，比 dispatch_async 看起来“更有结构”，但在 Swift 的现代并发系统中，它的定义其实很明确：Task 是 unstructured top-level task。Max Seelemann 在本文中解释了“结构化”的真正含义：真正属于结构化并发的，其实只有两种——async let 和 TaskGroup。它们的共同点在于一种不可逃避的依赖关系：调用者必须等待子任务完成，且取消会自动向下传播。而 Task 则完全相反——可以被随意创建和遗忘，其生命周期与调用者脱钩。

文章最后给出了一条颇具实践意义的建议：能用闭包就尽量不用 Task。将工作单元表达为 () async -> Void，相比传递一个 Task 对象，更简单、更易测试，同时取消行为也会自然继承自调用上下文。

.refreshable 自己终结自己的陷阱 (SwiftUI: Refreshable Task Cancellation)

.refreshable 接受一个异步闭包，开发者可以在其中获取新数据并更新视图状态。但它有一个容易踩到的陷阱：如果在闭包执行过程中修改了驱动当前视图的 @State，由此触发的视图重绘，可能会让 refreshable 的任务在完成前被取消。Anton Gubarenko 在本文中对这一行为做了清晰解释：.refreshable 的任务生命周期与视图绑定，当刷新过程中触发重绘时，SwiftUI 可能提前终止该任务，也就是“任务被自己触发的更新所取消”。

作者给出了两种修复思路：要么将中间结果收集到本地变量，最后一次性更新状态，避免多次触发重绘；要么将实际工作包裹在 Task { }.value 中，使其从当前刷新任务中“脱离”，从而避免被视图生命周期打断。

.refreshable 面临的问题，在 .task 中同样存在。这并不是 Bug，而是 SwiftUI 对结构化并发的一种具体体现：异步任务依附于视图生命周期，并随其结束而被取消。如果没有意识到这一点，就很容易在状态更新与任务执行之间制造出“自我取消”的场景。

Swift 6.3 experimentalCGen 指南：SwiftPM 原生支持 C 代码生成

Swift 6.3 引入的 experimentalCGen 填补了 SwiftPM 长期以来的一个关键缺口：Build Tool Plugin 生成的 C-family 产物，终于可以直接参与 C module target 的编译，而不再依赖外部脚本或预提交的生成文件。这意味着完整的构建图可以在 SwiftPM 内闭环——本地、CI、Xcode 使用同一套规则，不再各自维护一部分构建知识。Snow 在本文中详细梳理了其背景、用法与迁移思路。

experimentalCGen 目前仍有明确限制，例如同一 target 只能有一个生成的 module map，且 module map 引用的 header 需要位于同一目录。因此它更适合边界清晰、输出稳定的代码生成场景，而不是用来替代完整的原生构建系统。

将 300 个视图迁移到 SwiftUI 后所学到的 (How I migrated 300 screens to SwiftUI and what I learned)

将 300 个界面迁移到 SwiftUI，听起来像一次彻底的转型，但 Artem Mirzabekian 及其团队的策略却相当克制：SwiftUI 只负责 UI 构建，导航依然留在 UIKit。这种分层并非妥协，而是有意为之——让团队在享受 SwiftUI 布局与组件复用优势的同时，避免在导航、深链路和复杂流程上引入不必要的风险。文章记录了迁移中反复出现的问题：团队习惯了命令式思维，常把 SwiftUI 当作“语法不同的 UIKit”来写；body 中夹带副作用、将 onAppear 当作 viewDidLoad 使用、嵌套 ObservableObject 导致状态传播不如预期……这些问题在迁移过程中一再出现。经过持续的审查与内部工作坊，团队最终沉淀出一套清晰的架构方向：MVVM + 枚举驱动的状态与交互建模 + Use Case 分离业务逻辑。

即便不是迁移项目，SwiftUI 与 UIKit 混用也是一种现实且有效的选择。两个框架并非对立，混用本身不难，难的是在各自的思维模型下写出符合其设计意图的代码。

工具

Mini Swift: 纯 C 写的 Swift 编译器

一个很有趣且极具极客精神的项目。Ugur Toprakdeviren 在不使用 LLVM、Clang 或苹果任何官方工具链的情况下，单枪匹马用 7 万多行 C 语言“手搓”了一个轻量级的 Swift 编译器。他从词法分析、抽象语法树一路写到了直接输出 WASM 的后端，为网页端带来了 0.1 毫秒级“秒编译”的惊人体验。在这个动辄拉入几百兆依赖包的时代，这种零依赖的“徒手造轮子”行为无疑是一种复古的浪漫。

这个项目源于作者一个简单初衷：做一个不会崩溃的 SwiftUI 浏览器预览。作者透露，他目前正在开发一个名为 UIIR（UI 中间表示）的层，最终目的是想把 SwiftUI 代码映射成一套平台无关的指令，直接在 Web 甚至 Android 上渲染出原生效果，以此来完成他最初的设想。

该编译器前端的核心代码（词法、语法、语义分析）目前已 开源。

如果结合终端版本的 WASM 运行时（如 Wasmtime 等），或许 Mini Swift 可以大幅改善目前 Swift 编写终端脚本时冷启动过慢的痛点，真正提升 Swift 的脚本化体验。我很期待社区在这个方向上的尝试。

Yotei: SwiftUI 日历组件库

Yotei 是一个 iOS 日历组件库，作者是 Mikalai Zmachynski。项目提供了 SwiftUI API，同时在日程列表、分页和时间轴等高负载场景中借助 UIKit 保持滚动性能。它有 date picker、day timeline、month grid、schedule list 等组件，也给了较细的定制入口。

Yotei 展示了一种在复杂 SwiftUI 组件中越来越常见的取舍：SwiftUI 负责组合、状态绑定与扩展点，UIKit 负责更成熟、稳定的列表和分页体验。

Runtime Viewer

如果你还记得 RuntimeBrowser，那么 Mx-Iris 开发的 Runtime Viewer 可以看作它在今天苹果平台语境下的一次现代化重写。它不仅能浏览 Objective-C runtime 信息，也把 Swift 类型、枚举布局、VTable 偏移等内容纳入了分析范围，并提供接近 Xcode 的代码阅读体验。

它不只是“能看更多接口”，而是把运行时检查、跨进程通信、代码注入、Bonjour 设备发现，甚至 MCP 接入放进了同一个工具里。对逆向、安全研究、系统 Framework 学习，或者只是想理解某个二进制内部结构的开发者来说，它都更像一个面向现代 Apple 平台的 runtime inspection 工作台。

From OpenSwiftUI to DanceUI: Another Way to Dive into SwiftUI

Read on web →

Counting from its debut in 2019, SwiftUI is approaching its seventh year. It has long shed its initial growing pains and gradually become one of the foundational skills for developers in the Apple ecosystem. However, SwiftUI’s closed-source nature also means that many of its underlying mechanisms remain opaque. While developers can certainly feel its expressive advantages when using it, it’s often difficult to trace the root cause once a problem occurs. This characteristic also puts SwiftUI at a bit of a disadvantage in the era of AI-assisted programming—compared to technologies that have long been exposed in community discussions, source codes, and documentation, the high-quality materials available for large models to reference are ultimately limited.

Because of this, the community has always hoped to replicate SwiftUI through open-source projects: on the one hand, to give this excellent design a chance to run on more platforms; on the other hand, to gain a better understanding of SwiftUI’s internal mechanisms through the replication process. In recent years, the most highly-watched project in this regard is undoubtedly OpenSwiftUI. Driven continuously by the community, it has already filled in some of the core implementations of SwiftUI and made experimental explorations on platforms outside the Apple ecosystem. Although it obviously still has a long way to go to reach its goal, it remains one of the most important gateways for developers today to understand SwiftUI’s internal mechanisms.

Actually, besides the community, some companies—even very large ones—have also conducted in-depth research and replication of SwiftUI over the past few years. Last week, ByteDance open-sourced their SwiftUI replication project, DanceUI.

I first heard about this project in 2022. What surprised me the most at the time wasn’t “someone is replicating SwiftUI,” but rather, “why is ByteDance doing this?” Later, after communicating with the developers involved in this project, I roughly understood their motives: on one hand, they wanted to gain stronger control when introducing declarative development into their massive product ecosystem; on the other hand, they hoped to grasp key capabilities like runtime, dependency graphs, and host integration in their own hands by studying excellent frameworks like SwiftUI. Compared to OpenSwiftUI, DanceUI looks less like a community-driven replica and more like a sample of reverse-engineering SwiftUI driven by practical engineering needs.

More importantly, over the past few years, DanceUI has already entered production environments in some product modules within ByteDance. This means it is clearly not just an experimental toy, but a set of development tools that have withstood a certain level of testing in terms of performance and stability. For SwiftUI developers, it therefore provides another gateway to understanding SwiftUI.

Of course, such projects shouldn’t be over-glorified. They are not SwiftUI itself, nor do they represent Apple’s official implementation. Projects like OpenSwiftUI, which are strongly research- and compatibility-oriented, naturally have clear boundaries; while projects like DanceUI carry an obvious background of large-tech internal engineering and practical application. Neither should be treated as the sole source of “SwiftUI truth.”

However, this does not prevent them from being excellent learning materials. None of them are SwiftUI, yet they can all help us get closer to it. Diving into SwiftUI by following open-source projects is essentially not about finding an “open-source alternative,” but rather using these projects to train our own way of understanding SwiftUI.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

Interface Segregation Principle In IOS: How To Prevent A Protocol From Becoming A Prison

Many developers have likely experienced a similar trajectory: a carefully designed small protocol in the early stages of a project gradually evolves into an unwieldy “monster” as team collaboration and business requirements grow. Pawel Kozielecki illustrates this through a progressively bloated UserService, showing how fat protocols introduce testing overhead, hidden coupling, and significant refactoring costs. Beyond proposing a practical approach based on smaller protocols and incremental migration, the article highlights a deeper issue: the real danger often lies not in a single flawed design decision, but in a series of seemingly reasonable “let’s just add this here for now” choices.

In the era of AI-assisted programming, this problem can be further amplified. Large models tend to infer semantics from file and protocol names, and vague or overly broad naming naturally attracts more loosely related responsibilities. Clear, precise, and restrained naming is no longer just a matter of style—it increasingly defines system boundaries.

Animating Strikethroughs in SwiftUI

How would you animate a strikethrough or underline in SwiftUI Text? A common first instinct is to use an overlay with Shape. However, this approach struggles with Dynamic Type and multi-line text. Ashli Rankin presents a more systematic solution: leveraging the TextRenderer API introduced in iOS 17 to access Text.Layout internals (lines, glyphs, etc.), and using a progress value accumulated across lines to draw a continuous, animatable strikethrough. By conforming to Animatable, SwiftUI can smoothly interpolate state changes.

An interesting detail: TextField does not use the same rendering pipeline as Text, so TextRenderer cannot be applied directly. The workaround involves overlaying a transparent Text (for rendering the animation) on top of a real TextField, combined with a custom Layout to enforce consistent wrapping width, ultimately resolving multi-line alignment issues.

Checking accessibility with SwiftUI Previews

SwiftUI Previews are typically used to verify UI layout, but they can also help validate certain aspects of accessibility during development. Rob Whitaker outlines several practical approaches: using Xcode Canvas to quickly toggle light/dark mode, orientation, and Dynamic Type, or defining specific environments via Preview Traits.

The article also highlights some private environment properties available only in Previews (such as increased contrast, reduced motion, or inverted colors), which can be enabled via underscored key paths. These must be restricted to #if DEBUG to avoid leaking private APIs into production builds.

A UIKit Project’s SwiftUI Migration: A Practical Retrospective

Yusuke Hosonuma reflects on his experience working on a UIKit + RxSwift + Coordinator project and gradually migrating most of its UI to SwiftUI over the course of a year. Rather than focusing on implementation details, the article centers on real-world engineering trade-offs: how a small team, with minimal communication and almost no documentation, can maintain long-term evolvability through continuous delivery, incremental replacement, and intentionally simple design.

The author also offers grounded reflections on common practices, such as being cautious with protocol abstraction, EnvironmentObject, premature generalization, and the urge to “clean up everything” during migration. This is less a technical guide and more a realistic retrospective on team practices and engineering judgment.

Cancelling SwiftUI Animations: What Actually Works (And Why)

Stopping an in-flight repeatForever animation in SwiftUI is not as straightforward as it seems. Using .none or disabling animations via Transaction only affects new animations, not those already running in the rendering system. Codelaby provides a working solution: defining a custom CustomAnimation that returns nil from animate (signaling immediate completion), and using shouldMerge to take over the current animation, effectively cancelling it.

SwiftUI performs interpolation based on state changes and animation functions. “Stopping” an animation is essentially replacing it with a new state transition that takes control, rather than interrupting the existing animation.

Tools

Swift Institute: Rebuilding the Swift Ecosystem as a Solo Effort

An astonishing project discovered by chance. Over the past nine months, Coen ten Thije Boonkkamp has made nearly 9,800 commits, single-handedly building a Swift ecosystem of almost 300 packages across three layers: primitives, standards, and foundations. The goal is to realize his proposed Modern Swift Library Architecture: dependencies flow downward, integration happens outside core types, and “test what you own, trust what you import.”

One person, one idea, explored and validated with AI. Whether it ultimately succeeds or not, this is exactly the kind of exploration that demonstrates the real value of AI.

swift-ast-lint: Writing Swift Lint Rules in Swift

Developed by Ryu, swift-ast-lint is not another SwiftLint, but a custom linting infrastructure built on SwiftSyntax. It is designed for teams that need AST-level rules, filling the gap where regex-based approaches fall short.

The project supports scaffolding, parameterized rules, path filtering, and --fix auto-correction. It is well-suited for enforcing architectural constraints, code organization, and module boundaries—areas where regex is unreliable. While not ideal for out-of-the-box use, it is a strong option for teams with established conventions who want to formalize them as tooling.

As AI-assisted development becomes more common, the real value may lie not only in generation, but in how we encode and enforce team constraints.

Event

Swift Craft 2026

Swift Craft is a community-driven iOS / Apple platform developer conference taking place May 18–20 in Folkestone, UK. The schedule is already available, covering topics across Swift, SwiftUI, and application architecture.

Compared to larger conferences, Swift Craft focuses more on small-scale, in-depth discussions and emphasizes a strong community atmosphere. One notable detail is the venue: Leas Cliff Hall, perched on a seaside cliff with floor-to-ceiling windows overlooking the English Channel—an environment that naturally enhances the overall experience.

The organizers are offering a discount code FBM26 (£50 off Indie tickets) for readers of this newsletter. If you’re considering attending a developer event in Europe, you can check the details via the Swift Craft tickets page.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

从 OpenSwiftUI 到 DanceUI：换个方式 Dive SwiftUI

网页版

从 2019 年问世算起，SwiftUI 已经快七年了。它早已脱去了最初几年的稚气，逐渐成为苹果生态开发者的基础能力之一。不过，SwiftUI 的闭源属性也意味着，它的很多运行机制始终不透明。开发者在使用时固然能感受到它的表达优势，但一旦遇到问题，往往很难进一步追踪原因。这种特性也让 SwiftUI 在 AI 辅助编程时代显得有些“吃亏”——相比那些长期暴露在社区讨论、源码和文档中的技术，大模型能参考的高质量材料终究有限。

也正因此，社区一直希望通过开源项目去复刻 SwiftUI：一方面，是希望让 SwiftUI 这套优秀的设计有机会运行在更多平台上；另一方面，也是希望借助复刻过程，对 SwiftUI 的内部机制获得更多理解。最近几年，这方面最受关注的项目无疑是 OpenSwiftUI。在社区持续推进下，它已经补齐了 SwiftUI 的一部分核心实现，并在苹果生态之外的平台上做出了一些实验性探索。虽然距离它的目标显然还有不短的路要走，但它依然是当下开发者理解 SwiftUI 内部机制的重要入口之一。

其实，除了社区之外，一些公司，甚至规模很大的公司，也在过去几年里做过对 SwiftUI 的深入研究和复刻。上周，字节跳动开源了他们的 SwiftUI 复刻项目 DanceUI。

我第一次听说这个项目是在 2022 年。当时最让我感到意外的，不是“有人在复刻 SwiftUI”，而是“为什么是字节跳动在做这件事”。后来陆续和参与这个项目的开发者交流后，我大致理解了他们的动机：一方面，他们希望在将声明式开发引入庞大产品体系时获得更强的控制力；另一方面，也希望借由对 SwiftUI 这类优秀框架的研究，把运行时、依赖图和宿主整合等关键能力握在自己手里。和 OpenSwiftUI 相比，DanceUI 更不像一个社区式复刻项目，而更像一套从工程落地出发、反向拆解 SwiftUI 的样本。

更重要的是，过去几年中，DanceUI 已经在字节内部的一些产品模块中进入了生产环境。这意味着它显然不只是一个实验性的玩具，而是一套在性能和稳定性上都经受过一定检验的开发工具。对于 SwiftUI 开发者来说，它也因此提供了另一个理解 SwiftUI 的入口。

当然，这类项目并不适合被简单神化。它们不是 SwiftUI 本身，也不代表苹果官方实现。尤其像 OpenSwiftUI 这样带有强烈研究和兼容性导向的项目，本身就有明确边界；而像 DanceUI 这样的项目，则带着明显的大厂内部工程背景和落地取向。它们都不应该被当成“SwiftUI 真相”的唯一来源。

但这并不妨碍它们成为很好的学习材料。它们都不是 SwiftUI，却都能帮助我们更接近 SwiftUI。跟着开源项目去 dive SwiftUI，本质上不是在找一个“开源替代品”，而是在借这些项目训练自己理解 SwiftUI 的方式。

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

近期推荐

别让协议变成“怪物”：iOS 中的接口隔离实践 (Interface Segregation Principle In IOS: How To Prevent A Protocol From Becoming A Prison)

很多开发者可能都经历过类似的过程：项目早期一个精心设计的小协议，随着团队协作与业务演进，逐渐膨胀为难以维护的“怪物”。Pawel Kozielecki 通过一个逐步失控的 UserService 案例，具体展示了胖协议如何在团队协作中引入测试负担、隐性耦合，以及难以推进的重构成本。作者不仅给出了基于小协议组合与渐进迁移的现实方案，也点出了问题的根源：真正危险的，往往不是一次明显的设计失误，而是一连串“这次先加进去也没关系”的合理决定。

在 AI 辅助编程日益普及的背景下，这一问题反而更容易被放大。大模型倾向于依据文件名、协议名进行语义推断，一个模糊或过于宽泛的命名，往往会自然地吸引更多“不那么相关”的职责被不断叠加进去。清晰、准确且克制的命名，正在从代码风格问题，逐渐演变为影响系统边界的重要因素。

为 Text 实现删除线动画 (Animating Strikethroughs in SwiftUI)

为 SwiftUI Text 的删除线或下划线实现动画效果？不少人第一反应可能是基于 overlay + Shape 的方案。不过，这种方式很难正确适配 Dynamic Type 以及多行文本场景。Ashli Rankin 展示了一条更“系统化”的路径：基于 iOS 17 引入的 TextRenderer，直接访问 Text.Layout 的内部结构（行、glyph 等），并通过一个 progress 值在所有行之间累计绘制，从而实现连续、可动画的删除线效果。同时通过实现 Animatable，让 SwiftUI 在状态变化时自动完成插值过渡。

一个更有意思的细节在于：TextField 并不会走 Text 的渲染流程，因此 TextRenderer 无法直接应用。作者通过叠加一个透明的 Text（负责绘制动画）与真实的 TextField，并结合自定义 Layout 强制两者使用一致的换行宽度，最终解决了多行错位问题。

在 SwiftUI 预览中验证可访问性 (Checking accessibility with SwiftUI Previews)

SwiftUI Previews 通常用于检查界面布局，但同样可以在开发阶段快速验证部分可访问性（Accessibility）表现。Rob Whitake 梳理了几种常用途径：例如通过 Xcode Canvas 直接切换深浅色、方向、Dynamic Type 等进行快速检查，或借助 Preview Traits 定义特定的预览环境。文章还提到了一些仅用于 Preview 的私有环境变量（如增强对比度、减少动画、颜色反转等），通过带下划线的 keyPath 可以强制开启这些状态。不过需要注意，这类 API 必须限制在 #if DEBUG 中使用，以避免私有符号进入最终构建，带来审核风险。

一个 UIKit 项目的 SwiftUI 迁移实录

Yusuke Hosonuma 回顾了自己参与一个 UIKit + RxSwift + Coordinator 项目，并在一年多时间里逐步完成大部分界面 SwiftUI 化的经历。文章聚焦于真实项目中的工程取舍：在小团队、低沟通、几乎无文档的条件下，如何通过持续交付、渐进替换与尽量简单的设计，让项目保持可演进性。作者对不少常见做法都给出了很有现实感的反思，例如谨慎对待 protocol 抽象、EnvironmentObject、过早共通化，以及“顺手清理一切旧架构”的冲动。这并非单纯的技术实现总结，而是一篇充满真实感的团队实践复盘。

如何停止一个运行中的 SwiftUI 动画 Cancelling SwiftUI Animations: What Actually Works (And Why)

在 SwiftUI 中，停止一个已经运行的 repeatForever 动画并不像想象中那么简单。无论是使用 .none，还是通过 Transaction 禁用动画，都只能影响新的动画，而无法中断已经存在于渲染系统中的动画。Codelaby 给出了一个可行方案：通过自定义 CustomAnimation，让 animate 返回 nil（表示立即完成），并通过 shouldMerge 接管当前动画，从而实现终止动画的效果。

SwiftUI 会基于状态变化与动画函数自动进行插值计算。所谓“停止”，本质上是用一个新的状态变化去接管当前动画，而不是中断之前的动画。

工具

Swift Institute: 一个人的 Swift 基础设施重写

偶然看到的一个让我震惊的项目。Coen ten Thije Boonkkamp 在过去 9 个月里提交了约 9800 次 git commit，独自构建了一个分为 primitives、standards、foundations 三层、累计近 300 个包的 Swift 生态。目标只有一个——落地他去年提出的 Modern Swift Library Architecture 思想：依赖只能向下、集成发生在核心类型之外、”test what you own, trust what you import”。

一个人、一个构想，通过 AI 来进行尝试、验证。无论最后是否成功，但这是我想看到的 AI 意义。

swift-ast-lint：用 Swift 写 Swift 代码检查规则

由 Ryu 开发的 swift-ast-lint 不是另一个 SwiftLint，而是一套基于 SwiftSyntax 的自定义 lint 基础设施。它更适合需要编写 AST 级规则的团队，用来补足正则匹配在结构化检查上的局限。

项目支持脚手架生成、参数化规则、路径过滤以及 --fix 自动修复，比较适合处理架构约束、代码组织、模块边界等 regex 很难可靠覆盖的问题。它不太适合只想开箱即用的用户，但对于已经有明确工程规范、又希望把这些规范工具化的 Swift 团队来说，是一个值得关注的项目。

在 AI 辅助开发越来越普遍之后，真正有价值的可能不只是生成能力本身，还包括如何把团队规范和结构约束工具化。

活动

Swift Craft 2026

Swift Craft 是一个由社区驱动的 iOS / Apple 平台开发者大会，将于 5 月 18–20 日在英国 Folkestone 举行。目前议程已经公布，涵盖 Swift、SwiftUI 以及应用架构等多个方向。

相比大型会议，Swift Craft 更偏向小规模与深度交流，也更强调开发者之间的社区氛围。一个有趣的细节是本次会议的场地：位于海边悬崖上的 Leas Cliff Hall，会场三面落地窗直面英吉利海峡，这种环境本身就足以让会议体验变得与众不同。

主办方为本周报读者提供了折扣码 FBM26（£50 off Indie 票）。如果你有参与线下开发者活动的计划，可以通过 Swift Craft tickets page 了解详情。

Copyright Walls Demolished by Vibe Coding, and the Developer’s New Moat

Read on web →

Anthropic recently announced that because its latest model, Mythos, has become “too powerful” at cybersecurity work and software vulnerability discovery—reaching a level the company finds unsettling—it has taken the unusually restrained step of not releasing the model publicly. Access is limited to a handful of critical infrastructure companies within Project Glasswing, and ordinary developers cannot reach it through the API either. (Some analysts have pointed out, of course, that this arrangement also conveniently helps prevent model distillation and locks in enterprise-tier customers.) But even with this “beast” kept on a leash for the moment, the coding capabilities of today’s mainstream AI models are already more than enough to make cloning a product trivially easy.

Last week, a developer on Reddit claimed that he had spent a year “reverse-engineering the SwiftUI API” to build an entirely new Swift web framework. The post was fluent and precise in its terminology, and it drew considerable attention. Paul Hudson soon appeared in the comments and called it out: the so-called “independent research” was in fact little more than a string replacement performed on his MIT-licensed open-source project Ignite—down to the point that the original author’s personal, stylistically distinctive code comments had been preserved verbatim. The entire repository was then squashed into a single commit to erase its history, and the license was illicitly changed to the copyleft GPL. A number of developers in the community suspect that the “reverse-engineering SwiftUI” narrative itself was AI-generated as well. More intriguingly, the author in question was actually a major contributor to Ignite himself—when Vibe Coding has driven the cost of “repackaging a project” close to zero, “I was involved in this” can itself become a rhetorical device for blurring the lines of responsibility.

Around the same time, Vibe Island—a polished macOS menu-bar app for monitoring AI coding agents—was pixel-for-pixel cloned shortly after its release. Although the copycat published its code under the banner of an “open-source alternative,” the impact on the original author’s sales and creative motivation was real and significant. Yet even if the author wished to pursue legal action, he would run into a new problem of the times: in both establishing ownership and enforcing his rights, he might need to prove that his work possesses sufficient human originality and account for the extent of AI-generated content involved—otherwise, he would face considerably greater legal uncertainty.

Indeed, the legal walls protecting code are beginning to crumble on the “ownership side” first. Last month, China’s Copyright Protection Centre officially rolled out a new version of its software copyright registration application and accompanying review rules, which explicitly require the filer to make a notarized personal commitment that “no AI has been used to develop the code, author the documentation, or generate the registration materials,” and the review process now focuses on whether the human intellectual contribution clears the originality threshold required by copyright law. Content without substantive human involvement will struggle to obtain registration. Violators may also be placed on a registry of dishonest filers, with consequences tied to their personal credit records.

This trend is converging with the recent direction of case law in Europe and the United States: if a piece of code is primarily “rewritten or recombined” at high speed by an AI responding to prompts, its chances of obtaining copyright protection drop considerably.

We have to face a harsh truth: “I had a brilliant idea and vibe-coded it into existence” is no longer enough to constitute a business moat. The new paradigm we call Vibe Coding has not only reshaped development workflows and dramatically improved efficiency—it has simultaneously shaken the foundational logic of the software copyright system from three directions at once: the bar for ownership has risen, the burden of proof for infringement has grown heavier, and functional cloning has been quietly normalized.

What makes it all the more disheartening is that, controversial as these clone projects may be, they still rack up no small number of stars on GitHub. That suggests that when the cost of getting something is vanishingly low, moral appeals alone can no longer hold back the rush toward “free equivalents.”

Perhaps, as we noted in Issue 120’s discussion of Skip’s move to go open source—in an era where the cost of implementing code is approaching zero and any app can be cloned at any moment by an AI, building behind closed doors and “selling the tool” will only get harder. Forging real connections with users, and turning “the credibility of the maker and the trust of the community” into brand equity that cannot be copied—this, perhaps, is the true core competency and moat for developers in the years ahead.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

Swift Blog Carnival: Tiny Languages

The Swift community has launched its first Blog Carnival, with April’s theme being Tiny Languages. Christian Tietze invites developers to write about this topic—custom DSLs, result builders, scripting languages, routing rules… any perspective related to “tiny languages” is welcome. The submission deadline is May 1.

So far, three entries have been published:

• Matt Massicotte reflects on his journey from Rake to Make, and then to various Swift-based task runners, noting that he still hasn’t found an ideal replacement

• Chris Liscio shares the design of Capo’s embedded DSL, used to describe keyboard and MIDI bindings, built on Point-Free’s swift-parsing library

• Nicolas Zinovieff presents an experimental symbolic math DSL, leveraging protocols and operator overloading to make expressions like (1 + 2 * "X") * (3 - "Y") valid Swift code, with lazy evaluation when concrete values are provided—implemented in under 300 lines

Indicating Selection in macOS Menus Using SwiftUI

SwiftUI provides several components for representing selection, such as Picker, Toggle, and Menu. However, clearly guiding users through choices and accurately reflecting the current selection is not as straightforward as it may seem. Gabriel Theodoropoulos starts from basic Button implementations and gradually evolves toward Picker and Toggle, systematically outlining common approaches and their limitations.

The value of this article lies not in presenting a “single correct solution,” but in reminding developers that SwiftUI’s standard components do not automatically guarantee the best user experience. In practice, you still need to balance system consistency and implementation flexibility.

Building List Replacement in SwiftUI

Choosing between List and ScrollView + LazyStack remains a common challenge for SwiftUI developers. In this article, Majid Jabrayilov rebuilds parts of his CardioBot app using the SwiftUI Container View API (iOS 18+), creating three reusable components—ScrollingSurface, DividedCard, and SectionedSurface—as a replacement for List.

These components closely mirror the usage of List + Section, while eliminating constraints tied to List, such as listRowBackground and listItemTint.

List is not just a “styled LazyVStack”—the two differ fundamentally in architecture, scrolling behavior, integration with navigation containers, and performance on large datasets. For a deeper comparison, see this previous article.

AppIntents meet MCP

While many still see AppIntents as a companion to Siri and Shortcuts, Florian Schweizer explores a more forward-looking direction: exposing AppIntents as MCP (Model Context Protocol) tools, enabling LLMs to directly interact with your app’s capabilities.

Based on SwiftMCP, Florian uses macros to build an MCP server and seamlessly maps AppIntents into MCP tools. This allows AI agents to invoke app functionality directly, enabling cross-app automation.

Rumors have suggested since last year that Apple is bringing MCP support into its ecosystem. Perhaps we’ll get answers at WWDC 26 in a couple of months.

Ride the Lightning Air: Building Interactive WidgetKit Widgets

Many developers are misled by WidgetKit documentation, mistakenly treating AppIntentTimelineProvider as the key to interactive widgets. In reality, it is designed for user-configurable widgets (e.g., editing options via long-press), not for interactivity.

The actual foundation for interactive widgets remains TimelineProvider. Wesley Matlock demonstrates the correct approach through a fictional airline widget: Using TimelineProvider + Button(intent:) + App Group shared storage to build interactive widgets.

The data flow forms a clean loop: User action → Intent execution → State update → Widget reload → UI refresh

File Storage and iCloud: A Complete View from Local to Cloud

In iOS and macOS development (and usage), file storage is often treated as a basic capability—but it actually defines the lifecycle and behavior of your data.

In Working with files and directories in iOS, Natascha Fadeeva systematically explains the App Sandbox structure and the roles of Documents, Library, and Caches, helping developers understand where different types of data should reside—and how to avoid unnecessary iCloud backups.

Meanwhile, Howard Oakley in Understanding and Testing iCloud explores what happens next: iCloud is not a single service, but a collection of subsystems such as CloudKit, iCloud Drive, and system update services. Different types of data follow different synchronization and backup paths.

File placement is not just an organizational concern—it defines whether data is backed up, synchronized, and how it flows across devices.

As a result, iCloud issues are rarely just about “whether sync is enabled.” They often involve multiple layers, including client state, network conditions, caching behavior, and server-side throttling.

Tools

Bad Dock: Animate Your Dock Icon

This is a “ridiculous yet serious” macOS experiment. Eric Martz uses the public NSDockTile / NSDockTilePlugin APIs to bypass the squircle constraints introduced in Big Sur and render a video stream directly inside a Dock icon.

The implementation is straightforward but well-structured: decoding video with AVAssetReader, reducing frame rate to ~12fps, and managing memory with a ring buffer. The result is a polished technical proof-of-concept built from what initially seems like a playful idea.

The real value of projects like this lies not in their functionality, but in revealing that system API boundaries often extend far beyond what the documentation suggests.

Note: This project implements runtime dynamic Dock icons (continuously rendered while the app is running). After the app exits, only a static custom icon can be preserved via NSDockTilePlugin.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

被 Vibe 摧毁的版权壁垒，与开发者的新护城河

网页版

Anthropic 不久前宣布，由于其最新模型 Mythos 在网络安全与代码漏洞挖掘方面的能力“过于强大”，已达到令人不安的程度，因此采取了极为罕见的克制措施：仅向 Project Glasswing 内的少数关键基础设施企业开放，不面向公众发布，普通开发者也无法通过 API 调用（当然，也有分析者指出，这一安排同样有助于防止模型蒸馏，并锁定企业级客户）。但即便这头“猛兽”被暂时按住，当前主流 AI 模型的代码能力，已经足以让复制一款产品变得轻而易举。

上周，Reddit 上一位开发者宣称，自己花了一年时间“逆向 SwiftUI API”，打造了一个全新的 Swift Web 框架。帖子行文流畅、术语考究，一度吸引了不少关注。但 Paul Hudson 很快现身评论区打假：所谓“独立研发”，实际上只是将他的 MIT 开源项目 Ignite 做了简单的字符串替换，甚至连原作者带有个人风格的代码注释都原封不动保留，随后将整个仓库压缩为一次提交以抹除历史，并违规改为具有传染性的 GPL 协议。社区中不少开发者都怀疑，这套“逆向 SwiftUI”的叙事本身也是由 AI 生成。更耐人寻味的是，该作者本就是 Ignite 的主要贡献者之一——当 Vibe Coding 将“重新打包一个项目”的成本降至极低时，“我参与过”本身也可能成为一种模糊责任边界的话术。

几乎在同一时间，macOS 上精致的 AI 工作状态监控应用 Vibe Island 在发布后不久便遭遇了像素级仿制。尽管仿制者打着“开源替代品”的旗号公开了代码，这依然对原作者的商业销售与创作热情造成了明显冲击。然而，即便作者希望采取法律手段，也将面临一个新的时代难题：在确权与维权过程中，他可能需要证明其作品具备足够的人类独创性，并说明 AI 生成内容的参与程度，否则将面临更高的不确定性。

事实上，代码的法律壁垒正从“确权端”开始松动。上个月，中国版权保护中心正式启用新版《计算机软件著作权登记申请表》及相关审查新规，明确要求经办人实名承诺“未使用 AI 开发编写代码、撰写文档或生成登记材料”，并在审查中重点评估人类智力投入是否达到著作权法所要求的“独创性”门槛；缺乏实质人类参与的内容，将难以获得确权。违规者还可能被纳入失信名单，并与个人征信挂钩。

这一趋势也与欧美近期的判例方向趋于一致：如果一段代码主要由 AI 根据提示词快速“改写或重组”生成，其获得著作权保护的可能性将显著降低。

我们必须承认一个残酷的事实：“我有一个绝妙的 Idea，并把它 Vibe 成代码”，已经不足以构成商业壁垒。这种名为 Vibe Coding 的新范式，不仅改变了开发流程、显著提升了效率，也从三个方向同时动摇了软件版权体系的基础逻辑：确权门槛提高、侵权举证变难、功能复刻被默许。

令人遗憾的是，即便这些克隆项目饱受争议，它们依然在 GitHub 上收获了不菲的 Star。这说明，在获取成本极低的前提下，仅靠道德呼吁，已经很难阻止人们对“免费平替”的追逐。

或许，正如我们在 第 120 期周报中讨论 Skip 的开源举措 时所提到的那样——在代码实现成本趋近于零、应用随时可能被 AI 一键克隆的当下，闭门造车“卖工具”将变得愈发困难。与用户建立真实连接，将“出品方的信誉与社区的信任”转化为不可复制的品牌资产，或许才是未来开发者真正的核心竞争力与护城河。

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

近期推荐

Swift Blog Carnival: Tiny Languages

Swift 社区正在发起第一届 Blog Carnival，四月的主题是 Tiny Languages。Christian Tietze 邀请开发者围绕这一主题撰写博客：自定义 DSL、Result Builder、脚本解析器、路由规则……任何与“微型语言”相关的思考都可以作为切入点，截止日期为 5 月 1 日。

目前已有三篇投稿：

• Matt Massicotte 回顾了他 从 Rake 到 Make，再到各类 Swift 任务运行器的探索历程，坦言至今仍未找到理想替代品

• Chris Liscio 分享了 Capo 应用内置 DSL 的设计：用于描述键盘与 MIDI 绑定，基于 Point-Free 的 swift-parsing 库构建

• Nicolas Zinovieff 则展示了一个 符号数学 DSL 的实验：通过协议与运算符重载，让 (1 + 2 * "X") * (3 - "Y")成为合法的 Swift 表达式，并在提供具体值时惰性求值，核心实现不超过 300 行

在 macOS 菜单中清晰显示当前选中状态 (Indicating Selection in macOS Menus Using SwiftUI)

SwiftUI 提供了不少用于表达选择的组件，例如 Picker、Toggle、Menu，但如何清晰地引导用户进行选择，并准确标识当前选中项，并没有想象中那样理所当然。Gabriel Theodoropoulos 从最基础的 Button 出发，一步步演进到 Picker 与 Toggle，系统梳理了几种常见方案及其各自的局限。文章的价值不在于给出“唯一正确解”，而在于提醒开发者：SwiftUI 提供的标准组件，并不会自动带来最佳的用户呈现效果。很多时候，你仍需在“系统一致性”与“实现自由度”之间做出权衡。

构建 List 的替代组件 (Building List replacement in SwiftUI)

如何在 List 与 ScrollView + LazyStack 之间做出选择，一直是困扰不少 SwiftUI 开发者的问题。在本文中，Majid Jabrayilov 在重构其 CardioBot 应用时，选择基于 SwiftUI 的 Container View API（iOS 18+）构建了三个可复用的 UI 组件：ScrollingSurface、DividedCard、SectionedSurface，以替代 List。这些组件在使用方式上与 List + Section 高度相似，但彻底摆脱了 listRowBackground、listItemTint 等仅在 List 中生效的限制。

List 并非只是“有默认样式的 LazyVStack”——两者在底层架构、滚动控制、与导航容器的协同、以及大数据集下的性能表现上均有本质差异。如何在两者之间做出综合判断，可以参考这篇旧文。

AppIntents meet MCP

当大家还在将 AppIntents 视为 Siri 与快捷指令的“配套工具”时，Florian Schweizer 给出了一个更值得关注的方向：将 AppIntents 直接暴露为 MCP（Model Context Protocol）工具，从而让 LLM 能够调用你的应用能力。Florian 基于 SwiftMCP，通过宏构建 MCP Server，并将 AppIntents 无缝映射为 MCP Tools，使 AI Agent 能够直接调用应用中的 Intent，实现跨应用自动化。

去年便有传闻，苹果正在为其生态系统引入 MCP 支持。或许再过两个月，在 WWDC 26 上答案便会揭晓。

创建交互式小组件 (Ride the Lightning Air: Building Interactive WidgetKit Widgets)

很多开发者都会被 WidgetKit 的文档误导，错将 AppIntentTimelineProvider 视为实现交互按钮的关键——实则不然。它是为“用户可配置 Widget”（如长按后编辑设置项）准备的，与交互行为并无直接关系。而真正用于实现交互（按钮点击触发行为）的，依然是最基础的 TimelineProvider。Wesley Matlock 通过一个虚构航空公司的登机状态 Widget，完整演示了正确路径：使用 TimelineProvider

• Button(intent:) + AppGroup 共享存储来构建交互式 Widget。

  整个数据流形成一个清晰的闭环：用户操作 → Intent 执行 → 状态写入 → Widget 刷新 → UI 更新。

文件存储与 iCloud：从本地到云端的完整认知

在 iOS / macOS 开发和使用中，文件存储往往被当作“基础能力”，但它实际上直接决定了数据的生命周期与系统行为。

在 Working with files and directories in iOS 一文中，Natascha Fadeeva 系统梳理了 App Sandbox 的结构，以及 Documents、Library、Caches 等目录的职责划分，帮助开发者建立“什么数据该放在哪里”的基本认知，并说明如何避免无关文件被 iCloud 备份。

而 Howard Oakley 撰写的 Understanding and Testing iCloud 则从系统层面揭示了这些数据的“后续命运”。iCloud 并非单一服务，而是由 CloudKit、iCloud Drive、系统更新等多个子系统组成，不同数据类型对应不同的同步与备份路径。

文件的存储位置，并不仅仅是组织问题，更是在定义它是否会被备份、同步，以及在设备之间如何流转。

因此，iCloud 问题往往不是“是否开启同步”这么简单，而是涉及客户端、网络、缓存以及服务端限流等多个环节。

工具

Bad Dock: 让你的 Dock 图标动起来

这是一个“离谱但严肃”的 macOS 实验项目。Eric Martz 利用公开的 NSDockTile / NSDockTilePlugin API，绕过 Big Sur 之后 Dock 图标的 squircle 限制，将视频流直接渲染进 Dock 图标。实现思路并不复杂，但非常完整：使用 AVAssetReader 解码视频、主动降帧至约 12fps、通过 ring buffer 控制内存占用，最终将一个“整活想法”打磨成了结构清晰的技术验证。

这类项目的价值不在功能本身，而在于展示：系统 API 的边界，往往比文档写得更远。

补充说明：该项目实现的是运行时动态 Dock 图标（应用运行时持续绘制）；应用退出后，仅能通过 NSDockTilePlugin 保留静态自定义图标。

Apple’s Rare Concession: When Critical Vulnerabilities Meet the “Update Refusal” Wave

Read on web →

Most iOS users have recently encountered news about two serious security threats: Coruna and DarkSword. Both exploit chains rely on watering hole attacks — no user interaction required. Simply visiting a legitimate website embedded with a malicious iframe, or loading a compromised advertisement in Safari, is enough to trigger the full attack chain. Once data is exfiltrated, the malware cleans up its own traces automatically. Because the vulnerabilities exploited span the vast majority of iOS versions from iOS 13 through iOS 18.7, hundreds of millions of devices have been affected to date.

Coruna primarily targets devices running iOS 13 through iOS 17. Apple has pushed multiple security updates to these systems over the past several months. DarkSword, meanwhile, targets iOS 18.4 through 18.7 — devices that are all perfectly capable of running iOS 26, yet for various reasons, a significant number of iOS 18 users have chosen to stay put.

For a long time, iOS users were notably eager to update — one of the defining characteristics of the Apple ecosystem. That changed last year. The sweeping visual overhaul introduced by Liquid Glass prompted an unprecedented wave of deliberate refusals to upgrade to iOS 26, something Apple had never seen at this scale before. Compounding the problem, Apple introduced a mandatory age verification system in iOS 26.4 for UK users, in compliance with the Online Safety Act. The verification requirements proved strict enough that many adults found themselves forcibly locked into a “child mode,” fueling a separate wave of UK users choosing to remain on iOS 18 or iOS 26.3. In both cases, the decision to avoid updating meant forgoing all subsequent security patches — leaving devices increasingly exposed.

Faced with this situation, Apple came under significant public pressure and reputational risk. The turning point came in late March, when DarkSword’s complete exploit code was leaked to GitHub, effectively democratizing what had been a nation-state-level hacking tool and forcing Apple’s hand. Apple ultimately took the rare step of releasing a dedicated security patch for iOS 18 — iOS 18.7.7 — backporting the same protections already present in iOS 26 to the older system. With that, Apple completed its official security response to this wave of critical vulnerabilities.

Both Apple and developers across the ecosystem generally want users to stay current with system updates — it reduces the burden of maintaining compatibility across multiple versions and lets users benefit from new APIs sooner. The reality, though, is that a portion of users will always choose to lock their devices to a particular version, whether for performance, battery life, habit, or privacy reasons.

This episode may leave two lasting marks. On one side, Apple — under pressure — broke from a long-held update policy and made a concession to users who had deliberately chosen to stay on older software. On the other, the widespread attention the attacks received may nudge more users to reconsider the “update only when necessary” mindset and return to a more proactive stance toward system updates. That shift in both directions might just be the unexpected upside of an otherwise alarming security event.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

Animatable in SwiftUI Explained - Complete Guide with Examples & Deep Dive

There is no shortage of articles exploring SwiftUI’s animation system, yet this piece by Sagar Unagar offers a particularly insightful perspective. Rather than starting from implicit or explicit animations, it builds a systematic understanding around the Animatable protocol: from the role of animatableData, to how AnimatablePair carries multiple interpolated values, and finally to enabling more complex data structures to participate in animations via custom VectorArithmetic.

The most valuable takeaway is its core viewpoint: SwiftUI is not animating views directly—it is animating data.

Localization in Swift Packages

Xcode can automatically generate type-safe Swift symbols for .xcstrings files, but these symbols are only visible within the module that owns the resources. Once localization is extracted into a standalone Localization package, other feature modules lose the benefit of compile-time checks.

Khan Winter proposes a straightforward solution: use a bash script to parse the JSON structure of .xcstrings and generate a public extension LocalizedStringResource, allowing all modules to access keys via .l10n.helloWorld.

One particularly noteworthy detail is the use of @dynamicMemberLookup in Debug builds—missing keys log warnings instead of crashing, while Release builds retain full compile-time validation. Compared to approaches based on Swift executables, this solution is lightweight and easy to adopt—just copy the script.

SwiftUI Coordinator Pattern: Navigation Without NavigationLink

Although SwiftUI continues to evolve its state-driven navigation APIs, managing global navigation remains a persistent challenge. Wesley Matlock demonstrates a Coordinator-based approach using a five-tab music collection app as an example.

The idea is to extract navigation decisions from views: define all destinations in a Route enum, let a single Coordinator own navigation state and perform transitions, and have views simply declare “where to go” without caring about “how to get there.”

The article does not shy away from real-world tradeoffs, such as the opacity of NavigationPath and the complications of making route-carrying model objects conform to Hashable. For most mid-sized SwiftUI applications, this is a pragmatic and implementable approach to regaining control over navigation.

Teach your AI to write Swift the Hacking with Swift way

Paul Hudson and his Hacking with Swift have helped many developers get started with Swift and SwiftUI. In the age of AI, Paul is not only releasing specialized skills for Apple platform development, but also experimenting with injecting his personal coding style into AI collaboration.

In this article, he shares a highly distinctive (and characteristically humorous) AGENTS.md configuration. These rules go beyond technical choices—they embed Paul’s personality into the AI: prioritize showing results before explanations, favor clarity over cleverness, and even encourage a well-timed “Boom!” when code turns out particularly satisfying.

Rather than a simple system prompt, this feels more like defining a coding philosophy for AI. In a sense, it pushes code generation beyond mechanical output toward something closer to style transfer.

The Principles and Practices of AI Agents

At the recent Let’s Vision 2026, Wang Wei (Onevcat) delivered a talk on applying AI agents within large development teams. The focus was not on specific tools, but on how development workflows should evolve when the cost of code generation drops dramatically—and how the role of engineers should be redefined.

As a member of the LINE development team, Onevcat’s own work has already shifted in recent months. In his words, he is transitioning from a traditional iOS engineer to someone exploring how AI can support large-scale product development. This perspective gives the talk a depth that goes beyond typical tool introductions.

The talk revolves around three key questions: how to control context pollution, how to turn individual experience into reusable team-level memory and skills, and how to evolve collaboration from “humans directing multiple agents” toward more automated workflows. It includes many practical suggestions, such as keeping AGENTS.md concise, providing architectural lookup scripts, encouraging multiple harnesses (Claude Code, Codex, OpenCode) to coexist, and integrating agents into workflows via webhooks, cron jobs, pipelines, and automated validation.

The presentation repository includes not only the Slidev source but also supporting materials such as raw research and full AI collaboration traces—well worth exploring.

From Zero: The Complete Guide to Building a Native iOS App with AI

I often see “non-developers” on social media building products entirely with AI. Even after using AI tools for quite some time, I still find myself wondering: is this path really as effective as it seems?

Zachary Zhang shares a full end-to-end journey of building and shipping a native iOS app (SwiftUI + Cloudflare backend) entirely with AI. What stands out most is his disciplined engineering pipeline: before generating any code, he first produces a structured PRD and HTML-based visual references. For tooling, he strongly recommends terminal-based tools like Claude Code during the “0 to 1” phase, as they provide better visibility and control when constructing a multi-file project architecture.

You might share the same skepticism about fully AI-driven development. But as code generation becomes increasingly cheap, the true leverage of developers is shifting toward precise requirement decomposition, architectural control, and the ability to orchestrate systems in response to errors.

Tools

Slots: A Macro for Improving Custom SwiftUI Component Design

Composing multiple views into reusable components is a common need in SwiftUI—especially for teams and library authors. However, once a component introduces multiple generic slots (title, icon, image, action, etc.), initializer combinations can quickly explode.

The Slots macro by Kyle Bashour addresses this problem by generating initializer combinations automatically based on declared slot properties, eliminating the need to manually write numerous init overloads. For text-friendly slots, @Slot(.text) can also generate LocalizedStringKey and String variants automatically.

Slots is particularly well-suited for building design system components such as Card, Row, Banner, and Toolbar—where both ease of use and flexibility are required.

Explore SwiftUI: A Visual Reference for Native Components and Modifiers

Although Apple’s documentation has improved over the years, SwiftUI—being declarative and visually driven—still lacks intuitive side-by-side mappings between code and UI results, especially across platforms like iOS, macOS, and visionOS.

As a result, developers often resort to complex third-party libraries or verbose custom views for UI details that SwiftUI might already support natively.

Florian created Explore SwiftUI as a “visual dictionary” to address this gap. It focuses entirely on native components, with no third-party abstractions. Code examples are stripped of unrelated logic and paired with high-quality previews—allowing developers to simply copy, paste, and run.

Book

SwiftUI Architecture: Patterns and Practices for Building Scalable Applications

This is a recently published book by Mohammad Azam. It is not an introductory guide to VStack or animations, but a deep dive into SwiftUI architecture, data flow, and modern engineering practices.

The book addresses real production challenges, such as building global Sheets and Toasts, designing decoupled multi-tab routing with NavigationPath, and implementing elegant form validation using property wrappers. Importantly, it does not enforce a rigid architectural pattern, but instead helps you develop a true declarative mindset.

Some might wonder whether architecture-focused books still matter in the age of AI-assisted coding. As Azam puts it: AI makes code generation cheap—but precisely because of that, system design (clear boundaries and ownership of state) becomes more important than ever.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

苹果的罕见妥协：当高危漏洞遇上“拒升”潮

网页版

对于 iOS 用户来说，最近或多或少都会看到与 Coruna、DarkSword 有关的高危漏洞消息。两个攻击链均采用水坑攻击的方式，攻击者无需受害者进行任何交互，仅需访问一个被植入恶意 iframe 的合法网站或加载恶意广告，即可触发完整的攻击链，在窃取资料后自动清理攻击痕迹。由于工具链利用的漏洞存在于 iOS 13 至 18.7 的绝大多数版本中，截止目前，已有上亿用户受到影响。

Coruna 主要针对 iOS 13 至 iOS 17 的设备，在过去几个月间，苹果已为这些系统推送了多次安全更新。DarkSword 则主要针对 iOS 18.4 至 18.7 的设备。尽管这部分设备均具备升级至 iOS 26 的硬件条件，但由于种种原因，仍有不少 iOS 18 用户选择按兵不动。

在很长一段时间里，苹果用户对于系统更新的态度都相当积极，这也是苹果生态的一大特色。但这一趋势在去年出现了变化——Liquid Glass 带来的巨大视觉冲击，让苹果用户中第一次出现了相当比例主动拒绝升级到 iOS 26 的现象。与此同时，为遵守英国《网络安全法》（Online Safety Act）的要求，苹果在 iOS 26.4 中为英国用户引入了强制年龄验证机制，由于验证条件严苛，不少成年用户甚至被系统强行锁入‘儿童模式’，进一步推动了英国用户停留在 iOS 18 或 iOS 26.3 的风潮。而拒绝安装新版本，意味着这部分用户同时放弃了后续所有安全补丁，让设备进一步暴露在潜在风险之下。

面对这一局面，苹果承受了明显的舆论压力与品牌风险。特别是在 3 月下旬，DarkSword 的完整攻击代码被泄露到了 GitHub 上，让这一国家级黑客工具瞬间平民化，直接迫使苹果必须采取紧急行动。最终，苹果罕见地为 iOS 18 单独推出了安全补丁 iOS 18.7.7，将原本仅用于 iOS 26 的防护机制回移植到旧系统。至此，苹果完成了针对本次高危漏洞的全部官方安全响应。

无论是苹果还是生态中的开发者，大多希望用户能积极跟进系统更新——既能减少多版本适配的维护负担，也能让用户尽快享受到新 API 带来的便利。但现实是，始终有一部分用户出于性能、续航、使用习惯乃至隐私等方面的考量，有意将设备锁定在某个版本。

本次事件或许会带来两个方向上的变化：苹果在压力下调整了长期坚守的更新策略，为刻意留守旧系统的用户做出了妥协；而事件本身的广泛传播，也可能促使更多用户从安全角度重新审视“能不更新就不更新”的惯性，回到积极更新的轨道。这种双向的改变，或许正是这场风波意料之外的收获。

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

近期推荐

通过 Animatable 深入 SwiftUI 动画 (Animatable in SwiftUI Explained - Complete Guide with Examples & Deep Dive)

网络上并不缺少探讨 SwiftUI 动画机制的文章，但 Sagar Unagar的这篇仍然提供了一个颇具启发性的切入点。他没有从隐式或显式动画入手，而是围绕 Animatable 协议做了一次系统梳理：从 animatableData 的作用，到 AnimatablePair 如何承载多个插值参数，再到通过自定义 VectorArithmetic 让更复杂的数据结构参与动画。文章最值得注意的一点在于其核心视角：SwiftUI 实际上是在“动画数据”，而非直接对视图进行动画处理。

在 Swift Package 中共享本地化资源 (Localization in Swift Packages)

Xcode 能为 .xcstrings 文件自动生成类型安全的 Swift 符号，但这些符号仅在资源所在的 module 内可见——一旦将本地化资源抽离为独立的 Localization 包，其他 feature 包便无法享受编译期检查的优势。Khan Winter 的解决方案相当直接：通过一个 bash 脚本解析 .xcstrings 的 JSON 结构，生成 public extension LocalizedStringResource 扩展，使所有模块都能以 .l10n.helloWorld 的形式访问翻译键。

其中一个颇具参考价值的细节是 Debug 模式下的 @dynamicMemberLookup 设计——访问不存在的键时仅记录日志而不崩溃，而在 Release 构建中仍保留完整的编译期校验。相比基于 Swift 可执行文件的方案，这种实现更加轻量，复制脚本即可使用。

Coordinator 全局导航模式 (SwiftUI Coordinator Pattern: Navigation Without NavigationLink)

尽管 SwiftUI 一直在丰富基于状态驱动的导航 API，但管理全局导航一直是 SwiftUI 中的一个“痛点”。Wesley Matlock 以一个五 Tab 的音乐收藏应用为例，展示了如何通过 Coordinator 模式将导航决策从 View 中抽离：用一个 Route 枚举统一描述所有目的地，由单一的 Coordinator 对象持有导航状态并执行跳转，View 只需声明“去哪”而无需关心“怎么去”。文章没有回避 NavigationPath 不透明、路由携带模型对象导致的 Hashable 困境等实际问题。对于大多数中等规模的 SwiftUI 应用来说，这是一个务实且易于落地的导航治理方案。

把 Hacking with Swift 的编程风格写进 AI (Teach your AI to write Swift the Hacking with Swift way)

Paul Hudson 和他的 Hacking with Swift 让很多开发者走上了 Swift 与 SwiftUI 的学习之路。在 AI 时代，Paul 不仅推出了面向苹果开发生态的各类专业 Skill，也开始尝试在与 AI 的协作中注入更具个人特质的编程风格。

在本文中，他分享了一份极具辨识度（且充满他标志性幽默）的 AGENTS.md 配置。这套规则不仅约束了 AI 的技术选型，还为 AI 注入了 Paul 的灵魂：强调先展示结果再解释原理、偏好清晰而非炫技、甚至包括在代码写得漂亮时适时地喊出一句 “Boom!”。与其说这是一份用于 AI 的“系统提示词”，不如说是在为 AI 定义一种编码哲学——某种程度上，这种方式正在将冷冰冰的“代码生成”推向带有人情味的“风格迁移”。

AI Agent 的道与术

在刚过去的 Let’s Vision 2026 中，王巍（Onevcat） 发表了关于在大型开发团队中应用 AI Agent 的演讲。整场分享讨论的重点，并不是某个具体工具有多强，而是当代码实现成本被迅速压低后，团队该如何重新组织开发流程，以及工程师的价值该如何重新定位。

作为 LINE 应用开发团队的一员，Onevcat 在过去几个月中的工作重心也已明显发生变化。用他自己的话说，他正在逐步从传统意义上的 iOS 工程师，转向探索如何将 AI 应用于服务大型产品研发团队的实践者。这种角色上的变化，也让这场分享比一般的工具介绍更有说服力。

演讲围绕三个关键问题展开：如何控制上下文污染，如何把个人经验沉淀为团队可复用的 memory 与 skill，以及如何让协作模式从“人指挥多个 Agent”逐步走向更自动化的闭环。里面有不少相当接地气的实践建议，例如将 AGENTS.md 控制在精简范围内、为 Agent 提供模块定位与架构速查脚本、鼓励 Claude Code、Codex、OpenCode 等多种 harness 并存，以及通过 webhook、cron、pipeline 和自动验收机制让 Agent 真正进入团队流程。

演讲稿仓库 中不仅包含完整的 Slidev 源码，也保留了不少演讲配套材料，包括原始资料收集和与 AI 协作的完整 trace，值得一并阅读。

从零开始：用 AI 开发一个 iOS 原生 APP 完整指南

我经常会在社交媒体上看到一些零基础的“开发者”通过 AI 构建了自己的产品或服务。尽管我使用 AI 的时间也不短，但我仍然比较困惑：这条路径真的像大家描述的那样有效吗？Zachary Zhang 分享了他完全借助 AI 工具，从零构建并上架一款纯原生 iOS 应用（SwiftUI + Cloudflare 后端）的实战全过程。这篇文章最让我印象深刻的，是他严谨的“工程化管线”：在让 AI 写代码前，必须先生成结构化的 PRD 和 HTML 格式的视觉参考；而在工具选择上，他在项目“从 0 到 1”的冷启动阶段，极力推荐 Claude Code 等终端工具，以便更好地统览全局，一次性构建出合理的多文件项目架构。

或许你和我一样，对于 100% 基于 AI 的开发方式仍存疑惑。但在代码生成越来越廉价的今天，开发者的核心壁垒，正在加速向“需求精准拆解”、“系统架构把控”以及“面向报错的全局调度能力”转移。

工具

Slots：提高自定义 SwiftUI 组件设计效率的宏

将多个视图组合封装成可复用组件，是 SwiftUI 开发中的常见需求，对团队内部开发者或第三方库作者来说更是如此。但当组件包 title、icon、image、action 等多个泛型 View 插槽后，初始化器的组合数量往往会迅速膨胀。Kyle Bashour 创建的 Slots 宏，正是为了解决这类多 slot 组件的样板代码问题。

开发者只需声明组件的 slot 属性，宏便会按组合自动生成所需的初始化器，无需手写大量 init 重载。对于需要支持文本便捷写法的 slot，还可以通过 @Slot(.text) 自动获得 LocalizedStringKey 和 String 版本的初始化方式。 Slots 很适合用于构建设计系统中的 Card、Row、Banner、Toolbar 这类既要支持简单调用、又要保留高度定制能力的组件。

Explore SwiftUI：纯原生组件与修饰符的视觉速查图库

尽管 Apple 官方文档的质量在逐年改善，但对于以声明式和视觉驱动为主的 SwiftUI 来说，官方文档中依然缺乏足够直观的代码与 UI 效果对照，尤其是同一组件在 iOS、macOS 和 visionOS 等多平台上的表现差异。很多时候，开发者为了实现某个特定的 UI 细节，往往会去求助于复杂的第三方库或手写冗长的自定义视图，却忽略了 SwiftUI 本身可能已经提供了绝佳的原生解决方案。Florian 建立的 Explore SwiftUI 站点，正是一个为了解决这一痛点而生的“视觉速查字典”。它摒弃了任何第三方封装，纯粹以展示 Apple 官方内置组件的原生能力为核心。所有的代码示例都被剥离了无关的业务逻辑，保持极简，配以高质量的视觉预览，开发者只需“复制、粘贴、运行”即可直接验证效果。

书籍

SwiftUI Architecture: Patterns and Practices for Building Scalable Applications

这是一本 Mohammad Azam 在不久前出版的新书。它不是一本教你如何使用 VStack 或编写动画的入门书，而是一本纯粹探讨 SwiftUI 应用架构、数据流和现代工程化实践的进阶读物。

书中提供了大量直击生产环境痛点的解决方案，例如：如何构建全局的 Sheets 和 Toasts、如何利用 NavigationPath 设计解耦的多 Tab 编程式路由、以及如何使用 Property Wrapper 编写优雅的表单验证。尤为重要的是，作者并不是要向你灌输某种死板的架构模式，而是旨在帮助你建立真正的声明式心智模型。

或许有人觉得，在 AI 辅助编程盛行的时代，这类探讨架构的书籍还重要吗？借用 Mohammad Azam 在书中的观点：AI 让代码生成变得廉价，但也正因如此，系统架构的设计（边界的划分和状态所有权的明确）变得比以往任何时候都更加重要。

A Wall Away, Worlds Apart

Read on web →

The annual Let’s Vision conference was held in Shanghai as scheduled, with this year’s theme being: “Born to Create, Powered by AI.” Therefore, alongside the regular sessions on Swift and spatial computing, the conference invited many developers to share their applications and insights regarding AI in their daily workflows. I benefited immensely from the speakers’ introductions to their AI workflows. The AI-themed venue, originally designed to hold only 300 people, was packed inside and out with an enthusiastic crowd.

However, among the many excellent sessions, a talk prepared by YuChe Cheng titled “Let’s Create 1-liner Code in Swift” drew my attention to another room. What exactly was this topic about? Driven by curiosity, I walked in. As a developer with a LeetCode rating of 2200+, YuChe Cheng demonstrated how to use the extensive higher-order functions provided by Foundation and Swift Algorithms to transform plain, ordinary for-loop code into elegant, beautiful, and highly Swift-styled function chaining (1-liner code). In doing so, he achieved a brilliant balance between readability and performance.

Watching the function chaining on the slides being elegantly iterated over and over again, I felt a refreshing sense of clarity and enlightenment. For the entire 30-minute talk, I remained in a state of pure excitement—a feeling that typically only emerges after I’ve racked my brain to finally conquer a difficult problem, or when I’ve deeply grasped a new concept.

Even though it was only a wall away from the main venue, the overwhelming popularity of the AI topic meant the audience for this talk was noticeably sparse. Rather than feeling regret that so many missed out on a fantastic presentation, my real concern is this: As AI penetrates further into our industry, will that distinctive “character” developers once pursued and imbued into their code—beyond mere functionality—fade into oblivion?

Developers shouldn’t only care about cold, compiled binaries. Code itself is a vessel for personal style. Just like writing an essay, beyond delivering logic and results, it carries aesthetic expression, reflecting the author’s personal taste and ingenuity.

At this year’s Let’s Vision, I felt as though we were standing at a crossroads: Should we relentlessly pursue the extreme efficiency brought by AI, or, while embracing change, can we ensure that the pride and craftsmanship belonging to developers are still preserved in the AI era?

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

Swift 6.3 Released

Since Swift 6, the language has settled into a steady cadence of one minor release every six months. Swift 6.3 was released as expected last week. Compared to previous releases, this version does not introduce any major headline features, but instead focuses on refining the existing system: improvements in concurrency diagnostics, the introduction of the @c attribute to further strengthen C/C++ interoperability, and more granular control over compiler optimizations.

That said, this release still sends a clear signal: Swift is evolving from a language centered around Apple platforms into a more general-purpose language with cross-platform and system-level capabilities. The continued progress of Embedded Swift, Android support, and the unification of the SwiftPM build system all point in this direction. For most iOS developers, the short-term impact may feel limited, but in the long run, this is a foundational update paving the way for what comes next.

Designing a type-driven JSON in Swift

When API contracts are unstable and the understanding of fields between frontend and backend frequently drifts, Swift’s strong type system can actually amplify the friction at the JSON boundary. Roman Niekipielov introduces a deliberately minimal JSONValue type to handle such transitional data.

Compared to [String: Any], it preserves clearer type structure; compared to fully defined Codable models, it better accommodates frequently changing contracts. This approach does not aim to replace formal models, but rather to contain uncertainty at the boundary layer.

Swift Native AI Agent Development Series

While many developers build AI agents using Python or TypeScript, Chris Karani argues that Swift’s concurrency model is naturally well-suited for agent isolation and scheduling, with its strong type system and macro capabilities adding extra safety guarantees.

Across six articles, he explores this idea from multiple angles—from a unified multi-provider LLM SDK Conduit, to an agent runtime built on Apple Foundation Models Colony, and even Metal-accelerated context memory management. If you are considering building AI features on Apple platforms, this is one of the few comprehensive native approaches available today.

Talking Liquid Glass with Apple

Danny Bolella attended Apple’s Liquid Glass design workshop in New York, spending three days in close collaboration with design teams and SwiftUI engineers. The message from the event was clear: Liquid Glass is not a transitional experiment, but a long-term design direction that will become the default across future toolchains.

Apple also repeatedly emphasized the importance of hierarchy—interfaces should be built around content, with controls serving as supporting elements positioned toward the edges. Beyond that, Danny also shares practical advice and implementation insights from Apple engineers. The article offers an early look into the direction and philosophy behind this design evolution.

Apple Dropped 100+ New Metrics. Your Competitors Are Already Using Them

Apple has rolled out one of the most significant updates to App Store Connect in recent years, introducing 100+ first-party metrics, cohort analysis by source, peer benchmarks (conversion rate and revenue per download), and subscription data export via API. Jessica Chung provides a structured overview of these changes.

Since all data now comes directly from Apple, developers can move away from third-party estimates and make decisions based on real user behavior. More importantly, this update fills a long-standing gap: you can now track user quality across channels and keywords, build a full funnel from impression to subscription and retention, and benchmark your performance against peers.

This update is clearly beneficial for developers, but it also raises the bar for third-party App Store analytics tools, pushing them to deliver higher-value capabilities to remain competitive.

Package Traits in Xcode

When building an SPM package, some dependencies may only be used by specific APIs. However, once the package is added, those dependencies are included regardless of whether those APIs are used. Package Traits were introduced to address this issue by allowing developers to define optional features that consumers can enable as needed, avoiding unnecessary dependencies.

Unfortunately, after its introduction, this feature was only available in community Swift toolchains. With the release of Xcode 26.4, Package Traits finally gained official support from Apple, making broader adoption more likely. Matt Massicotte introduces the feature and demonstrates its usage in this article.

Why your SwiftUI app feels slow even though Instruments says it’s fine?

When users complain about slow responsiveness, is it always a performance issue? Rafał Dubiel shifts the focus from actual performance to perceived performance, exploring how UI feedback and interaction timing can make apps feel faster.

Techniques such as skeleton views, delayed loading, and thoughtful animations can effectively mask waiting time. The key insight is that user experience is often less about reducing milliseconds and more about providing timely feedback. Compared to raw performance optimization, this perspective has a more direct impact on how users perceive fluidity.

Adjusting line height in SwiftUI on iOS 26

iOS 26 introduces a new lineHeight(_:) modifier in SwiftUI for controlling the baseline distance between lines of text. Natalia Panferova provides a detailed comparison of its configurations, including presets (.loose, .tight), proportional scaling (.multiple(factor:)), incremental adjustments (.leading(increase:)), and absolute control (.exact(points:)).

Unlike lineSpacing(_:), which adjusts spacing between lines, lineHeight(_:) directly defines baseline distance, offering more consistent control. This addition further improves SwiftUI’s typography capabilities.

Natalia Panferova, a former member of Apple’s SwiftUI core team, has recently published a new book The SwiftUI Way, aimed at experienced SwiftUI developers. The book focuses on production patterns, common anti-patterns, and how to work with the framework rather than against it.

Tools

Cove: A Swift 6 Native macOS Open Source Database Client

Cove, developed by Emanuele Micheletti, is a native macOS database client built entirely with Swift 6. It currently supports a wide range of backends including PostgreSQL, MySQL, MariaDB, SQLite, MongoDB, Redis, ScyllaDB, Cassandra, and Elasticsearch. Built with SwiftUI and AppKit instead of Electron or web technologies, it delivers a lightweight experience aligned with macOS conventions.

What makes Cove particularly interesting is its architecture. All database capabilities are abstracted through a unified DatabaseBackend protocol, with no backend-specific logic in the UI layer. Whether dealing with SQL databases, key-value stores like Redis, or NoSQL systems like MongoDB and Elasticsearch, everything is normalized into a table model for rendering. Although still in an early v0.1.0 stage, it already supports querying, schema browsing, editing, SSH tunneling, and multi-tab workflows. Even if you don’t plan to use it as your daily database tool, it’s a valuable reference for Swift-based desktop app architecture.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

一墙之隔，不同的时空

网页版

一年一度的 Let’s Vision 大会在上海如期举行，今年的主题是：“Born to Create, Powered by AI”。除了与 Swift、空间计算相关的常规 Session，大会还邀请了许多开发者分享他们在工作中对 AI 的应用与理解。通过这些讲师对 AI 工作流的介绍，我也受益匪浅。原本只能容纳 300 人的 AI 主题会场，里三层外三层站满了热情高涨的观众。

然而，在众多优秀的 Session 中，一场由 YuChe Cheng 准备的、名为《Let’s Create 1-liner Code in Swift》的演讲却将我的注意力引向了另一个会场。这究竟是一个怎样的话题？带着疑问我走了进去。作为一个 LeetCode 积分 2200+ 的开发者，YuChe Cheng 在演讲中展示了如何通过 Foundation 以及 Swift Algorithms 提供的大量高阶函数，将原本平淡无奇的 For-loop 代码，转换成更加优雅、美观、极具 Swift 风格的 Function Chaining（1-liner code），并在易读性与性能之间取得了很好的平衡。

看着幻灯片上的 Function Chaining 被一次又一次地优雅迭代，我有种茅塞顿开的畅快。整整 30 分钟的演讲，让我始终处于一种纯粹的兴奋之中——这种感觉，通常只在我绞尽脑汁最终攻克了一个难题，或是深刻理解了一个新概念后才会涌现。

尽管与主会场只有一墙之隔，但由于 AI 话题的绝对热度，本场演讲的听众明显偏少。与其说我为许多人错失了一场精彩演讲而感到遗憾，我真正担心的其实是：随着 AI 的进一步渗透，许多开发者原本在追求功能之外所赋予代码的那份“气质”，会不会就此消亡？

开发者不应该只关心编译后冷冰冰的二进制功能，代码本身也是个人风格的载体。它就像文章一样，在输出逻辑与结果之外，还承载着美学表达，体现着编写者的个人品味与巧思。

在今年的 Let’s Vision 上，我感觉我们正站在一个时间的十字路口：我们是该一味追求 AI 带来的极致高效，还是在拥抱变化的同时，依然让属于开发者的那份骄傲与手艺，在 AI 时代得以保留？

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

本期推荐

Swift 6.3 Released

从 Swift 6 开始，语言演进已经稳定在半年一个 minor 版本的节奏，上周 Swift 6.3 如期发布。与前几个版本相比，这一版本并未引入明显的重磅特性，更多是对既有体系的打磨：并发模型在诊断准确性方面有所改进，新增的 @c 特性（attribute）进一步强化了 C/C++ 互操作能力，同时编译优化的控制粒度也变得更加细致。

尽管如此，这一版本也释放出一个清晰的信号：Swift 正在从“以 Apple 平台为中心的应用开发语言”，逐步向“具备跨平台与系统级能力的通用语言”演进。Embedded Swift、Android 支持的持续推进，以及 SwiftPM 构建体系的统一，都在指向这一方向。对多数 iOS 开发者而言，短期体感或许有限，但从更长的时间维度来看，这更像是一次为未来铺路的基础性更新。

如何在 Swift 中承接尚未稳定的 JSON (Designing a type-driven JSON in Swift)

当 API 契约尚未稳定、前后端对字段的理解又经常漂移时，Swift 的强类型系统反而会放大数据与 JSON 之间转换时的边界问题。Roman Niekipielov 在本文中介绍了一个刻意做小的 JSONValue 类型，用来承接这类过渡阶段的 JSON 数据。相比 [String: Any]，它保留了更明确的类型结构；相比直接编写 Codable 模型，又更适合应对频繁变化的契约。这个实现并不试图替代正式模型，而是将不确定性暂时限制在边界层。

Swift 原生 AI Agent 开发实践系列

市面上有大量开发者使用 Python、TypeScript 开发 AI Agent，但 Chris Karani 认为，Swift 的并发模型天然更适合 Agent 的隔离与调度，强类型系统和宏功能也带来了额外的安全保证。他用 6 篇文章、从多个角度实践了这一观点——从统一多个 LLM Provider 的 SDK Conduit，到基于 Apple Foundation Models 的 Agent 运行时 Colony，再到用 Metal 加速的上下文记忆管理。如果你正在考虑在 Apple 平台上构建 AI 功能，这个系列是目前少见的完整原生方案。

Liquid Glass 设计工作坊 (Talking Liquid Glass with Apple)

Danny Bolella 在纽约参加了苹果举办的 Liquid Glass 设计工作坊，与设计团队和 SwiftUI 工程师进行了为期三天的深入交流。本次活动传递出非常明确的信号：Liquid Glass 并非过渡性尝试，而是苹果未来数年的设计方向，且将在后续工具链中成为默认前提。与此同时，苹果反复强调“层级（Hierarchy）”的重要性——界面应围绕内容构建，控件只是服务于内容的辅助元素，应尽量退居边缘，让信息本身成为视觉与交互的中心。除此之外，Danny 还在本文中记录了其他一些 SwiftUI 工程师给出的建议和技巧。本文记录的内容可以帮助你更早理解这场设计演进的节奏与方向。

App Store Connect 大更新 (Apple Dropped 100+ New Metrics. Your Competitors Are Already Using Them)

苹果对 App Store Connect 进行了近年来最大的一次更新，一口气引入了 100+ 官方指标、按来源划分的 cohort 分析、同行基准对比（转化率与单下载收益）以及可通过 API 导出的订阅数据。Jessica Chung 在本文中对这些关键变化进行了系统梳理。由于所有数据均来自苹果一手统计，这意味着开发者在 ASO 和增长决策中，将不再依赖第三方估算，而可以直接基于真实用户行为进行分析与优化。更重要的是，这次更新补齐了长期缺失的关键能力：你可以追踪不同关键词与渠道带来的用户质量，建立从曝光、下载到订阅与续费的完整转化链路，并通过同行基准明确自身所处位置。

本次更新对于开发者而言无疑是利好，但对于部分第三方 App Store 分析服务来说，也在一定程度上提高了竞争门槛，促使其提供更具附加值的能力。

Package Traits in Xcode

在创建 SPM 时，某些依赖可能只被特定 API 使用，但一旦用户引入该包，即便不使用这些 API，也需要一并引入相关依赖。Package Traits 正是为了解决这一问题而引入的，它为 SPM 提供了一种声明可选特性的方式，使使用者能够按需启用功能，从而避免引入不必要的依赖。遗憾的是，在该功能推出后，一直只能在社区版本的 Swift 工具链中使用。随着 Xcode 26.4 的发布，Package Traits 终于获得了苹果官方支持，有望迎来更广泛的应用。Matt Massicotte 在本文中对该特性进行了介绍，并展示了其基本用法。

优化感官性能，让用户感觉更快 (Why your SwiftUI app feels slow even though Instruments says it’s fine?)

用户投诉响应慢，一定是应用性能问题吗？Rafał Dubiel 将关注点从“实际性能”转向“感知性能（Perceived Performance)”，讨论如何通过界面反馈与交互节奏，让用户感觉应用“更快”。例如通过 skeleton view、延迟加载，以及合理的动画与状态过渡来掩盖等待时间。作者指出，在许多场景下，用户体验的关键并不在于减少毫秒级的计算时间，而在于是否及时提供反馈。相比单纯优化性能指标，这种从用户感知出发的思路，往往更直接地影响用户对应用流畅度的判断。

在 SwiftUI 中控制行高 (Adjusting line height in SwiftUI on iOS 26)

iOS 26 为 SwiftUI 新增了 lineHeight(_:) modifier，用于控制文本相邻两行基线之间的距离。Natalia Panferova 在本文中对各种配置方式进行了详细对比：内置预设（.loose、.tight）、基于字号倍数的 .multiple(factor:)、固定增量的 .leading(increase:)，以及绝对值控制的 .exact(points:)。此外，lineHeight(_:) 与已有的 lineSpacing(_:) 并不相同：前者控制基线间距，后者控制行底到下一行行顶的距离。

Natalia Panferova 曾是 Apple SwiftUI 核心团队成员，参与过多个关键 API 的设计与开发。本月她刚刚出版了新书 The SwiftUI Way，面向有一定 SwiftUI 经验的开发者，聚焦于生产环境中的模式选择、常见反模式识别，以及如何与框架“顺势而为”而非对抗。

工具

Cove：Swift 6 编写的 macOS 开源数据库客户端

Cove 是由 Emanuele Micheletti 开发的一款原生 macOS 数据库客户端，整个项目完全使用 Swift 6 构建，目前已经支持 PostgreSQL、MySQL、MariaDB、SQLite、MongoDB、Redis、ScyllaDB、Cassandra 和 Elasticsearch 等多种后端。它采用 SwiftUI 搭配 AppKit 原生控件实现，没有走 Electron 或 Web 技术栈，因此整体更轻量，也更符合 macOS 用户熟悉的交互体验。

相比“又一个数据库 GUI”，Cove 更值得关注的是它的实现思路。作者将所有数据库能力统一抽象为 DatabaseBackend 协议，UI 层不包含任何针对特定后端的分支逻辑。无论是 SQL 数据库、Redis 这类键值数据库，还是 MongoDB、Elasticsearch 这类非关系型后端，最终都会被整理为统一的表格模型交由界面渲染。项目目前仍处于 v0.1.0 的早期阶段，但已经具备查询、结构浏览、编辑、SSH 隧道和多标签等基础能力。即便你并不打算把它作为日常数据库工具，Cove 依然是一个很值得 Swift 开发者研究的桌面应用架构样本。

Is My App Stuck in Review?

Read on web →

Last Thursday, a user in my Discord community complained that their app had been submitted to App Store Connect for four or five days but still hadn’t entered the review process. While I was enthusiastically analyzing the possible reasons with everyone, my heart suddenly skipped a beat: it seemed that the app I submitted on Monday hadn’t received any review updates either.

Someone suggested I apply for an “Expedited Review”. However, when I clicked into the page, the system prompted that I had “no eligible apps”. Upon closer inspection, I realized I was just a bit rusty from not updating my apps for so long—although my app had completed all the prerequisite steps, I simply hadn’t clicked the “Submit for Review” button at all.

Just a few hours after I finally clicked the button, the app was successfully approved and published.

While my situation was a mere false alarm, discussions in the community about Apple’s app review process slowing down have indeed been increasing recently. Many speculate that this might be related to the recent rise of Vibe Coding. Although there is no official confirmation, Vibe Coding has undeniably lowered the barrier to entry for development. In doing so, it has simultaneously amplified the volume of app submissions and the frequency of iterations in a short period, thereby passing the pressure down to the review team.

In fact, Apple has recently been holding up the review process for apps like Replit, which allow everyday consumers to engage in Vibe Coding. Even when allowing them to remain on the store, Apple has demanded compromises on core features. In Michael Tsai’s blog post covering this news, I came across a very sharp comment:

I thought the implication was that the vibe coding apps were being used to make the vibecoded apps that get submitted.

AI is not only reshaping the way we develop software but also posing new challenges to the app review and distribution systems. One might ask: if we fight magic with magic and let AI fully take over the review process, wouldn’t it be more efficient?

Apple’s review mechanism has never been entirely transparent. Sometimes, whether an app passes smoothly or not even depends on whether you “happen to” encounter a sympathetic reviewer. But looking at it from another angle, at least “humans” remain the most crucial part of this defense line. Human judgment can be flawed and biased, but it still retains a certain degree of flexibility when dealing with rigid rules.

I truly hope that the software ecosystem of the future does not devolve into a closed loop of “AI Development -> AI Review”.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Original

CDE: An Attempt to Make Core Data Feel More Like Modern Swift

In last week’s article, I discussed the current reality of Core Data in modern projects: it hasn’t disappeared and still holds unique value, but the sense of misalignment between it and modern Swift development is becoming increasingly apparent. In this article, I continue along that line of thought and introduce an experimental project of mine: Core Data Evolution (CDE).

It is not a new framework intended to replace Core Data, nor is it an attempt to pull developers back to older technologies. More accurately, it is my own response to this misalignment: if I still recognize the value of Core Data’s object graph model, migration system, and mature runtime, can it continue to exist in modern Swift projects in a more natural way?

Recent Recommendations

Expanding Animations in SwiftUI Lists

Developers often encounter a frustrating animation issue: when dynamically changing the height of a row inside a List, the content does not expand smoothly, but instead jumps abruptly. In this article, Pavel Zak demonstrates through several experiments why common approaches such as conditional rendering with if, withAnimation, or even .transition fail to produce the desired effect inside List. While built-in solutions like DisclosureGroup can achieve smoother results, Pavel presents a more flexible approach: using Animatable combined with view size measurement to ensure that List receives continuously changing height values during the animation, resulting in a truly smooth expansion.

A key characteristic of List (which is still backed by UIKit/AppKit) is that it requires a definitive row height during layout. Therefore, instead of letting List deal with structural changes, developers should, like DisclosureGroup, transform “discrete changes” into “continuous changes” by providing interpolatable height values. This is also why developers often resort to the Animatable protocol when dealing with animation anomalies. For a deeper understanding of this protocol and its use cases, you can refer to my previous article.

SwiftUI iPad Adaptive Layout: Five Layers for Apps That Don’t Break in Split View

While Apple’s push toward multi-window capabilities in iPadOS is well-intentioned, it significantly increases the complexity of layout adaptation. Apps may appear in various forms, such as iPhone-like layouts, traditional full-screen iPad views, or Stage Manager windows. Wesley Matlock points out that relying solely on horizontalSizeClass is often insufficient in real-world scenarios. Developers need to combine container size with size classes to build a more fine-grained LayoutEnvironment, make layout branching decisions at the root view, and leverage mechanisms like ViewThatFits to let the system choose the most appropriate UI based on actual constraints, rather than assumptions about the device.

Pitfalls and workarounds when dealing with RGB HDR Gain Map using ImageIO

The introduction of RGB HDR Gain Map based on the ISO 21496-1 standard in iOS 18 enables richer HDR image processing, but also introduces new pitfalls. Although the relevant APIs can return auxiliary data dictionaries, in the RGB Gain Map scenario the actual bitmap data (kCGImageAuxiliaryDataInfoData) is missing, preventing further processing. In other words, ImageIO is unable to fully read the content it generates in this case. Weichao Deng proposes a hybrid approach: use Core Image to read the Gain Map as a CIImage, manually render it into bitmap data, reconstruct the missing fields, and then write it back via ImageIO. For developers working on camera or image processing apps that involve HDR Gain Maps, this article can save a significant amount of debugging time.

A Vision for Networking in Swift

The Swift Ecosystem Steering Group recently published a vision document on networking, discussing the current fragmentation in Swift’s networking ecosystem and its potential future direction.

The document highlights a clear divide: URLSession, SwiftNIO, and Network.framework coexist with overlapping functionality but incompatible abstractions. Developers often need to commit early to a specific stack, making later changes costly. Additionally, most existing networking APIs were designed before Swift Concurrency and rely on completion handlers, delegates, or reactive patterns, which feel increasingly out of place in modern Swift.

The proposed direction is a unified, layered networking architecture: shared I/O primitives and buffer types at the bottom, reusable protocol implementations (TLS, HTTP/1.1/2/3, QUIC, WebSocket) in the middle, and async/await-based client and server APIs at the top. The swift-http-types package (defining HTTPRequest / HTTPResponse) can be seen as an early step in this direction. The document also emphasizes that SwiftNIO and Network.framework will not be replaced, but will gradually converge toward shared underlying primitives.

The vision is currently open for community feedback. You can participate here.

Preparing Your iOS Codebase for AI Agents

As AI agents (such as Codex and Claude Code) become increasingly involved in real-world development workflows, the focus is shifting from “how to use AI to write code” to “how to make codebases suitable for AI collaboration”. Hesham Salman explores this transition from an engineering perspective.

He argues that AI relies more on explicit contracts than on prompts. By structuring project conventions and behavioral rules through layered AGENTS.md documentation, using a Makefile to standardize build and test workflows, and encoding multi-step processes into reusable “skills,” implicit engineering knowledge can be transformed into structured, machine-readable systems.

One particularly insightful detail: the author requires agents to update documentation whenever they encounter undocumented conventions, while enforcing a strict rule — every change must make the document shorter or more useful. This self-maintaining mechanism prevents both documentation decay and uncontrolled growth, striking a practical balance.

iOS Conf SG 2026 Videos

iOS Conf SG 2026 was held from January 21 to 23 in Singapore, featuring dozens of developers and content creators from around the world sharing their insights and experiences in the Apple ecosystem. Last week, the full set of talks was released. I also had the opportunity to participate as a speaker, and you can explore the sessions as you’re interested.

Tools

TaskGate: Managing Actor Reentrancy

While actors largely eliminate data races, their reentrant nature means that logic which appears sequential can lose its execution order after an await, leading to duplicate work or inconsistent state.

TaskGate, created by Matt Massicotte, addresses this scenario by introducing AsyncGate and AsyncRecursiveGate, which define critical sections for asynchronous code within actors. These ensure that only one task can enter a given section at a time. Unlike traditional locks, TaskGate allows safe asynchronous operations while holding the gate.

Matt explicitly notes that this is not a replacement for well-designed actor models, but rather a supplementary tool when other approaches are insufficient. The gates are intentionally non-Sendable to reduce misuse across actors. If you’re dealing with reentrancy-related state issues or want to better understand this subtle aspect of Swift concurrency, both the library and the related Reddit discussion are worth exploring.

pico-bare-swift

When Apple created Swift, the goal was clearly broader than just app development—it was meant to evolve into a general-purpose language across domains and abstraction levels. However, for a long time, Swift has struggled to gain traction in areas traditionally dominated by C/C++ or Rust. Through this example project, kishikawa katsumi demonstrates another possibility: with Embedded Swift, the language is beginning to enter the domain of embedded systems.

What makes this project particularly appealing is that it turns something traditionally associated with low-level, C-centric development into a structured learning path. It goes far beyond “blinking an LED with Swift,” covering startup code, vector tables, memory initialization, register access, as well as drivers for UART, PWM, I2C, and SSD1306 OLED displays. In a sense, the value of such projects lies not in their practicality, but in how they redefine the boundaries of what Swift can do.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

我的 App 审核被卡了？

网页版

上周四，我 Discord 社区里的一位网友抱怨，说他的应用在 App Store Connect 上提交了四五天，却迟迟没有进入审核状态。就在我还津津有味地跟大伙儿分析原因时，突然心里一紧：我周一提交的应用，好像也一直没收到审核动态？

有网友建议我去申请一下“加急审核”。可当我点进页面时，系统却提示我“没有可加急的应用”。仔细一查才发现，原来是太久没更新 App，业务都生疏了——我的应用虽然完成了所有前置步骤，但我压根儿就没点那个“提交以供审核”的按钮。

补点按钮没过几个小时，应用就顺利上架了。

尽管我这纯属虚惊一场，但最近社区里关于“苹果审核变慢”的讨论确实多了起来。很多人猜测，这或许与近期 Vibe Coding 的盛行有关。虽然没有官方证实，但 Vibe Coding 确实在降低开发门槛的同时，也在短时间内放大了应用提交的数量与迭代频率，从而把压力传导到了审核环节。

事实上，苹果最近也确实对 Replit 这类允许普通用户进行 Vibe Coding 的应用在审核上进行了卡关。即便允许其上架，也要求在核心功能上做出妥协。在 Michael Tsai 关于此事的博客介绍中，我看到了一条非常敏锐的留言：

I thought the implication was that the vibe coding apps were being used to make the vibecoded apps that get submitted.

这些 Vibe Coding 应用正被用来批量制造那些提交上架的应用。

AI 不仅在重塑开发方式，也正在对应用审核与发行体系提出新的挑战。有人或许会问：如果用魔法打败魔法，让 AI 也全面接管审核流程，会不会更高效？

苹果的审核机制向来不够透明，有时候应用能否顺利过审，甚至取决于是否“碰巧”遇到一位气味相投的审核员。但换个角度看，至少“人”仍然是这道防线中最重要的一环。人的判断会出错，也会带有偏差，但在面对规则时仍保有一定的弹性。

我不希望，未来的软件生态，走向“AI 开发 -> AI 审核”的闭环。

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

原创

CDE：一次让 Core Data 更像现代 Swift 的尝试

在 上周的文章 中，我聊了聊 Core Data 在当下项目中的一些现实处境：它并没有消失，也仍然有其独特价值，但它和现代 Swift 项目之间的错位感却越来越明显。在本文中，我想继续顺着这个问题往下走，介绍我的一个实验性项目：Core Data Evolution（CDE）。

它不是一个取代 Core Data 的新框架，也不是要把开发者重新拉回旧技术。更准确地说，它是我面对这些错位时，给自己的一种回答：如果我仍然认可 Core Data 的对象图模型、迁移体系和成熟运行时能力，那么能不能让它在现代 Swift 项目中以一种更自然的方式继续存在下去？

近期推荐

实现平滑的 SwiftUI List 展开动画 (Expanding Animations in SwiftUI Lists)

开发者经常会遇到一个动画窘境：在动态调整 List 中某一行高度时，内容并不是平滑展开，而是伴随着明显的高度跳变。在本文中，Pavel Zak 通过几个实验，展示了为什么常见的 if 条件渲染、withAnimation 甚至 .transition 在 List 中都难以达到理想效果。尽管 DisclosureGroup 这种内建方案可以达到预期，但 Pavel 还是给出了一个更灵活的方案：基于 Animatable 与视图尺寸测量的实现方式，让 List 在动画过程中始终获得连续变化的高度，从而实现平滑的展开动画。

List（底层仍然是 UIKit/AppKit 的列表实现）有一个核心特点：它需要在布局阶段就拿到每一行的“确定高度”。因此，对开发者来说，不要让 List 面对结构变化，而是像 DisclosureGroup 那样，将“离散变化”转化为“连续变化”，持续提供可插值的高度值。这也是在处理动画异常时，开发者常常借助 Animatable 协议的原因。想进一步了解该协议的原理与适用场景，可以阅读我之前的一篇文章。

如何更好的适配 iPadOS 的布局 (SwiftUI iPad Adaptive Layout: Five Layers for Apps That Don’t Break in Split View)

尽管苹果强化 iPadOS 多窗口能力的初衷是好的，但这也显著提升了开发者在布局适配上的复杂度。应用可能以类 iPhone、传统 iPad 全屏、Stage Manager 窗口等多种模式呈现。Wesley Matlock 指出，仅依赖 horizontalSizeClass 进行布局判断在实际环境中往往是不够的。开发者需要结合容器尺寸与 size class 构建更细粒度的 LayoutEnvironment，并在根视图中统一完成布局分支决策；同时借助 ViewThatFits 等机制，让系统基于真实约束选择最合适的界面形式，而不是由开发者预先假设设备类型。

RGB HDR Gain Map + ImageIO 中的使用陷阱 (Pitfalls and workarounds when dealing with RGB HDR Gain Map using ImageIO)

iOS 18 中引入的基于 ISO 21496-1 标准的 RGB HDR Gain Map，让开发者在处理 HDR 图像时获得了更高的表现力，但在实际应用中也更容易踩坑：尽管相关接口能够返回辅助数据字典，但在 RGB Gain Map 场景下却缺失了实际的位图数据（kCGImageAuxiliaryDataInfoData），导致后续处理无法继续。换句话说，ImageIO 在这一场景下甚至无法完整读取自身生成的内容。Weichao Deng 提出了一种混合方案：使用 Core Image 读取 Gain Map 的 CIImage，手动渲染为 Bitmap Data，补齐缺失字段后，再通过 ImageIO 写回文件。对于正在开发相机或图像处理类应用、需要处理 HDR Gain Map 的开发者来说，这篇文章或许能帮你省下不少调试时间。

Swift 社区的网络愿景 (A Vision for Networking in Swift)

Swift Ecosystem Steering Group 上周发布了一份关于网络编程的愿景文档，讨论了 Swift 网络生态当前的困境以及未来可能的发展方向。

文档指出，Swift 在网络领域存在明显的分裂：URLSession、SwiftNIO 与 Network.framework 并存，功能重叠却互不兼容，开发者往往需要在项目早期就押注某一套技术栈，且切换成本极高。与此同时，现有的大多数网络 API 都诞生于 Swift Concurrency 之前，依赖 completion handler、delegate 或响应式模式，与现代 Swift 的语言特性存在明显脱节。

文档提出的方向是构建一套分层统一的网络架构：底层共享 I/O 原语与缓冲类型，中间层复用 TLS、HTTP/1.1/2/3、QUIC、WebSocket 等协议实现，顶层提供以 async/await 和结构化并发为基础的客户端与服务端 API。已有的 swift-http-types（定义了 HTTPRequest / HTTPResponse）可以视为这一思路的早期实践。文档同时强调，SwiftNIO 和 Network.framework 不会被废弃，而是将逐步向统一的底层原语收敛。

该愿景目前正在征集社区反馈，可以在此参与。

让你的 iOS 项目更适合 AI 协作 (Preparing Your iOS Codebase for AI Agents)

随着 AI agent（如 Codex、Claude Code 等）逐渐参与到实际开发流程中，问题开始从“如何使用 AI 写代码”转向“如何让代码库本身适合 AI 协作”。Hesham Salman 从工程实践的角度，系统性地探讨了这一转变。

Hesham 指出，相较于提示词，AI 更依赖显式契约。通过分层的 AGENTS.md 文档明确项目约定与行为规则，使用 Makefile 将构建、测试等操作统一为可执行入口，并通过“skills”将多步骤流程编码为可复用的执行方法，从而将原本隐性的工程知识结构化地嵌入到代码库中。

文章中有一个细节令人印象深刻：作者要求 agent 在发现未记录的约定时主动更新文档，同时加入了一条强约束——每次修改都必须让文档更短或更有用。这一自维护机制既防止文档腐化，也避免文档膨胀，是一个值得借鉴的平衡策略。

iOS Conf SG 2026 视频

2026 年 iOS Conf SG 于 1 月 21 日至 23 日在新加坡举行，来自全球的数十位开发者与内容创作者分享了各自在苹果生态开发中的经验与思考。上周，官方放出了本届的全部演讲视频。我也有幸参与了其中的一场分享，感兴趣的读者可以按需挑选观看。

工具

TaskGate：解决 Actor 重入的工具

尽管 actor 在很大程度上避免了数据竞争，但其可重入（reentrancy）特性也意味着，一些看似串行的逻辑在 await 之后可能失去原有的执行顺序，进而造成重复执行或状态不一致。

Matt Massicotte 编写的 TaskGate 正是为这类场景准备的。它提供了 AsyncGate 和 AsyncRecursiveGate 两种机制，用来为 actor 内部的异步代码定义“临界区”，确保同一时间只有一个任务能够进入相关逻辑。与传统锁不同的是，它允许在持有 gate 的同时安全地执行异步调用。

Matt 明确指出：该库并不是用来替代良好的 actor 设计，而更像是一种在其他手段不够合适时的补充工具。库中将 gate 刻意设计为 non-Sendable，以降低跨 actor 误用的风险。如果你正在处理 actor 重入导致的状态一致性问题，或希望更深入理解 Swift 并发中的这一薄弱环节，这个库以及 Matt 在 Reddit 中的 讨论 都值得一看。

pico-bare-swift

苹果当年创建 Swift 时，对它的期待显然不只是用于开发 App，而是希望它最终成长为一门适用于不同领域、不同层次的通用语言。不过，在相当长一段时间里，Swift 在那些传统上由 C/C++ 或 Rust 主导的领域中，始终没有展现出足够的存在感。kishikawa katsumi 通过这个示例项目展示了另一种可能：借助 Embedded Swift，Swift 已经开始具备进入嵌入式开发场景的能力。

这个项目最吸引我的地方，在于它将一件原本带有明显“底层/C 语言专属”色彩的事情，组织成了一条相当清晰的学习路径。它不仅是“用 Swift 点亮一个 LED”，而是将启动代码、向量表、内存初始化、寄存器访问，以及 UART、PWM、I2C、SSD1306 OLED 等外设驱动一并纳入 Swift 的实现范围之中。某种程度上，这类项目的意义不在于“是否实用”，而在于它重新划定了 Swift 的能力边界。

Apple at 50 and Me at 51

Read on web →

In less than half a month, Apple will celebrate its 50th birthday. Tim Cook has also published a short piece paying tribute to the journey of the past half-century. However, because of Apple’s image as a constant trendsetter, many people don’t realize that it is now a veritable elder statesman in the IT industry. Among the tech giants of its age, very few remain at the top-tier table today.

As a tech enthusiast who is only one year older than Apple, from the Apple II to today’s iPhone and MacBook, Apple’s products have accompanied me through most of my life. Strictly speaking, I wouldn’t call myself a hardcore Apple fan—I don’t feel regret if I don’t buy a new product on day one, I rarely stay up late to watch keynotes anymore, and I’m even less familiar with the exact specs of their newest devices. But looking back, at every major milestone in my life, I have naturally chosen Apple products, and in recent years, I have become a part of the Apple developer ecosystem.

To be honest, I haven’t entirely figured out where Apple’s enduring appeal to me comes from. Is it because I started using its products so early on? Is it its innovation, user experience, and overall vibe? Or is it Steve Jobs’ charisma? Truth be told, my choice today is driven purely by habit and instinct, much like the unspoken understanding between old friends—it simply no longer requires any specific reason.

Of course, Apple’s path of growth hasn’t always been smooth sailing; there have been valleys along the way. But one thing must be acknowledged: its corporate positioning over the past 50 years has remained almost completely unchanged—to create powerful tools for individuals and society. Even in the latest wave of AI, where Apple seems to have lost the first-mover advantage, as the core player connecting people to the digital world in that “last centimeter,” it still holds the capital to remain at the center of the table in the AI era. After all, we live in a physical world, and we need tangible hardware and personalized services to truly enjoy the fruits of technological progress.

Apple at 50 might offer an inspiration to other companies: rather than imitating its “cool” and “innovative” exterior, it is better to learn from its focus and persistence. Becoming a long-term companion to its users is perhaps the true secret to its success.

In all likelihood, ten years from now, when Apple turns 60 and I turn 61, I will still be using a Mac.

Happy Birthday, Apple!

Previous Issue｜Newsletter Archive

This Week’s Sponsor

Native AI chat app — ultra-fast, privacy-first, 100+ pro features

One native app, 100+ AI models on Mac, iOS, and Android. Fast, keyboard-driven, no Electron. 25% off for a limited time with code FATBOBMAN25.

⚡️ Get BoltAI — 25% off ->

Original

Why I’m Still Thinking About Core Data in 2026

By 2026, Core Data has been around for 21 years. While many developers still use it, in modern Swift projects it increasingly feels like a relic of an earlier era. Concurrency still relies on layers of perform calls, model declarations are filled with boilerplate, and string-based predicates are always ready to trip you up. This article is not a defense of Core Data, nor an attempt to persuade new developers to adopt it. Instead, it’s more of a problem inventory: why do some developers still choose to stick with Core Data in 2026, and if we continue using it, what are the real issues we need to address today?

Recent Recommendations

Fortify Your App: Essential Strategies to Strengthen Security Q&A

During a security-focused event hosted by Apple’s Developer Center, several Apple engineers spent nearly six hours discussing application security and memory safety, covering topics such as modern security challenges and the defensive technologies available across Apple platforms. Anton Gubarenko compiled and organized a large portion of the developer Q&A from the session. The discussion touches on topics such as evaluating the security of third-party libraries, risks when storing data with UserDefaults or plist files, best practices for Keychain and file protection, the safe use of Swift unsafe APIs, and enabling Enhanced Security capabilities in Xcode. For developers interested in understanding Apple’s platform security model and practical recommendations, this is a dense and valuable collection of insights, many of them coming directly from Apple engineers.

Faster iOS Subscriptions with ASC CLI and RevenueCat MCP

Adding subscription support to an app isn’t particularly difficult, but configuring everything across both App Store Connect and RevenueCat can be surprisingly tedious. Rudrank Riyam introduces a more efficient approach: using the ASC CLI to create App Store Connect subscription products directly from the terminal, and then letting an AI agent configure the corresponding entitlements, offerings, and paywalls through RevenueCat’s MCP Server. This workflow effectively moves the entire setup process from manual dashboard interactions into a CLI + AI agent automation pipeline.

JetBrains Swift Developers Survey

JetBrains recently released a survey aimed at Swift developers, inviting them to share the tools they use, their development workflows, and the pain points they encounter in the Swift ecosystem. Although JetBrains has not explained the specific purpose of the survey, the community has already started to speculate that it may be related to a renewed evaluation of Swift development tooling support.

After JetBrains discontinued AppCode in 2022, most Swift developers returned to an Xcode-centric toolchain. This new survey has sparked some discussion: some developers hope JetBrains might revisit Swift tooling, while others suspect the effort could be more closely related to Kotlin Multiplatform or Swift build tooling. If you’re interested in the future direction of Swift development tools, you might want to take part in the survey.

How Well Can You Detect a Swift Protocol Without the Compiler?

Protocols are everywhere in Swift projects, but how reliably can you determine whether a Swift file defines or references a protocol without compiling the project or resolving its dependencies? In this article, Xiangyu Sun evaluates a variety of detection strategies, including SourceKit/LSP queries, SwiftSyntax AST parsing, simple keyword regex matching, and heuristic signals such as extension Foo: Bar or the any/some prefixes. Each method is analyzed in terms of accuracy and applicability.

One particularly interesting finding is that simple naming conventions can dramatically improve static analysis accuracy. If a team consistently uses a *Protocol suffix for protocol types (for example, PaymentServiceProtocol), many otherwise ambiguous heuristics become far more reliable. The author also explores how this convention can benefit AI-assisted development workflows: by pre-classifying protocol files before sending code to an LLM, it becomes possible to reduce token usage and improve analysis efficiency — an insightful perspective for teams experimenting with AI-driven tooling.

What you should know before Migrating from GCD to Swift Concurrency

Migrating from GCD to Swift Concurrency is not merely a matter of replacing syntax. In this article, Soumya Ranjan Mahunt highlights several important differences between the two concurrency models. Swift Concurrency differs from GCD in task scheduling, execution ordering, and concurrency semantics — differences that can introduce subtle data races or difficult-to-reproduce runtime issues during migration if not properly considered.

For example, Task scheduling does not guarantee the same FIFO execution order as GCD, and actor should not be viewed as a direct replacement for DispatchQueue, since task priorities and scheduling strategies can influence execution behavior. The article also discusses practical migration pitfalls, such as the lack of a direct equivalent to DispatchGroup in Swift Concurrency, and compatibility issues that may arise when using assumeIsolated on older system versions.

A 9-Step Framework for Choosing the Right Agent Skill

As AI agents become increasingly integrated into development workflows, designing the right “skills” (tools or capabilities) for those agents is emerging as a new engineering challenge. Antoine van der Lee proposes a nine-step framework to help determine when it actually makes sense to implement a dedicated agent skill.

As Antoine points out, not every task should be delegated directly to an LLM, and not every capability needs to become an agent tool. The framework evaluates factors such as task determinism, execution cost, reusability, and security considerations, providing a structured way to reason about when and how to extend an AI agent’s capabilities.

Tools

DataStoreKit

This is a particularly interesting open-source project developed by Anferne Pineda. It leverages SwiftData’s custom store capability to re-implement a SQLite-backed persistence engine while preserving SwiftData’s higher-level developer experience. The project maps SwiftData models, predicates, and queries to SQLite schemas, SQL execution, snapshots, and persistent history management.

DataStoreKit also introduces several noteworthy capabilities. For example, it supports predicate queries on collection types such as arrays and dictionaries by mapping them to JSON structures stored in SQLite. It also exposes a SQL passthrough layer, allowing developers to bypass #Predicate when necessary and directly execute SQLite queries or maintenance operations.

This is one of the few projects that explores SwiftData’s DataStore extensibility at significant depth, demonstrating how SwiftData can function as a data abstraction layer rather than a complete persistence engine. The project is still in an early stage and its APIs and capabilities may evolve, but it is already well worth watching.

Playwright for Swift

Developed by Miguel Piedrafita, swift-playwright brings the mature browser automation capabilities of Playwright into the Swift ecosystem. Developers can control Chromium, Firefox, and WebKit directly from Swift code to perform tasks such as page navigation, clicking, form input, screenshots, and JavaScript execution. The API design also closely mirrors the official Playwright interface.

Under the hood, the project does not re-implement a browser automation framework. Instead, it wraps the Playwright protocol on the Swift side while continuing to communicate with browsers through the Node.js Playwright driver. For developers interested in building testing tools, CLI utilities, or even AI agents using Swift, this project offers a compelling entry point.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

50 岁的苹果和 51 岁的我

网页版

再有不到半个月，Apple 将迎来 50 岁生日。Tim Cook 也发表了一篇短文，致敬过去半个世纪的历程。不过，由于苹果一直以来始终引领潮流的形象，很多人并没有意识到它已经是 IT 产业中名副其实的元老。与它年龄相当的 IT 巨头，如今仍留在一线牌桌上的寥寥无几。

作为一个只比苹果大一岁的科技爱好者，从 Apple II 到如今的 iPhone、MacBook，苹果的产品几乎伴随我走过了大半人生。严格来说，我并不算真正的果粉——不会因为没能第一时间买到新品而遗憾，也几乎不再熬夜看发布会，更说不出新产品的具体参数。但回顾过去，在每一个人生节点上，我都会很自然地选择苹果的产品，并在近几年成为了苹果开发生态中的一员。

其实我也没有完全想明白，苹果对我持久的吸引力究竟来自哪里。是因为很早就开始使用它的产品？是它的创新、体验和气质？还是 Jobs 的人格魅力？说实话，如今的选择已经完全出于习惯和本能，就像老友间的默契，早已不需要什么特别的理由。

当然，苹果的成长之路并非一帆风顺，其间也有过低谷。但有一点必须承认：它在过去 50 年间的企业定位几乎没变——为个人和社会创造强大的工具。即便在最新一轮 AI 浪潮中，苹果看似失去了先机，但作为连接人与数字世界的“最后一厘米”的核心参与者，它仍然具备在 AI 时代留在牌桌中央的资本。毕竟，我们生活在物质世界中，需要实打实的硬件设备和个人化服务来享受技术进步的成果。

50 岁的苹果或许能给更多企业带来启示：与其模仿它“炫酷”、“创新”的外表，不如学习它的专注与坚持。成为与用户长久互相陪伴的伙伴，或许才是它成功的真正密码。

大概率再过十年，当苹果 60 岁、我 61 岁的时候，我仍然用着一台苹果电脑。

生日快乐，苹果！

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

本期赞助

原生 AI 聊天应用 — 极速、隐私优先、100+ 专业功能

一个原生应用，100+ AI 模型，支持 Mac、iOS 和 Android。极速响应、键盘驱动、非 Electron。限时优惠，使用码 FATBOBMAN25 立享 75 折。

⚡️ 获取 BoltAI — 75 折优惠 ->

原创

2026 年，为什么我仍在思考 Core Data

到 2026 年，Core Data 已经问世 21 年，尽管仍有不少开发者在使用它，但在今天的 Swift 项目里，它越来越像个“时代遗留”。并发得靠 perform 一层层套，模型声明堆满样板代码，字符串谓词随时等你踩坑。这篇文章不是要为 Core Data 辩护，也不是要说服新的开发者回到 Core Data。它更像是一篇问题整理：在 2026 年，为什么仍有人坚持使用 Core Data；而如果要继续使用它，我们今天真正需要解决的问题又是什么。

近期推荐

苹果工程师谈应用安全与内存保护 (Fortify Your App: Essential Strategies to Strengthen Security Q&A)

在苹果开发者中心举办的一场安全专题活动中，多位苹果工程师围绕应用安全与内存安全进行了近六小时的分享与问答，内容涵盖现代应用面临的安全挑战，以及 Apple 平台提供的一系列防护技术。Anton Gubarenko 将这场活动中的大量开发者问答整理成文，讨论了第三方库安全评估、UserDefaults 与 plist 数据存储的风险、Keychain 与文件保护策略、Swift unsafe API 的使用边界，以及如何在 Xcode 中启用 Enhanced Security 等能力。对于希望了解 Apple 平台安全机制与实践建议的开发者来说，这是一份信息密度很高的问答整理，其中包含不少来自苹果工程师的一手信息。

用 CLI 与 MCP 自动化配置 iOS 订阅 (Faster iOS Subscriptions with ASC CLI and RevenueCat MCP)

为应用添加订阅功能本身并不复杂，但在 App Store Connect 与 RevenueCat 两个后台之间来回配置，过程往往相当繁琐。Rudrank Riyam 介绍了一种更高效的做法：使用 ASC CLI 在终端中一次性创建订阅产品，再让 AI 代理通过 RevenueCat 的 MCP Server 自动完成 entitlements、offerings 与 paywall 的配置，从而将原本依赖控制台点击的流程迁移到 CLI + AI Agent 的自动化工作流中。

JetBrains 面向 Swift 开发者的调查 (JetBrains Swift Developers Survey)

JetBrains 最近发布了一份面向 Swift 开发者的调研问卷，邀请开发者分享当前使用的开发工具、工作流程以及在 Swift 生态中的痛点。尽管官方并未说明调研的具体用途，但社区中已经出现不少猜测：这项调查可能与 JetBrains 重新评估 Swift 开发工具支持有关。

在 JetBrains 于 2022 年宣布停止维护 AppCode 之后，Swift 开发者基本回到了以 Xcode 为核心的工具链。此次调研也引发了一些讨论——有人期待 JetBrains 重新探索 Swift tooling 的可能性，也有人认为这更可能与 Kotlin Multiplatform 或 Swift 构建工具链相关。如果你对 Swift 开发工具生态的未来方向感兴趣，不妨参与这份调查。

不依赖编译器识别 Swift Protocol 的方法 (How Well Can You Detect a Swift Protocol Without the Compiler?)

在 Swift 项目中，Protocol 几乎无处不在，但如果不依赖编译器或完整构建环境，仅通过源码文本判断一个文件是否定义或使用了协议，结果会有多可靠？Xiangyu Sun 在这篇文章中系统评估了多种检测策略，例如使用 SourceKit/LSP、SwiftSyntax AST、关键字正则匹配，以及通过 extension Foo: Bar、any / some 等语法信号进行启发式判断，并对这些方法的准确率与适用场景进行了比较。

文章最有意思的部分在于作者发现：简单的命名约定可以显著提升静态分析效果。如果团队统一使用 *Protocol 后缀命名协议类型（如 PaymentServiceProtocol），很多原本存在歧义的检测方法都会变得更加可靠。作者还进一步讨论了这种约定在 AI 辅助开发中的价值：通过在文件级别预分类协议文件，可以在向 LLM 提供上下文时显著减少 token 消耗，并提高分析效率，这是一个颇具启发性的视角。

迁移到 Swift Concurrency 前需要注意的细节 (What you should know before Migrating from GCD to Swift Concurrency)

从 GCD 迁移到 Swift Concurrency 并非简单的语法替换。在这篇文章中，Soumya Ranjan Mahunt 指出：Swift Concurrency 在任务调度、执行顺序以及并发语义上与 GCD 存在一些关键差异，例如 Task 的调度并不保证与 GCD 相同的 FIFO 执行顺序，而 actor 也并不是 DispatchQueue 的直接替代，其执行行为可能受到任务优先级和调度策略的影响。此外，文中还讨论了一些在实际迁移过程中容易被忽视的问题，例如 DispatchGroup 在 Swift Concurrency 中并没有完全等价的 API，以及在旧系统版本中使用 assumeIsolated 可能遇到的兼容性问题。

选择 AI Agent Skill 的九步框架 (A 9-Step Framework for Choosing the Right Agent Skill)

随着 AI Agent 在开发工作流中的应用越来越广泛，如何为 Agent 设计合适的“技能”（Skill / Tool）也逐渐成为一个新的工程问题。Antoine van der Lee 提出了一个用于判断何时应该为 Agent 创建技能的九步框架，帮助开发者在自动化能力、可维护性以及系统复杂度之间取得平衡。Antoine 指出，并非所有任务都适合直接交给 LLM，也并非所有能力都需要实现为 Agent 工具。文章从任务确定性、执行成本、可复用性以及安全性等角度出发，提供了一套相对系统的评估思路。

工具

DataStoreKit

这是一个很有意思的开源项目，由 Anferne Pineda 开发。它基于 SwiftData 的自定义 store 能力，在保留 SwiftData 上层开发体验的同时，重新实现了一套面向 SQLite 的底层存储后端，包括从 SwiftData 模型、谓词到 SQLite schema、SQL、快照与持久化历史的映射和执行。

DataStoreKit 提供了一些值得关注的特性，例如支持对数组、字典等集合类型数据进行谓词查询，底层以 JSON 形式映射到 SQLite；同时也提供了 SQL 直通能力，让开发者在 #Predicate 之外，能够直接利用 SQLite 的能力完成查询或维护操作。

这是目前为数不多、且实现深度较高的 SwiftData DataStore 自定义实践，展示了 SwiftData 作为数据表现层而非完整持久化引擎的另一种可能性。项目目前仍处于较早期阶段，API 和能力边界可能还会继续调整，但已经非常值得持续关注。

Playwright for Swift

Miguel Piedrafita 开发的 swift-playwright，将 Playwright 这套成熟的浏览器自动化能力带入了 Swift 生态。开发者可以直接使用 Swift 代码驱动 Chromium、Firefox 和 WebKit，完成页面导航、点击、输入、截图、执行 JavaScript 等常见操作，整体 API 风格也尽量贴近官方 Playwright。

从实现方式上看，它并不是重新实现一套浏览器自动化框架，而是在 Swift 侧封装了 Playwright 协议，底层依然通过 Node.js 的 Playwright driver 与浏览器通信。对于希望使用 Swift 构建测试工具、CLI，甚至 AI Agent 的开发者来说，这个项目提供了一个颇具吸引力的切入点。

活动

LET’S VISION 2026 -- Born to Create · Powered by AI

• 👀 70+ 展商现场体验

• 🤖 AI 创新产品 / AI Agent

• 🥽 XR / 空间计算沉浸体验

• 🎤 创作者与开发者分享

如果你是开发者、设计师、产品经理、创作者，还是对 AI 和未来科技感兴趣的探索者，都很值得来逛逛。

• 📅 2026.3.28 – 3.29

• 📍 上海 · 漕河泾会议中心

八五折门票获取入口 👇

MacBook Neo: The Starting Point of Apple’s Return to Campus

Read on web →

Last week, Apple launched several new hardware products. Unlike previous launch events, this release was unusually low-key. Initially, I was only interested in the newly announced monitor, but after seeing numerous tech media outlets criticizing the MacBook Neo’s specs, I couldn’t help but pay closer attention to it. Looking past the superficial “downgrades”, I saw Apple’s clear determination to return to the education market through its precise pricing strategy.

Over a decade ago, Apple was a dominant player in the education hardware market. A significant portion of students who grew up using Apple devices on campus naturally transitioned into long-term consumers of Apple’s hardware and software after entering the workforce. However, as Google continuously ramped up its investments in Chromebooks and Apple lacked a price-competitive alternative, this K-12-centric market was gradually taken over by competitors (Chromebooks once captured nearly 60% of the U.S. K-12 education market). This not only cost Apple a portion of its revenue but, more importantly, weakened the brand affinity it had established among teenagers surrounding desktop and laptop computing forms. Compared to tablets, laptops still hold distinct advantages in teaching experience, use cases, durability, and centralized IT management.

In today’s service-first era, hardware is deeply intertwined with ecosystems. Chromebooks have long cultivated a massive cohort of young users accustomed to using Google Docs. As these users grow older and accumulate data, even if they eventually have the purchasing power to buy Apple devices, it becomes incredibly difficult to deeply lock them into Apple’s service ecosystem, let alone cultivate true brand loyalty.

The precise pricing of the Neo changes this dynamic. A starting price of $599 and an education discount of $499 give more children the opportunity to start using Apple devices and owning an Apple ID in school, thereby following Apple’s “predetermined path” to gradually purchase more products and services. As for the widely criticized “downgraded specs”—the A18 Pro chip is more than sufficient for daily K-12 scenarios. It isn’t lacking in performance; this is exactly where it is meant to be positioned. Apple traded a mobile chip for aggressive pricing headroom—a very shrewd calculation.

The subscription-based Apple Creator Studio also demonstrates Apple’s ambition to build long-term relationships with a broader audience within its ecosystem. For schools, cheap hardware combined with a powerful creative software suite forms a perfect closed loop. The MacBook Neo’s hardware performance may not be top-tier, but it is enough to provide a stable, usable experience over a typical 4- to 5-year device lifecycle, allowing users to gradually assimilate into Apple’s service system. From this perspective, the MacBook Neo acts more like an “ecosystem anchor” tossed by Apple to Gen Z and Gen Alpha.

Too many consumers and tech reviewers focus entirely on whether Apple’s products are cool or innovative, forgetting Apple’s roots—the education hardware market is deeply embedded in its DNA. Its success today stems from decades of past accumulation, and now it needs to fill the void left over the past dozen years. For the readers of this newsletter, the Neo is highly unlikely to be your cup of tea. But that doesn’t prevent it from being a highly targeted and ambitious product—one that isn’t designed to make a quick buck, but rather serves as Apple’s long-term bet on its ecosystem landscape for the next two decades.

Previous Issue｜Newsletter Archive

This Week’s Sponsor

Notepad.exe — Your First Stop for Swift Experiments

New Swift 6 syntax to try? Xcode is too heavy, Playground too slow. Notepad.exe gets you from idea to running code in 30 seconds — no project setup. Multi-toolchain support, simulator integration, just open and code.

🚀 Download for macOS →

Original

Why Does Passing NSManagedObjectContext Across Isolation Domains No Longer Error in Swift 6.2? The Real Change Isn’t in the Compiler

When a piece of concurrency-related code fails to compile in older versions of Xcode but compiles successfully in the latest Xcode 26 (Swift 6.2), what would be your first guess? Many developers might initially assume that Swift’s concurrency analysis—such as Region-Based Isolation—has evolved again. But the reality is not that simple. In this article, I document a rather interesting debugging journey I recently encountered: starting from a failing test, constructing a minimal reproducible example, and tracing the issue all the way down to the Core Data SDK interface. Eventually, I discovered that the key change was not entirely in the Swift compiler itself, but in how the framework is imported. In the new SDK, NSManagedObjectContext is now annotated with macros like NS_SWIFT_SENDABLE, giving it Sendable semantics in Swift.

Although SwiftData is the most important persistence framework for the future of the Apple ecosystem, Core Data—the foundation beneath it—has not been neglected by Apple. Over the past few years, Apple has been quietly improving its compatibility and concurrency behavior in Swift 6, which is a very encouraging sign.

Recent Recommendations

What’s new in Swift: February 2026 Edition

Karen Chu and Dave Lester compiled the latest developments in the Swift ecosystem for February 2026 on the official blog. The post not only highlights Swift’s strong presence at FOSDEM—the world’s largest open source conference—but also showcases several notable open-source updates and Swift Evolution proposals. Among them, SE-0506 particularly caught my attention. The proposal introduces an Options parameter to withObservationTracking, allowing developers to precisely control whether they observe changes before mutation (willSet), after mutation (didSet), or even lifecycle events such as deinit. Additionally, withContinuousObservationTracking enables stable, automatic continuous observation without the need to manually re-register observers recursively.

The acceptance of SE-0506 is significant. It not only completes the timing control and continuity capabilities of state observation, but also marks the maturity of Swift’s native Observation system. It is no longer merely a companion feature for SwiftUI, but has evolved into a robust foundation capable of supporting industrial-grade, high-performance state-flow scheduling across Swift applications.

macOS Input Method Development Guidelines for 2026

Based on years of experience developing macOS input methods, ShikiSuen, the author of the vChewing Input Method, provides a comprehensive overview of the historical baggage of InputMethodKit (IMK) and the various issues it exposes under Swift 6’s strict concurrency checks. The article explores challenges such as NSConnection naming conventions, sandbox requirements, MainActor isolation conflicts, ARC congestion caused by frequent language switching (CapsLock), and even NSWindow memory leaks under the macOS 26 Liquid Glass mechanism. Rather than simply criticizing these legacy frameworks, the author proposes a set of engineering practices that resemble a “risk-control model”: reducing controllers to simple forwarding layers, moving business logic into weak-referenced sessions, using self-checking memory guards, and avoiding IMKCandidates entirely.

Notably, ShikiSuen implemented these ideas in an open-source library called IMKSwift. It provides an @MainActor-isolated IMKInputSessionController base class designed for Swift 6+, covering many concurrency pitfalls in the original IMKInputController. If you are developing macOS desktop applications or input methods, this library allows you to write type-safe, modern Swift code without manual hacks or data-race warnings.

SwiftUI, Swift Effects: A Beautiful Onion Architecture

Handling data loading states in SwiftUI is something almost every application has to deal with. The common states—loading, loaded, and failed—are often intertwined with side effects such as network requests, caching, and logging, which can quickly make view code messy. In this article, Salgara proposes an approach inspired by Onion Architecture. By combining ViewState with Effect Handlers, side effects such as Fetch, caching, and logging are separated into composable layers. AsyncSequence and injectable Effect Handlers then drive state transitions, allowing the UI to render purely based on state. In this design, the view layer remains clean while data and side effects flow through a clearly structured “effect pipeline.” The architecture also provides strong testability—tests can intercept effects and simulate data sources to validate state transitions.

Salgara openly acknowledges that this architecture is still experimental: prototype-first, and treating everything as a view (Everything as a View). As more developers explore architectures that better align with SwiftUI’s design philosophy, such experiments may not only benefit SwiftUI itself but also enrich the broader landscape of declarative programming rather than merely replicating patterns from other UI frameworks.

Spec-Driven Development: After AI Starts Writing Code

With the growing adoption of AI coding agents such as Cursor and Claude Code, developers are facing a new challenge: when AI can generate thousands of lines of code across dozens of files in minutes, how can humans effectively review it? And how should we deal with issues like context decay and hallucinations as conversations grow longer? A new development paradigm is emerging in response: Spec-Driven Development (SDD). In this model, developers no longer focus primarily on writing code directly. Instead, they define clear specifications (Specs), and AI generates implementations based on those specifications.

Snow explores this idea through a four-part series. Starting with the limitations of “Vibe Coding,” the articles outline a specification-centered development workflow and examine the evolving role of specifications in future software engineering. In this vision, code may no longer be the center of a project—it may simply become a byproduct of well-defined specifications.

As AI increasingly handles implementation details, the center of software engineering may shift from “writing code” to “expressing intent.” SDD attempts to establish a strong layer of constraints between human ambiguity and AI’s indiscriminate code generation.

Building a Mini Linker for SwiftUI Previews

Among the many tools provided by mcpbridge in Xcode 26.3, RenderPreview can directly return screenshots of SwiftUI previews, making them easier for AI to analyze. For developers who cannot yet use Xcode 26.3 mcpbridge, the approach and accompanying tools introduced by Hesham Salman offer a similar capability. The technical highlight lies in using SwiftSyntax to construct a declaration dependency graph, then applying BFS to determine the minimal set of source files required by a given preview. This avoids the need to compile the entire App target, significantly reducing build time.

The real value of this article lies in its approach: using SwiftSyntax + BFS to quickly identify the code segments required by a preview. In the past, SwiftSyntax had a relatively high barrier to entry, but in the age of AI-assisted development it is increasingly becoming foundational infrastructure for understanding code structure. Even if you are not as experienced with SwiftSyntax as Hesham Salman, once you understand its basic capabilities you can leverage AI to implement similar ideas—tools that previously were often built only by developers deeply familiar with compiler tooling.

Swift at scale: building the TelemetryDeck analytics service

When discussing Swift on Server, many people still focus on a simple question: can it be used in production? TelemetryDeck provides a more concrete answer—not only can it be used, it is already powering an analytics service that processes data from over 16 million users each month. In this article, Daniel Jilg explains why the team chose Swift + Vapor for their backend stack and shares valuable lessons from operating a production system. These include using Codable to simplify API encoding and validation, keeping DTOs close to controllers, and recognizing that seemingly mundane practices—like cache TTLs, API versioning, and monitoring—often become the true moat in large-scale production systems.

Get Rid of Your SwiftGen Dependency

For many years, developers relied on tools like SwiftGen to solve a longstanding issue in Apple’s resource system: resource access was stringly typed. Whether it was localization keys, image names, or color assets, typos often went unnoticed until runtime. Asser Osama points out that with the introduction and maturation of String Catalogs (.xcstrings) and Asset Catalog Symbols, Xcode can now automatically generate resource symbols during compilation. For many modern projects, this built-in capability may already replace the need for SwiftGen.

It is worth noting that removing the dependency assumes your project runs entirely within the standard Xcode ecosystem. Resource symbol generation is an internal feature of the Xcode build system rather than a capability of the Swift compiler or Swift Package Manager. For teams using non-standard build systems such as Bazel or Buck, SwiftGen may still remain the more portable and controllable option.

Tools

SwiftUI Agent Skill

Written by Paul Hudson, this SwiftUI Agent Skill aims to help developers produce smarter, simpler, and more modern SwiftUI code. The project gained over 1k stars within just two days of release.

Over the past few weeks, this newsletter has recommended several skills created by well-known developers. While these skills encapsulate the authors’ experience, I still don’t recommend using them blindly. At the very least, read them thoroughly before adopting them. A skill is essentially a condensed form of insights accumulated across dozens or even hundreds of articles. Only by understanding the underlying design ideas—and adapting them to your own development habits and project needs—can you truly unlock their value.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

Macbook Neo：苹果重回校园的起点

网页版

上周，苹果推出了若干新款硬件产品。与以往的发布会不同，这次发布显得异常低调。起初我只对其中新发布的显示器感兴趣，但在看到不少数码媒体对 Macbook Neo 配置的吐槽后，也不由得多留意了这款产品。相较于其“减配”的表象，我更从其精准的定价中看到了苹果重返教育市场的决心。

十几年前，苹果还曾是教育硬件市场的重要参与者。那些在校园中使用苹果设备成长起来的学生，也有相当一部分在进入社会后顺理成章地成为苹果软硬件的长期消费者。但随着谷歌持续加大在 Chromebook 上的投入，而苹果又缺乏更具价格竞争力的产品，这一以 K12 为核心的市场逐渐被对手占据（Chromebook 曾一度拿下美国基础教育市场近 60% 的份额）。这不仅让苹果损失了一部分收入，更重要的是削弱了其在青少年群体中、围绕台式机与笔记本这种计算形态所建立的品牌亲和力。相比平板设备，笔记本在教学体验、适用场景、耐用性以及 IT 集中管理等方面依然具有明显优势。

在服务优先的今天，硬件往往与生态深度绑定。Chromebook 早早培养出一大批习惯使用 Google Docs 的年轻用户。随着年龄增长与数据的积累，即便他们日后具备购买苹果设备的能力，也很难再与苹果的服务生态形成深度绑定，更难形成真正的品牌信仰。

Neo 精准的定价改变了这一局面。$599 的起售价、$499 的教育优惠，让更多孩子有机会在学校就开始使用苹果设备、拥有 Apple ID，从而顺着苹果“预设”的轨迹，逐步购买更多产品与服务。至于被广泛批评的”减配”——A18 Pro 芯片对 K12 日常使用场景而言完全足够，它缺的不是性能，而是定位本就如此。苹果用移动端芯片换来了激进的定价空间，这是一笔算得很清楚的账。

采用订阅制的 Apple Creator Studio，同样展现了苹果希望让更多人与其生态建立长期联系的野心。对于学校而言，廉价硬件+强大的创作软件套件，构成了闭环。Macbook Neo 的硬件性能或许不算强劲，但足以在每台设备约 4–5 年的生命周期中提供稳定、可用的体验，让使用者逐步融入苹果的服务体系。从这个角度来看，MacBook Neo 更像是苹果抛向 Z 世代与 Alpha 世代的一枚“生态锚点”。

太多消费者和数码博主过于聚焦于苹果产品是否炫酷、是否有创新，却忘记了苹果的来时路——教育硬件市场深植于它的基因之中，今天的成功源于数十年前的积累，而现在它需要补上最近十几年的空缺。对于本周报的读者来说，Neo 大概率不是你的菜。但这并不妨碍它成为一款极具针对性、也颇具野心的产品——不是用来赚快钱的，而是苹果为未来二十年的生态版图所做的一次长期押注。

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

本期赞助

Notepad.exe — Swift 新特性的第一个实验场

Swift 6 出了新语法？Xcode 太重，Playground 又太慢。Notepad.exe 让你在 30 秒内写代码、跑结果，专注验证想法本身。支持多版本工具链切换，集成模拟器，随开随用。

🚀 立即使用 →

原创

跨域传递 NSManagedObjectContext 为什么在 Swift 6.2 中不再报错？真正的变化不在编译器

当同一段与并发有关的代码在旧版 Xcode 中无法通过，却在新版 Xcode 26（Swift 6.2）中顺利编译时，你第一时间会想到什么？很多人最初的判断可能是 Swift 编译器的并发分析（如 Region-Based Isolation）又进化了，但现实并没有这么简单。本文记录了我最近遇到的一次非常有意思的排查过程：从测试失败出发，通过构建最小复现用例，一步步追溯到 Core Data 的 SDK interface，最终发现，问题的关键并不完全在 Swift 编译器本身，而是框架的导入语义发生了变化——在新的 SDK 中，NSManagedObjectContext 获得了 NS_SWIFT_SENDABLE 等宏标注，使其在 Swift 中拥有了 Sendable 语义。

尽管 SwiftData 是未来苹果生态最重要的持久化框架，但作为其基础的 Core Data 并没有被苹果冷落。在过去几年中，苹果一直在默默改善其在 Swift 6 中的兼容性和并发体验，这是一个很好的现象。

近期推荐

Swift 语言 2 月新动态 (What’s new in Swift: February 2026 Edition)

Karen Chu 和 Dave Lester 在官方博客上整理了 2026 年 2 月 Swift 社区的生态动态。内容不仅涵盖了 Swift 在 FOSDEM（全球最大开源会议）上的活跃表现，还推介了多项重磅的开源进展与 Swift Evolution 提案。其中的 SE-0506 尤为让我惊喜。该提案为 withObservationTracking 增加了 Options 参数，开发者现在可以精确控制是观察变化前（willSet）、变化后（didSet）还是对象的生命周期（如 deinit）。并且通过 withContinuousObservationTracking 无需再手动递归注册，即可实现稳定、自动循环的连续事件追踪。

SE-0506 提案的通过意义重大。它不仅完美补齐了状态追踪的时机控制和连续性能力，更标志着 Swift 原生的 Observation 已经彻底成熟——它不再仅仅是 SwiftUI 的“专属附庸”，而是真正蜕变为了 Swift 语言中足以应对各种工业级、高性能状态流调度的核心基础设施。

写在 2026 年的 macOS 输入法开发规范

vChewing 维音输入法 的作者 ShikiSuen 基于多年深耕 macOS 输入法的开发经验，全面梳理了 InputMethodKit (IMK) 的历史包袱，以及它在 Swift 6 严格并发检查下暴露出的种种痛点。文章深入探讨了 NSConnection 的命名规范、启用沙盒的必要性、MainActor 隔离冲突，以及高频中英切换（CapsLock）导致的 ARC 拥堵、macOS 26 Liquid Glass 机制下 NSWindow 内存不释放等棘手问题。面对苹果“上古框架”与现代 Swift 并发模型的碰撞，作者没有停留在抱怨上，而是提出了一套像“风险控制模型”一样的工程规范——将控制器退化为纯转发层、把业务逻辑剥离到弱引用 Session、使用内存自查自尽、彻底避开 IMKCandidates 等。

可贵的是，ShikiSuen 基于上述思路开发并开源了 IMKSwift 库。它为 Swift 6+ 提供了 @MainActor 完整隔离的 IMKInputSessionController 基类，完美覆盖了原生 IMKInputController 的并发地雷区。如果你需要开发 macOS 桌面端应用或输入法，这个库能让你无需手动 Hack，就能写出类型安全、无 data-race 警告的现代代码，非常值得学习与使用。

SwiftUI 的洋葱式架构：Swift Effects 实践 (SwiftUI, Swift Effects: A Beautiful Onion Architecture)

在 SwiftUI 中处理数据加载状态几乎是每个应用都会面对的问题：loading、loaded、failed 三种状态往往伴随着网络请求、缓存、日志记录等副作用逻辑，很容易让视图代码逐渐变得臃肿。Salgara 在本文中提出了一种类似 Onion Architecture 的思路：通过 ViewState + Effect Handlers 将 Fetch、缓存、日志等副作用拆分为多个可组合层级，并利用 AsyncSequence 与可注入的 Effect Handler 驱动状态变化，使 UI 仅根据状态进行渲染。这样一来，视图保持纯粹，而数据获取与副作用则沿着一条清晰的“Effect 管道”逐层流动。同时，这种结构也天然具备良好的可测试性——测试代码可以直接拦截并模拟数据源返回值，从而验证完整的状态转换流程。

Salgara 坦言，这种架构目前仍然是实验性的：原型优先，并尝试将一切视为视图（Everything as a View）。随着越来越多开发者从不同角度思考并尝试构建更符合 SwiftUI 特性的架构，这类探索不仅可能让 SwiftUI 本身受益，也有机会反过来丰富整个声明式编程范式，而不再只是复制其他 UI 框架的既有实践。

Spec-Driven Development：当 AI 写代码之后

随着 Cursor、Claude Code 等 AI 编程智能体（Agent）的普及，开发者们正面临一个新的痛点：当 AI 能在几分钟内跨越几十个文件生成上千行代码时，人类该如何有效审查？又该如何应对 AI 在长流程中逐渐出现的“上下文遗忘（Context Decay）”与幻觉问题？为此，一种新的开发范式正在逐渐成形：Spec-Driven Development（SDD）。在这一模式下，开发者的主要任务不再是直接编写代码，而是定义清晰的规格（Spec），再由 AI 根据这些规格生成实现。

Snow 通过四篇文章系统梳理了这一思路：从 “Vibe Coding” 的局限出发，介绍以规格为核心的开发流程，并进一步探讨规格在未来软件工程中的角色——代码或许不再是项目的中心，而只是规格的衍生物。

在 AI 逐渐承担实现细节的时代，软件工程的重心或许正在从“写代码”转向“表达意图”。SDD 尝试在人类的模糊意图与 AI 的无差别生成之间，建立一层强有力的约束。

为 SwiftUI Preview 构建一个 Mini Linker (Building a Mini Linker for SwiftUI Previews)

在 Xcode 26.3 的 mcpbridge 提供的众多工具中，RenderPreview 可以直接返回 SwiftUI Preview 的截图，方便 AI 进行分析。对于暂时无法使用 Xcode 26.3 mcpbridge 的开发者，Hesham Salman 在本文中介绍的思路以及配套工具，同样可以实现类似的能力。其技术亮点在于利用 SwiftSyntax 构建声明依赖图，再通过 BFS 找出当前 Preview 真正需要的最小源文件集合，从而避免编译整个 App Target 带来的构建等待。

本文的精华在于思路：利用 SwiftSyntax + BFS 快速定位 Preview 依赖的代码片段。过去 SwiftSyntax 的使用门槛较高，但在 AI 辅助开发逐渐普及的今天，它正逐渐成为理解代码结构的重要基础设施。即便你不像 Hesham Salman 那样熟练掌握该工具，了解其基本能力后，也可以借助 AI 将类似思路落地——而这类工具在过去往往只属于少数熟悉编译器工具链的开发者。

Swift 的规模化实践：TelemetryDeck 的分析服务 (Swift at scale: building the TelemetryDeck analytics service)

很多人讨论 Swift on Server 时，关注点往往停留在“能不能用”，而 TelemetryDeck 给出的则是一个更实际的答案：不仅能用，而且已经支撑起一项面向开发者、每月处理超过 1600 万用户数据的 analytics 服务。Daniel Jilg 在这篇文章中回顾了团队为何选择 Swift + Vapor 构建后端，并分享了不少来自生产环境的经验：例如如何借助 Codable 简化 API 编解码与校验、为什么应让 DTO 更贴近 controller、以及为何缓存 TTL、API 版本管理和错误监控这些“老生常谈”，在规模化的生产环境中往往才是真正的护城河。

是时候告别 SwiftGen 了吗？ (Get Rid of Your SwiftGen Dependency)

很长一段时间，开发者需要依赖类似 SwiftGen 这样的工具来解决 Apple 资源系统中的一个老问题：资源访问是字符串类型（stringly-typed）。无论是 localization key、图片名称还是颜色资产，一旦拼写错误，往往只能在运行时才会暴露问题。Asser Osama 指出，随着 String Catalog（.xcstrings）与 Asset Catalog Symbols 的引入与逐步完善，Xcode 已经能够在编译阶段自动生成资源符号，这种原生能力在不少现代项目中或许已经足以替代 SwiftGen。

需要说明的是，“移除依赖”的前提是项目完全运行在标准的 Xcode 生态中。Xcode 的符号生成属于构建系统内部机制，而不是 Swift 编译器或 Swift Package Manager 的能力——这意味着对于使用 Bazel、Buck 等非标准构建系统的团队来说，SwiftGen 仍然可能是更可移植、更可控的选择。

工具

SwiftUI Agent Skill

由 Paul Hudson 编写的 SwiftUI Agent Skill，旨在帮助开发者编写更智能、更简洁、更现代的 SwiftUI 代码。该项目发布仅两天便获得了 1k+ Star。

在过去几周中，本周报已经推荐了不少知名开发者编写的各类 Skill。尽管这些 Skill 都凝聚了作者的经验，但我仍不建议开发者直接“拿来即用”。至少应在采用前完整阅读一遍：Skill 更像是作者对自己数十甚至上百篇文章经验的提炼，而不是可以直接替代思考的“最佳实践”。开发者在理解其背后的设计思路后，再根据自己的开发习惯与项目需求进行取舍，这样才能更大地发挥它们的价值。

活动

LET’S VISION 2026，开票啦！

作为在中国举办、面向全球的 Apple 生态下的大会，今年的 LET’S VISION 将会有约 20 场演讲、超过 80 个展位，欢迎前往官网和票务平台了解更多信息。

• 时间及地点：03.28 - 03.29，上海·漕河泾会议中心

• 活动官网

• 获取门票

OpenClaw Is Impressive — I Just Don’t Really Need It (Yet)

Read on web →

On the morning of March 1st, I received a message from OpenClaw. It was part of a scheduled task I had set up after installing it: on the first day of every month, it sends me a summary of the main tasks it executed on my behalf over the past month.

Reading through that rather sparse report, I found myself pausing. At this stage, I don’t think I actually need a personal AI agent. To be honest, if it hadn’t sent that message yesterday, I might have almost forgotten it was even there.

After the OpenClaw project name was finalized, I still couldn’t quite resist the stream of flashy demos filling my social media timeline. I dug out an idle Mac mini M4 and followed the setup guides to get everything running. During the first few days, I spent some time studying how others were using it, trying to see whether it could naturally fit into my own life and workflow.

Eventually, though, I came to realize that—at least given my current workload and habits—many traditional tools that have already matured are more than sufficient for my needs. Even when I do need an agent loop on mobile devices, using more focused, single-purpose tools often results in less configuration overhead and a lower cognitive burden overall.

A year ago, few people would have expected that CLI tools would see a resurgence at a time when GUIs have long been the default. In a similar way, before OpenClaw gained traction, hardly anyone anticipated the sudden emergence of so many OpenClaw-like projects. I have little doubt that most people will eventually have their own personal AI assistants. OpenClaw presents one possible vision of that future—very much from a hacker’s perspective. But what form these assistants will ultimately take, and how they will balance privacy, security, and efficiency, remains an open question.

From one angle, having an intelligent assistant does seem pretty cool. Still, life without one feels just as calm and comfortable. For now, I’ll let 🦞 rest quietly on my mini—until the day I truly need to wake it up.

Previous Issue｜Newsletter Archive

This Week’s Sponsor

Notepad.exe — A Notepad for Developers

Notepad.exe is a lightweight coding scratchpad for macOS, built for experiments, snippets, and rapid prototyping. Open it, write your code, and run it — no project setup required.

🚀 Download for macOS →

Recent Recommendations

Building Lists: A High-Performance Diffable Data Source Framework

After integrating UICollectionViewDiffableDataSource with TCA, Hesham Salman noticed more than 100 UI stalls per minute. A deeper investigation revealed that NSDiffableDataSourceSnapshot heavily relies on Objective-C’s NSOrderedSet under the hood. In a reactive architecture where state updates frequently, repeated snapshot reconstruction leads to substantial hashing costs and Objective-C bridging overhead. To address this, Hesham built a pure Swift alternative, ListKit. By leveraging ContiguousArray, a two-level diff algorithm, and lazily constructed reverse indices, snapshot construction performance improved by several hundred times.

In imperative frameworks, developers can precisely control refresh timing, so diff performance issues may not be immediately obvious. But as reactive programming increasingly makes its way into UIKit, traditional assumptions and techniques must adapt to new refresh patterns. Yesterday’s “best practice APIs” can quietly become today’s performance bottlenecks.

SwiftUI Charts caused major stutter in my app — replacing it with Path fixed everything

There is no doubt that Swift Charts provides a clean declarative API and polished visual output, making it a go-to choice for many developers. However, even years after its release, when dealing with large datasets and high-frequency interactions, its reliance on numerous fine-grained view components can amplify SwiftUI’s diffing and layout costs, resulting in noticeable performance degradation. After reassessing his needs, Oscar Berggren replaced Charts with a custom Shape built on Path, completely eliminating drag-related stutters.

As highlighted in the ListKit article above, when high-frequency state updates (such as gesture-driven refreshes) combine with heavyweight view construction (hundreds of LineMark instances), performance bottlenecks become almost inevitable. In such cases, stepping back to lower-level drawing APIs like Path often yields more predictable and stable results.

We added an MCP server to our macOS app and learned a lot the hard way

Adding MCP support to a macOS app sounds like just exposing a few more interfaces — until you actually try it. Charidimos Chaintoutis discovered this firsthand while implementing native Swift MCP support for unclutr: the gap between “works in dev” and “users can configure, diagnose, and install it” is wider than expected.

The article details challenges around stdio transport, client handshakes, launcher configuration, and macOS sandbox restrictions—particularly the friction between sandboxing and spawning external processes. These constraints ultimately forced them to disable MCP support in the Mac App Store version and offer it only in the direct-download build. The security model they arrived at is especially instructive: separating read and write tools, requiring explicit deletion calls, enforcing absolute paths, supporting dry runs, and always moving files to Trash rather than permanently deleting them. These are lessons learned the hard way.

Array expression trailing closures in Swift

In this article, Artem Mirzabekian introduces the accepted Swift Evolution proposal SE-0508. The proposal removes a long-standing syntactic special case: array and dictionary type expressions previously could not be followed directly by trailing closures. With this restriction lifted, building collections using result builders (for example, let items = [String] { "First"; "Second" }) becomes far more natural. It also enables calling callAsFunction directly after array literals, such as ["a", "b", "c"] { $0.uppercased() }.

At first glance, this may seem like a minor syntactic refinement. In reality, it eliminates inconsistencies between collection types and other types, further smoothing Swift’s surface. Language progress does not always come from bold new features—sometimes it comes from patiently sanding down long-standing rough edges.

Mastering Geometry in SwiftUI - GeometryReader, GeometryProxy & onGeometryChange

For a long time, developers relied almost exclusively on GeometryReader to obtain a view’s size or position. However, GeometryReader is itself a layout container that expands to fill all available space. This “greedy” behavior often causes unexpected layout issues for those unfamiliar with its mechanics. In this comprehensive article, Sagar Unagar revisits SwiftUI’s geometry system from an architectural perspective. He compares the traditional GeometryReader + PreferenceKey pattern, the Layout protocol introduced in iOS 16, and the .onGeometryChange modifier introduced in iOS 18. Rather than merely listing APIs, the article explains how geometry fits into SwiftUI’s proposal-driven layout system.

If you approach SwiftUI with a command-style mindset and attempt to “control” layout directly, it will likely feel awkward. But once your mental model aligns with its negotiation-based design, you begin to see that SwiftUI’s expressive ceiling is much higher than it first appears.

Tools

Xcode Assistant Copilot Server

Xcode 26.3 introduced support for Codex and Claude Code, officially bringing agent capabilities into the IDE workflow. But not every developer uses those services. Developed by Fernando Romiti, Xcode Assistant Copilot Server offers an alternative for GitHub Copilot subscribers. It is a Swift-based local service that translates Xcode’s OpenAI-compatible requests into GitHub Copilot API calls. However, it should not be mistaken for a simple protocol adapter.

In its default mode, it acts as a transparent proxy, forwarding Xcode’s /v1/chat/completions requests to Copilot. Once Agent mode is enabled and MCP is configured, it runs a full local agent loop. When the Copilot model issues tool calls, the server intercepts them, executes the corresponding operations locally (via xcrun mcpbridge or permitted CLI tools), appends the results to the conversation, re-queries the model, and continues this cycle until a final response is produced and returned to Xcode.

Foundation Models SDK for Python

Foundation Models SDK for Python is a recently released open-source project from Apple. Through a Swift bridge, it enables developers to directly invoke Apple Intelligence foundation models running on macOS (on-device) from a Python environment.

In modern LLM application development, evaluation is critical. Developers need to run large test suites to measure the impact of prompt adjustments and tool-calling strategies. Data-driven analysis of this kind has long been dominated by the Python ecosystem. This SDK fills that gap: developers can export real transcripts (JSON) from Swift, then reproduce on-device inference behavior in Python and perform batch analysis, scoring, clustering, and error attribution as if processing ordinary datasets.

In effect, Apple is signaling a standardized workflow for AI application development: Swift handles on-device integration and user experience, while Python powers offline evaluation and iterative optimization.

vphone-cli: Running a Real iPhone on Your Mac

When Apple introduced Apple Intelligence in 2024, it also unveiled PCC (Private Cloud Compute), a privacy-focused infrastructure running on Apple Silicon servers. Its significance lies not merely in “offloading AI to the cloud”, but in extending the iPhone’s security model to server-side environments. Apple even released research materials and virtual research environments to allow security researchers to audit PCC nodes locally.

Starting with cloudOS 26, Apple added components related to vphone600ap in PCC firmware. The community quickly took notice. Building on in-depth reverse engineering work by Hyungyu Seo and others, Lakr developed vphone-cli, which operationalizes this virtualization mechanism. By leveraging private APIs from Virtualization.framework, it creates a fully functional virtual iPhone research environment on macOS. Unlike the Xcode Simulator, this setup runs real iOS firmware, executing the full boot chain from start to finish.

What makes this development fascinating is not merely jailbreak research or firmware analysis, but the broader signal it sends: Apple appears to be externalizing the iOS security architecture it has refined for over a decade, extending it to reshape its cloud computing infrastructure.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

OpenClaw 不错，但我好像没有那么需要

网页版

3 月 1 日早上，我收到了 OpenClaw 发来的信息。这是我在安装它之后设置的一个定时任务：每个月的第一天，向我汇报过去一个月它为我执行过的主要任务汇总。看着汇总中寥寥数语，我不由得陷入了思考——现阶段，我似乎真的还不需要一个个人智能体。说实话，如果不是它昨天发来的这条消息，我几乎已经忽略了它的存在。

在 OpenClaw 项目名称正式确定之后，我还是没能抵挡住社交媒体时间线上那些炫酷演示的诱惑，翻出了一台闲置的 Mac mini M4，照着教程折腾了起来。最初几天，我也认真研究过其他人的使用场景，尝试将它融入自己的生活和工作流中。但后来我逐渐意识到，至少以我目前的工作强度和使用习惯来看，一些已经足够成熟的传统工具，依然可以很好地满足我的需求。即便需要在移动设备上进行 Agent loop，直接使用功能更聚焦的单一用途产品，反而能减少配置和使用上的心智负担。

一年前，或许没有多少人会想到，在 GUI 已经成为默认形态的今天，CLI 会重新迎来一轮回潮。同样，在 OpenClaw 火爆之前，也很少有人预料到，如今会涌现出如此多的 OpenClaw-like 项目。我并不怀疑，未来大多数人都会拥有属于自己的个人智能助手。OpenClaw 以一种相当极客的方式，展示了其中的一种可能性；但智能体助手最终会以怎样的形态存在，又将如何在隐私、安全与效率之间取得平衡，直到现在依然没有一个确定的答案。

从某种角度来看，拥有一个智能助手确实挺酷；但没有它，也丝毫不影响我享受当下的平静与安逸。就让 🦞 在我的 mini 里好好休息吧，等到我真正需要唤醒它的那一天。

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

本期赞助

Notepad.exe — 随开随用的代码草稿本

轻量级 macOS 代码草稿工具，专为代码实验、片段记录和快速原型而生。打开即用，写代码、跑代码，零项目配置。

🚀 免费下载 →

近期推荐

Diffable 的性能陷阱与 ListKit 破局 (Building Lists: A High-Performance Diffable Data Source Framework)

Hesham Salman 在将 UICollectionViewDiffableDataSource 与 TCA 配合使用后，发现原生 DiffableDataSource 导致了每分钟 100 多次的卡顿。深入分析后，他发现 NSDiffableDataSourceSnapshot 底层其实重度依赖 Objective-C 的 NSOrderedSet。在响应式架构中，由于状态的高频刷新，Snapshot 的频繁重建引发了巨大的哈希计算与 Obj-C 桥接开销。为此，Hesham 开发了一个纯 Swift 实现的替代品 ListKit。通过使用 ContiguousArray、双层 Diff 算法以及延迟构建反向索引，将构建 Snapshot 的速度提升了数百倍。

在命令式框架中，由于开发者可以精确控制刷新时机，因此 Diff 的效率问题可能暴露得并不明显。但随着越来越多的开发者将响应式编程引入 UIKit，一些传统的思维或技巧需要根据新的刷新机制来做调整，过去的“最佳实践 API”可能正在成为新的性能瓶颈。

SwiftUI Charts 性能避坑：回归底层 Path 绘制 (SwiftUI Charts caused major stutter in my app — replacing it with Path fixed everything)

毋庸置疑，Swift Charts 提供了简洁的声明式体验与精致的视觉呈现，自发布以来便成为不少开发者绘制图表的首选。然而，即便在推出多年之后，当面对包含高频交互的大数据集场景时，其基于大量细粒度 View 组合的实现方式，仍可能放大 SwiftUI 的 diff 与布局成本，从而引发性能问题。Oscar Berggren 在评估自身需求后，放弃使用 Charts，为折线绘制改用自定义 Shape + Path，成功消除了拖拽过程中的卡顿。

正如前文 ListKit 所揭示的，当高频状态变更（例如手势驱动的刷新）叠加在重量级对象构建（大量 LineMark）之上时，性能瓶颈往往不可避免。此时，适度回归更底层的绘制 API（如 Path），反而能够带来更稳定、可控的表现。

纯 Swift MCP Server 开发与分发踩坑实录 (We added an MCP server to our macOS app and learned a lot the hard way)

为 macOS 应用添加 MCP 能力，听起来不过是多暴露几个接口——直到你真正去做。Charidimos Chaintoutis 在为应用 unclutr 实现纯 Swift 的 MCP 支持时发现，从“开发环境可运行”到“用户可配置、可诊断、可分发”之间，仍有相当长的一段距离。

文章记录了他在 stdio 通信、客户端握手、launcher 配置以及 macOS 沙盒（Sandbox）限制等方面遇到的问题，尤其是沙盒环境下外部进程唤起的权限冲突，最终迫使他们在 Mac App Store 版本中关闭 MCP 功能，仅在直装版本中提供支持。此外，在“如何安全地让 AI 操作用户文件”这一点上，作者总结出的实践经验尤为值得参考：读写工具分离、删除必须显式调用、强制绝对路径、支持 Dry Run、统一使用 Trash 而非硬删除。这些设计都是在踩过足够多坑之后才能得到的经验。

解锁数组与字典的尾随闭包语法 (Array expression trailing closures in Swift)

Artem Mirzabekian 在本文中介绍了一个已经通过的提案：SE-0508。该提案移除了 Swift 语法中的一个“历史特例”：数组与字典类型表达式此前无法直接跟随 trailing closure。随着这一限制被解除，利用 Result Builder 构建集合类型（例如 let items = [String] { "First"; "Second" }）将变得更加自然，同时也允许在数组字面量后直接触发 callAsFunction（如 ["a", "b", "c"] { $0.uppercased() }）。

这看似只是一次语法层面的细节调整，却进一步消除了集合类型与普通类型之间的解析差异，让语言在表达一致性上更进一步。有时候，语言的进步并非来自宏大的新特性，而是来自对那些存在多年的小瑕疵的持续打磨。

重塑 SwiftUI 布局心智：告别 GeometryReader 滥用 (Mastering Geometry in SwiftUI - GeometryReader, GeometryProxy & onGeometryChange)

很长一段时间里，开发者若想获取视图的尺寸或位置，几乎只能依赖 GeometryReader。然而，GeometryReader 本质上是一个会占满所有可用空间的布局容器，这种“贪婪”的特性，常常让不熟悉其行为的开发者陷入布局困境。Sagar Unagar 在本文中系统梳理了 SwiftUI 几何体系的演进路径与心智模型，对比了传统的 GeometryReader + PreferenceKey 组合、iOS 16 引入的 Layout 协议，以及 iOS 18 带来的 .onGeometryChange 修饰符。从架构视角解释了几何信息在 proposal-driven 布局系统中的位置，而不仅仅是 API 的使用方法。

在 SwiftUI 中，如果你始终试图用命令式思维去“控制”布局，它往往会显得别扭；但当你的理解与其协商式布局机制对齐时，你会发现它的表达能力远比想象中更高。

iOS 开发 2015-2025

这是一部用十年时光写就的个人技术编年史，也是一份关于 iOS 生态演进的珍贵记录。从 2015 年的 Auto Layout 适配、组件化浪潮，到 2025 年的 Liquid Glass 与 AI Agent，戴铭 以亲历者的视角，串联起技术变迁、社区故事与工程实践。文中既有对底层原理的深挖（如 dyld、Runtime、性能优化），也有对技术前辈的深切回望。作者认为：底层原理永远不过时；不要被新技术焦虑绑架；技术在变，但学习的方法没变。保持好奇与学习，方能坦然面对更多的十年。

工具

Xcode Assistant Copilot Server

Xcode 26.3 引入了对 Codex 与 Claude Code 的支持，将智能体能力正式带入 IDE 工作流。但并非每位开发者都使用这些服务。由 Fernando Romiti 开发的 Xcode Assistant Copilot Server 则为 GitHub Copilot 订阅者提供了一条替代路径。它是一个基于 Swift 实现的本地服务，将 Xcode 的 OpenAI 兼容请求转译为 Copilot API 调用。但不要将其误解为一个简单的接口转换层。

在默认模式下，它确实充当透明代理，将 Xcode 的 /v1/chat/completions 请求转发至 GitHub Copilot API；然而一旦启用 Agent 模式并配置 MCP，它便会在本地运行完整的 agent loop。当 Copilot 模型发起 tool call 时，Server 会在本地拦截调用，通过 xcrun mcpbridge 或允许的 CLI 工具执行相应操作，将执行结果追加至对话上下文，再次请求模型推理，直至生成最终响应，最后才将结果返回给 Xcode。

Foundation Models SDK for Python

Foundation Models SDK for Python 是苹果官方近期推出的一个开源项目。它在底层通过 Swift 桥接，让开发者能够直接在 Python 环境中调用 macOS 本地（On-Device）的 Apple Intelligence 基础模型。

在现代大模型应用开发中，评测（Evaluation）是极其重要的一环。开发者需要运行大量的测试用例，用各种测试集去验证 Prompt 调整或工具调用的准确率，而这些数据驱动的工作在业界一直是由 Python 生态主导。该 SDK 恰好填补了这一空白：开发者可以无缝实现从 Swift 端导出真实运行的 transcript（JSON），然后在 Python 端利用该 SDK 原生复现端侧的推理过程，并像处理普通数据一样进行批量分析、打分、聚类与误差归因。

这基本等于 Apple 在向开发者明示一种标准化的 AI 应用开发范式：Swift 负责线上体验与端侧集成；Python 负责离线评测与迭代优化。

vphone-cli：在 Mac 上运行一台真实的 iPhone

2024 年 Apple 发布 Apple Intelligence 时，同步推出了 PCC（Private Cloud Compute）：一套运行在 Apple Silicon 服务器上的隐私计算基础设施。它的特别之处不只是”把 AI 请求放到云端处理”，而是把 iPhone那套安全模型延伸到了服务器侧。为此，Apple 还罕见地开放了研究材料和虚拟研究环境，允许安全研究员在本地审计 PCC 节点的软件栈。

从 cloudOS 26 开始，苹果在 PCC 固件中新增了与 vphone600ap 相关的组件。社区的极客们敏锐地抓住了这个契机，基于 Hyungyu Seo 等人 对该虚拟化机制的硬核逆向研究，Lakr 开发的 vphone-cli 将其彻底工程化：通过调用 Virtualization.framework 的私有 API，直接在 Mac 上搭出一套完整的虚拟 iPhone 研究环境。和 Xcode 模拟器不同，这里跑的是真实的 iOS 固件，完整的启动链会从头走一遍。

有意思的地方不只是越狱或固件研究本身，更在于从 PCC 到这一类虚拟化工具所透露出的底层方向：Apple 正在把它十多年来在移动端积累的 iOS 安全架构，彻底外溢并重塑云端计算基础设施。

活动

LET’S VISION 2026，开票啦！

作为在中国举办、面向全球的 Apple 生态下的大会，今年的 LET’S VISION 将会有约 20 场演讲、超过 80 个展位，欢迎前往官网和票务平台了解更多信息。

• 时间及地点：03.28 - 03.29，上海·漕河泾会议中心

• 活动官网

• 获取门票

The Spring Festival Gala, Robots, AI, and LLMs

Read on web →

As a television program with over a billion viewers, the China Central Television’s Spring Festival Gala is undoubtedly an exceptional showcase platform. In this year’s Gala, multiple Chinese robotics manufacturers presented their products in various performances, among which Unitree’s humanoid robots caught the most attention. During the show, multiple models of these humanoid robots executed a series of highly complex martial arts and dynamic movements. Compared to the more static, stationary displays of last year, the complexity and stability of their movements have seen a significant leap—a progress that has drawn attention from global media.

Following the Gala, discussions on social media showed a clear divide. Alongside the amazement at the technological progress, there was no shortage of skeptical voices dismissing the performance as “pre-programmed,” “lacking AI,” or “impractical.” To a certain extent, this reflects the public’s underestimation of the sheer complexity of robotics—especially a lack of awareness regarding the difficulties of motion control, real-time feedback systems, and system-level integration.

One point needs clarification: pre-trained does not equal “record-and-playback.” It is true that humanoid robots currently employ highly orchestrated movement sequences in such performances, but this shares a similar logic with the training of human dancers or athletes. Extensive offline training and rehearsal form the foundation of the movements, but during actual execution, the “body” must still rely on dynamic balance and real-time corrections to cope with real-world disturbances. It is precisely this fault tolerance and real-time repair capability that allows humanoid robots—a naturally unstable bipedal system—to pull off highly dynamic, continuous movements.

Meanwhile, the explosion of Large Language Models (LLMs) in recent years has led many to mistakenly equate LLMs with AI as a whole. In reality, AI, a field with decades of history, encompasses far more than just language understanding. Especially when interacting with the real physical world, the usage of specialized models—such as computer vision, path planning, motion control, and reinforcement learning—in industrial and physical systems still vastly exceeds that of LLMs. In the realm of robotics, the true ceiling of a system’s capability is typically determined by its perception systems, control systems, and low-latency feedback algorithms, rather than its language reasoning abilities.

Even if stronger “cognitive abilities” are introduced to humanoid robots in the future, the better path may not necessarily be directly plugging in an LLM. Instead, it will likely involve building World Models that inherently understand the laws of physics, paired with control systems capable of low-latency responses—two areas that happen to be inherent weaknesses of LLMs. The challenges of Embodied AI are fundamentally different from pure text reasoning.

As for the issue of “practicality,” kung fu or dancing indeed hardly correspond directly to real-world job scenarios. However, it is precisely these movements—which demand extreme balance, coordination, and dynamic response—that provide the perfect validation ground for highly complex and unstable systems like humanoid robots. They function as engineering stress tests, demonstrating the maturity of mechanical design, electronic control, and algorithmic integration, rather than proving short-term commercial viability.

Personally, I remain cautious about the future market size for humanoid robots. There is often a significant chasm between technological breakthroughs and widespread commercial adoption. Nevertheless, judging by the magnitude of progress showcased at this year’s Gala, it is reasonable to conclude that within the next decade, robots or smart machines integrating into our daily work and living environments is no longer just sci-fi imagination. Whether you like “robots” or not, the trajectory of technological evolution is unmistakably clear: we will eventually need to coexist with them.

As for the apocalyptic scenario of “robots enslaving humanity,” I’m not worried about that for now. My more realistic concern is this: if they encounter a bug at work and swing a punch at me, I genuinely couldn’t take the hit.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

How to Migrate to @Observable Without Breaking Your App

As more apps raise their minimum deployment target to iOS 17, @Observable is replacing ObservableObject as the new state management foundation. However, when a project has deeply relied on ObservableObject + @Published, migration is far from a simple macro substitution. Pawel Kozielecki draws on a real-world migration experience to systematically walk through the correct usage of property wrappers in the new system — using @State for lifecycle management, @Bindable for two-way bindings, and plain properties for read-only access — while highlighting easily overlooked details such as @ObservationIgnored and computed property tracking blind spots. The real challenge of migration was never about syntax; it’s about truly understanding who owns the view model’s lifecycle.

Testing with Event Streams

Although Swift Testing offers a rich assertion API, in practice you’ll find there’s no single tool that fully corresponds to XCTest’s ability to verify that multiple callbacks are triggered in order (fulfillment + enforceOrder). confirmation requires nesting and cannot directly validate trigger order. Matt Massicotte proposes an approach that better fits Swift’s concurrency model: using AsyncStream to collect events, wrapped in a lightweight EventStream type — yielding event identifiers when callbacks fire, then calling collect at the end to retrieve the full event sequence for comparison against an expected array. As for why not just use a plain array, Matt provides a compelling answer: when @Sendable constraints or inconsistent actor isolation are involved, writing directly to an array creates concurrency safety issues, whereas the AsyncStream-based approach naturally conforms to the concurrency model.

If You’re Not Versioning Your SwiftData Schema, You’re Gambling

SwiftData’s declarative syntax and automatic migration capabilities make it easy to fall into the trap of thinking “the framework will handle everything.” The reality is that once your model structure changes — adding fields, renaming, adjusting relationships — without an explicit schema version and migration plan, you’re left relying on implicit inference. When that inference fails, the result is rarely a graceful migration; more often it’s crashes, data loss, or an app that won’t launch. Mohammad Azam offers direct, pragmatic advice: explicitly declare Schema versions; prepare migration paths for future structural changes; and treat migration design as part of model design, not an afterthought.

This advice applies equally to Core Data. Even when a model is fully compatible with lightweight migration, creating a corresponding model version file for each release (whenever structural changes occur) not only helps track the model’s evolution but also enables clear, controlled rollback when issues arise. Using explicit versioning to govern model evolution is fundamentally about establishing safety boundaries for long-term maintenance.

How to build a simple CLI tool using Swift

There’s an interesting phenomenon in the age of AI Coding: CLI tools are experiencing a renaissance — more and more developers are building CLI tools to power their MCP and Agent workflows. Natascha Fadeeva walks through how to build structured command-line tools using Swift Package Manager and Apple’s official ArgumentParser library: defining root commands and subcommands, handling async network requests, and compiling to a standalone distributable binary. For iOS developers already fluent in Swift, this path is more natural than maintaining a bash or Python script, and easier to evolve alongside the project.

Navigation Notes – Agentic coding

As an experienced developer, Joseph Heck observes that as AI becomes capable of executing tasks, generating code, and driving changes autonomously, the developer’s role shifts from “line-by-line implementer” to “path navigator.” The truly scarce skill is no longer coding speed, but navigation — how developers maintain their sense of direction in complex codebases and multi-agent environments. Joseph offers several practical suggestions: always include “ask me about anything ambiguous” in your prompts; have the agent draft a plan and get your approval before implementation; provide deterministic feedback loops (unit tests, compiler errors) that allow the agent to self-correct; and distill frequently reused instructions into Skill files.

Heck avoids amplifying the “AI will disrupt developers” narrative, instead emphasizing a more grounded reality: agentic coding amplifies existing engineering capabilities. If you’re already good at modular design and abstraction, AI will accelerate you. If your sense of boundaries is fuzzy, AI will just create chaos faster.

Setting up a delivery pipeline for your agentic iOS projects

When code generation, modification, and refactoring begin to be driven by agents, is the traditional CI/CD pipeline still sufficient? Donny Wals opens with a real experience: his app crashed mid-workout at the gym, he handed the crash report to an agent for analysis, and by the time he finished training, a PR was waiting. After merging, a TestFlight build landed shortly after. Around this experience, he systematically outlines how to build a reliable delivery pipeline for agentic iOS projects — one that keeps automated changes controllable, verifiable, and releasable.

The article’s focus isn’t on any specific tool, but on pipeline design itself. Donny emphasizes that code generated by agents is fundamentally “a change that hasn’t been reviewed line by line,” which makes clear quality gates all the more important: automated testing, continuous integration, and the release pipeline must bear ultimate responsibility for delivery. Agents can significantly accelerate implementation, but engineering discipline cannot be relaxed in kind — when velocity increases, control mechanisms become even more critical.

Tracking Token Usage in Foundation Models

Apple’s Foundation Models run on-device with a context window of just 4,096 tokens — once exceeded, the conversation cannot continue. iOS 26.4 introduces token usage tracking APIs to help developers monitor context consumption in real time. Artem Novichkov covers four key metrics: total model context capacity (contextSize), token consumption for Instructions, consumption for individual Prompts, and cumulative usage for the full conversation Transcript. The article also highlights an easily overlooked detail: when a Tool is introduced, its name, description, and argument schema are serialized and counted toward the token budget — the same Instructions jump from 16 to 79 tokens once a Tool is attached. For on-device models, token observability will become essential infrastructure for optimizing the user experience.

Tools

App Store Connect CLI

App Store Connect CLI is an unofficial App Store Connect command-line tool developed by Rudrank Riyam, covering the full release pipeline: TestFlight management, build uploads, code signing, screenshot automation, localization sync, app review submission, notarization, and financial report downloads. The tool was designed from the ground up with agent scenarios in mind and includes dedicated documentation for agent-oriented workflows. If your release pipeline centers on TestFlight, metadata, submission, signing, and CI automation, ASC is worth considering as a lightweight alternative to fastlane.

GRDB 7.10.0: Android, Linux, and Windows Support

GRDB 7.10.0 is a milestone release: it formally introduces support for Android, Linux, and Windows, and adds the ability to use SQLCipher (encrypted databases) via Swift Package Manager — two long-awaited features from the community. This marks a meaningful evolution for Swift’s most mature SQLite wrapper, from an Apple-platform tool into a truly cross-platform data layer solution.

Gwendal Roué notes in the release announcement that because Xcode does not yet support package traits, SwiftPM will still download unused dependencies; until this is resolved, SQLCipher support will continue to require a fork.

Swift System Metrics

Swift System Metrics provides Swift applications — particularly server-side projects — with unified system-level metrics collection: CPU utilization, memory usage, file descriptor counts, and more, exposed through a standardized Metrics interface that integrates with existing monitoring systems such as Prometheus. It is not a standalone monitoring system, but rather an infrastructure component driven by the Swift Server Work Group, designed to align with the Swift Metrics ecosystem and bring system resource metrics into the same observability stack as application-level metrics. The 1.0 release signals API stability and production readiness. For teams building Swift backend services or investing in Swift observability, this is a foundational piece of the puzzle.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

春晚、机器人、AI 与 LLM

网页版

作为一个观众数量超十亿的电视节目，央视春晚无疑是极佳的展示平台。今年春晚中，多家中国机器人厂商在不同节目中展示了其产品，其中讨论度最高的当属宇树（Unitree）的人形机器人。在表演环节，多款型号的人形机器人完成了大量较为复杂的武术与动态动作展示。与去年偏静态、偏站桩式的呈现相比，今年的动作复杂度与稳定性确实有明显提升，这一点也得到了全球媒体的关注与报道。

春晚之后，社交媒体上的讨论呈现出明显分化。除了对技术进步的惊叹之外，“预编程”、“没有 AI”、“缺乏实用性”等质疑声音同样不少。这在一定程度上反映了公众对机器人技术复杂度的低估——尤其是对运动控制、实时反馈系统和系统级整合难度的认知不足。

需要澄清的一点是：预训练并不等于“录制-回放”。当前人形机器人在此类表演中的确采用了高度规划的动作流程，这与人类舞者、运动员的训练逻辑有相通之处——大量的离线训练与调试构成了动作的基础，但在实际执行过程中，身体仍需依赖动态平衡与即时修正来应对真实环境的扰动。正是这种容错与实时修复能力，才让人形机器人这个天然不稳定的双足系统得以完成高动态的连续动作。

与此同时，近年来大语言模型（LLM）的爆发，让不少人将 LLM 与 AI 等同起来。事实上，AI 作为一个已有数十年发展的领域，远远不止语言理解这一分支。尤其是面对真实的物理世界时，视觉识别、路径规划、运动控制、强化学习等专用模型在工业与实体系统中的使用量，依然远高于 LLM。在机器人领域，真正决定能力上限的往往是感知系统、控制系统以及低延迟反馈算法，而不是语言推理能力。

即便未来为人形机器人引入更强的”认知能力”，更适合的路径也未必是直接接入 LLM，而可能是构建能理解物理规律的世界模型（World Models）与具备低延迟响应能力的控制系统——这两点恰恰是 LLM 的固有短板。具身智能（Embodied AI）的挑战，与纯文本推理存在本质差异。

至于“实用性”的问题，功夫或舞蹈确实难以直接对应现实工作场景。但恰恰是这些对平衡性、协调性与动态响应要求极高的动作，为人形机器人这种高度复杂且不稳定的系统提供了极佳的验证场景。它们更像是工程能力的压力测试，展示的是机械设计、电子控制与算法系统整合的成熟度，而非短期商业落地能力。

我个人对于人形机器人未来的市场规模仍然持审慎态度。技术进步与商业普及之间往往存在不小的鸿沟。但从今年春晚所呈现的进步幅度来看，可以合理判断：在未来十年内，机器人或智能机器以某种形式融入日常工作与生活场景，已不再是科幻想象。无论你是否喜欢“机器人”，技术演进的趋势已经十分明确，我们终将需要与它们共存。

至于“机器人奴役人类”的情景，我暂时并不担心。我更现实的担忧是：如果它们在工作中出现 Bug，给我一拳，我真的挨不住。

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

近期推荐

如何在不破坏 App 的前提下迁移到 @Observable (How to Migrate to @Observable Without Breaking Your App)

随着越来越多的应用将最低系统版本提升至 iOS 17，@Observable 正在取代 ObservableObject 成为新的状态管理基础设施，但当项目已经深度依赖 ObservableObject + @Published 时，迁移远非简单替换宏即可完成。Pawel Kozielecki 结合一次真实的迁移踩坑经历，从底层机制差异出发，系统梳理了新体系下属性包装器的正确使用方式——用 @State 管理生命周期、用 @Bindable 处理双向绑定、只读场景直接使用普通属性，并特别指出了 @ObservationIgnored、计算属性追踪盲点等容易被忽视的细节。迁移的难点从来不在语法层面，而在于真正厘清“谁拥有 view model 的生命周期”这一根本问题。

验证多个回调按顺序触发 (Testing with Event Streams)

尽管 Swift Testing 提供了丰富的断言 API，但在实际使用中你会发现，并没有一个工具能够完全对应 XCTest 中“验证多个回调按顺序触发”（fulfillment + enforceOrder）的能力。confirmation 既需要嵌套使用，也无法直接校验触发顺序。对此，Matt Massicotte 提出了一种更符合 Swift 并发模型的思路：使用 AsyncStream 收集事件，并封装为一个轻量级的 EventStream 类型——当回调触发时 yield 事件标识，测试结束后通过 collect 获取完整事件序列，再与预期数组进行对比。对于“为什么不直接使用数组”这一疑问，Matt 也给出了充分理由：在存在 @Sendable 约束或 actor 隔离不一致的场景下，直接写入数组会触发并发安全问题，而基于 AsyncStream 的方案则天然符合并发模型的约束。

务必为 SwiftData 模型显式声明 Schema 版本 (If You’re Not Versioning Your SwiftData Schema, You’re Gambling)

SwiftData 的声明式写法与自动迁移能力很容易让人产生“框架会替我处理一切”的错觉，但现实是，一旦模型结构发生变化（字段新增、重命名、关系调整），如果没有显式的 schema version 与 migration plan，就只能依赖隐式推断。一旦推断失败，结果往往不是优雅的迁移，而是崩溃、数据丢失，甚至导致应用无法启动。Mohammad Azam 的建议直接而务实：显式声明 Schema 版本；为未来的结构变化预留迁移路径；将“迁移设计”视为模型设计的一部分，而不是事后补救。

本文的观点同样适用于 Core Data。即便模型完全兼容轻量迁移，为每个发行版本创建对应的模型版本文件（只要发生结构修改），不仅有助于追踪模型演化轨迹，也能在出现问题时实现清晰而可控的回滚。用明确的版本机制约束模型演进，本质上是在为长期维护建立安全边界。

用 Swift 开发 CLI 工具 (How to build a simple CLI tool using Swift)

一个有趣的现象是，在 AI Coding 时代，CLI 正在重焕青春——越来越多的开发者通过构建 CLI 工具来承载自己的 MCP 与 Agent 工作流。Natascha Fadeeva 介绍了如何用 Swift Package Manager 和 Apple 官方的 ArgumentParser 库构建结构化的命令行工具：定义主命令与子命令、处理异步网络请求、最终编译为可独立分发的二进制文件。对于已经熟悉 Swift 的 iOS 开发者来说，这条路径比维护一套 bash/Python 脚本更自然，也更容易随项目一起演进。

在 AI 编程时保持方向感 (Navigation Notes – Agentic coding)

作为一个拥有丰富经验的开发者，Joseph Heck 认为当 AI 能够主动执行任务、生成代码甚至推动改动时，开发者的角色从“逐行实现者”转变为“路径规划者”。真正稀缺的能力不再是写代码的速度，而在“导航”——也就是开发者在复杂代码与多代理环境中如何保持方向感。Joseph 给出了几条建议，例如：在提示词中始终加入”对任何模糊之处向我提问”；先让 Agent 制定计划并获得确认，再开始实施；提供确定性的反馈回路（单元测试、编译器错误），让 Agent 能够自我修正；以及将反复使用的指令集沉淀为 Skill 文件等。

Heck 并没有过度渲染“AI 颠覆开发者”的叙事，而是强调一种更冷静的现实：agentic coding 会放大已有的工程能力。如果你本来就善于模块划分与抽象设计，AI 会加速你；如果边界感模糊，AI 只会更快制造混乱。

为 Agent 驱动的 iOS 项目构建可靠交付管线 (Setting up a delivery pipeline for your agentic iOS projects)

当代码的生成、修改与重构开始由 Agent 驱动时，传统的 CI/CD 流程是否仍然足够？Donny Wals 以一次真实经历展开：健身时应用崩溃，他将 Crash Report 交给 Agent 分析，训练结束后 PR 已经准备就绪，合并后 TestFlight 构建随即落地。围绕这一实践，他系统梳理了如何为“agentic iOS 项目”构建一条可靠的交付管线（delivery pipeline），确保自动化改动依然可控、可验证、可发布。

文章的重点并不在某个具体工具，而在流程设计本身。Donny 强调，Agent 生成的代码本质上仍属于“未经人工逐行审查的改动”，因此更需要明确的边界与质量闸口：自动化测试、持续集成与发布流程必须承担最终的交付责任。Agent 可以显著提升实现速度，但工程纪律不能随之放松——速度提升之后，控制机制反而更为关键。

实时掌握 Foundation Models 的上下文消耗 (Tracking Token Usage in Foundation Models)

Apple 的 Foundation Models 运行在设备端，上下文窗口仅 4096 个 token，一旦超出便无法继续对话。iOS 26.4 新增了 token 用量追踪 API，帮助开发者实时掌握上下文消耗情况。Artem Novichkov 系统介绍了四个关键指标：模型上下文总容量（contextSize）、Instructions 的 token 消耗、单条 Prompt 的消耗，以及完整对话记录（Transcript）的累计用量。文章还揭示了一个容易被忽视的细节：当引入 Tool 时，其名称、描述与参数 Schema 会被序列化并计入 token，同一段 Instructions 在附加 Tool 后 token 数从 16 跃升至 79。对于设备端模型而言，token 的可观测性将成为优化体验的基础设施。

工具

App Store Connect CLI

App Store Connect CLI 是由 Rudrank Riyam 开发的非官方 App Store Connect 命令行工具，功能覆盖 TestFlight 管理、构建上传、代码签名、截图自动化、本地化同步、应用审核提交、notarization，以及财务报告下载等完整发布链路。它从设计阶段就强调 Agent 场景，并提供了面向 Agent 的实践文档。若你的发布流程重心在 TestFlight、元数据、提审、签名与 CI 自动化，ASC 可以作为 fastlane 的轻量替代方案之一。

GRDB 7.10.0: 新增 Android、Linux、Windows 支持

GRDB 7.10.0 是一个具有里程碑意义的版本更新：本次正式引入对 Android、Linux、Windows 的支持，并新增通过 Swift Package Manager 使用 SQLCipher（加密数据库）的能力——这两项功能都长期受到社区期待。这意味着这个 Swift 生态中最成熟的 SQLite 封装库，正在从 Apple 平台工具演进为真正的跨平台数据层解决方案。

Gwendal Roué 在 版本公告 中也特别说明，由于 Xcode 尚未支持 package traits，SwiftPM 目前仍会下载未实际使用的依赖；在相关问题解决之前，SQLCipher 支持将以 fork 形式长期维护。

Swift System Metrics

Swift System Metrics 为 Swift 应用（尤其是服务端项目）提供了统一的系统级指标采集能力，例如 CPU 使用率、内存占用、文件描述符数量等，并通过标准化的 Metrics 接口对外暴露，便于接入 Prometheus 等现有监控体系。它并非一个独立的监控系统，而是由 Swift Server Work Group 推动的基础设施组件，旨在与 Swift Metrics 生态对齐，使系统资源指标与应用级指标纳入同一可观测体系。1.0 的发布意味着 API 已趋于稳定，具备生产环境使用条件。对正在构建 Swift 后端服务、或持续完善 Swift 可观测性能力的团队来说，这是一个基础设施层面的关键拼图。

Wishing Everyone a Happy Year of the Horse!

Read on web →

This Chinese New Year ushers in the Bingwu Year (丙午) — a once‑in‑60‑years “Red Horse Year” (赤马年) .

In the traditional Chinese stem‑branch calendar, the Heavenly Stem Bing (丙) and the Earthly Branch Wu (午) both belong to the Fire element. This double‑fire combination creates an exceptionally rare “Fire Horse” pattern. Since fire is associated with the colour red, this Year of the Horse is also called the “Red Horse Year” (红马年) . This red horse embodies pure vitality and soaring spirits, symbolising a year full of boundless energy and enterprising drive.

At this once‑in‑60‑years auspicious moment, I wish all my readers: good health (CPU at full power), a soaring career (performance optimised), smooth sailing in everything (bug‑free runtime), and immediate success (compilation passed)! 🎉

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

Swift Concurrency from Zero to Hero | Reading List

Setting AI aside—since it still struggles to handle complex Swift 6 concurrency code at an expert level—even as tools rapidly evolve, you shouldn’t remain a passive observer. A systematic and comprehensive understanding of Swift Concurrency—its concepts, usage patterns, and historical evolution—is essential for building safer and more resilient applications from the ground up. In this article, Alex Ozun organizes a structured learning roadmap for Swift Concurrency, divided by difficulty levels. Each stage is accompanied by publicly available, free resources, with complexity gradually increasing. The goal is simple: complete the journey and move from Zero to Hero.

A Modern iOS Project Setup in 15 Steps

For many developers, starting a new project means repeating a series of tedious setup steps. In this thread, Ertem Biyik outlines a modern engineering baseline for iOS projects in 15 steps: using Tuist to manage dependencies and project generation, centralizing configuration through xcconfig, simplifying onboarding with a Makefile, and validating builds with GitHub Actions. He also recommends standardizing AI context with AGENTS.md and leveraging sosumi.ai for LLM-friendly Apple documentation.

Micelio: Growing Software Like Nature Grows Forests

As AI becomes deeply embedded in development workflows, many traditional tools are starting to show their limitations. Using the metaphor of a mycelium network, Pedro Piñera argues that Git’s model—capturing what changed but rarely preserving why it changed—may no longer be sufficient in an AI-first world. This article presents his systematic reflection on a “post-Git era” and introduces an experimental approach to agent-first collaboration. The accompanying open-source forge project, Micelio, centers around sessions as the core unit to capture context and reasoning, shifting code hosting from storing diffs to storing decisions. Though still early-stage, the problem framing and engineering direction are worth watching.

Copy-on-Write in Swift - How It Works and Why It Optimizes Memory

Copy-on-Write (COW) is a fundamental mechanism in Swift and a key reason value types can achieve strong semantics without sacrificing performance. Sagar Unagar explains how Swift balances value semantics and runtime efficiency through a “struct wrapper + reference storage” model: reads share storage, while writes trigger a real copy only when the reference is no longer unique, detected via isKnownUniquelyReferenced. The article also demonstrates how to implement COW in custom types.

Taking First Steps into Metal Shaders

For many SwiftUI developers, Metal can feel distant and complex. In this article, Letizia Granata walks through the basics of working with shaders—from understanding CPU/GPU responsibilities to adding a .metal file in Xcode and applying a simple shader effect in SwiftUI. Rather than diving into rendering pipelines or graphics theory, the focus is on getting something running, lowering the barrier to entry for experimentation.

Setting Up a Backend Server for Our Landmarks App

Landmarks is Apple’s classic SwiftUI tutorial app, but its reliance on local JSON data leaves a gap between example and real-world architecture. Kyle Browning builds a simple backend using Vapor to serve data via API, transforming the static demo into a client-server structure. The article covers model definition, routing, data responses, and integration with SwiftUI—less about complex business logic and more about extending a teaching example into something closer to production reality.

In the Background: Spotlight Indexing

After a system update, Macs often run hot and sluggish for a few days—commonly attributed to Spotlight reindexing. But how exactly does Spotlight scan files, decide when to rebuild its index, and manage system resources in the background? Howard Oakley analyzes logs and empirical data to explore Spotlight’s triggering mechanisms, process behavior, and impact on I/O and performance, offering a deeper technical look at macOS internals.

Tools

ScreenStateKit: A Better MVVM for the SwiftUI Concurrency Era

If you appreciate TCA’s unidirectional data flow and predictable state management but don’t want to fully refactor your existing MVVM architecture, ScreenStateKit may offer a pragmatic middle ground. Anthony Tran splits the traditional ViewModel into two clearly defined components: a @MainActor-isolated ScreenState that holds UI state, and a Swift actor-based ScreenActionStore that handles business logic and async tasks. All mutations flow through strongly typed Actions, bringing compile-time concurrency safety and TCA-like discipline to MVVM. Built-in loading/error handling, duplicate request prevention (ActionLocker), parent-child state propagation, and pagination support round out the design. Anthony also provides a detailed design article explaining the architecture and its rationale.

GitHub Directory Downloader

If you’ve ever cloned an entire repository just to download a single folder from GitHub, this tool is for you. Developed by Stewart Lynch, this native macOS app lets you paste any GitHub repository or directory URL (including tree/branch/path formats), automatically detect the default branch, recursively download the selected directory, and preserve its original structure.

SimTag: Branch Context for Your iOS Simulators

In parallel development workflows, it’s easy to lose track of which branch is running in which iOS Simulator. Developed by Aryaman Sharda, SimTag overlays a lightweight label on each Simulator window, showing the git branch and commit corresponding to the running build. For developers using worktrees, reviewing PRs, or collaborating with AI tools, it helps reduce cognitive friction and prevents debugging the wrong branch.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

祝大家马年新春快乐！

网页版

今年的中国农历年是丙午年，是一个60年一遇的“赤马年”。

在干支纪年中，天干“丙”与地支“午”五行皆属火，双火叠加，形成了极为罕见的“火马”格局。因火色为赤，故此马年又称“红马年”。这匹“红马”承载着最纯粹的阳刚之气与蓬勃活力，预示着接下来的一年将充满奔放的能量与昂扬的进取心。

在这个 60 年一遇的吉庆节点，我在此祝各位读者新的一年：身体健康（CPU 满血），事业驰骋（性能优化），万事顺遂（无 Bug 运行），马到成功（编译通过）！ 🎉

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

近期推荐

Swift 并发进阶阅读路线图 (Swift Concurrency from Zero to Hero | Reading List)

暂不说 AI 目前还很难像专家一样处理 Swift 6 并发相关的复杂代码，即便工具能力突飞猛进，作为使用者的你也不该只当旁观者：系统、全面地理解 Swift 并发的概念、用法与历史脉络，才能从源头构建更安全、更强健的应用。Alex Ozun 在本文中按难度划分关卡，整理了一份“从入门到进阶”的 Swift Concurrency 阅读路线图：每一关都配套了公开且免费的参考资料，难度也会逐级递增，希望你在完成这条主线之后，能从 Zero 走到 Hero。

15 步打造现代 iOS 项目 (A Modern iOS Project Setup in 15 Steps)

对于不少开发者而言，新项目的开始往往伴随着重复而琐碎的配置工作。Ertem Biyik 在这条串贴中用 15 个步骤梳理了一套现代 iOS 项目的工程化基线：以 Tuist 为核心管理依赖与生成，通过 xcconfig 统一环境配置与构建参数，借助 Makefile 简化初始化流程，并在 GitHub Actions 中完成 lint 与构建校验；同时，他还建议使用 AGENTS.md 统一 AI 上下文，并配合 sosumi.ai 获取更利于 LLM 阅读的 Apple 文档。

Micelio：后 Git 时代的代码托管工具 (Micelio: Growing Software Like Nature Grows Forests)

AI 深度参与开发流程后，许多传统工具开始显露出“水土不服”。Pedro Piñera 以“菌丝网络（mycelium）”为隐喻，指出随着 AI agent 参与开发的规模与频率不断提升，Git 这种只记录 what changed、却难以保留 why it changed 的历史模型，正在变得不够充分。本文是他对“后 Git 时代”的一次系统性思考，也是对“agent-first 协作方式”的公开实验。配套的开源 git forge Micelio 项目尝试以 session 为核心单元捕获上下文与推理，将代码托管的重心从“存 diff”转向“存决策”。项目仍处于早期阶段，但其问题意识与工程方向，都值得持续关注。

Swift 写时复制 (Copy-on-Write in Swift - How It Works and Why It Optimizes Memory)

写时复制（COW）是 Swift 的核心机制之一，也是值类型在保证语义一致性的同时获得良好性能的关键。Sagar Unagar 结合集合类型的内部实现，解释了 Swift 如何通过“结构体外壳 + 引用存储”的方式实现读共享、写分离：只有在发生写入且检测到非唯一引用时，才会借助 isKnownUniquelyReferenced 触发真正的拷贝。文章同时展示了自定义类型实现 COW 的基本模式。

Metal Shader 入门 (Taking First Steps into Metal Shaders)

对于大多数 SwiftUI 开发者而言，Metal 往往显得遥远而复杂。Letizia Granata 通过本文带你从 0 开始接触 Shader：从理解 GPU 与 CPU 的分工，到在 Xcode 中添加 .metal 文件，再到编写并在 SwiftUI 中应用一个最简单的 shader 效果。Letizia 没有深入渲染管线或图形学细节，而是聚焦“如何真正跑起来”，帮助读者跨过入门门槛。

为 Landmarks 构建 Vapor 后端 (Setting Up a Backend Server for Our Landmarks App)

Landmarks 是 Apple 在 SwiftUI 教程中提供的经典示例应用，但由于它使用本地 JSON 数据，与真实项目的客户端—服务器架构仍存在差距。Kyle Browning 使用 Vapor 为 Landmarks 构建了一个简单的后端服务，将静态示例升级为通过 API 获取数据的完整结构。文章围绕模型定义、路由配置、数据响应以及与 SwiftUI 前端的对接展开，重点不在复杂业务逻辑，而在于示范如何把一个“教学示例”扩展为更贴近真实世界的项目。

Spotlight 后台索引机制解析 (In the Background: Spotlight Indexing)

系统更新后的几天里机器发热、卡顿，很多人都知道这与 Spotlight 的重新索引有关，但它在后台如何扫描文件、何时触发重建索引、又如何调度系统资源，却鲜少被系统性梳理。Howard Oakley 基于日志与实测数据，对 Spotlight 索引的触发机制、进程行为以及对 I/O 与性能的影响进行了细致分析，提供了一次关于 macOS 内部运行机制的深入技术观察。

工具

ScreenStateKit：并发时代的 MVVM 演进

如果你欣赏 TCA 的单向数据流与可预测状态管理，却又不想在现有 MVVM 项目中彻底重构架构，那么 ScreenStateKit 状态管理库也许是一个折中方案。作者 Anthony Tran 将传统 ViewModel 拆分为两个职责清晰的部分：一个运行在 @MainActor 上、只负责持有 UI 状态的 ScreenState，以及一个以 Swift actor 实现、专门处理业务逻辑与异步任务的 ScreenActionStore，所有状态变更都通过强类型 Action 作为唯一入口，从而在保持 MVVM 结构直观性的同时，引入类似 TCA 的单向数据流与编译期并发安全。配合内建的加载与错误状态管理、重复请求防护（ActionLocker）、父子状态传播与分页支持。Anthony 亦撰写了一篇详尽的设计说明文章，对其架构理念与实践细节进行了系统阐述。

GitHub 子目录下载工具

如果你曾为了下载 GitHub 上的某个示例目录而被迫 git clone 整个仓库，这款 GitHub Downloader 显然正是为此而生。它是 Stewart Lynch 开发的一款原生 macOS 应用，允许你粘贴任意 GitHub 仓库或子目录 URL（包括 tree/branch/path 形式），自动识别默认分支，递归下载所选目录内容，并完整保留其原始层级结构。

SimTag：为模拟器标注分支上下文

在并行开发成为常态的今天，面对多个外观几乎相同的 iOS Simulator，开发者很容易迷失：到底哪个分支正在运行？是否调试了错误的构建版本？Aryaman Sharda 开发的 SimTag 会在每个 Simulator 窗口上叠加一个轻量标识，显示当前构建对应的 git 分支与提交信息。对于习惯使用 worktrees、进行 PR 审查或结合 AI 协作开发的团队来说，这是一个能够显著减少认知摩擦、避免“调错分支”的实用小工具。

Xcode Enters the Agent Era

Read on web →

Although Apple had already incorporated AI-assisted programming capabilities in the initial version of Xcode 26, the experience felt more like ChatGPT being awkwardly embedded into the IDE: the functionality existed, but felt disconnected. Compared to the then-popular Cursor, it seemed like a product from a different era. As AI CLI tools like Claude Code gradually matured, Xcode appeared to fall further behind, leading many developers to question whether it could still serve as a “primary IDE” in the AI age.

The arrival of version 26.3, with almost no advance notice, responded to these doubts with concrete action. By integrating Claude Code/Codex, Apple’s answer was direct: with the right strategy, Xcode remains a highly promising development environment within the Apple ecosystem. This time, Xcode didn’t simply add a CLI tool panel; instead, it introduced a native set of Xcode Tools (MCP), coordinated with official technical documentation for Swift 6, SwiftUI, SwiftData, and more, creating a highly consistent experience aligned with the latest practices. Even for developers already proficient with CLI + XcodeBuildMCP + various Skills, this native solution remains highly competitive—especially with its near-zero configuration cost, which is significant for the vast majority of developers.

More notably, the Xcode Tools provided in this update don’t just serve Xcode itself; they can also function as standard MCP to provide capabilities for other AI tools. This open approach doesn’t entirely align with the outside world’s impression of Apple’s usual style.

Of course, from today’s vantage point, we cannot yet assert that Xcode has returned to the first tier. But what’s certain is that 26.3 has sent a very clear signal: Apple is willing to collaborate with mainstream tools and services to create development experiences that truly align with the times. For this reason, I have higher expectations for the next iteration of Siri—likely in iOS 27, Apple will provide more standardized interfaces for the system and apps beyond the existing Intent framework, allowing AI to integrate more naturally into the entire ecosystem.

Xcode + Agent is just the beginning.

Apple + Agent is the future worth paying more attention to.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Original

Xcode 26.3 + Claude Agent: Model Swapping, MCP, Skills, and Adaptive Configuration

Xcode 26.3 directly provides support for Claude Code/Codex. Finally, developers can conveniently use native AI Agents in Xcode. Over the past few days, I’ve conducted a series of experiments with the new version, including how to use the latest models, configure MCPs/Skills/Commands, and write adaptive CLAUDE.md. This article uses Claude Code as an example to share some tips beyond the documentation.

Recent Recommendations

From Pixel Capture to Metadata: Reimagining Screen Recording Architecture on macOS

Video is replacing text as a more popular form of expression, and good tools accelerate creation. Sintone, developer of the macOS screen recording software ScreenSage Pro, provides an in-depth retrospective on implementing “finished editing upon recording completion” based on ScreenCaptureKit and Metal. From solving the cryptic SCK -3821 error to migrating from ObservableObject to @Observable to optimize timeline performance, this article openly shares the entire process from pixel capture to high-performance composition.

Which Method is Fastest for Checking if a String is in a Whitelist: Set, Array, Enum, Dictionary, or Switch?

In Swift, checking whether a string belongs to a set of keys can be written as Set.contains, Array.contains, RawRepresentable enum’s init?(rawValue:), switch with multiple cases, or even using a Dictionary for mapping. They may look similar, but when placed in performance-sensitive paths, the results might not fully align with intuition. Helge Heß conducted a simple benchmark test: Set.contains leads without suspense, followed by enum(rawValue:) and Dictionary (very close to each other); while switch, which many would instinctively overestimate, actually ranks after enum, with Array.contains finishing last. As a small experiment, these results might be just what we need to calibrate our intuition about Swift performance.

Migrating an iOS app from Paid up Front to Freemium

Paid download and free + in-app purchase are two fundamentally different business models, and as apps evolve, developers may need to transition between them. In this article, Donny Wals shares his complete experience converting the Practical Core Data app from a $4.99 paid download to freemium. The article not only covers StoreKit 2 technical implementation details (purchase flow, state management, family sharing), but more valuably, his deep thinking on business decisions: while the paid barrier can filter for serious users, it also blocks many potential users from experiencing the product’s value. For educational or utility indie apps, freemium may be a better balance between user growth and revenue.

On-demand resources in iOS app

App size has always been a concern for developers, especially when apps contain large amounts of images, audio, or other resources. Although Apple introduced On-Demand Resources (ODR) in iOS early on to address this challenge, this feature has a weak presence and is often overlooked by developers. In this article, Majid Jabrayilov systematically reviews ODR’s working mechanism and usage, including resource grouping, tag management, download lifecycle, and collaboration with system caching strategies.

While Apple is promoting Background Assets as a more modern solution, ODR still has unique value in scenarios requiring immediate response for on-demand downloads and fine-grained resource control.

Objectively Better, Observably Trickier

When fully embracing the Observation framework, developers need to be aware that its working mechanism differs from Combine’s @Published, and simple replacement often introduces subtle issues. Danny Bolella summarizes four common pitfalls during migration: non-lazy initialization when @State holds reference types, update loss caused by nested @Observable objects, changes in array element binding methods, and conflicts with other property wrappers. The article provides solutions through clear code examples and repeatedly emphasizes a core principle: updates only trigger when properties currently being accessed (getter called) by the view change. Understanding and adapting to this “lazy observation” mindset is key to correctly using the Observation framework.

Add an Open Recent Menu to a SwiftUI app

“Open Recent” is a standard macOS app feature, but for SwiftUI developers, correctly implementing this functionality is not intuitive. In this article, Mark Szymczyk demonstrates through a concise example how to use NSDocumentController to integrate system-level recent file management capabilities into your app: automatic list maintenance, menu updates, and seamless coordination with document lifecycle. For document or utility apps, this is a low-cost detail optimization that can significantly enhance the “native feel.”

Tools

Radioform: A Native, Open-Source macOS Audio Equalizer

macOS has long lacked a system-level audio equalizer. Radioform, developed by Matthew Porteous, fills this gap. The project employs a layered architecture of SwiftUI menu bar App + Swift Host + CoreAudio HAL Driver + C++ DSP, completely decoupling UI from real-time audio processing. The DSP portion implements 10-band parametric EQ, parameter smoothing, limiting, and real-time safety control; the engineering also includes complete CI, code signing notarization, and DMG release workflow. This isn’t a “just make it work” demo, but a production-grade audio engineering template approaching long-term maintainability.

CircuitPro: Native macOS PCB Design Tool

This is a domain rarely explored by macOS native apps: PCB design. CircuitPro is a PCB EDA tool for macOS, aiming to make schematic, layout, and component library workflows more aligned with Apple platform conventions. (The project is still in early development stages)

What attracts me most about the project is the custom-built CanvasKit. It’s more like a 2D interaction engine for EDA scenarios rather than just a regular canvas component: the top layer is declarative CanvasView, the middle layer is the state hub CanvasController, and the bottom layer is input routing, render tree, and tool system. More critically, snapping, input handling, and wiring engine are all made into protocol-based pluggable points, allowing schematics and layout to share the same infrastructure while retaining their respective routing rules.

Even if you’re not interested in PCB design itself, CircuitPro is worth attention, especially for its engineering practices in SwiftUI + AppKit hybrid architecture.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

Xcode 迈入 Agent 时代

网页版

尽管在 Xcode 26 的最初版本中，苹果就已经加入了一定的 AI 辅助编程能力，但当时的体验更像是把 ChatGPT 生硬地嵌入到 IDE 中：功能存在，却彼此割裂。与当时风头正盛的 Cursor 相比，它更像是两个时代的产物。随着 Claude Code 等 AI CLI 工具逐渐成熟，Xcode 更显得步伐迟缓，甚至让不少开发者开始怀疑：在 AI 时代，它是否还能胜任“主力 IDE”的角色。

26.3 版本的到来，几乎没有任何预热，却用实际行动回应了这些质疑。通过集成 Claude Code / Codex，苹果给出的答案很直接：只要策略得当，Xcode 依然是苹果生态中极具潜力的开发环境。这一次，Xcode 并没有简单地塞进一个 CLI 工具面板，而是引入了一套原生的 Xcode Tools（MCP），并配合 Swift 6、SwiftUI、SwiftData 等官方技术文档，形成了高度一致、贴合最新实践的整体体验。即便对于已经熟练使用 CLI + XcodeBuildMCP + 各类 Skills 的开发者而言，这套原生方案依然具备很强的竞争力——尤其是几乎为零的配置成本，这对绝大多数开发者来说意义重大。

更值得注意的是，这次提供的 Xcode Tools 并不只是服务于 Xcode 本身，它们同样可以作为标准 MCP，为其他 AI 工具提供能力支持。这种开放姿态，并不完全符合外界对苹果一贯风格的印象。

当然，站在今天这个时间点，我们还不能断言 Xcode 已经重新回到了第一阵营。但可以肯定的是，26.3 释放了一个非常明确的信号：苹果愿意与主流工具和服务协作，去打造真正符合时代的开发体验。也正因为如此，我对下一阶段的 Siri 抱有更高的期待——很可能在 iOS 27 中，苹果会在现有 Intent 体系之外，为系统和应用提供更多标准化接口，让 AI 更自然地融入整个生态。

Xcode + Agent 只是起点。

Apple + Agent，才是更值得关注的未来。

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

原创

Xcode 26.3 + Claude Agent：模型替换、MCP、Skill 与自适应配置

Xcode 26.3 版本中苹果直接提供了对 Claude Code/Codex 的支持。自此，开发者终于可以在 Xcode 中方便的使用原生 AI Agent 了。 这两天我针对新版本进行了一系列尝试，包括如何使用最新模型、配置 MCPs/Skill/Command、以及编写自适应的 CLAUDE.md。本文以 Claude Code 为例，分享一些文档之外的技巧。

近期推荐

macOS 录屏软件开发实录：从像素抓取到元数据重现

视频正在取代文字成为更受欢迎的表达方式，而好工具是创作的加速器。macOS 录屏软件 ScreenSage Pro 的开发者 Sintone 深度复盘了如何基于 ScreenCaptureKit 和 Metal 实现“录完即剪完”。从解决 SCK -3821 诡异报错，到由 ObservableObject 迁移至 @Observable 优化时间线性能，本文毫无保留地分享了从像素抓取到高性能合成的全过程。

哪种方式判断字符串是否在白名单里最快：Set、Array、Enum、Dictionary 还是 switch?

在 Swift 里，判断一个字符串是否属于某个键集合，可以写成 Set.contains、Array.contains、RawRepresentable enum 的 init?(rawValue:)、switch 多分支，甚至用 Dictionary 来做映射。看起来差别不大，但真要放进性能敏感路径，结果可能并不完全符合直觉。Helge Heß 做了一次简单的基准测试：Set.contains 毫无悬念地领先，其次是 enum(rawValue:)和 Dictionary（两者非常接近）；而很多人下意识会高估的 switch，反而排在 enum 之后，Array.contains 则垫底收场。作为一个小实验，这个结果或许正好可以拿来校准一下我们对 Swift 性能的直觉。

从一次性付费到 Freemium (Migrating an iOS app from Paid up Front to Freemium)

付费下载和免费 + 应用内购买是两种截然不同的商业模式，随着应用发展，开发者可能需要在两者之间转换。Donny Wals 在本文中分享了他将 Practical Core Data 应用从 $4.99 付费下载转为 freemium 的完整经历。文章不仅涵盖了 StoreKit 2 的技术实现细节（购买流程、状态管理、家庭共享），更有价值的是他对商业决策的深入思考：付费门槛虽然能筛选出认真的用户，但也阻挡了大量潜在用户体验产品价值的机会。对于教育类或工具类独立应用，freemium 可能是用户增长和收入之间更好的平衡点。

iOS 应用中的按需资源 (On-demand resources in iOS app)

应用体积一直是开发者需要关注的问题，尤其是在应用包含大量图片、音频或其他资源时。尽管苹果很早就在 iOS 中提供了 On-Demand Resources（ODR）来应对这一挑战，但这一功能的存在感并不强，常被开发者忽略。在本文中，Majid Jabrayilov 系统性地回顾了 ODR 的工作机制与使用方式，包括资源分组、标签管理、下载生命周期，以及与系统缓存策略之间的协作关系。

虽然苹果在推广 Background Assets 作为更现代的方案，但 ODR 在需要即时响应的按需下载、细粒度资源控制等场景下仍有其独特价值。

Observation 四个常见陷阱 (Objectively Better, Observably Trickier)

在全面拥抱 Observation 框架时，开发者需要警惕其工作机制与 Combine 的 @Published 并不相同，简单替换往往会引入隐蔽的问题。Danny Bolella 总结了迁移过程中四个常见陷阱：@State 持有引用类型时的非惰性初始化、嵌套 @Observable 对象导致的更新丢失、数组元素绑定方式的变化，以及与其他属性包装器产生的冲突。文章通过清晰的代码示例逐一给出解决方案，并反复强调一个核心原则：只有视图当前正在访问（调用 getter）的属性发生变化时，才会触发更新。理解并顺应这种“惰性观察”的思维方式，是正确使用 Observation 框架的关键。

在 macOS 应用中实现 Open Recent 菜单 (Add an Open Recent Menu to a SwiftUI app)

“Open Recent” 是 macOS 应用的标准功能，但对于 SwiftUI 开发者来说，正确实现这个功能并不直观。在本文中，Mark Szymczyk 通过一个简洁的示例，展示了如何利用 NSDocumentController 为应用接入系统级的最近文件管理能力：自动维护列表、更新菜单，以及与文档生命周期的无缝协作。对于文档型或工具类应用，这是一个低成本、却能明显提升“原生感”的细节优化。

工具

Radioform：一个原生、开源的 macOS 音频均衡器

macOS 一直缺少系统级的音频均衡器，由 Matthew Porteous 开发的 Radioform 填补了这个空白。该项目采用 SwiftUI 菜单栏 App + Swift Host + CoreAudio HAL Driver + C++ DSP 的分层架构，把 UI 与实时音频处理彻底解耦。DSP 部分实现了 10 段参数 EQ、参数平滑、限幅与实时安全控制；工程上也有完整 CI、签名公证与 DMG 发布流程。不是“能跑就行”的 Demo，而是接近可长期维护的生产级音频工程样板。

CircuitPro：macOS 原生的 PCB 设计工具

这是一个 macOS 原生应用较少涉足的领域：PCB 设计。CircuitPro 是一款面向 macOS 的 PCB EDA 工具，目标是把原理图、布局与元件库流程做成更符合 Apple 平台习惯的体验。（项目仍处于早期开发阶段）

项目里最吸引我的是自研的 CanvasKit。它更像一个面向 EDA 场景的 2D 交互引擎，而不只是普通画布组件：上层是声明式 CanvasView，中层是状态中枢 CanvasController，底层是输入路由、渲染树与工具系统。更关键的是，吸附、输入处理、连线引擎都被做成了协议化插拔点，让原理图和布局共享同一基础设施，同时保留各自的路由规则。

即便你对 PCB 设计本身不感兴趣，CircuitPro 也很值得关注，尤其是它在 SwiftUI + AppKit 融合架构上的工程实践。

求贤

了解二次元的 iOS 工程师

本公司是二次元文生图头部企业（总部新加坡），招聘岗位为大陆全职 remote。求职者需要了解二次元文化，懂得二次元用语（黑话）。

岗位职责 (Responsibilities):

• 我们正在寻找一位经验丰富的 iOS 工程师（中高级），负责主导我们 iOS 应用的开发与优化工作。

• 理想的候选人应具备深厚的 Swift 技术功底，出色的测试与团队协作能力，并拥有现代 iOS 架构及工具链的实战经验。

任职要求 (Requirements):

• 3 年以上 iOS 开发经验，主要使用 Swift，同时具备一定的 Objective-C 代码维护能力。

• 至少 1 年的 SwiftUI 和 SPM (Swift Package Manager) 实战经验，熟悉其生态系统及最佳实践。

• 熟悉 iOS 15+ 新特性，能够针对不同的 iOS 版本和设备屏幕尺寸进行适配及性能优化。

• 掌握单元测试和 UI 自动化测试 (XCTest, XCUITest)，有能力编写可维护的代码，以确保项目的稳定性和可扩展性。

• 精通 Git 工作流（Git Flow, 主干开发/Trunk-Based Development），并具备基本的代码审查 (Code Review) 技能。

• 理解基础的 iOS 应用模块化设计、多种单页面架构模式以及性能优化方法，并具备在项目中落地的能力。

加分项/优先考虑 (We will give priority to who):

• 拥有跨平台开发经验（满足以下任意一项即可）：

  • 6 个月以上的任意前端技术栈经验 (TypeScript/JavaScript, React, React Native)。

  • 6 个月以上使用 Kotlin 及相关框架的 Android 开发经验。

  • 6 个月以上的任意后端开发框架经验。

• 拥有至少 6 个月的 iOS 基础设施工具或框架搭建经验，包括代码质量提升（Linting, 静态分析, CI/CD）、效率优化（模块化，Gradle 组件化*）、以及性能调优（启动速度、帧率、离线模式、多线程）。

• 拥有 1 年以上 SDK 开发经验，包括通用库开发，如图片加载库 (SDWebImage, Kingfisher)、富文本编辑器、网络层或持久化层 (SQLite, Realm, Core Data)。

• 具备 UI/UX 相关经验：

  • 熟悉 Apple 人机交互指南 (HIG)，能够在理解跨平台设计差异的同时，实现符合 Apple 设计标准的 UI。

  • 拥有扎实的动画和交互动效开发经验，熟悉 Core Animation, UIKit Dynamics 等。

  • 有深色模式 (Dark Mode) 及主题切换功能的开发经验。

• 具备极强的审美感知力，拥有绘画、摄影或设计相关的技能或爱好（附带作品集者优先）。

• 拥有完整的 App 生命周期经验：曾独立开发、发布并维护过支持多国/多语言的 iOS 应用。

• 积极参与技术社区，例如：

  • 具有主动学习和分享的心态，有进行技术演讲的经验。

  • 有技术写作经验（博客、文章）。

  • 有开源项目贡献经历。

• 有使用 AI 编程工具的经验，如 Claude, ChatGPT, GitHub Copilot, Cursor 或 Windsurf。

• 具备流利的英语沟通能力或持有日语 N2 证书。

联系人

xx2bab@gmail.com

Shifting Light, Unchanging Haystacks

Read on web →

Two weeks ago, taking the opportunity of attending iOS Conf SG 2026, I visited the National Gallery Singapore and had the pleasure of viewing the special exhibition “Into the Modern: Impressionism from the Museum of Fine Arts, Boston”. Although I have seen many excellent exhibitions in the past, this experience resonated with me in a distinct and unexpected way.

The National Gallery Singapore is formed by merging two historically significant national monuments—the former Supreme Court and the City Hall. Architects connected these two classical structures with a minimalist metal and glass roof, creating a striking sense of place architecturally: history and modernity intertwined within the same physical space. The ongoing exhibition “Into the Modern”, which features over one hundred original works by masters such as Monet, Renoir, Manet, Cézanne, and Degas, elevates this cross-temporal dialogue to the realm of art.

The exhibition does not simply follow a chronological timeline; instead, it uses “modernity” as its core narrative thread, unfolding layer by layer through themes like “Cities and Change”, “Light and Moments,” and “Class and Leisure”. Although the “modern” here refers to the late 19th century, the urban renewal of Paris, the evolution of lighting techniques, and the rise of new forms of leisure depicted in the paintings all demonstrate, from multiple dimensions, the rhythm of social progress in that era. In this space where time and geography cross, the exhibition goes far beyond the mere level of “viewing art.” For someone like me, who is swept along daily by the torrent of “new tech” information on social media, this was a rare moment of tranquility and introspection.

Returning to reality, in just the past few days, the names of the hottest AI projects have shifted from Clawdbot to Moltbot, and then rapidly evolved into OpenClaw. From a microscopic perspective, we seem to be living in an era of change measured in minutes and seconds. However, if we were to look back at the current AI fever from a longer time scale years from now, we might discover that the world did not undergo the radical, fundamental mutations that we perceive while caught in the current.

Immersed in this environment, it is inevitable that we feel excitement—or even anxiety—over the endless stream of new technologies and tools. Perhaps, beyond these emotions, what we need is a deeper sense of grounding. History repeatedly reminds us that any “high tech” has its temporal limitations. Just as Monet repeatedly depicted the same haystack under different times and lighting conditions: the painting techniques may evolve, but the core object remains unchanged. What truly changes is often the way of seeing, the depth of understanding, and the creator’s own state of mind.

When facing the “present and future”, perhaps we can afford to be less frantic in our pursuit of change, and more composed in our contemplation of the moment.

Previous Issue｜Newsletter Archive

This Week’s Sponsor

Need to debug HTTPS on your iPhone?

Try Proxyman! The best-in-class macOS that helps you capture/debug HTTP(s) with a few clicks. Support iOS devices and Simulator.

🚀 Get Started Now →

Recent Recommendations

DebugReplaceableView and Swift 6.2’s Multiple Type Erasers

You may still find Xcode Previews less than ideal, but Apple has been actively optimizing this experience over the past few years with notable progress. Starting with Xcode 16, views are automatically converted to AnyView via @_typeEraser in preview and debug modes to provide richer debugging information. From Xcode 26 onwards, the enhanced @_typeErasernow supports multiple type erasers, converting views to DebugReplaceableView on macOS/iOS 26+ platforms. This enables hot-swapping of views without rebuilding the entire view hierarchy, further improving preview performance. In this article, Kyle Ye dives deep into the compiler source code to analyze the implementation, explaining how the compiler automatically selects the appropriate type eraser based on platform availability.

Tiered Caching in Swift

When you need to balance performance, memory footprint, and data consistency simultaneously, a single caching strategy often falls short. In this article, Kyle Browning provides a practical guide to implementing tiered caching in Swift: organizing memory and disk caches into a clear hierarchical structure, combined with flexible cache policies (such as cacheThenFetch, cacheElseFetch, etc.) to enable data to flow smoothly between different access cost tiers.

SwiftUI: Realtime, Multi-User Content Collaboration With CloudFlare +YJS-Swift

Despite the availability of numerous services and frameworks, implementing real-time collaborative editing remains a significant engineering challenge. In this article, Itsuki demonstrates how to build a low-cost, scalable, multi-user real-time collaborative content editing system in SwiftUI using Cloudflare Durable Objects + WebSocket Hibernation API + YJS-Swift.

Particularly noteworthy is the author’s detailed explanation of how to properly maintain text cursor and selection positions when receiving remote content updates in SwiftUI—this is closely aligned with real-world product development and clearly represents hard-won experience from actual implementation.

Swift Actors: 6 pitfalls that will catch even experienced developers

Actors are one of the most important—and most easily misunderstood—features in Swift’s concurrency model. Reality, however, is far more complex than it appears. In this article, Rafał Dubiel summarizes 6 Actor pitfalls that even experienced developers commonly encounter: state inconsistency caused by reentrancy, the performance cost of Actor hopping, thread-safety vulnerabilities when @MainActor interacts with Objective-C callbacks, the risks of misusing @unchecked Sendable, misconceptions about nonisolated, and the counterintuitive fact that Actors don’t guarantee execution order.

Rafał doesn’t stop at conceptual warnings—he explains through concrete scenarios why these issues genuinely exist and why they’re so easy to overlook.

Designing a Scalable App-Wide Theming System in SwiftUI

Implementing app-wide theming in SwiftUI may seem like a simple “style management” problem, but it easily touches on deeper design decisions involving state propagation, dependency injection, and view refresh boundaries. Sagar Unagarapproaches this from a real-world requirement, demonstrating a comprehensive theming system design based on SwiftUI’s Environment: using EnvironmentKey to make themes accessible like built-in environment values, and replacing scattered hardcoded values with semantic Design Tokens.

Sagar’s focus isn’t just on “how to do it,” but on “which approach is more maintainable in the long run”—this solution doesn’t depend on any specific library, with its core philosophy being “semantic + reactive,” easily extensible to fonts, spacing, corner radius, and other design elements.

Call Once

“Ensuring a closure executes only once” sounds like a basic requirement, but in real systems, it’s often not as simple as adding a boolean flag. In this article, Paul Samuels demonstrates how to encapsulate this behavior using @propertyWrapper, progressively evolving the solution: from a basic version supporting only () -> Void, to introducing generics for return values, and finally leveraging Swift’s Parameter Packs (each Argument) to support arbitrary function signatures.

This is a thought-provoking article whose value lies not only in the final CallOnce implementation, but in demonstrating how to progressively combine multiple Swift language features to solve a seemingly simple yet representative engineering problem.

Tools

SwiftUI-Agent-Skill: Making AI Write More Reliable SwiftUI Code

If you’re using AI coding assistants (like Claude Code, Cursor, or Codex), you’ve likely encountered this problem: AI-generated SwiftUI code uses deprecated APIs, or deviates from best practices in state management and view organization—even when you’ve repeatedly emphasized these requirements in your base rules.

SwiftUI-Agent-Skill, released by Antoine van der Lee, is designed to bridge this “last mile” gap. It provides AI tools with expert-level SwiftUI guidance covering state management trade-offs, modern API replacements, performance and maintainability checks, and iOS 26+ Liquid Glass usage boundaries—turning “the places where SwiftUI code most commonly goes wrong” into a reusable, executable review workflow.

In addition to this skill, Antoine also provides skills for Swift Concurrency and Core Data.

I recommend that developers don’t just configure these into their AI environment and call it done—these skill documents themselves are structured summaries of practical experience in specific domains. Reading through them carefully benefits not just your AI, but elevates your own understanding as well.

PierreDiffsSwift: Render Beautiful Code Diff Views in macOS Apps

PierreDiffsSwift, developed by James Rochabrun, helps developers render beautiful, syntax-highlighted code diff views in macOS applications.

The library provides an out-of-the-box solution: built on the @pierre/diffs JavaScript library, wrapped into SwiftUI-native views via WKWebView, supporting syntax highlighting for 40+ languages, Split/Unified view modes, inline word-level change highlighting, and automatic dark/light theme switching.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

变幻的光影，不变的干草堆

网页版

两周前，借着参加 iOS Conf SG 2026 的契机，我造访了新加坡国立美术馆，并有幸参观了《走进现代：波士顿美术博物馆印象派大师展》。尽管此前也看过不少优秀的展览，但这次经历仍带来了某种不同寻常的触动。

新加坡国立美术馆由两座极具历史分量的国家古迹——前最高法院与前市政厅——合并而成。设计师以极简的金属与玻璃屋顶将两座古典建筑连接在一起，在建筑层面便营造出一种强烈的临场感：历史与现代在同一物理空间中彼此交织。而正在展出的特展《Into the Modern》，汇集了莫奈、雷诺阿、马奈、塞尚、德加等 25 位大师的一百余幅原作，则将这种跨越时间的对话进一步推向了艺术层面。

展览并未简单依循时间线展开，而是以“现代性”为核心叙事线索，通过“城市与变革”“光影与瞬间”“阶级与休闲”等主题层层铺陈。尽管这里的“现代”指向的是 19 世纪末，但画作中所呈现的巴黎城市改造、光影技法的演变，以及新兴休闲与娱乐方式的兴起，无不从多个维度展现了那个时代社会前行的节奏。在这样一个时空交错的场域中，展览早已超越了单纯“观看艺术品”的层次。对于每天都被社交媒体时间线中海量“新技术”信息裹挟的我而言，这无疑是一段难得的平静与反思时刻。

回到现实，仅仅在过去的几天里，大热 AI 项目的名字就从 Clawdbot 变成 Moltbot，又迅速演化为 OpenClaw。从微观视角看，我们仿佛正身处一个以分秒计量的变革时代；但若在若干年后，从更长的时间尺度重新审视当下的 AI 热潮，或许会发现，世界并未如洪流之中的我们所感知的那样，发生着本质上的突变。

身处其中，我们难免会因层出不穷的新技术、新工具而兴奋，甚至焦虑。或许，在这种情绪之外，更需要一种更深层的定力。历史反复提醒我们，任何“高技术”都具有其时间局限性。正如莫奈在不同时间、不同光线下反复描绘同一座干草堆：绘画技法在变化，但核心对象始终未变；真正发生变化的，往往是观看方式、理解层次与创作者自身的心境。

在面对“现在与未来”时，也许我们可以少一些追逐变革的慌张，多一些凝视瞬间的从容。

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

本期赞助

调试 iOS 网络请求总是被证书配置难住？

Proxyman 是一款为 iOS 开发者打造的现代 HTTP 抓包工具。支持 SSL 代理、GraphQL、WebSocket 及强大的脚本注入功能。告别笨重的传统工具，体验专为 macOS 优化的极致调试效率。

🚀 立即试用 →

近期推荐

SwiftUI 调试背后的多重类型擦除机制 (DebugReplaceableView and Swift 6.2’s Multiple Type Erasers)

或许你可能对 Xcode 的 Preview 仍不甚满意，但其实在过去几年间，苹果一直在这方面积极地进行着优化工作，并且取得了不少的进展。比如，从 Xcode 16 开始，便在预览和调试模式下，通过 @_typeEraser 自动将视图转换为 AnyView 以增加更多的调试信息。而从 Xcode 26 开始，通过增强 @_typeEraser 使其支持多重类型擦除器，在 macOS/iOS 26+ 平台上将视图转换成 DebugReplaceableView，实现视图的热替换而无需重建整个视图层级，进一步改善预览性能。在本文中，Kyle Ye 从编译器源码层面深入剖析了这一机制的实现原理，解释了编译器如何根据平台可用性自动选择合适的类型擦除器。

Swift 中的分层缓存设计 (Tiered Caching in Swift)

在需要同时兼顾性能、内存占用与数据一致性的场景中，单一缓存策略往往很快就会捉襟见肘。这篇文章中，Kyle Browning 以实践视角系统介绍了分层缓存（Tiered Caching）在 Swift 中的实现思路：通过将内存缓存与磁盘缓存组织成清晰的层级结构，配合灵活的缓存策略（如 cacheThenFetch、cacheElseFetch 等），让数据在不同访问成本之间有序流动。

基于 Cloudflare 的 SwiftUI 实时协作编辑实践 (SwiftUI: Realtime, Multi-User Content Collaboration With CloudFlare +YJS-Swift)

尽管市面上已经存在不少现成的服务与框架，实时协作编辑在工程层面依然是一道不低的门槛。本文中，Itsuki 系统性地展示了如何在 SwiftUI 中，借助 Cloudflare Durable Objects + WebSocket Hibernation API + YJS-Swift，构建一个低成本、可扩展、支持多用户实时协作的内容编辑系统。

尤其值得一提的是，作者详细分享了在 SwiftUI 接收远程内容更新时，如何正确维护文本光标与选区位置的处理技巧——这一部分非常贴近真实产品开发，明显属于“踩过坑之后才会写出来”的经验。

Swift Actor 的 6 个常见陷阱 (Swift Actors: 6 pitfalls that will catch even experienced developers)

Actor 是 Swift 并发模型中最重要、也最容易被“想当然”使用的语言特性之一，然而现实远比这复杂。Rafał Dubiel 在本文中总结了 6 个即使是资深开发者也常踩的 Actor 陷阱：可重入性导致的状态不一致、Actor Hopping 的性能代价、@MainActor 与 Objective-C 回调交互时的线程安全漏洞、@unchecked Sendable 的滥用风险、nonisolated 的误解，以及 Actor 并不保证执行顺序这一反直觉的事实。

Rafał 并未停留在概念层面的提醒，而是结合具体场景解释这些问题为何真实存在、又为何容易被忽视。

SwiftUI 全局主题系统的可扩展设计 (Designing a Scalable App-Wide Theming System in SwiftUI)

在 SwiftUI 中实现全局主题（Theming），看似是个“样式管理”问题，实则很容易牵扯到状态传播、依赖注入以及视图刷新边界等更深层的设计选择。Sagar Unagar 从一个现实需求出发，系统展示了一套基于 SwiftUI Environment 的全局主题系统设计：通过 EnvironmentKey 让主题像内置环境值一样访问，以语义化的 Design Tokens 取代散落各处的硬编码值。

Sagar 关注的并不仅是“如何做”，而是“哪种方式在长期更可控”——这套方案不依赖特定库，核心思想是“语义化 + 响应式”，可以轻松扩展到字体、间距、圆角等设计要素。

在 Swift 中实现“只执行一次”的优雅方式 (Call Once)

“确保闭包只执行一次”听起来像是一个再基础不过的需求，但在真实系统里，这往往并不只是加一个布尔值那么简单。Paul Samuels 在本文中展示了如何用 @propertyWrapper 封装这一行为，并逐步演进：从只支持 () -> Void 的基础版本，到引入泛型支持返回值，最终借助 Swift 的 Parameter Packs（each Argument）实现对任意函数签名的支持。

这是一篇偏思考型的文章，其价值不仅在于最终的 CallOnce 实现，更在于展示了如何将多个 Swift 语言特性逐步组合起来，解决一个看似简单却颇具代表性的工程问题。

工具

SwiftUI-Agent-Skill：让 AI 写出更“靠谱”的 SwiftUI 代码

如果你正在使用 AI 编程助手（如 Claude Code、Cursor、Codex），很可能遇到过类似的问题：AI 生成的 SwiftUI 代码使用了过时的 API，或在状态管理、视图组织上偏离最佳实践——即便你已经在基础规则中反复强调过这些要求。

Antoine van der Lee 发布的 SwiftUI-Agent-Skill，正是为了解决这一“最后一公里”的落差。它为 AI 工具提供了一套专家级的 SwiftUI 指导规范，涵盖状态管理取舍、现代 API 替换、性能与可维护性检查，以及 iOS 26+ 的 Liquid Glass 使用边界等内容，把“SwiftUI 最容易写歪的地方”整理成可复用、可执行的审查流程。

除了这套 skill 外，Antoine 还提供了面向 Swift Concurrency 和 Core Data 的 skill。

我建议开发者不要只是把它们简单配置进 AI 环境中就结束了——这些 skill 文档本身就是对某一领域实践经验的结构化总结。认真读一遍，受益的不只是 AI，你自己也会随之进阶。

PierreDiffsSwift：在 macOS 应用中渲染精美的代码 Diff 视图

James Rochabrun 开发的 PierreDiffsSwift，帮助开发者在 macOS 应用中渲染漂亮的、带语法高亮的代码 Diff 视图。

该库提供了一个开箱即用的解决方案：基于 @pierre/diffs JavaScript 库，通过 WKWebView 封装成 SwiftUI 原生视图，支持 40+ 种语言的语法高亮、Split/Unified 两种视图模式、行内单词级变更高亮，以及深色/浅色主题自动切换。

Skip Goes Open Source: A High-Stakes Bet from “Selling Tools” to “Selling Trust”

Read on web →

Just two months after announcing that the Fuse edition would be free for indie developers, Skip Tools made another bold move: making its core engine, skipstone, completely free and open source. This decision marks a fundamental shift in Skip’s business model—from selling a product to relying on services and community sponsorships. The change reflects both the pressure of an underperforming commercial strategy and the team’s willingness to take risks. In an era dominated by AI and a largely entrenched developer tooling landscape, Skip chose to actively pivot rather than stand still.

Many technically strong and distinctive products fail to gain traction not because of their technology, but because of a lack of trust. As Skip itself points out, companies fear a “rug pull”: if the vendor shuts down or gets acquired, the products and tech stacks built on top of that tool may need to be rebuilt from scratch. By going open source, Skip aims to eliminate this trust barrier—placing itself on equal footing with other cross-platform tools, while also activating the community to help grow the ecosystem.

That said, while the community has largely praised Skip’s open-source decision, concerns remain. After giving up license keys as a stable revenue stream, can sponsorship alone sustain long-term development? History shows that while some open-source business models succeed, many do not. This concern is hardly unfounded. At the time of writing this issue—just days after the open-source announcement—discussion on social media was lively, yet Skip had only a handful of individual sponsors on GitHub. The gap between enthusiastic conversation and real financial support appears wider than expected. This may also explain why Skip ultimately chose to go open source: if developers cannot be convinced to pay for the tool, at least they might be persuaded to use it.

An interesting shift has emerged amid this mix of optimism and anxiety. The conversation has quietly moved from “Why pay for Skip instead of using free KMP?” to “Do you prefer writing Swift or Kotlin?” This change is significant. It suggests that Skip has successfully reframed the competition—from a debate over business models to one centered on language ecosystems. In doing so, the competitive arena expands from a single company to the entire Swift community. In this language-level contest, Skip has—perhaps intentionally, perhaps not—repositioned itself from a central protagonist to underlying infrastructure.

From the beginning, Skip was driven by the belief that there was a real commercial opportunity with sufficient returns. Without such expectations, it is unlikely that either the company or the community alone could have pushed Swift forward on non-Apple platforms so quickly. This path closely resembles how The Browser Company aggressively promoted Swift on Windows in pursuit of building the Arc browser.

As a Swift developer, I sincerely hope this pivot delivers the results Skip is aiming for. Open source is both an experiment in trust and an investment in the ecosystem. If you, too, hope to see Swift thrive beyond iOS, consider starting by becoming a individual sponsor ($10/month). This is not just support for Skip—it is a vote for the broader Swift cross-platform ecosystem. How far open-source Skip can go ultimately depends on how many people are willing to move from being observers to active participants.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Original

isolated(any) and #isolation: Letting Swift Closures Automatically Inherit Isolation

Swift 6 introduces many new features and keywords to its concurrency model. While some of them may rarely be used in day-to-day development, lacking an understanding of these concepts can leave you stuck in specific scenarios—even with AI assistance. This article walks through a real concurrency issue encountered during development and testing, demonstrating how @isolated(any) and the #isolation macro can be used to let functions inherit isolation automatically, allowing the compiler to infer the execution context of closures.

Recent Recommendations

A Deep Dive into SwiftData migrations

As apps evolve, changes to data models are almost inevitable, and performing safe data migrations remains a significant challenge for many developers. In this article, Donny Wals provides a comprehensive overview of SwiftData’s migration system, covering everything from basic versioning to complex custom migration strategies. He also shares several particularly valuable recommendations: even a V1 model should be wrapped in a VersionedSchema to prepare for future changes; new schema versions should be introduced only between App Store release cycles, rather than being modified repeatedly during development; and for lightweight migrations, even when SwiftData can handle them automatically, it is still advisable to explicitly define them in a SchemaMigrationPlan to make intentions clearer and easier to test.

One of the highlights of the article is its detailed explanation of when to use willMigrate versus didMigrate in MigrationStage.custom, along with a “bridge version” strategy for handling complex refactors, such as splitting entities.

Why MVVM-C with Coordinators does Scale -> A real-world SwiftUI perspective

Despite the title referencing “MVVM-C,” this is not simply an article defending a specific architectural pattern. Bruno Valente Pimentel redefines what “scalability” really means—arguing that it should not be measured by the number of screens or files, but by how well an architecture supports efficient collaboration and independent feature evolution. As the author puts it, “architecture is not about patterns, but about reducing fear”—the fear of changing code, collaborating with others, and evolving features.

No matter which architecture you prefer, when building SwiftUI apps you should seriously ask yourself: are we leveraging SwiftUI’s strengths, or trying to bend SwiftUI into the shape of UIKit as we know it?

TCA (Composable Architecture): The Honest Review

Following Bruno’s reevaluation of MVVM-C, Chandra Welim offers an objective assessment of another highly debated architecture: TCA. The article summarizes five key strengths of TCA (predictable state management, excellent testability, time-travel debugging, composability, and strong type safety) alongside five major challenges (learning curve, boilerplate, team adoption, overengineering for simple apps, and third-party dependencies). It also provides pragmatic guidance: TCA is a powerful tool, but it is not suitable for every scenario. For simple MVPs or teams without a functional programming background, traditional MVVM may be a more practical choice; for large-scale projects with complex state and a need for time-travel debugging, TCA can offer unmatched control. The core takeaway: TCA is worth it when you truly need it—but most apps don’t.

There is no silver bullet in architecture—only trade-offs in a specific context.

Improving the usability of C libraries in Swift

Although Swift is designed to interoperate with C, calling C APIs directly often results in a poor developer experience—exposing raw pointers, requiring manual memory management, and using naming conventions that feel foreign to Swift. To achieve a more “native” experience, developers often have to write and maintain cumbersome wrapper layers. In this article, Doug Gregor explains how API Notes and Clang Attributes can be used to “guide” the Swift compiler into generating Swift-friendly interfaces without modifying the underlying C library implementation.

The significance of this improvement lies in shifting the cost of “wrapping C libraries” from the logic layer (writing Swift glue code) to the declaration layer (authoring API Notes or adding annotations to headers). This is particularly important for the adoption of Embedded Swift, where existing C libraries are fundamental to the ecosystem. As the toolchain matures, developers may eventually need only a few annotations to use C libraries in Swift as if they were native. The article also provides regex-based automation scripts for generating API Notes in bulk from structured C headers.

Introduction to Building Swift for Yocto

For most iOS developers, Yocto may be unfamiliar, but it is the de facto standard in the embedded Linux world—offering precise control over every component included in a system. As Embedded Swift advances, integrating Swift into the Yocto ecosystem becomes a key challenge. Jesse L. Zamora demonstrates how to build a Swift runtime for Yocto using the recently revived meta-swift layer. Using a Raspberry Pi Zero 2 as an example, the article walks through the entire workflow, from setting up a Docker environment and building Yocto, to flashing the image and running Swift code on the device.

It is worth noting that a full build can take several hours and requires some familiarity with Yocto’s build system. However, the provided meta-swift-examples repository includes a Dockerized environment and one-click scripts that significantly lower the barrier to entry.

meta-swift is the Yocto layer for Swift. It had long been stalled at Swift 5.7, but thanks to community efforts, it now supports Swift 6.1.3.

TIL how to auto-move Xcode DEBUG builds to Applications

When developing apps that include App Intents, you may run into this issue: App Intents only appear in Shortcuts.app when the app is located in the /Applications directory. Since DEBUG builds are placed in DerivedData by default, this makes testing Shortcuts integration difficult. Carlo Zottmann previously relied on complex post-build scripts to move apps around, but in this article he shares a more “native” solution—using just three lines of .xcconfig to have Xcode automatically deploy build artifacts to a specified directory and clean them up properly when builds are removed.

This trick is useful not only for testing App Intents, but for any scenario where DEBUG builds need to live in a specific location.

Visualise anything with SwiftUI Charts

If you needed to build a custom, animated, and interactive circular stress indicator in SwiftUI, how would you approach it—using Shape, or Canvas? In this article, Kyryl Horbushko presents a creative solution by leveraging Swift Charts’ SectorMark to implement the component elegantly and efficiently.

Kyryl’s approach challenges the common assumption that Swift Charts are only suitable for traditional data visualization. For developers building complex dashboards in health or finance apps, this represents a highly instructive “dimensionality reduction” strategy—solving custom UI problems with a data visualization framework, while benefiting from built-in animations and interaction support.

Tools

Commander: A Focused Yet Flexible AI Coding Experience

I enjoy using CLI tools on macOS (such as Claude Code and Codex), but the visual experience of native terminal apps leaves much to be desired, so I usually rely on VS Code extensions to improve the workflow. However, one design choice in VS Code has consistently bothered me: even when the Claude Code panel is maximized, any file modifications made by the AI will still open new editor tabs or windows, disrupting the existing interaction flow.

Marcin Krzyżanowski’s macOS-native app Commander offers a compelling alternative. It provides a more polished interface than the terminal while preserving my “flow”—files are opened only when needed, and system-default apps can be used for viewing. Commander currently supports Claude Code and Codex, includes Git worktrees and code diff features, and is completely free. It occupies a sweet spot between the “focus” of the terminal and the “flexibility” of VS Code.

Oh My Agents: Centrally Managing Configuration for All AI Coding Assistants

With the rise of AI coding assistants like Claude Code, Cursor, Codex, and Windsurf, developers are facing a new challenge: managing scattered prompts, skills, and rules across multiple projects. Each agent has its own configuration format (CLAUDE.md, CURSOR.md, etc.), and manual copying is both inefficient and error-prone. Oh My Agents, created by Wei Wang (onevcat), addresses this problem directly.

Core features:

• Centralized management of all AI agent configurations

• Rule-based distribution with one-click syncing across projects

• Bidirectional sync, allowing project-level improvements to flow back into the central repository

• Change previews to prevent accidental overwrites

Note: Currently macOS-only (Windows/Linux support in progress). Free during the beta period.

Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.

Share

Skip 开源：从“卖工具”到“卖信任”的豪赌

网页版

在宣布 Fuse 版本对独立开发者免费 仅两个月后，Skip Tools 再次做出惊人之举——全面免费并开源核心引擎 skipstone。这意味着 Skip 彻底改变了经营方式：从“卖产品”转向“卖服务+社区赞助”。这次变化，既有对之前商业模式执行不佳而被迫调整的无奈，也体现了 Skip 团队的果敢——在当前 AI 盛行、开发工具格局固化的背景下，主动求变，力求突破。

很多优秀且有特点的产品没能获得应有的使用量，最大的阻碍往往不是技术，而是“信任”。正如 Skip 官方所言，企业最担心的是“rug pull”——万一公司倒闭或被收购，押注在这个工具上的产品和技术栈将面临推倒重来的风险。Skip 希望通过开源消除这种信任危机，让自己和其他跨平台工具站在同一起跑线上，同时激活社区力量，加速生态建设。

尽管社区对 Skip 的开源决定给予了充分肯定，但也有不少人担心：在放弃了 license key 这一稳定收入来源后，仅靠赞助模式能否支撑持续开发成本？毕竟，成功的开源商业案例虽有，但失败的也不少。这种担忧并非杞人忧天。在我撰写本期周报时（宣布开源数天后），尽管开源消息在社交媒体上引发了热议，但在 GitHub 上，Skip 的个人赞助者仅有十几位。从“热闹的讨论”到“真金白银的支持”，中间的鸿沟似乎比想象中还要深。这或许也解释了为什么 Skip 最终选择了开源——在无法说服开发者”付费使用”时，至少要争取到他们”免费使用”的机会。

一个有趣的现象是，在肯定与忧虑并存的情绪中，讨论的焦点悄然发生了变化：从“为什么要花钱买 Skip 而不是用免费的 KMP?”变成了“你是更喜欢写 Swift 还是 Kotlin?”。这个转变意义重大——它意味着 Skip 已经成功将竞争维度从“商业模式”转移到了“语言生态”，而参与竞争的主体也从“一家小公司”扩展为“整个 Swift 社区”。在这场语言之争中，Skip 聪明地（或许是无意间）将自己的角色从“主角”变成了“基础设施”。

Skip 最早的出发点是看到了一个商业机会，认为有足够的商业回报。如果不是有这样的预期，仅靠官方或社区的力量，Swift 可能无法快速推进在其他平台上的进展。这一路径与 The Browser Company 为了打造 Arc 浏览器而大力推动 Swift 在 Windows 平台上的适配如出一辙。

作为一个 Swift 开发者，我由衷希望 Skip 的这次调整能够取得预期效果。开源是一场信任的实验，也是一次生态的投资。如果你也期待 Swift 能在 iOS 之外的平台上拥有更多可能，不妨从成为一个独立赞助者($10/月)做起——这不仅是对 Skip 的支持，更是对整个 Swift 跨平台生态的投票。开源的 Skip 能走多远，取决于有多少人愿意从旁观者变成参与者。

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

原创

isolated(any) 与 #isolation：让 Swift 闭包自动继承隔离域

Swift 6 为并发引入了许多新功能与关键字。虽然其中不少内容在日常开发中可能鲜少用到，但一旦遭遇特定场景，若对这些新概念缺乏了解，即便有 AI 辅助也可能陷入僵局。本文将通过一个在开发测试中遇到的实际并发问题，来介绍如何利用 @isolated(any) 以及 #isolation 宏，实现函数的隔离域继承，从而让编译器自动推断闭包的运行环境。

近期推荐

SwiftData 数据迁移全解析 (A Deep Dive into SwiftData migrations)

随着应用的发展，数据模型几乎无可避免地会出现变化，如何安全地进行数据迁移对很多开发者来说都是一个不小的挑战。在本文中，Donny Wals 全面讲解了 SwiftData 的数据迁移机制，从基础的版本控制到复杂的自定义迁移策略。其中，Donny 给出了几个特别有价值的建议：即使是 V1 版本也应该使用 VersionedSchema 进行封装，为未来的迁移打好基础；只在 App Store 发布周期之间引入新的 Schema 版本，而不是在开发过程中频繁修改；对于轻量迁移，即使 SwiftData 可以自动完成，也建议显式地写入 SchemaMigrationPlan 中，使意图更加明确且易于测试。

文章的一大亮点是详细解释了 MigrationStage.custom 中 willMigrate 与 didMigrate 的适用场景，并提出了应对复杂重构（例如拆分实体）的“桥接版本（Bridge Version）”策略。

为什么 MVVM-C 在 SwiftUI 项目中依然能扩展 (Why MVVM-C with Coordinators does Scale -> A real-world SwiftUI perspective)

尽管标题中包含“MVVM-C”，但这并非一篇单纯为某种架构模式辩护的文章。Bruno Valente Pimentel 在文中重新定义了“扩展性”的内涵——它不应仅以屏幕或文件的数量来衡量，而应看其是否支持高效的多人协作及功能的独立演进。正如作者所言：“架构无关乎模式，而关乎减少恐惧”——减少修改代码、团队协作以及功能演进时的恐惧。

无论你倾向于哪种架构模式，在用它构建 SwiftUI 项目时，都应该认真思考：我们到底是在利用 SwiftUI 的特性，还是在试图把 SwiftUI 改造成我们熟悉的 UIKit？

TCA 架构的真实评估 (TCA (Composable Architecture): The Honest Review)

继 Bruno 为 MVVM-C “正名”后，Chandra Welim 对另一个极具争议的架构——TCA 进行了客观评估。作者总结了 TCA 的五大优势（可预测的状态管理、优秀的可测试性、时间旅行调试、组合性、强类型安全）和五大挑战（学习曲线、样板代码、团队采纳、对简单应用过度设计、第三方依赖），同时给出了务实的建议：TCA 是一个强大的工具，但绝非适用于所有场景。对于简单的 MVP 或缺乏函数式编程背景的团队，传统的 MVVM 或许是更务实的选择；而对于状态错综复杂、需要“时间旅行”调试的大型项目，TCA 则能提供无与伦比的掌控力。核心结论：TCA 在你需要时很值得，但大多数应用并不需要它。

架构选择没有银弹，只有在特定上下文中的权衡。

让 C 库在 Swift 中“像原生 API 一样好用” (Improving the usability of C libraries in Swift)

Swift 虽然生来就兼容 C，但直接调用 C API 往往体验不佳——开发者通常需要面对裸指针、手动内存管理以及不符合 Swift 命名习惯的函数。为了获得“原生”体验，开发者不得不编写和维护繁琐的 Wrapper 层。在这篇文章中，Doug Gregor 详细介绍了如何利用 API Notes 和 Clang Attributes 机制，在不修改 C 库实现代码的前提下，“指导” Swift 编译器生成符合 Swift 风格的接口。

这项改进的意义在于，它将“封装 C 库”的成本从逻辑层（编写 Swift 胶水代码）转移到了声明层（编写 API Notes 或添加头文件注解）。这对于 Embedded Swift 的普及至关重要，因为嵌入式开发高度依赖现有的 C 库生态。随着工具链的完善，未来开发者可能只需要给 C 库加几个注解，就能直接在 Swift 中像使用原生库一样调用它。文章还提供了基于正则表达式的自动化脚本，可以为结构化的 C 头文件批量生成 API Notes。

在 Yocto 系统中构建 Swift (Introduction to Building Swift for Yocto)

对于大多数 iOS 开发者来说，Yocto 可能比较陌生，但它是嵌入式 Linux 领域的事实标准——它能够精确控制系统中包含的每一个组件。随着 Embedded Swift 的推进，如何在 Yocto 生态中集成 Swift 成为了一个关键问题。Jesse L. Zamora 详细演示了如何使用近期重获更新的 meta-swift 在 Yocto 系统中构建 Swift 运行环境。文章以 Raspberry Pi Zero 2 为例，从 Docker 环境搭建、Yocto 构建、镜像烧录到实际运行，演示了完整的工作流。

需要注意的是，完整构建过程需要数小时，且要求对 Yocto 构建系统有基本了解。不过，文章提供的 meta-swift-examples 仓库已经包含了 Docker 化的构建环境和一键脚本，大大降低了上手门槛。

meta-swift 是 Swift 语言的 Yocto 层，此前曾长期停滞于 Swift 5.7，但在社区的努力下，目前已支持到 Swift 6.1.3。

让 Xcode 的 DEBUG 构建自动部署到 /Applications (TIL how to auto-move Xcode DEBUG builds to Applications)

开发包含 App Intents 的应用时，你可能遇到过这个问题：App Intents 必须在 /Applications 目录下才能在 Shortcuts.app 中显示。这意味着 DEBUG 构建默认放在 DerivedData 中时，开发者无法测试 Shortcuts 集成。 Carlo Zottmann 曾长期使用复杂的 Post-build 脚本来搬运 App，但他在本文中分享了一个更“原生”的方案——通过三行 .xcconfig 配置让 Xcode 自动将构建产物部署到指定目录，并在清理构建时正确删除已部署的文件。

这个技巧不仅适用于 App Intents 测试，也适用于任何需要将 DEBUG 构建放到特定位置的场景。

用 Swift Charts 构建自定义可交互仪表盘 (Visualise anything with SwiftUI Charts)

如果你需要自定义一个可动画、可交互的环形压力仪表盘（Stress Indicator）的 SwiftUI 组件，你会如何进行？是使用 Shape，还是 Canvas？Kyryl Horbushko 在本文中展示了一个非常有创意的解法——利用 Swift Charts 的 SectorMark，优雅且高效地实现了需求。

Kyryl 的实现打破了我们对 Swift Charts 仅用于“数据可视化”的刻板印象。对于需要开发健康类、金融类复杂 Dashboard 的开发者来说，这是一种极具参考价值的”降维打击”式方案——用数据可视化框架解决自定义 UI 问题，既减少代码量，又获得内置的动画和交互支持。

工具

Commander：兼顾专注与灵活的 AI 变成体验

我喜欢在 macOS 上使用 CLI 工具(Claude Code、Codex)，但原生终端应用的视觉体验实在不敢恭维，因此多数情况下我都在 VSCode 中通过插件来改善体验。然而，VSCode 的一个设计始终让我困扰：即便将 Claude Code 的对话栏最大化，AI 修改文件时仍会自动打开新的文件栏或窗口，打断既有的交互节奏。

Marcin Krzyżanowski 开发的 macOS 原生应用 Commander 给了我一个新的选择。它提供了一个比终端更优的交互界面，同时保护了我的“心流”——文件只在需要时才开启，并能调用系统默认应用查看。Commander 目前支持 Claude Code 和 Codex，内置了 Git worktrees 和 Code diff 支持，且完全免费。它在终端的“专注”与 VSCode 的“灵活”之间，构建了一个绝佳的中间地带。

Oh My Agents: 统一管理所有 AI 编程助手的配置

随着 Claude Code、Cursor、Codex、Windsurf 等 AI 编程助手的涌现，开发者面临着一个新问题：如何管理散落在各个项目中的 prompts、skills 和 rules? 每个 Agent 都有自己的配置规范(CLAUDE.md、CURSOR.md...)，手动复制粘贴不仅低效，还容易导致版本混乱。王巍(onevcat) 开发的 Oh My Agents 提供了解决方案。

核心功能:

• 集中管理所有 AI Agent 配置

• 定义分发规则，一键同步到多个项目

• 双向同步，项目改进可拉回中央库并更新所有关联项目

• 预览变更，避免意外覆盖

注：目前仅支持 macOS (Windows/Linux 开发中)，Beta 期间免费。