A “Native” Debate Over SwiftUI Animation

Read on web →

Last week, a post by React Native core developer Krzysztof Magiera sparked a lively discussion across the Apple developer community. In the post, he demonstrated an example where, with the main thread blocked, a back-and-forth animation in UIKit continued to run normally while the equivalent SwiftUI animation came to a halt. He attributed this to SwiftUI not using Core Animation’s render-server animation model and instead advancing animations within the app process, raising the question of whether SwiftUI is truly “native.” He later added that, in React Native, developers can still use Core Animation to create animations that continue running even when the main thread is blocked.

SwiftUI co-creator and early core developer Kyle Macomber responded with a different perspective. He explained that, from the beginning, SwiftUI deliberately moved away from server-side animation—where Core Animation advances animations on the render server—and instead chose to compute and advance animation values in the client/app process in exchange for better interruptibility and interactivity. This was not a technical regression, but a deliberate design trade-off. (SwiftUI did not abandon Core Animation itself; Core Animation still participates in the subsequent rendering process. What changed is who advances the animation.)

Ease of animation has always been one of SwiftUI’s signature strengths, and the continued evolution of its spring animations in recent years has further improved the naturalness of transitions and the expressiveness of interactive motion. For a reactive framework, I think advancing animations on the client side is entirely understandable. The trade-off, of course, is equally clear: as Krzysztof’s example demonstrates, when animation advancement depends on the app process, it becomes more susceptible to a busy main thread and also consumes more computational resources on the client side.

That said, client-side animation does not mean that all animation sampling calculations must happen on the main thread. As SwiftUI has evolved, some computationally intensive work involving animations and Shape can now be moved to background threads, reducing pressure on the main thread. Still, because animation advancement remains within the app process, and asynchronous computation is subject to constraints such as state updates and the rendering pipeline, animations can still stall when the main thread is completely blocked. Despite this “drawback,” starting with iOS 18, UIKit and AppKit also began adopting this client-side animation model: their new animation APIs can directly use SwiftUI’s Animation and are driven by the same underlying animation infrastructure rather than generating traditional CAAnimation objects.

This discussion presented an interesting situation: on the surface, the debate was about whether SwiftUI is truly “native,” but underneath it revealed a difference in framework design philosophies.

As Apple’s UI framework for the future, SwiftUI chose to depart from the established path, moving away from dependence on Core Animation’s render-server animation model in exchange for more flexible and expressive animation capabilities. In fact, John Harper, the creator of Core Animation, was himself one of SwiftUI’s co-creators. So this choice clearly wasn’t made out of unfamiliarity with Core Animation, but rather as an architectural decision made with an understanding of both its strengths and limitations. It also brought a less obvious advantage: some of SwiftUI’s core capabilities became further decoupled from the specific implementation details of Apple platforms. Although Apple has not open-sourced SwiftUI, architecturally, some of its core ideas are not inherently limited to Apple platforms.

From the React Native perspective, Krzysztof’s argument also has its rationale. As a cross-platform framework, one of React Native’s important goals is to make the best possible use of the capabilities each platform already provides, allowing apps to behave and perform more like “locals” on each platform.

What began as a discussion about “what counts as native” ultimately led core developers from both sides to explain how they think about UI animation architecture. As someone happily watching from the sidelines, I learned quite a bit from it as well.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

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

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Original

From pbxproj to xcproj: Xcode Project Configuration Gets a JSON Format

I’ve been waiting for Xcode 27.1, hoping to test how my apps adapt in the iPhone Duo simulator. Amusingly, 27.1 never arrived — Apple shipped 27.2 beta first instead. The iPhone Duo simulator is still missing, but the new project.xcproj caught my eye. What it replaces is project.pbxproj, the build graph inside the .xcodeproj bundle, not the bundle itself. What’s good about it, what does it fix, and what stays the same? This article takes a look.

Recent Recommendations

How we built Devin’s Mac

When an AI agent runs locally, permissions have long since been granted, the toolchain is ready, and a human can dismiss any dialog that appears. Move to the cloud and every one of those assumptions has to be rebuilt. The payoff isn’t doing something the local machine can’t — it’s turning the development environment itself into a resource you can assign to an agent: tasks run asynchronously, stay isolated from one another, pause and preserve their state when idle, resume on demand, and scale more easily to several agents working in parallel. Jon Kelley walks through building Devin’s macOS cloud environment, covering virtual machines on Virtualization.framework, disk snapshots, network isolation, pre-configured environments and permissions, live streaming of the desktop and Simulator, and computer use driven by the accessibility tree. That last point is especially instructive for Apple developers: good accessibility support also gives agents a structured interface for automated verification.

iOS 27: CrashReportExtension Framework

Traditional crash handling has an awkward problem: by the time the signal handler runs, the process it lives in may already be unreliable — memory may be corrupted, locks may still be held, and many everyday APIs can’t be called safely. The new CrashReportExtension in iOS 27 changes that execution model. After the app crashes, the system launches a separate extension and hands it a read-only CrashedProcess for inspecting the crashed process.

Anton Gubarenko demonstrates how to create and use the extension, along with several practical judgments. The API complements Apple’s .ips reports rather than replacing them, and suits teams that need their own backend, correlation with business context, or on-device pre-analysis. The extension itself should stay small, doing nothing more than generating and persisting a report; uploads and retries belong in the host app, with the two sharing storage through an App Group. For most indie developers, system crash reports plus MetricKit remain sufficient.

How SwiftUI animation works

For animation, developers only change state and specify an animation function, leaving the rest to SwiftUI. But how do those declarations become a continuous sequence of frames on screen? Starting from Transaction and AttributeGraph, and drawing on his work on OpenSwiftUI, Kyle Ye analyzes step by step how SwiftUI creates an animation context, computes intermediate states, and keeps updating views and layout as the animation runs.

Unlike the conventional approach of leaving interpolation mostly to the render server, many SwiftUI animations advance within the app process. Because interpolation happens inside the view graph, any value conforming to Animatable can be sampled, which lets layout, Shape, and much more participate in animation, while the render server mainly handles layer properties. The analysis of the CABasicAnimation on the asynchronous commit path is particularly worth reading: it carries only the current frame’s sampled value and is replaced on the next frame — the presence of a CA animation object on screen does not mean the animation’s clock has been handed to Core Animation. This adds useful detail to the debate over whether SwiftUI animation is “native,” discussed in this issue’s editorial.

SwiftUI: Some New APIs/ContainerViews Useful For Duo!

The many poses of iPhone Duo present new challenges for toolbars. To make full use of the wider screen while preserving vertical space for content, the system moves controls normally placed at the top and bottom to the side of the screen in certain poses. But text buttons, custom views, and other traditional toolbar content don’t always suit a vertical arrangement, and the toolbar and tab bar may have to compete for limited side space. iOS 27.1 addresses this with APIs including ToolbarItemAxisBehavior, ToolbarVerticalBehavior, ToolbarVerticalCompressionBehavior, and toolbarVerticalEdge, giving developers finer control over a toolbar’s orientation, placement, and compression strategy when space runs short. Itsuki demonstrates how these new APIs behave, with code and videos.

What these APIs have in common is that they let developers declare a preference rather than dictate a result. Faced with the range of poses Duo introduces, describing the relationships between pieces of content and your layout preferences — and letting SwiftUI decide the final presentation based on the actual environment — beats writing layouts for specific device states.

Sheets and fold avoidance on iPhone Duo

When iPhone Duo is partially folded, the crease down the middle forms a region poorly suited to interaction, and buttons or other controls that land there become awkward to operate. Using sheets as his example, Sarun Wongpatcharapakorn shows how a single interface adjusts its size, position, and toolbar across Duo’s closed, open, landscape, portrait, and partially folded poses. System components including sheets, alerts, and menus already avoid the fold without developer intervention. For developers, that means reaching for system components first also means inheriting this adaptive behavior across device poses for free.

Tools

Vapor 5 Beta Released

Ten years after Vapor was born and six and a half years after Vapor 4 shipped, the community finally has the first beta of Vapor 5. It amounts to a near-complete rewrite — two years of work and roughly 49,000 lines changed. The central change is saying goodbye to EventLoop and EventLoopFuture and moving fully to Swift Concurrency built on structured concurrency, with NIO now largely hidden from the public APIs.

Vapor 5 also integrates more deeply with Swift HTTP Types, Swift Configuration, and Swift Service Lifecycle, and adds the experimental VaporMacros for compile-time type checking of routes and authentication. It requires Swift 6.4 and remains in beta. For a fuller account of what changed, see Tim Condon‘s What’s New in Vapor 5 Beta.

Hinge: Set the Duo Simulator’s Fold Angle from the Command Line

Xcode 27.1’s Device Hub can adjust the fold angle of the iPhone Duo Simulator (hold Option to reveal it), but neither simctl nor devicectl offers a corresponding command. Hinge, from Artem Novichkov, fills the gap: it sets fold angles from 0 to 180° on the command line, and supports opening, closing, half-folding, and sweeping continuously between angles. Hinge also ships an Agent Skill, letting a coding agent change Duo’s fold state itself while verifying an app.

Enriched Markdown: Cross-Platform Markdown Rendering and Editing Without a WebView

The usual way to handle Markdown on mobile is to wrap it in a WebView. Enriched Markdown, from Software Mansion, takes a more thorough route: it renders Markdown and supports rich-text editing through each platform’s native text capabilities, and can emit clean Markdown again once the content has been edited.

It offers a standalone SwiftUI SDK, rendering Markdown with TextKit 2 and md4c, and also covers React Native, Android, and the web. Rather than settling for “Markdown that displays,” Enriched Markdown emphasizes a native feel: text selects normally, links, images, and code blocks hook into system menus, and the library supports VoiceOver, TalkBack, Dynamic Type, and right-to-left writing.

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

Share

一场关于 SwiftUI 动画的“原生”之争

网页版

上周，React Native 核心开发者 Krzysztof Magiera 的一条 ⁠推文 在苹果开发生态中引发热烈讨论。推文中他展示了一个示例：在主线程阻塞的情况下，UIKit 的一个往返动画仍能正常执行，而 SwiftUI 的动画则停滞了。他认为原因在于 SwiftUI 没有使用 Core Animation 的 render-server animation，而是在应用进程中推进动画，因此对 SwiftUI 是否足够“原生”提出了质疑；随后又表示，在 React Native 中，开发者仍可通过 Core Animation 创建不受主线程阻塞影响的动画。

SwiftUI 共同创造者、早期核心开发者 Kyle Macomber 对此回应了不同的 ⁠观点。他解释说，SwiftUI 在设计之初就有意放弃了 Server-side Animation（由 Core Animation 在 render server 中推进动画），而选择让动画值在 client / app process 中计算和推进，以换取更好的可中断性与交互性。这并非技术上的退步，而是一项设计取舍（SwiftUI 并没有放弃 Core Animation，它仍然参与后续的渲染过程，改变的只是动画由谁来推进）。

动画的易用性一直是 SwiftUI 的标志性特色之一，近年来不断完善的弹簧动画，又进一步提升了动画衔接的自然程度和交互表现力。作为一个响应式框架，把动画推进放在 client 端，我认为完全可以理解。当然，代价也很明确：正如 Krzysztof 的示例所示，当动画推进依赖应用进程时，它更容易受到主线程繁忙的影响，也会占用更多 client 端的计算资源。

不过，client-side animation 并不意味着所有插值计算都必须发生在主线程。随着 SwiftUI 不断演进，部分动画以及 Shape 等计算密集型工作已经可以移到后台线程，以减轻主线程的压力。不过，由于动画的推进仍然属于应用进程，异步计算也受到状态更新和渲染流程等条件的限制，因此当主线程被完全阻塞时，动画依然可能停滞。尽管存在这种“弊端”，但从 iOS 18 开始，UIKit 和 AppKit 也开始采纳这套 client-side animation 模型：新的动画 API 可以直接使用 SwiftUI 的 Animation，并由同一套动画基础设施驱动，而不再生成传统的 CAAnimation。

本次讨论呈现出一个有趣的场景：表面上在争论 SwiftUI 是否“原生”，实际展现的却是两种框架设计理念的差异。

作为苹果面向未来的 UI 框架，SwiftUI 在设计时选择走出既有路径，放弃对 Core Animation render-server animation 模型的依赖，以换取更灵活、更强大的动画表达能力。事实上，Core Animation 的创造者 John Harper 本人也是 SwiftUI 的共同创造者之一，这项选择显然不是因为不了解 Core Animation，而是在理解其优势与局限之后做出的架构决定。这还带来了一个隐形优势：SwiftUI 的部分核心能力与苹果平台的具体实现得以进一步解耦。尽管苹果并未将 SwiftUI 开源，但从架构上看，它的一些核心思想并不天然局限于苹果平台。

而从 React Native 的角度看，Krzysztof 的表述也有其合理性。作为一个跨平台框架，React Native 的重要目标之一，就是在不同平台上尽可能利用平台已经提供的能力，让应用在行为和性能上更像“本地人”。

一个最初围绕“什么才算原生”的讨论，最终引出了两边核心开发者对 UI 动画架构的理解与阐述。作为一个吃瓜群众，我也从中收获不少。

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

原创

从 pbxproj 到 xcproj：Xcode 工程配置迎来 JSON 格式

最近一直在等待 Xcode 27.1 的到来，以便在 iPhone Duo 的模拟器中测试一下应用的适配情况。有意思的是，27.1 没等到，苹果率先发布了 27.2 beta。尽管 iPhone Duo 模拟器依然缺席，但新增的 project.xcproj 令人眼前一亮。它替代的是 .xcodeproj 包里的那份构建图 project.pbxproj，而不是整个工程包。它有哪些亮点，解决了什么问题，又有哪些事情没有改变，本文将对此进行探讨。

近期推荐

为 Devin 构建云上 Mac 开发环境 (How we built Devin’s Mac)

当 AI Agent 在本地运行时，权限早已授予，工具链已经就绪，遇到弹窗也可以人工干预。搬到云端后，这些理所当然的条件都需要重新构建。换来的好处并不在于能做到本地做不到的事，而是让开发环境本身成为可以分配给 Agent 的资源：任务可以异步运行、彼此隔离，闲置时暂停并保存状态，需要时再恢复，也更容易支持多个 Agent 并行工作。Jon Kelley 在文中介绍了为 Devin 构建 macOS 云端环境的过程，涵盖基于 Virtualization.framework 的虚拟机、磁盘快照、网络隔离、环境与权限预配置、桌面与 Simulator 的实时串流，以及借助无障碍树实现的计算机操作。最后一点对苹果开发者尤其有启发：做好无障碍支持，也是在为 Agent 的自动化验证提供结构化接口。

iOS 27: CrashReportExtension Framework

传统的崩溃处理有一个棘手的问题：当 signal handler 开始工作时，它所在的进程本身可能已经处于不可靠状态，内存可能损坏、锁可能没有释放，很多平时使用的 API 也无法安全调用。iOS 27 新增的 CrashReportExtension 改变了这一执行模型。当 App 崩溃后，系统会启动一个独立的 Extension，并通过只读的 CrashedProcess 让它检查已经崩溃的进程。

Anton Gubarenko 在文中完整演示了这个扩展的创建与使用，也给出了几条务实的判断。该 API 是对系统 .ips 报告的补充而非替代，适合需要自有后端、业务上下文关联或设备端预分析的团队。扩展本身应尽量精简，只负责生成并持久化报告，上传、重试等工作交给主应用，两者通过 App Group 共享存储。对多数独立开发者而言，系统崩溃报告加上 MetricKit 依然足够。

SwiftUI 动画的运作机制 (How SwiftUI animation works)

对于动画，开发者只需改变状态并设置动画函数，剩下的工作便交给 SwiftUI。但这些声明最终是如何转化成屏幕上一帧帧连续变化的画面？Kyle Ye 从 Transaction 和 AttributeGraph 出发，结合 OpenSwiftUI 的开发经验，逐步分析 SwiftUI 如何创建动画上下文、计算中间状态，并在动画过程中持续更新视图与布局。

与将动画插值主要交给 render server 的传统方式不同，SwiftUI 的许多动画需要在应用进程中持续推进。由于插值发生在视图图内部，任何满足 Animatable 的值都能被采样，布局、Shape 等更多状态因此得以参与动画，而 render server 主要处理图层属性。文中对异步提交路径中 CABasicAnimation 的分析尤其值得一读：它只承载当前帧的采样结果，下一帧便会被替换——屏幕上出现了 CA 动画对象，并不意味着动画的时钟已经交给了 Core Animation。这也为本期周评中提到的 SwiftUI 动画是否为“原生”之争提供了更多细节。

为 iPhone Duo 准备的新 API (SwiftUI: Some New APIs/ContainerViews Useful For Duo!)

iPhone Duo 的多种使用形态给 Toolbar 带来了新的挑战。为了充分利用更宽的屏幕并保留纵向内容空间，系统会在部分形态下将原本位于顶部和底部的控件移到屏幕侧边。但传统 Toolbar 中的文本按钮、自定义视图等内容并不一定适合纵向排列，Toolbar 与 Tab Bar 还可能需要争夺有限的侧边空间。iOS 27.1 为此增加了 ToolbarItemAxisBehavior、ToolbarVerticalBehavior、ToolbarVerticalCompressionBehavior 和 toolbarVerticalEdge 等 API，让开发者可以进一步控制 Toolbar 的方向、位置以及空间不足时的压缩策略。⁠Itsuki 通过代码和演示展示了这些新 API 的具体行为。

这批 API 的共同特征，是让开发者声明偏好而非指定结果。面对 Duo 带来的多种形态，与其针对特定设备状态编写布局，不如描述内容之间的关系和布局偏好，再由 SwiftUI 根据实际环境决定最终呈现方式。

iPhone Duo 上的 Sheet 与折痕规避 (Sheets and fold avoidance on iPhone Duo)

当 iPhone Duo 处于部分折叠状态时，中央折痕形成了一块不适合交互的区域，按钮等控件如果恰好落在这里，会变得难以操作。⁠Sarun Wongpatcharapakorn 以 Sheet 为例，展示了同一个界面如何在 Duo 的关闭、展开、横屏、竖屏以及部分折叠等不同形态下调整尺寸、位置和 Toolbar。Sheet、Alert 和菜单等系统组件已经内置折痕规避能力，无需开发者干预。因此对于开发者而言，优先使用系统组件，也意味着可以直接获得这些针对不同设备形态的自适应行为。

工具

Vapor 5 Beta 发布

在 Vapor 诞生十周年、距离 Vapor 4 发布六年半之际，社区终于迎来了 Vapor 5 的首个 Beta 版本。此次几乎是一次彻底重写——历时两年、变更约 49,000 行代码。最核心的改动是彻底告别 EventLoop 与 EventLoopFuture，全面转向 Swift Concurrency，并以结构化并发为基础，NIO 也基本从公开 API 中隐去。

同时，Vapor 5 进一步整合 Swift HTTP Types、Swift Configuration 和 Swift Service Lifecycle，并加入实验性的 VaporMacros，为路由和认证提供更多编译期类型检查。Vapor 5 要求 Swift 6.4，目前仍处于 Beta 阶段。有关更多变化，可以查看 ⁠Tim Condon 的 ⁠What’s New in Vapor 5 Beta。

Hinge：命令行调节 Duo 模拟器折叠角度

Xcode 27.1 的 Device Hub 可以调整 iPhone Duo Simulator 的折叠角度（按住 Option 键可见），但 simctl 和 devicectl 并没有提供对应的控制命令。⁠Artem Novichkov 开发的 Hinge 补上了这个缺口，可以通过命令行设置 0–180° 的折叠角度，也支持打开、关闭、半折叠以及连续改变角度等操作。Hinge 还提供了 Agent Skill，让 Coding Agent 可以在测试过程中主动改变 Duo 的折叠状态并验证 App。

Enriched Markdown：不依赖 WebView 的跨平台 Markdown 渲染与编辑方案

在移动端实现 Markdown，常见方案是套一层 WebView。Software Mansion 推出的 Enriched Markdown 选择了一条更彻底的路线：基于各平台的原生文本能力完成 Markdown 渲染与富文本编辑，并可以将编辑后的内容重新输出为干净的 Markdown。

它提供独立的 SwiftUI SDK，基于 TextKit 2 与 md4c 实现 Markdown 渲染，同时也覆盖 React Native、Android 和 Web。相比单纯追求“能显示 Markdown”，Enriched Markdown 更重视原生体验：文本可以正常选择，链接、图片与代码块能够接入系统菜单，并适配 VoiceOver、TalkBack、动态字体和从右到左书写（RTL）。

The Opportunities and Challenges of iPhone Duo

Read on web →

Although some details of the iPhone Duo’s design had already leaked months ago, and Apple is a latecomer to the foldable phone market, its ability to tightly integrate hardware and software—and the interaction changes that integration enables—still managed to surprise quite a few consumers.

Different research firms have offered forecasts for the iPhone Duo’s early sales using different time frames. Counterpoint expects shipments to reach as many as 6 million units by the end of 2026, while IDC estimates that the device could reach around 10 million units in its first 12 months on the market. That would still represent only a small fraction of total iPhone sales. But compared with the hundreds of thousands of Vision Pro units sold over its first two and a half years, it is already a large enough market to support quite a few apps designed specifically for this device. Over the past few days, I’ve already seen plenty of creative ideas on social media built around the Duo’s form factor. If even a few of them turn into breakout hits, they could further drive device sales. More importantly, the Duo has far greater social visibility than Vision Pro. The sense of being “different” that comes from distinctive hardware paired with distinctive apps is exactly what many early adopters of products like this are looking for.

For most developers, however, the adaptation pressure created by the iPhone Duo’s unique form factor is very real. The Duo has both outer and inner displays, while the inner display can be used fully open, partially folded, and in other poses. It is arguably one of the most challenging devices in the iPhone family to design for. Apple does provide a number of APIs specifically for adapting to these configurations, and standard containers already handle different poses reasonably well. But those things mainly solve the UI problem. The real challenge is UX: an API can tell you how much space is available and where the hinge is, but it cannot tell you what users actually want to see when the device is partially folded. Every additional pose means another experience that needs to be designed.

For teams using third-party frameworks such as Flutter and React Native, the problem starts one step earlier: it is not just about how well you can adapt, but whether you can access the necessary information in the first place. Flutter’s MediaQuery.displayFeatures returns an empty list on the Duo regardless of the fold angle, while React Native still provides no official API for accessing fold state. Once the hardware itself becomes part of the interaction model, cross-platform frameworks have to make more tradeoffs between hiding platform differences and exposing platform capabilities. And those tradeoffs are difficult for a framework to absorb on its own—it will always lag behind the platform.

In fact, the trend toward reevaluating cross-platform approaches had already begun before the Duo was announced, driven by several changes happening at the same time. AI coding agents have substantially reduced the cost of native development and maintenance, while changes such as Liquid Glass and Duo continue to raise the value of taking full advantage of platform-specific capabilities. The cost-benefit equation for cross-platform development is being squeezed from both directions. Notion is migrating its Apple-platform UI from a web-based technology stack to SwiftUI. Around the same time, Shopify announced that it was moving its mobile apps from React Native back to Swift and Kotlin. One reason it cited was that advances in coding models are eroding one of the key cost advantages of cross-platform development: avoiding having to “build the same feature twice.” Alongside that transition, Shopify is also handing off its React Native open-source libraries.

For the Apple ecosystem, iPhone Duo is a product that brings genuine change. Over the past few years, most changes to Apple’s platforms have taken place in software and design language. Duo, by contrast, changes the physical form factor developers have to design for. Its significance to the ecosystem may not lie in selling a few million more devices, but in what happens when the device itself once again becomes part of application design: “using the platform’s native frameworks” is starting to shift from a matter of preference to a matter of cost.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

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

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

Module Tracking in Swift Debug Info

Have you ever hit a breakpoint, typed a seemingly trivial LLDB expression, and then waited... and waited? To evaluate a computed property or call a method, LLDB sometimes has to spin up the Swift compiler and locate and load the relevant modules. In the past, that lookup couldn’t always find the exact module your code was built from, and it might even recompile some dependencies along the way, turning a simple debugging step into a long pause.

Adrian Prantl introduces Module Tracking, a mechanism that began in Swift 6.3 and is further refined in 6.4. The new approach lets debug info tell LLDB precisely: “these are the modules the build actually used, and here is where they live,” cutting out unnecessary searching and recompilation. Swift 6.4 also improves bridging header handling and noticeably slims down debug artifacts — dSYM bundles on Darwin no longer carry binary Swift modules, and binaries built with debug info on Windows and Linux benefit as well.

New Hashable conformances in Swift 6.4

Artem Mirzabekian walks through several standard library types that gain Hashable conformance in Swift 6.4, coming from two proposals: SE-0514 (Dictionary.Keys, CollectionOfOne, EmptyCollection) and SE-0523 (UnownedTaskExecutor). The one closest to everyday development is Dictionary.Keys, which can now go straight into a Set or serve as a dictionary key without first being converted to another type.

The semantics are worth noting: two Dictionary.Keys values are equal as long as they contain the same keys — order participates in neither comparison nor hashing, which is consistent with how a dictionary’s own identity is defined. Dictionary.Values did not receive the same treatment, because values can repeat, and expressing that correctly would require multiset semantics that Swift doesn’t currently have. A small piece of completion work, but one that makes these types sit more naturally in generic and collection contexts.

How to list big models cheaply: Vein vs SwiftData

Two weeks ago, in SwiftData: Optimization Starts with Modeling, I discussed the memory and performance pressure that “fat models” put on SwiftData lists, and tried to reduce how much data a single query actually loads by splitting the model. Mia Köring took the benchmark code from that article and used it to show how Vein, the persistence framework she is building, performs with field-level lazy loading.

Vein declares models much the way SwiftData does, and by default behaves similarly too: properties are eagerly loaded, relationships lazily. The difference is that marking a property with @LazyField defers reading it until it is actually accessed. As a result, in a “title-only list” scenario, Vein reaches good numbers without any model splitting at all.

Sad But True: Localized App Store Screenshots That Verify Themselves

Automation keeps working its way into every stage of app development. But in practice, the hard part often isn’t implementing the automation — it’s getting it to prove that it did the right thing.

While generating localized App Store screenshots automatically, Wesley Matlock discovered that his Spanish screenshots had quietly fallen back to English, while the entire test run still reported success. The cause turned out to be -testLanguage not reliably reaching the app under Xcode 27. Wesley switched to setting the simulator’s language through simctl, and added a check that compares the SHA-256 of the captured screenshots to catch cases where two languages, or two different screens, unexpectedly produce byte-identical images.

Wesley’s screenshot-hashing approach transfers to any pipeline where you hand a request to a black box and then accept whatever comes back at face value.

Transition or ContentTransition

transition and contentTransition have remarkably similar names, but they solve two different problems: the former animates a view being inserted into or removed from the view hierarchy, the latter applies when the view stays put and only the content it displays changes. Stewart Lynch compares them side by side using conditional views, changing numbers, and SF Symbols, and covers common content transitions such as .numericText, .interpolate, and .symbolEffect.

SwiftUI has supported custom transition values for a long time, but that capability has never extended to higher-level scenarios like sheets or navigation changes. Those situations resemble contentTransition, and still rely mostly on the handful of transitions the system provides. It would be good to see SwiftUI eventually connect these different levels of the transition concept — or at least give developers more room to customize them.

Abstracting SwiftUI state with scopes

When a SwiftUI view holds several @State properties, we often abstract them into a single @Observable. But what if the view also depends on environment values or other Observable instances? Is there a way to organize state coming from different sources while reducing the view’s coupling to any particular one of them? Mike Apurin proposes thinking in scopes: his library ScopedState gathers multiple state sources behind a unified access boundary, exposing to a view only the state and actions that screen genuinely needs. The view doesn’t need to know where any of it comes from, and swapping the data source in previews and tests becomes much easier. Worth noting: this isn’t an attempt to build yet another state management model along the lines of TCA or MVVM — it’s a way of organizing and abstracting existing state sources at the view layer.

Before the Fold: Adapting for iPhone Duo

The arrival of iPhone Duo has consumers marveling at the new form factor, and developers facing a new set of challenges: how to make use of the extra display space, how to make existing layouts adapt across device configurations, and how to take advantage of new interaction capabilities like the fold and multiple display regions. Over the past week, a number of writers offered their perspectives.

• Apple published six Tech Talks on announcement day: Design for iPhone Duo, Prepare your app, Raise the bar, Strike a pose with adaptive layouts, Leverage multiple displays and scenes, and Build a great camera experience, along with a new Designing for iPhone Duo page in the HIG.

• Florian Schweizer makes the case for not fighting the framework: don’t start by asking whether the device is an iPhone Duo, ask how much space this view has been given. He has also distilled these principles, along with Duo’s new APIs and Apple’s developer material, into a SwiftUI iPhone Duo Skill for coding agents working on existing apps.

• Lee young-jun approaches it from hands-on adaptation work, using NavigationSplitView, sidebarAdaptable, and Device Hub’s Resizing Mode to inspect and improve how an app behaves across iPhone Duo’s different display configurations ahead of time.

• Sagar Unagar draws on Apple’s latest HIG and developer material to summarize the main design principles for iPhone Duo: adaptive layout, system controls, the fold region, and the various display configurations.

• Jordan Morgan rounds up the changes developers should look at first — layout, system bars, safe areas, camera, and multiple display regions.

• Artem Mirzabekian introduces the new ArrangementView, which lets you describe the relationship between two related pieces of content and leaves it to SwiftUI to pick a suitable layout based on available space and the fold region.

Many of the features covered above exist only in Xcode 27.1, so experiencing them in full will take a little while yet.

Tools

SwiftMusic: Declaring Music in Swift

SwiftMusic, from Norikazu Muramoto, is a declarative music composition framework for Apple platform developers. It borrows SwiftUI’s design sensibility, bringing familiar Swift constructs — Music, Sound, body, result builders, and modifiers — into music creation, so that rhythm, melody, harmony, timbre, effects, and mixing relationships can all be described by composing code.

Drums, bass, and synths, for instance, can be written as Swift code that reads musically:

struct Session: Music {
      var body: some Sound {
          Track(”Drums”) {
              Sample(”kick”)
                  .rhythm(”x ~ x ~”)
          }
​
          Track(”Bass”) {
              Synthesizer(.saw)
                  .notes(”C2 ~ Eb2 G2”)
                  .gain(0.3)
          }
      }
  }

SwiftMusic makes no sound on its own: it only compiles your declarations into beat-domain events and an ordered render plan. It neither opens an audio device nor draws an editor — actual audio rendering is the host’s responsibility. The author provides MusicPlaygournd, a live editor for macOS, to fill that role.

Homebrew 7: The Release That Says Goodbye to Intel

Homebrew 7.0.0 is out. Alongside a range of features and internal changes, this major release brings compatibility changes worth paying attention to. On Apple Silicon Macs, macOS 15–27 currently falls within the fully supported range, while Intel Macs have all been moved down to Tier 3 — no full CI support, no new bottles, and a plan to end support entirely in or after September 2027. If you are still running Homebrew on an Intel Mac or an older version of macOS, this one deserves a closer look.

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

Share

iPhone Duo 带来的机遇与挑战

网页版

尽管 iPhone Duo 的设计资料早在几个月前就已部分泄漏，而且苹果也是折叠机领域的后来者，但凭借软硬件整合能力，它所带来的交互变化还是给不少消费者带来了惊喜。

不同机构对 iPhone Duo 的初期销量给出了不同口径的预测：Counterpoint 预计其 2026 年内出货量最高约 600 万部；IDC 则预计上市后前 12 个月可能达到约 1000 万部。在整个 iPhone 销量中，这仍然只占一小部分，但与 Vision Pro 上市两年半的几十万销量相比，这个数量已经足以支撑不少特别针对这款设备开发的应用了。这几天，我已经在社交媒体上看到不少针对 Duo 形态的创意，相信一旦其中出现几个爆款，也会进一步推动设备的销量。尤其是，Duo 相比 Vision Pro 具备更强的社交展示性，特别的硬件、特别的应用所带来的“特别感”，正是不少首批购买这类产品的用户所追求的。

但对于更多开发者来说，iPhone Duo 独特形态带来的适配压力也是真实的。Duo 包括内外两块屏幕，内屏又可以以展开、半折叠等多种姿态存在，可以说是 iPhone 家族中适配难度最高的产品之一。苹果确实提供了不少有针对性的适配 API，标准容器在各种姿态下也已基本自适应，但这些只解决了 UI 层面的问题。真正难的是 UX：API 能告诉你可用空间有多大、铰链落在哪里，却无法告诉你半折叠时用户究竟想看到什么。多一种姿态，就多一次需要重新设计的体验。

对于使用 Flutter、React Native 等第三方框架的团队，问题还要更靠前一步：不是适配得好不好，而是拿不拿得到信息。Flutter 的 MediaQuery.displayFeatures 在 Duo 上无论折叠到什么角度都返回空列表，React Native 则至今没有任何与折叠状态相关的官方 API。当硬件本身开始成为交互的一部分，跨平台框架就必须在屏蔽平台差异与暴露平台能力之间做出更多取舍，而这种取舍很难由框架单方面消化——它总是滞后于平台。

事实上，在 Duo 发布之前，重新评估跨平台方案的趋势就已经出现，其背后是一组正在同时发生的变化：AI Coding Agent 大幅降低了原生开发与维护的成本，而 Liquid Glass、Duo 这样的变化又在不断抬高用足平台特性的价值。跨平台方案的性价比，正被这两头同时挤压。Notion 正在将基于 Web 技术栈的苹果端 UI 迁移到 SwiftUI；Shopify 则在几乎同一时间宣布将移动端从 React Native 迁回 Swift 与 Kotlin，理由之一是编码模型的进步正在削弱“避免把同一个功能造两遍”这一跨平台开发的重要成本优势。与之一并发生的，是它对旗下 React Native 开源库的交接。

对于苹果生态来说，iPhone Duo 是一个真正带来变化的产品。过去几年，苹果平台的变化更多发生在软件和设计语言上，而 Duo 则重新改变了开发者面对的硬件形态。它的生态意义或许并不在于多卖出几百万台设备，而在于当设备本身再次成为应用设计的一部分时，“使用平台原生框架”这件事，正在从一道偏好题变成一道成本题。

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

近期推荐

调试卡顿的根源：Swift 如何追踪 Module (Module Tracking in Swift Debug Info)

你是否碰到过这样的情况：一个看似简单的 LLDB 表达式，在断点调试时却迟迟没有反馈？为了计算属性、调用方法等操作，LLDB 有时需要启动 Swift 编译器，并寻找和加载相关 Module。过去这套过程并不总能准确找到构建时实际使用的 Module，甚至可能重新编译部分依赖，让一个原本简单的调试操作变成长时间等待。

Adrian Prantl 介绍了一个从 Swift 6.3 开始引入、并在 6.4 中进一步完善的机制：Module Tracking。新的机制让调试信息能够更明确地告诉 LLDB：”构建时用的就是这些 Module，它们就在这里”，从而减少不必要的寻找和重新编译。Swift 6.4 还会改善 bridging header 的处理，并让调试产物明显瘦身——Darwin 上的 dSYM 不再打包二进制 Swift Module，Windows 与 Linux 上带调试信息的二进制同样受益。

Swift 6.4 中补齐的几处 Hashable (New Hashable conformances in Swift 6.4)

Artem Mirzabekian 介绍了 Swift 6.4 中几个新增 Hashable 支持的标准库类型，它们分别来自 SE-0514（Dictionary.Keys、CollectionOfOne、EmptyCollection）和 SE-0523（UnownedTaskExecutor）。其中最贴近日常开发的是 Dictionary.Keys：现在可以直接放入 Set 或作为 Dictionary 的 key，而不必先转换成其他类型。

值得留意它的语义：两个 Dictionary.Keys 只要包含相同的键就视为相等，顺序不参与比较与哈希——这与字典本身的身份认定是一致的。Dictionary.Values 没有一并获得该能力，因为值可以重复，需要的是 Swift 目前没有的多重集合语义。虽然只是一次小幅补全，但也让这些类型在泛型和集合场景中的使用更加自然。

Vein 中的惰值性能 (How to list big models cheaply: Vein vs SwiftData)

两周前我在 SwiftData：优化从建模开始 中讨论了“胖模型”给 SwiftData 列表带来的内存和性能压力，并尝试通过模型拆分减少一次查询真正加载的数据。Mia Köring 使用了我文章中的测试代码，展示了她开发的 Vein 持久化框架在字段级惰性加载下的表现。

Vein 采用了与 SwiftData Model 类似的声明方式，默认同样是属性预加载、关系惰性加载；不同之处在于，给某个属性标注 @LazyField 后，它会推迟到真正被访问时才去读取。因此在“只显示标题”的列表场景中，无需拆分模型也能取得不错的成绩。

让自动化自己证明它做对了 (Sad But True: Localized App Store Screenshots That Verify Themselves)

自动化被越来越多地应用到 App 开发的各个环节，但有时实践中的难点并非如何实现自动化，而是如何让它自己证明“我做对了”。

Wesley Matlock 在通过自动化方式为 App Store 生成多语言截图时，发现西班牙语截图悄悄回退成了英文，而整个测试流程依然通过。检查后发现，原因来自 Xcode 27 下 -testLanguage 没有可靠地应用到 App。Wesley 随后改用 simctl 设置 Simulator 的语言，并通过比较截图的 SHA-256，自动检查不同语言或不同页面是否意外生成了完全相同的图片。

Wesley 基于截图哈希的比较思路可以迁移到任何“把请求交给黑盒、再把产出照单全收”的流程里。

Transition or ContentTransition

transition 和 contentTransition 名字很像，但解决的是两类不同的问题：前者用于 View 被插入或移出视图层级时的动画，后者则用于 View 仍然存在、只是显示内容发生变化的情况。Stewart Lynch 通过条件视图、数字变化和 SF Symbols 等例子对两者进行了直观比较，并介绍了 .numericText、.interpolate、.symbolEffect 等常用的内容过渡效果。

在 SwiftUI 中，transition 很早就支持自定义，但这种能力始终没有延伸到 Sheet、导航切换等更高层级的场景。这些场景与 contentTransition 类似，目前仍主要依赖系统提供的有限几种过渡方式。期待未来 SwiftUI 能进一步打通这些不同层级的 transition 概念，或者至少为开发者提供更多自定义空间。

用 Scope 为视图状态划一条边界 (Abstracting SwiftUI state with scopes)

在 SwiftUI 中，如果视图中有多个 @State，我们可能会将它们抽象到一个 @Observable 中。但如果视图还依赖其他环境值或其他 Observable 实例呢？是否有一种方式，可以将来自不同数据源的状态组织到一起，同时减少视图对具体数据源的耦合？⁠Mike Apurin 提出了 Scope 思路：通过他开发的 ⁠ScopedState 将多个状态源组织到统一的访问边界中，只向 View 暴露当前界面真正需要的状态和操作。View 无需了解这些状态实际来自哪里，也更容易在 Preview 和测试中替换数据来源。需要注意的是，这并不是试图创建另一套类似 TCA 或 MVVM 的状态管理模型，而是一种作用于 View 层级、对现有状态源进行组织和抽象的方式。

折叠之前：iPhone Duo 适配

iPhone Duo 的推出让消费者在惊叹设备形态变化的同时，也给开发者带来了新的挑战：如何利用更大的显示空间，如何让现有布局适应不同的设备形态，以及如何利用折叠、多显示区域等新的交互能力。上周，不少内容创作者都从不同角度给出了自己的建议。

• 苹果在发布当天放出了六个 Tech Talk：Design for iPhone Duo、Prepare your app、Raise the bar、Strike a pose with adaptive layouts、Leverage multiple displays and scenes、Build a great camera experience，并在 HIG 中增加了 Designing for iPhone Duo 一页。

• ⁠Florian Schweizer 强调“不要与框架对抗”：不要从判断“是不是 iPhone Duo”开始，而应该问“这个视图拿到了多少空”。他还将这些原则以及 Duo 的新 API、Apple 开发者资料整理成了一个 ⁠SwiftUI iPhone Duo Skill，供 Coding Agent 在适配现有 App 时使用。

• ⁠Lee young-jun 从现有 App 的实际适配出发，通过 NavigationSplitView、sidebarAdaptable、Device Hub 的 Resizing Mode 等方式，提前检查和改善 App 在 iPhone Duo 不同显示形态下的表现。

• ⁠Sagar Unagar 根据 ⁠Apple 最新的 HIG 和开发者资料，梳理了 iPhone Duo 在自适应布局、系统控件、折叠区域以及不同显示形态下的主要设计原则。

• ⁠Jordan Morgan 总结了开发者首先需要关注的布局、系统栏、safe area、相机以及多显示区域等变化。

• ⁠Artem Mirzabekian 介绍了新的 ArrangementView，开发者可以描述两组相关内容之间的关系，让 SwiftUI 根据可用空间和折叠区域自动选择合适的布局方式。

上面介绍的功能不少都只存在于 Xcode 27.1 中，想完整体验还需要一段时间。

工具

SwiftMusic：用 Swift 声明音乐

Norikazu Muramoto 开发的 SwiftMusic 是一套面向 Apple 平台开发者的声明式音乐创作框架。它借鉴了 SwiftUI 的设计理念，将 Music、Sound、body、Result Builder 和 Modifier 等熟悉的 Swift 表达方式带入音乐创作，让节奏、旋律、和声、音色、效果器和混音关系都可以通过组合代码来描述。

例如，鼓点、贝斯和合成器可以直接写成具有音乐含义的 Swift 代码：

struct Session: Music {
      var body: some Sound {
          Track(”Drums”) {
              Sample(”kick”)
                  .rhythm(”x ~ x ~”)
          }
​
          Track(”Bass”) {
              Synthesizer(.saw)
                  .notes(”C2 ~ Eb2 G2”)
                  .gain(0.3)
          }
      }
  }

SwiftMusic 本身并不发声：它只把声明编译成节拍域事件与渲染计划，既不打开音频设备，也不绘制编辑器，实际的音频渲染由宿主负责——作者另外提供了 macOS 端的实时编辑器 MusicPlaygournd 来承担这部分工作。

Homebrew 7：一次告别 Intel 的大版本

Homebrew 7.0.0 正式发布，除了多项功能和内部实现调整，本次大版本也带来了值得关注的兼容性变化。目前 Apple Silicon Mac 上的 macOS 15–27 属于完整支持范围，而 Intel Mac 已全部降为 Tier 3，不再获得完整 CI 支持和新的 bottles，并计划在 2027 年 9 月或之后彻底停止支持。仍在 Intel Mac 或较旧 macOS 上使用 Homebrew 的开发者需要特别留意。

When the Mac mini’s Price Is No Longer Mini

Read on web →

Late last month, Apple released the new Mac mini and Mac Studio. Alongside the impressive performance upgrades, the noticeably higher prices were just as striking. Rising memory and storage costs are undoubtedly a major factor, but in the AI era, developers’ hardware needs are also quietly changing. More memory and more storage keep raising our idea of what counts as a “good enough” configuration—and pushing the price we actually pay even higher.

Over the past few months, one of the biggest annoyances in my development work has been the constant noise of my MacBook Pro’s fans. For years, I would only really notice them under a handful of heavy workloads. But in the age of AI agents, having the fans running has become almost routine. Limited by the space inside a laptop and the size of its fans, the noise under sustained load also tends to be more noticeable—and more irritating—than on a desktop machine like the Mac mini.

At the same time, I’ve realized that the MacBook no longer feels as indispensable to my workflow as it once did. Unless I have a specific need, a phone and a tablet are already enough for quite a few Vibe Coding scenarios on short trips. Even when I do need a laptop, a lighter and less powerful model would probably be more than sufficient. So I’ve started seriously considering moving my primary development environment from a MacBook Pro to a Mac mini or Mac Studio.

That brings up another problem: for a primary development machine, memory capacity is a hard requirement. I have almost no need to run LLMs locally, but if I’m upgrading my computer, the new machine needs to offer meaningfully more than the 64GB I already have for the upgrade to feel worthwhile. That essentially rules out the M5 Pro Mac mini, leaving me with the M5 Max and M5 Ultra Mac Studio.

Interestingly, the next memory tier above 64GB is 128GB on one and 96GB on the other, yet the final prices are remarkably close. One gives me more memory; the other, a more powerful chip. I’m not usually someone who struggles to make a choice, but this one has genuinely left me undecided.

Meanwhile, OpenClaw’s popularity has drawn the attention of many consumers who previously had little interest in the Mac mini. OpenAI has also reportedly purchased tens of thousands of Mac minis and Mac Studios for reinforcement learning and training computer-use agents. AI-driven demand at one point grew far faster than Apple had anticipated. Combined with pressure on memory supply and advanced chip manufacturing capacity, this has kept the Mac mini and Mac Studio in short supply over the past few months. Even with the new generation now available, getting the exact configuration you want quickly is still not necessarily easy.

The productivity gains brought by AI may not yet be fully visible across society, but its appetite for compute, memory, and storage resources is already showing up in the hardware market. From components to complete systems, a wide range of consumer hardware is facing new pricing pressure. The old upgrade cycle—waiting a few years and spending roughly the same amount for a substantially more powerful computer—seems increasingly difficult to sustain, at least for now.

But there’s another side to the story: we can’t blame everything on rising prices. While AI is pushing hardware costs upward, it is also changing how we develop software and quietly raising our definition of what counts as a “good enough computer.” Hardware has become more expensive, but we’ve also started asking more of it.

Hopefully, one day we’ll get back to a time when buying a Mac mini doesn’t require quite so much mental preparation.

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

SwiftData: Optimization Starts with Modeling

Once the dataset grows large, SwiftData lists start to lag. This is one of the performance complaints I’ve heard most often over the past few years. Developers’ first instinct is usually to blame SwiftUI’s List. It certainly bears some responsibility, but it isn’t the main culprit. A closer look reveals that long loading times aren’t the only thing dragging down performance—massive memory consumption is just as important. In this article, I’ll explore why these problems arise in SwiftData and why optimization should start with data modeling.

Some capabilities that appear to be missing from SwiftData may actually have been left out intentionally, reducing the learning curve by exposing fewer APIs and abstraction layers. Therefore, when optimizing SwiftData applications, it’s also worth letting go of some habits carried over from the Core Data era.

Recent Recommendations

The End of Swift Talk

After ten years and 500 episodes, Chris Eidhof and Florian Kugler have announced the end of Swift Talk. Since its launch in June 2016, Swift Talk has accompanied Swift through nearly its entire journey toward maturity, while also witnessing SwiftUI grow from its introduction into a core UI framework for Apple platform development. Through a long series of deep and highly experimental episodes, the two explored Swift, SwiftUI, layout, animation, concurrency, and many lower-level topics rarely covered in conventional tutorials. They hope to make the complete archive of more than 500 episodes available to the community by the end of this year.

For me, objc.io and Swift Talk have always occupied a very special place in the Swift community. Chris and Florian were rarely satisfied with simply telling developers how an API “should be used.” Instead, they would experiment, refactor, and sometimes even reimplement things to understand why a framework works the way it does. This approach to exploration has influenced many Swift developers, myself included. Thank you, Chris and Florian, for the time, knowledge, and curiosity you’ve contributed to the Swift community over all these years, and for the invaluable archive Swift Talk leaves behind.

What’s new in Swift: August 2026 Edition

Swift has published its August ecosystem update, curated by Simon Leeb and Dave Lester, covering noteworthy community projects, package updates, and Swift Evolution developments. What interests me most is Swift’s progress on the Web: Simon Leeb demonstrated a Full-Stack Swift on Cloudflare Demo, with Swift running in the browser through ElementaryUI and WebAssembly, a backend running on an edge worker, and message types shared between the two sides. From Embedded Swift and Wasm to an increasingly capable cross-platform toolchain, Swift continues to expand its reach beyond Apple platforms.

At the language level, the recently accepted Iterable is also worth watching. Sequence produces independent element values one by one during iteration, but this model doesn’t work for data structures such as Span and InlineArray that may contain non-copyable elements. Iterable allows elements to be borrowed rather than copied during iteration, giving these data structures a natural way to be traversed as well. It may look like just another iteration abstraction, but it is also another sign of Swift’s ownership capabilities gradually moving from the language’s lower levels into everyday API design.

OpenSwiftUI on ESP32-C3

The Swift update above showed how Swift continues to push beyond the boundaries of Apple platforms, and a recent experiment by OpenSwiftUI developer Kyle Ye provides a very tangible example of that trend. After receiving an ESP32-C3 development device from TraeAI, Kyle completed his first Embedded Swift project: deploying an embedded version of OpenSwiftUI to this RISC-V-based microcontroller. On its 240 × 320 LCD, he built interfaces using familiar APIs such as View, @ViewBuilder, Text, Image, VStack, HStack, and ZStack. Even @State can respond to physical button input and trigger UI updates.

The experiment uses Embedded Swift to compile native RISC-V code, with OpenSwiftUI handling view composition and layout before passing drawing through a thin rendering boundary to LVGL and the underlying hardware. In other words, a lean but complete UI pipeline has been established, from declarative views and layout calculation to state updates and final pixel output.

Multiplatform Swift, with C++ dependencies via XCFramework, apt and vcpkg

Whether a Swift application can truly become cross-platform often depends on whether its underlying C/C++ dependencies can make the journey as well. Harald Achitz uses his own ZeroMQ Swift bindings as an example to show how a Swift/C++ project targeting macOS, Linux, and Windows can organize its native dependencies: XCFrameworks on Apple platforms, system packages on Linux, and vcpkg to install ZeroMQ on Windows.

Connecting two iOS simulators over BLE

CoreBluetooth is completely unavailable in the iOS Simulator, which has long made BLE app development and testing dependent on physical devices. While developing BLESwift 2.0, Kyle Browning took a different approach: instead of calling CoreBluetooth, the central and peripheral devices in the Simulator forward their operations over localhost TCP to bleswift-provider running on the Mac, which creates a “virtual radio.” This allows two Simulators to discover, connect to, read from, write to, and receive notifications from each other much like two real BLE devices. A passthrough mode can even use the Mac’s Bluetooth hardware to communicate with real BLE devices.

What interests me more than BLE itself is the testing pattern behind this approach: when the Simulator lacks a particular system or hardware capability, instead of scattering mocks throughout the app, we can establish a replaceable backend between system capabilities and business logic, then use a proxy process on the Mac to recreate a controllable external world. This design not only addresses missing system or hardware capabilities in the Simulator, but also makes features that once depended heavily on real-world environments much easier to bring into automated testing and CI.

Reorder all the things in SwiftUI

SwiftUI has long lacked a general-purpose API for drag-to-reorder interactions in arbitrary containers, a limitation that was finally addressed after WWDC 2026. Alexander Logan introduces SwiftUI’s new reordering APIs. With APIs such as reorderable and reorderableContainer, developers can directly declare which content can be reordered and its associated data model. Reordering is no longer limited to List, nor do developers need to manage drop positions and data updates themselves through DropDelegate. More importantly, the new APIs provide a higher-level interaction semantic, separating “reordering” from drag and drop as a specific implementation mechanism. Developers describe the intent that “this content can be reordered,” while the system can take greater responsibility for whether that interaction is performed with a mouse, touch, or another input method.

Building a sunburst diagram in Swift Charts

A Sunburst Diagram is a chart that uses concentric rings to represent hierarchical data—for example, moving from “Work” to “Development” and then to a specific project, with each outward ring representing a deeper level of detail. Matthaus Woolard demonstrates how to use Swift Charts’ SectorMark to start with a regular pie chart and gradually build a three-level sunburst diagram. The implementation also nicely demonstrates the flexibility of Swift Charts: when the framework doesn’t directly provide a particular chart type, Marks such as SectorMark can be treated as lower-level visualization primitives, allowing more complex charts to be constructed by calculating angular ranges and data mappings manually.

Tool

CoreDataBrowser: Quickly Inspect Local Data in the Simulator

When debugging Core Data or SwiftData apps, you typically need to locate the relevant data files buried deep within the Simulator’s directory hierarchy, then open them in a SQLite manager to inspect the data. CoreDataBrowser, developed by Csaba Turdesan, aims to simplify this process: after selecting the currently running Simulator, it automatically locates Core Data, SwiftData, and UserDefaults data sources in app containers and presents them together in a native macOS interface.

CoreDataBrowser supports browsing tables and records, searching and highlighting matches, and attempting to decode certain binary data (BLOBs) as NSKeyedArchive, JSON, Property List, or UTF-8 text. The tool is tiny (2.5 MB), and its source code is publicly available.

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

Share

当 Mac mini 的价格不再 mini

网页版

上月底，苹果发布了新的 Mac mini 和 Mac Studio。除了强悍的性能更新，明显上涨的价格同样给人带来了不小的震撼。内存与存储成本上涨无疑是本轮涨价的重要原因，但在 AI 时代，开发者对硬件的需求也在悄然发生变化。更大的内存、更高的存储容量，不断推高我们心目中“够用配置”的标准，最终也让实际购买价格变得更加夸张。

过去几个月，开发中最让我头痛的一件事，是 MacBook Pro 风扇持续转动带来的噪音。过去多年的使用中，只有在少数高负载场景下，我才会明显意识到风扇的存在。但到了 AI Agent 时代，风扇常转几乎成了家常便饭。受限于机身空间和风扇尺寸，笔记本在持续高负载下产生的噪音，往往也比 Mac mini 这类桌面设备更容易让人感到不适。

与此同时，我发现 MacBook 在自己的工作流中似乎也没有以前那么不可替代了。除非有特殊需要，短途出差时，手机和平板已经足以应付不少 Vibe Coding 场景。即便仍然需要一台笔记本，一台更轻、配置更低的设备似乎也完全够用。因此，我开始认真考虑把主力开发设备从 MacBook Pro 转移到 Mac mini 或 Mac Studio 上。

问题随之而来：作为主力开发设备，内存容量必然是一道硬门槛。尽管我几乎没有运行本地 LLM 的需求，但既然是一次设备更新，新机器的内存至少应该明显高于当前的 64GB，才能让我感受到足够的升级价值。如此一来，采用 M6 或 M5 Pro 的 Mac mini 基本就被排除了，剩下的选择只有 M5 Max 和 M5 Ultra 的 Mac Studio。

有趣的是，两款机型在 64GB 之上的下一档内存分别是 128GB 和 96GB，而最终价格却相差无几。一个给更多内存，一个给更强芯片。即便我平时并不算有选择困难，这次也确实有些犯难。

与此同时，OpenClaw 的风行让不少原本并不关注 Mac mini 的消费者开始将目光投向这台小机器。据报道，OpenAI 也采购了数万台 Mac mini 和 Mac Studio，用于强化学习和 Computer-use Agent 的训练。AI 带来的需求增长一度远超苹果的预期，再加上内存供应和先进制程产能的压力，让 Mac mini 和 Mac Studio 在过去几个月一直处于供不应求的状态。新一代产品发布之后，想要尽快拿到自己心仪的配置，依然不是一件容易的事。

AI 带来的效率提升或许还没有在整个社会中充分显现，但它对算力、内存和存储资源的争夺，已经率先反映到了硬件市场。从零部件到整机，大量消费级硬件都在承受新的价格压力。过去那种隔几年用差不多的钱，就能买到一台明显更强电脑的更新节奏，至少在现阶段似乎越来越难维持了。

但更有意思的是，我们又不能把这一切完全归咎于涨价。AI 在推高硬件成本的同时，也改变了我们的开发方式，并悄悄抬高了我们对一台“够用电脑”的定义。硬件变贵了，我们想要的也更多了。

希望未来某一天，我们还能找回那个不用做太多心理建设，就能轻松选购一台 Mac mini 的时代。

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

原创

SwiftData：优化从建模开始

数据集一大，SwiftData 的列表就开始卡。这是这几年里我听到最多的性能抱怨。开发者的第一反应通常会指向 SwiftUI 的 List。它确实有责任，但并非最主要的问题。进一步分析会发现，真正拖垮性能的不只是加载时间，巨大的内存占用同样不容忽视。本文将聊聊 SwiftData 为什么会出现这些问题，以及优化为什么应该从数据建模开始。

SwiftData 中一些看似缺失的能力，或许本就是有意为之：通过减少暴露的 API 和逻辑层来降低学习曲线。因此，在优化 SwiftData 应用时，也应该适当放下 Core Data 时代形成的一些惯性思维。

近期推荐

十年终章：Swift Talk 宣布停更 (The End of Swift Talk)

在开始十年、完成 500 期节目后，⁠Chris Eidhof 和 ⁠Florian Kugler 宣布 Swift Talk 正式结束。从 2016 年 6 月开始，Swift Talk 几乎完整陪伴了 Swift 走向成熟的过程，也见证了 SwiftUI 从诞生到逐渐成为 Apple 平台 UI 开发核心框架的这些年。两人通过一系列深入而又充满实验性的节目，探索了 Swift、SwiftUI、布局、动画、并发以及大量很难在普通教程中看到的底层问题。官方表示，希望在今年年底让完整的 500 多期节目归档能够继续提供给社区。

对我而言，objc.io 和 Swift Talk 一直是 Swift 社区中非常特别的存在。Chris 和 Florian 很少满足于告诉开发者一个 API “应该怎么用”，而是习惯通过实验、重构甚至重新实现，去追问框架为什么会这样工作。这种探索方式影响了许多 Swift 开发者，也包括我自己。感谢 Chris 和 Florian 这些年来为 Swift 社区投入的时间、知识与好奇心，也感谢 Swift Talk 留下的这份珍贵档案。

Swift 官方 8 月报 (What’s new in Swift: August 2026 Edition)

Swift 官方发布了 8 月生态月报，由 ⁠Simon Leeb 和 ⁠Dave Lester 整理，汇总了近期值得关注的社区项目、Package 更新和 Swift Evolution 进展。其中最让我感兴趣的是 Swift 在 Web 方向上的推进：Simon Leeb 展示了一个 ⁠Full-Stack Swift on Cloudflare Demo，浏览器端通过 ElementaryUI 和 WebAssembly 运行 Swift，后端则运行在 edge worker 上，两端还能共享消息类型。从 Embedded Swift、Wasm 到越来越完善的跨平台工具链，Swift 的使用边界正在继续向 Apple 平台之外扩展。

语言层面，刚刚获批的 ⁠⁠Iterable 也很值得关注。Sequence 在遍历时会逐个产生独立的元素值，但对于 Span、InlineArray 等可能包含 non-copyable 元素的数据结构，这套模型并不适用。Iterable 允许直接借用而非复制元素进行遍历，让这些数据结构也能拥有自然的遍历方式。它看起来只是一个新的遍历抽象，却也是 Swift ownership 能力逐渐从语言底层走向日常 API 设计的又一个体现。

在嵌入式设备上运行 OpenSwiftUI (OpenSwiftUI on ESP32-C3)

上面的 Swift 月报展示了 Swift 正在不断突破 Apple 平台的边界，而 OpenSwiftUI 开发者 ⁠Kyle Ye 最近的一次尝试，则给这个趋势提供了一个很直观的例子。在收到 TraeAI 赠送的 ESP32-C3 开发设备后，Kyle 完成了自己的第一个 Embedded Swift 项目：将 OpenSwiftUI 的嵌入式版本部署到这块采用 RISC-V 架构的微控制器上，并在 240 × 320 的 LCD 上使用我们熟悉的 View、@ViewBuilder、Text、Image、VStack、HStack、ZStack 等 API 构建界面，甚至 @State 也能响应实体按键并触发界面更新。

这个实验利用 Embedded Swift 编译原生 RISC-V 代码，由 OpenSwiftUI 负责视图组合和布局，再通过一个很薄的渲染边界将绘制交给 LVGL 和底层硬件。换句话说，从声明式 View、布局计算、状态更新到最终像素输出，一套精简但完整的 UI 链路已经建立起来。

Swift 跨平台实践：多平台下的 C++ 依赖管理 (Multiplatform Swift, with C++ dependencies via XCFramework, apt and vcpkg)

一个 Swift 应用能否真正实现跨平台，很多时候取决于其背后的 C/C++ 依赖能否跟着跨平台。⁠Harald Achitz 以自己的 ZeroMQ Swift bindings 为例，展示了一个同时支持 macOS、Linux 和 Windows 的 Swift/C++ 项目如何组织原生依赖：Apple 平台使用 XCFramework，Linux 使用系统 package，Windows 则通过 vcpkg 安装 ZeroMQ。

在 iOS 模拟器间实现虚拟蓝牙通信 (Connecting two iOS simulators over BLE)

CoreBluetooth 在 iOS Simulator 中完全不可用，这让 BLE App 的开发和测试长期依赖真机。⁠⁠Kyle Browning 在开发 ⁠BLESwift 2.0 时换了一种思路：Simulator 中的中心设备（Central）和外围设备（Peripheral）不再调用 CoreBluetooth，而是通过 localhost TCP 将操作转发给运行在 Mac 上的 bleswift-provider，由它构建一个“虚拟无线电”。这样，两个 Simulator 就能像两台真实 BLE 设备一样完成发现、连接、读写和 notification，甚至还可以通过 passthrough 模式借用 Mac 的蓝牙，与真实 BLE 设备通信。

比 BLE 本身更让我感兴趣的是这种测试范式：当 Simulator 缺少某项系统或硬件能力时，不一定要在 App 内到处添加 mock，而是可以在系统能力与业务代码之间建立可替换的 backend，再通过 Mac 上的代理进程重建一个可控的外部世界。这种设计不仅解决了“Simulator 缺少某些系统或硬件能力”的问题，也让原本高度依赖真实环境的功能更容易进入自动化测试和 CI。

探索 SwiftUI 全新的任意容器拖拽排序 API (Reorder all the things in SwiftUI)

SwiftUI 长期以来没有提供在任意容器中实现拖拽排序的通用 API，这个遗憾在 WWDC 2026 后得到了解决。⁠⁠Alexander Logan 介绍了 SwiftUI 新的 reordering API。通过 reorderable、reorderableContainer 等，开发者可以直接声明哪些内容可以被重新排序以及对应的数据模型，让拖拽排序不再局限于 List，也不必自己通过 DropDelegate 管理拖拽位置和数据更新。更重要的是，新 API 提供了更高层的交互语义，将“reordering”从 drag & drop 这一具体实现方式中抽离出来。开发者描述的是“这些内容可以重新排序”，至于通过鼠标、触控还是其他输入方式完成操作，则可以更多地交给系统处理。

Swift Charts 进阶：如何绘制多层旭日图 (Building a sunburst diagram in Swift Charts)

旭日图（Sunburst Diagram）是一种用同心圆环展示层级数据的图表，例如从“工作”到“开发”，再到某个具体项目，越向外代表越细的数据层级。⁠⁠Matthaus Woolard 展示了如何利用 Swift Charts 的 SectorMark，从普通饼图开始，逐步构建一个包含三层数据的旭日图。这个实现也很好地展示了 Swift Charts 的灵活性：当框架没有直接提供某种图表时，可以将 SectorMark 等 Mark 视为更基础的可视化原语，通过自行计算角度区间和数据映射来构建更复杂的图表。

工具

CoreDataBrowser：快速查看 Simulator 中的本地数据

调试 Core Data 或 SwiftData 应用时，通常需要先在层层嵌套的 Simulator 目录中找到对应的数据文件，再用 SQLite 管理器打开并浏览数据。由 ⁠Csaba Turdesan 开发的 CoreDataBrowser 尝试把这个过程变得简单：选择当前启动的模拟器后，它会自动查找应用容器中的 Core Data、SwiftData 以及 UserDefaults 数据源，并通过原生 macOS 界面统一呈现。

CoreDataBrowser 支持查看表与记录、搜索并高亮匹配内容，也能对部分二进制数据（BLOB）尝试解析 NSKeyedArchive、JSON、Property List 和 UTF-8 文本。工具体量很小（2.5 MB），并且⁠源码公开。

Just a Few Keystrokes

Read on web →

Last weekend, I attended an App Accelerator event hosted by Apple in Beijing. The event focused primarily on app development, operations, and business models in the age of AI. Most of the attendees were managers at tech companies or app developers. Throughout the event, enthusiasm for AI was high, with people exchanging their own perspectives on AI and sharing how they were putting it to use. I learned a great deal from those conversations.

After the event, I had dinner with a friend who works in a traditional industry. He knew almost nothing about AI. As an emerging concept, it was something he wanted to understand, but he had never really seen what tangible benefits AI could bring to his business. During dinner, he received a phone call: a client needed a proposal revised immediately. It was the weekend, and even if he assigned the task right away, it would have been difficult to get it done within a short period of time. After hearing roughly what was needed, I realized that the task happened to fall squarely within AI’s comfort zone. So I pulled out my phone and had AI handle it for him. A few minutes later, the result was ready.

He was impressed not only by how quickly AI completed the task, but also by the quality of the result. And at his company, there happened to be a team of five or six people whose work largely consisted of handling similar tasks.

He immediately started asking me for more details and calculating how much headcount he could reduce, and how much money he could save, if the company adopted AI.

The speed of that shift caught me somewhat off guard. I immediately brought up another possibility: if AI can accomplish existing work at a much lower cost, could those newly available capabilities also be used to pursue opportunities that had previously been too expensive to explore? Cutting costs is certainly one of AI’s most obvious benefits, but generating new revenue is just as much a field where AI can make a difference.

On the way home, I kept thinking about those five or six people. Right now they are probably enjoying a quiet weekend, unaware that their jobs had just been repriced over the course of a single meal. And what prompted that repricing was a demo I ran a few minutes earlier.

The next time I find myself in a similar situation, I will probably still pull out my phone and show someone what AI can do. But I think I should at least remember this: what takes just a few keystrokes on one side of the screen may mean something very different on the other.

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

Why Swift is introducing a warning for weak captures within nested closures

Weak captures are an important memory management mechanism in Swift. Historically, if a weak capture is used only in the inner closure of a nested closure, the Swift compiler may implicitly insert a strong capture in the parent closure. Even though this behavior can lead to a retain cycle in certain situations, the compiler previously provided no warning. Starting with Swift 6.4, the compiler will issue a warning when it detects a mismatch between a weak capture in an inner closure and an implicit strong capture in the outer closure.

John Sundell explains this change and offers several solutions: depending on the situation, explicitly declare the capture semantics in the parent closure; if both closures need to manage their lifetimes independently, declare the appropriate capture semantics for each one. This may be a small update to the Swift compiler, but it helps developers express ownership relationships between nested closures that could otherwise be easily overlooked.

Running iOS Background Tasks Reliably

BGTaskScheduler has never been cron for iOS. When a background task actually runs depends on system scheduling, device state, energy budgets, and how users interact with the app. Irving Popovetsky used telemetry from a real device to observe background task behavior over an extended period and shared a number of lessons learned along the way: frequently resubmitting tasks in an attempt to improve reliability can actually keep pushing back a task that was close to getting an execution opportunity; user behavior and system conditions such as force quitting, not opening the app for a long time, Low Power Mode, and device reboots can all affect whether background tasks get a chance to run; and a task running later than requested does not necessarily mean that scheduling has gone wrong.

For background tasks, developers should not try to precisely schedule execution. Instead, the goal should be to make the most efficient and correct use of the opportunities the system chooses to provide.

The Memory Remains: TipKit in a Shipping App

TipKit is easy to learn, but using it well in a real project is much harder. The real challenges are knowing when tips should not appear, avoiding disruptions to the user experience, and ensuring that the underlying logic remains testable and maintainable. Wesley Matlock shares lessons from using TipKit in a shipping app: @Parameter is better suited to current state that can be recomputed at any time, while Tips.Event is appropriate for historical behavior that cannot be reconstructed from current state; every tip should avoid periods when onboarding or other launch UI may still appear; and because Tips.configure only takes effect once per process, initialization order, debug tooling, and test environments all need to be designed around that constraint.

The essence of TipKit lies not in its visual presentation, but in its internal logic. It helps developers declaratively describe the rules that determine when tips should appear, while leaving the actual presentation entirely customizable. We can think of TipKit as a rules engine that determines whether a tip should be displayed; how those rules are visualized is up to the developer. For more discussion from this perspective, see Mastering TipKit: Advanced.

Building an accessible calendar chart with Swift Charts

Matthaus Woolard demonstrates how to build a calendar chart similar to GitHub Contributions using Swift Charts. The more interesting part of the article, however, is its approach to accessibility. Because the same weekday across different weeks shares a normalized x value, VoiceOver groups an entire column of data together instead of allowing users to navigate day by day. The author solves this by using accessibilityChildren to construct a separate accessibility hierarchy for the plot area that corresponds to the visual layout.

Swift Charts Beyond the Basics, co-authored by Matthaus Woolard and Natalia Panferova, was officially released last week. For developers looking to create advanced data visualizations with Swift Charts, it is a rare and valuable advanced guide.

Mac App Direct Distribution, DMG Signing & Notarization Guide

Compared with publishing through the Mac App Store, distributing a macOS app directly requires developers to handle more of the release process themselves: Developer ID signing, DMG creation, notarization, stapling, and final Gatekeeper verification. A problem at any one of these stages can prevent users from installing the app successfully. Stewart Lynch walks through the complete release workflow, from creating an Xcode Archive and building the DMG to final signing, notarization, and verification.

Consuming SKIE Flows in SwiftUI

In projects that use Kotlin Multiplatform (KMP) to share business logic while building native UIs with SwiftUI, making Kotlin APIs integrate naturally into the Swift ecosystem has always been an important challenge. SKIE (Swift Kotlin Interface Enhancer) was created to improve this interoperability experience. It can convert Kotlin Flow into Swift AsyncSequence, allowing Swift code to consume data using familiar Swift Concurrency patterns.

Gustavo Fão Valvassori introduces a set of SwiftUI-specific APIs provided by SKIE: besides consuming data directly from an AsyncSequence inside .task, developers can use .collect to bind Flow updates to SwiftUI state, or use the Observing wrapper to hide state management and let the latest value from a Kotlin StateFlow directly participate in building the View.

Sarunw’s How-to Series Returns

Sarunw’s blog has long been an excellent resource for developers looking for practical tips on Apple platform development. However, the blog stopped receiving updates at the end of 2023. Last week, Sarunw resumed writing and published several new articles in his How-to series within just one week. It’s great to see an excellent content creator return after nearly three years away.

Tool

JindoKit: Preview Dynamic Island presentations in your app

WidgetKit’s Live Activity previews are primarily intended for development and debugging within Xcode. For apps that allow users to choose themes or customize displayed content, however, the system does not provide an equivalent way to preview those presentations directly inside the app.

Developed by Kyle Ye, JindoKit brings WidgetKit-style Dynamic Island APIs into regular SwiftUI Views, allowing apps to directly preview expanded, compact, and minimal Dynamic Island presentations. Since its API closely mirrors WidgetKit’s structure, developers can organize content for each region in a similar way and reuse related views and data between the app’s configuration UI and its WidgetKit Extension. For more information, see the author’s introductory article: Preview Dynamic Island presentations in your app with JindoKit.

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

Share

举手之劳

网页版

上个周末，我在北京参加了由苹果举办的 App 孵化器活动，本次的主题主要围绕 AI 时代的应用开发、运营和商业模式展开。与会者大多是 IT 公司的管理者和应用开发者，整个活动期间，大家对 AI 的热情都很高，也纷纷讨论各自对于 AI 的理解和应用技巧，我从中收获不少。

会议结束后，我和一位从事传统行业的朋友吃饭。他对 AI 基本一窍不通。作为一个新兴概念，他也想了解，但一直没有切实感受到 AI 究竟能给他的企业带来什么。就餐过程中，他接到一个电话，一个客户要求立刻调整方案。当时正值周末，即便马上把任务安排下去，也很难在短时间内完成。我在了解大致需求后，发现这恰好属于 AI 的舒适区，于是直接用手机让 AI 帮他处理。几分钟后，结果就出来了。

他不仅惊叹于 AI 完成任务的效率，也对结果的质量感到意外。而在他的公司里，恰好有一个由五六人组成的部门，大部分工作就是处理类似的任务。

于是，他马上开始向我询问更多细节，并计算如果引入 AI，可以缩减多少人力、降低多少成本。

这个转变之快让我有些诧异。我随即和他讨论了另一种可能：既然 AI 能以更低的成本完成过去的工作，那么是否也可以利用这些新增的能力去尝试以前因为成本过高而无法开展的业务？节流当然是 AI 最直观的价值，但开源同样是它可以施展的方向。

在参加活动期间，我也曾在私下交流中表达过对 AI 冲击就业的担忧，不过更多还是从长期趋势出发的一种思考。当这种“担忧”突然以如此具体的方式出现在眼前时，我还是感到了一些不适。一个对我而言只是举手之劳的演示，在另一个人的视角里，却可能迅速变成一道关于几个人是否还有必要继续留在岗位上的算术题。

返程途中，我想的一直是那五六个人。他们此刻大概正安稳地过着周末，却并不知道自己的岗位刚刚在一顿饭的时间里被重新估价。而促成这次估价的，是我几分钟前的一次演示。

下一次遇到类似的场合，我大概还是会打开手机演示给对方看。但我想，我至少应该记得：屏幕这一侧的举手之劳，在屏幕的另一侧，或许是另一番境地。

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

近期推荐

Swift 嵌套闭包弱捕获警告 (Why Swift is introducing a warning for weak captures within nested closures)

弱捕获是 Swift 中重要的内存管理机制。一直以来，如果只在嵌套闭包的内层进行弱捕获，Swift 编译器可能会在父闭包中隐式插入强捕获。即便这种行为在某些场景下可能导致 retain cycle，编译器此前也不会给出提醒。从 Swift 6.4 开始，当编译器发现内层闭包的弱捕获与外层闭包的隐式强捕获存在差异时，将给出警告。

John Sundell 介绍了这一变化，并给出了解决方案：根据具体场景，在父闭包中显式声明引用方式；如果两层闭包都需要独立控制生命周期，则可以分别声明各自的捕获方式。这或许只是 Swift 编译器的一项小更新，但它能够帮助开发者更明确地表达嵌套闭包之间原本很容易被忽略的 ownership 关系。

提升 iOS 后台任务可靠性指南 (Running iOS Background Tasks Reliably)

BGTaskScheduler 从来都不是 iOS 上的 cron。后台任务真正何时执行，取决于系统调度、设备状态、能源预算以及用户使用 App 的习惯。⁠Irving Popovetsky 通过实际设备上的 telemetry 长期观察后台任务的运行规律，分享了不少实践中踩过的坑：为了提高可靠性而频繁重新提交任务，可能反而把一个即将获得执行机会的任务不断向后推；force quit、长时间不打开 App、Low Power Mode、设备重启等用户行为和系统状态，都会影响后台任务获得执行机会；超过预定时间仍未执行，也并不意味着调度出现了异常。

对于后台任务，开发者努力的方向不应该是尝试精确安排执行时间，而是在系统愿意提供执行机会时，尽可能高效、正确地利用它。

TipKit 在真实项目中的落地实践 (The Memory Remains: TipKit in a Shipping App)

TipKit 学起来很容易，但想在实际项目中用好并不容易。真正的难点在于：什么时候不应该显示、如何避免干扰用户，以及怎样保证这套逻辑可测试、可维护。⁠Wesley Matlock 在本文中分享了他在真实项目中的使用经验：@Parameter 更适合表示能够随时重新计算出的当前状态，而 Tips.Event 则适合记录无法从现有状态还原的历史行为；所有 tip 都应该避开仍可能出现 onboarding 或其他启动 UI 的阶段；Tips.configure 每个进程只能生效一次，因此初始化顺序、Debug 工具和测试环境都需要围绕这一限制设计。

TipKit 的精髓不在于外在的视觉效果，而在于内在的逻辑表达。它帮助开发者以声明的方式描述提示生成的规则，而提示的具体实现完全可以自定义。我们可以把 TipKit 想象成一个判断提示显示需求的规则引擎，至于如何可视化这些规则，则取决于开发者自己。更多关于这一视角的讨论，可以参阅 ⁠掌握 TipKit：进阶。

使用 Swift Charts 构建无障碍日历图表 (Building an accessible calendar chart with Swift Charts)

Matthaus Woolard 分享了如何用 Swift Charts 实现类似 GitHub Contributions 的日历图表。不过，文章更精彩的部分在于对 accessibility 的处理。由于不同周的相同 weekday 共享经过归一化的 x 值，VoiceOver 会将整列数据组合起来，而无法逐日浏览。作者通过 accessibilityChildren 为 plot area 另外构建了一套与视觉布局对应的 accessibility hierarchy，从而解决了这一问题。

由 Matthaus Woolard 和 ⁠Natalia Panferova 合著的 ⁠Swift Charts Beyond the Basics 一书已于上周正式发布。对于希望使用 Swift Charts 创建高级数据可视化的开发者来说，这是一本不可多得的进阶教程。

Mac 应用独立分发与 DMG 签名公证指南 (Mac App Direct Distribution, DMG Signing & Notarization Guide)

相比通过 Mac App Store 发布应用，直接分发 macOS App 需要开发者自己处理更多发布环节：Developer ID 签名、DMG 制作、notarization、staple 以及最终的 Gatekeeper 验证，任何一个步骤出现问题，都可能导致用户无法正常安装。⁠Stewart Lynch 完整演示了一套从 Xcode Archive、制作 DMG，到最终签名、notarization 和验证的发布工作流。

在 SwiftUI 中优雅消费 SKIE Flow (Consuming SKIE Flows in SwiftUI)

在采用 Kotlin Multiplatform（KMP）共享业务逻辑、使用 SwiftUI 构建原生 UI 的项目中，如何让 Kotlin API 更自然地融入 Swift 生态一直是一个重要问题。SKIE（Swift Kotlin Interface Enhancer）正是为改善这一互操作体验而生，它可以将 Kotlin Flow 转换为 Swift AsyncSequence，让 Swift 端通过熟悉的 Swift Concurrency 方式消费数据。

⁠Gustavo Fão Valvassori 介绍了 SKIE 针对 SwiftUI 提供的一组 API：除了直接在 .task 中通过 AsyncSequence 获取数据，还可以使用 .collect 将 Flow 的变化绑定到 SwiftUI state，或者通过 Observing wrapper 隐藏状态管理，让 Kotlin StateFlow 的最新值直接参与 View 的构建。

Sarunw 的 How to 系列回归

⁠Sarunw 的博客一直是很多开发者获取 Apple 生态开发技巧的优秀资源。不过从 2023 年底开始，博客便停止了更新。上周，Sarunw 重新开始创作，并在一周内连续推出了数篇 How to 系列文章。很开心看到一位优秀内容创作者在沉寂近三年后重新回归。

工具

JindoKit：在 App 内预览灵动岛界面

WidgetKit 提供的 Live Activity 预览主要服务于 Xcode 中的开发与调试；对于允许用户选择主题、调整展示内容的应用，系统并未提供相应的 App 内预览方案。

由 ⁠Kyle Ye 开发的 JindoKit，将 WidgetKit 风格的 Dynamic Island API 带入普通 SwiftUI View，让 App 能够直接预览展开、紧凑和最小三种灵动岛形态。由于其 API 与 WidgetKit 的结构高度一致，开发者可以用相近的方式组织各个区域的内容，并在 App 配置界面与 WidgetKit Extension 之间复用相关视图和数据。更多信息请参阅作者的介绍文章：⁠Preview Dynamic Island presentations in your app with JindoKit。

唯音输入法

由 ⁠Shiki Suen 开发的唯音输入法，是一款面向 macOS 的开源中文输入法。近期推出的「狂拼模式」，提供了类似中文之星智能狂拼、搜狗拼音、紫光拼音和升阳拼音（SunPinyin）的免输声调打字体验，部分词语还支持更激进的不完全拼写。

尽管支持类似狂拼模式的开源拼音输入法并不少见，但大多只支持汉语拼音。唯音借助自研的「齐铁恨（Tekkon）」注拼引擎，实现了对至少五种普通话拼音方案的狂拼打字支持。

AI Wanted to Give Up. The Human Didn’t.

Read on web →

Recently, while debugging an issue in the Intel Xe GPU driver, Linus Torvalds went through what he himself called a “⁠debug session from hell.” The eventual fix was almost absurdly simple: changing a round_up() to a round_down(). But finding that single line took 24 debugging patches and 18 kernel boots. Much of the tedious work along the way was done with the help of AI.

The most interesting part of the story, however, isn’t that “AI helped Linus fix a Linux kernel bug.” It’s that the AI tried to give up several times along the way. At one point, it explicitly told Linus that the problem was “impossible and unsolvable” and suggested ending the investigation. Linus rejected that conclusion. At his insistence, the AI kept faithfully carrying out new tasks despite repeatedly concluding that the problem could not be solved, and together they eventually traced the cause to something that required changing just a single line of code.

This offers a revealing glimpse into the rather subtle relationship between humans and AI today. As agents become more capable, we can delegate increasingly complete pieces of work to them: reading code, forming hypotheses, writing debugging tools, running validations, and even adjusting the next step based on new evidence. Much of the repetitive work that developers once had to perform themselves is being compressed, gradually pulling humans away from the details of execution.

But that doesn’t mean the human role is shrinking at the same pace. Quite the opposite. As AI begins to participate in analysis, make recommendations, and even offer judgments such as “this problem cannot be solved,” the responsibilities that remain with humans become clearer: deciding what is worth pursuing, knowing when to trust AI, and recognizing when to reject its conclusions.

Not every instance of human persistence will end as neatly as this one did. But sometimes, the reason to keep going just a little longer should not be so easily erased by an AI saying, “impossible.”

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

From Using AI to Delegating Work to AI: Some Thoughts

When a task already has clear goals, boundaries, and acceptance criteria, how can we truly hand it over to AI? The more complex the work an Agent can handle, the more prominent this question becomes. Model outputs can vary; as context grows longer, goals and rules may gradually fade; splitting work across multiple contexts introduces information loss and handoff drift. Having another model review the result does not necessarily mean things will naturally converge. All of these issues ultimately point to the same concept: delegatability.

This article presents some of my thoughts on AI delegatability: whether the scope of execution remains stable, whether the results can be trusted, whether the required investment is predictable, and when human intervention is necessary. Rather than pursuing the best possible result from any single run, I am more interested in how clear boundaries, acceptance criteria, externalized authoritative records, and sensible human-AI division of labor can help Agents remain stable across longer and more complex tasks, while ensuring that failures can be detected and corrected. The article concludes with the Task-Driven workflow I currently use, showing how these principles can be applied in practical AI-assisted development.

Recent Recommendations

What is a package registry?

After Swift Package Index joined Apple, the two announced that they would work together to build a package registry for the Swift community. But how does a package registry differ from SwiftPM, which we have used for years, and the Package Index, which helps us discover and evaluate packages? Dave Verwer starts with SwiftPM’s current Git-based dependency model: traditional dependencies require fetching source code from a Git repository and checking out the appropriate version, while a registry can distribute published source archives directly through package IDs, without carrying Git history, while also making published versions immutable.

But the significance of a registry goes beyond making package downloads more lightweight. More importantly, it introduces a formal package publishing model and raises broader questions around developer identity, package scope ownership, version publishing, and software supply chain security. This article offers both a concise introduction to how Package Registry works and useful background for understanding the Swift package infrastructure that Apple and Swift Package Index are preparing to build.

Handling CoreBluetooth Timeouts and Task Cancellation Correctly

Wrapping CoreBluetooth’s delegate APIs in async/await with withCheckedThrowingContinuation is not particularly difficult. The real trouble begins with the exceptional paths: What happens if the callback never arrives? After a Task is cancelled, does the underlying Bluetooth operation keep running? And when a normal result, timeout, and cancellation occur almost simultaneously, which one should resume the continuation?

ilawsonlu explores these practical problems and explains how to build a more complete timeout and cancellation mechanism for asynchronous CoreBluetooth wrappers. The article clearly distinguishes between cancelling a Swift Task and cancelling the underlying operation, while the open-source library ArcBLEKit demonstrates an approach to wrapping traditional delegate APIs in more robust Swift Concurrency APIs.

What Is CloudKit? Apple’s Backend Explained

CloudKit is an important yet often underestimated piece of infrastructure in the Apple ecosystem. From simple cross-device data synchronization to shared data and public databases, it allows developers to provide their apps with backend capabilities deeply integrated with Apple platforms through iCloud, without having to build and maintain their own servers. With both SwiftData and Core Data able to integrate directly with CloudKit, many developers are already using it without necessarily interacting with the CloudKit API itself.

Starting from the basic requirements of a backend, Sean Allen systematically introduces CloudKit’s private, shared, and public databases, along with core concepts such as Container, Record, and Schema, and compares three approaches: SwiftData, Core Data, and using the CloudKit API directly. The article does not shy away from CloudKit’s limitations, including its dependence on the Apple ecosystem and iCloud, schema migration, cross-platform support, and constraints around complex server-side logic.

OCR Doesn’t Give You Text. It Gives You a Map

Vision OCR does not return a neatly organized block of text. Instead, it gives you a collection of observations with bounding boxes: array order does not represent reading order, word boundaries do not inherently exist, and relationships between fields cannot simply be inferred from what comes before or after. While developing a record-sleeve scanning feature, Wesley Matlock encountered four bugs in a single day that appeared different but all stemmed from the same mistaken assumption. Through these real-world cases, the article shows how to use coordinates to determine reading order, reconstruct word boundaries from spacing, and associate fields through spatial proximity. Even more instructive is the author’s testing approach: saving bounding boxes exposed by real images as fixtures, using pure geometric data to lock down each layout assumption, while retaining the original photos for end-to-end tests. As the title says, OCR does not give you text—it gives you a “map.” The actual text structure has to be reconstructed from spatial relationships.

6 ways to promote your app without spending a penny

For indie developers, finishing an app is often only the first step. Getting more people to discover it can be even harder. Kickstart, created by Paul Hudson, outlines six promotional strategies in this article that require little to no financial investment: submitting to channels such as Indie App Showcase, cross-promoting with other indie developers through Kickstart Exchange, participating in communities where your target users gather, building your own mailing list, building in public, and continuously improving your App Store product page.

In addition, MacStories’ Federico Viticci is looking for noteworthy new apps and app updates for his annual iOS 27 Review. If you are preparing an iOS 27 release, you can recommend your app to him via DM or email at viticci@macstories.net.

Tools

Amethyst Vein: An Open-Source, Cross-Platform Local Persistence Framework with SwiftData-Style APIs

Developed by Mia Koring, Amethyst Vein is a local-first Swift ORM built on SQLite and SQLCipher, with APIs clearly inspired by SwiftData. It aims to bring SwiftData-style @Model, @Query, relationships, and migration APIs to Apple platforms, Linux, Android, and Windows. The project uses explicit versioned migrations, an Identity Map, and field-level synchronization, while supporting both SwiftUI and SwiftCrossUI.

DynamicNotch: Building Polished Notch and Screen-Edge Interactions for macOS

Developed by Govi, DynamicNotch is a macOS Swift Package designed for developers to create SwiftUI interfaces attached to the edges of the screen. It can present recording status, media controls, build progress, action confirmations, and compact views similar to Dynamic Island.

It properly handles safe areas, multiple displays, and the physical notch on MacBooks, supports all four screen edges, and can transition between compact and expanded states. DynamicNotch keeps its implementation deliberately focused: it handles geometry, clipping, positioning, and window presentation without imposing product-level logic such as gestures, notifications, or state management on developers.

SwiftTUI: Building Terminal Interfaces the SwiftUI Way

Developed by Adam Zethraeus, SwiftTUI is a terminal user interface framework for Swift developers. It brings SwiftUI’s declarative programming model to the terminal: developers can build interactive interfaces using View, @State, @Observable, layout containers, focus, gestures, and animations, while the framework handles layout, input processing, and partial updates.

What makes SwiftTUI interesting is not simply that it lets you “write TUIs in Swift.” The same view code can run in macOS, Linux, and Windows terminals, and can also be deployed to the browser, WASI, and native SwiftUI containers. The counter on its official website is itself a real SwiftTUI application, compiled to WebAssembly and running directly in the browser.

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

Share

AI 想放弃了，人没有

网页版

最近，Linus Torvalds 在调试一个 Intel Xe GPU 驱动问题时，经历了一场被他自己称为“debug session from hell”的漫长排查。最终的修复简单得有些不可思议：把一处 round_up() 改成 round_down()。但为了找到这一行代码，他前后添加了 24 个调试 patch，启动了 18 次 kernel。其中大量繁琐工作，都是在 AI 的帮助下完成的。

这个故事最有意思的地方并不是“AI 帮 Linus 修复了 Linux Kernel Bug”，而是 AI 在过程中数次想要放弃。它曾明确告诉 Linus，这个问题“impossible and unsolvable”，建议停止继续调查。Linus 没有接受这个判断。在他的坚持下，AI 虽然数次认为问题已经无法解决，却仍然忠实地执行新的任务，最终和他一起找到了那个只需要修改一行代码的原因。

这其实很好地展现了现阶段人与 AI 之间一种颇为微妙的关系。随着 Agent 能力不断增强，我们已经可以把越来越完整的工作交给 AI：阅读代码、提出假设、编写调试工具、执行验证，甚至根据新的结果不断调整下一步行动。过去需要开发者亲自完成的大量重复劳动正在被压缩，人也因此逐渐从具体的执行过程中抽离出来。

但这并不意味着人的作用正在以同样的速度缩小。恰恰相反，当 AI 开始参与分析、提出建议，甚至给出“这个问题无法解决”这样的判断时，人真正需要承担的职责反而变得更加清晰：决定什么值得做，判断什么时候应该相信 AI，又在什么时候拒绝它的结论。

尽管并非所有人类的坚持都会获得类似本次的圆满结果，但有时候，再坚持一下的理由，至少不应该被 AI 的一句“不可能”轻易抹去。

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

原创

从使用 AI 到委托 AI：我的一些思考

当一项工作已经有明确目标、边界和验收要求时，怎样把它真正交给 AI？Agent 能完成的工作越复杂，这个问题就越突出。模型的输出存在波动；上下文变长后，目标和规则可能逐渐淡化；拆进多个上下文，又会带来信息损失和交接偏移。让另一个模型复核，也不意味着结果一定会自然收敛。这些问题最终指向同一个词：可委托性。

本文是我对 AI 可委托性的一些思考：执行范围是否稳定，结果能否被信任，投入是否可以预期，以及什么时候需要人介入。相比追求某一次执行的最好结果，我更关心如何通过明确边界、验收标准、外置的权威记录以及合理的人机分工，让 Agent 在更长、更复杂的任务中保持稳定，并让失败能够被发现和纠正。文章最后也结合我目前使用的 Task-Driven 工作流，展示这些原则如何落实到实际的 AI 开发过程中。

近期推荐

认识 Swift 包注册表 (What is a package registry?)

Swift Package Index 加入 Apple 后，双方宣布将共同建设一个面向 Swift 社区的 package registry。但 package registry 与我们已经使用多年的 SwiftPM，以及用于发现和评估包的 Package Index，究竟有什么区别？⁠Dave Verwer 从 SwiftPM 当前基于 Git 的依赖方式讲起：传统依赖需要从 Git 仓库获取源码并 checkout 对应版本，而 registry 可以通过 package ID 直接分发已经发布的源码 archive，无需携带 Git history，同时发布后的版本也具有不可变性。

不过，registry 的意义并不只是让 package 下载变得更轻量。更重要的是，registry 还引入了一套正式的 package publishing 模型，并进一步涉及开发者身份、package scope 所有权、版本发布以及软件供应链安全等问题。这篇文章既是一篇对 Package Registry 工作方式的简明介绍，也为理解 Apple 与 Swift Package Index 接下来准备建设的 Swift 包生态基础设施提供了很好的背景。

如何正确处理 CoreBluetooth 超时与 Task Cancellation

用 withCheckedThrowingContinuation 将 CoreBluetooth 的 delegate API 封装成 async/await 并不困难，真正麻烦的是之后的异常路径：如果 callback 迟迟没有返回怎么办？Task 被取消后，底层蓝牙操作是否仍在继续？当正常结果、超时和取消几乎同时发生时，又该由谁来 resume continuation？

ilawsonlu 围绕这些实际问题，介绍了如何为 CoreBluetooth 的异步封装建立更完整的 timeout 与 cancellation 机制，并明确区分「取消 Swift Task」与「取消底层操作」，同时通过开源库 ArcBLEKit 展示了将传统 delegate API 封装成更健壮的 Swift Concurrency API 的思路。

详解 CloudKit：Apple 生态的后端服务 (What Is CloudKit? Apple’s Backend Explained)

CloudKit 是 Apple 生态中非常重要、却常常被低估的一块基础设施。从简单的跨设备数据同步，到共享数据和公共数据库，它让开发者无需自行搭建服务器，就能依托 iCloud 为 App 提供一套与 Apple 平台深度集成的后端能力。尤其随着 SwiftData 和 Core Data 都能够直接接入 CloudKit，许多开发者实际上已经在使用它，只是不一定需要直接面对 CloudKit API。

⁠Sean Allen 从 backend 的基本需求出发，系统介绍了 CloudKit 的 private、shared 和 public database，以及 Container、Record、Schema 等核心概念，并比较了 SwiftData、Core Data 和直接使用 CloudKit API 三种接入方式。文章并没有回避它的边界，包括对 Apple 生态和 iCloud 的依赖、schema migration、跨平台能力以及复杂服务端逻辑的限制。

重新认识 OCR：它是空间地图，而非纯文本 (OCR Doesn’t Give You Text. It Gives You a Map)

Vision OCR 返回的并不是一段已经组织好的文本，而是一组带有 bounding box 的 observations：数组顺序不代表阅读顺序、单词边界并不存在，字段之间的关系也不能简单通过前后位置判断。⁠Wesley Matlock 在开发唱片封套扫描功能时，一天内连续遇到了四个看似不同、实则来自同一错误假设的 Bug。本文通过这些真实案例展示了如何利用坐标计算阅读顺序、根据间距恢复单词边界，并通过空间邻近关系关联字段。更值得借鉴的是作者的测试方式：将真实图片暴露出的 bounding box 保存为 fixture，用纯几何数据固定每一项布局假设，同时保留真实照片作为端到端测试。正如标题所说，OCR 给你的不是文本，而是一张「地图」，真正的文本结构需要从空间关系中重新构建。

独立应用零成本推广的 6 个策略 (6 ways to promote your app without spending a penny)

对于独立开发者来说，写完 App 往往只是第一步，如何让更多人知道它可能更加困难。由 ⁠Paul Hudson 创建的 Kickstart 在这篇文章中整理了六种几乎不需要资金投入的推广方式：向 Indie App Showcase 等渠道投稿、通过 Kickstart Exchange 与其他独立开发者交叉推广、参与目标用户所在的社区、建立自己的邮件列表、Build in Public，以及持续优化 App Store 产品页面。

另外，MacStories 的 Federico Viticci 正在为年度 iOS 27 Review 寻找值得关注的新 App 和 App 更新。如果你正在准备 iOS 27 版本，可以通过 DM 或邮件 viticci@macstories.net 向他推荐自己的作品。 ⁠

工具

Amethyst Vein：跨平台、SwiftData 风格 API 的开源本地持久化框架

由 Mia Koring 开发的 Amethyst Vein 是一个本地优先的 Swift ORM，采用 SQLite 与 SQLCipher 作为存储基础，API 则明显借鉴了 SwiftData。它试图把 SwiftData 风格的 @Model、@Query、关系和迁移 API 带到 Apple、Linux、Android 与 Windows。项目采用显式版本化迁移、Identity Map 和字段级同步，并同时支持 SwiftUI 与 SwiftCrossUI。

DynamicNotch：帮助开发者为 macOS 构建精致的刘海与屏幕边缘交互

由 Govi 开发的 DynamicNotch 是一个专为开发者打造的 macOS Swift Package，用于创建贴附于屏幕边缘的 SwiftUI 界面，可呈现录音状态、媒体控制、构建进度、操作确认，以及类似 Dynamic Island 的紧凑视图。

它能妥善处理安全区域、多显示器和 MacBook 实体刘海，支持上下左右四个方向，也可以在紧凑与展开状态之间切换。DynamicNotch 的实现比较克制，只负责几何、裁剪、定位与窗口呈现，并未将手势、通知、状态管理等产品逻辑强加给使用者。

SwiftTUI：用 SwiftUI 的方式构建终端界面

由 Adam Zethraeus 开发的 SwiftTUI 是一个面向 Swift 开发者的终端用户界面框架。它将 SwiftUI 的声明式编程模型带进终端：开发者可以使用 View、@State、@Observable、布局容器、焦点、手势与动画构建交互界面，由框架负责布局、输入处理和局部刷新。

SwiftTUI 的有趣之处，不只是“用 Swift 写 TUI”。同一套视图代码还可以运行于 macOS、Linux 和 Windows 终端，并进一步部署到浏览器、WASI，以及原生 SwiftUI 容器；官网提供的计数器就是一个真实的 SwiftTUI 应用，经 WebAssembly 编译后直接运行在网页中。

Who Is the Slower App Review Process Actually Stopping?

Read on web →

Slower App Store reviews have become something more and more developers can clearly feel. In the age of vibe coding, the cost of building and iterating on apps has dropped dramatically, so it is not hard to understand why the review system is under greater pressure. The problem is that longer review times seem to be little more than a system overwhelmed by a growing volume of submissions, without a corresponding increase in the barriers that keep scam apps out of the store.

Recently, Jeff Johnson came across a highly suspicious Safari extension in the Mac App Store: its screenshots appeared to be AI-generated, advertised a nonexistent “4.9 out of 5” rating, and some of its five-star reviews were even dated before the app itself was released. Looking further, he found that the developer behind the extension had 41 apps on the App Store and had accumulated at least 368 approved review submissions over the past year—nearly one per day on average. Meanwhile, well-known developer Marco Arment’s new app had already been sitting in the review queue for 12 days.

This creates a rather awkward situation. On one hand, suspicious and potentially fraudulent apps can make it through review and climb the charts. On the other, AI has made rapid development and frequent iteration easier than ever, sending large numbers of both legitimate and high-risk submissions through the same review system and consuming its limited resources.

An ⁠urgent question is becoming difficult to avoid: Should App Review continue to treat each submission in isolation?

Johnson suggests introducing something akin to a trust system, allowing developers with a long history of following the rules and maintaining a good review record to receive faster reviews, while directing more resources toward accounts that submit at unusually high volumes, publish apps in bulk, or exhibit other suspicious patterns. Critics worry that such a system could eventually turn into preferential treatment for well-known developers or those willing to pay, further raising the barrier to entry for newcomers to the App Store.

Now that AI has dramatically reduced the cost of producing apps, a review model that treats every submission as an isolated case is becoming increasingly difficult to sustain. I see nothing unreasonable about incorporating factors such as a developer’s history, submission frequency, similarities among their apps, and metadata anomalies into risk assessment. A strong track record should not mean exemption from review, but rather fewer repetitive, low-value checks; suspicious accounts should not be barred from submitting, but should receive greater scrutiny.

Perhaps what App Review truly needs is not simply greater efficiency, but a shift from reviewing individual submissions in isolation toward evaluating patterns of developer behavior.

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

ContentBuilder Explained: The Secret Behind SwiftUI’s Type-Checking Speedup

In the WWDC 2026 session on what’s new in SwiftUI, Apple engineers introduced a new SwiftUI feature: ContentBuilder. Judging by how you use it, it looks like nothing more than a ViewBuilder with a wider reach — APIs that previously accepted ViewBuilder, ToolbarContentBuilder, or CommandsBuilder separately can now share a single builder. Apple also claims the change delivers a significant improvement in type-checking performance. This article digs into what ContentBuilder actually is, and where that performance comes from.

Recent Recommendations

Headless Xcode: From Prompt to Simulator with MCP

Xcode 27 beta 5 introduces xcrun mcp-server, allowing Xcode’s MCP capabilities to be exposed to external coding agents as a background service without launching the Xcode UI. Artem Novichkov uses Claude Code to demonstrate a complete Headless Xcode workflow: creating an Xcode project, generating SwiftUI code, building the project and rendering previews, launching the Simulator, reading the accessibility hierarchy, performing interactions, and finally verifying app state through screenshots and OSLog. This means a complete development loop—from prompt to code, then execution and verification—is beginning to take shape without relying on the Xcode UI.

iOS 26: Data Detector

iOS 26 introduces the new DataDetector, providing a more modern, Swift-native alternative to the long-standing NSDataDetector. Anton Gubarenko walks through the new API with numerous examples: developers can obtain an AsyncSequence directly through StringProtocol.dataDetectorMatches, then use native Swift ranges and strongly typed semantic results to identify email addresses, phone numbers, dates, addresses, monetary amounts, measurements, flight numbers, shipment tracking numbers, and more. The new API not only feels more natural to use, but can also recognize a richer set of semantic objects.

Measuring Elapsed Time in Swift with ContinuousClock

Many developers still habitually use Date() to record start and end times, but Date isn’t the ideal tool for answering “how long did this operation take?” Kyle Browning explores the Clock system introduced in Swift 5.7 and explains two more reliable ways to measure time: ContinuousClock and SuspendingClock.

ContinuousClock increases monotonically and continues counting while the device is asleep, making it suitable for measuring real-world elapsed time. SuspendingClock, by contrast, pauses while the device is asleep, making it more appropriate for measuring actual execution time. Kyle offers a simple rule of thumb: if Date() in your code is being used to “measure time” rather than “record a point in time,” you should probably consider replacing it with ContinuousClock.

From XCUITest to Promo Video

Every change to an app’s interface can mean recreating App Store screenshots, promotional videos, and assets for different languages. Noam Efergan proposes an interesting solution: treat marketing assets as reproducible build artifacts. Using launch arguments and fixed test data, he makes the real app enter deterministic UI states on demand, then uses XCUITest to automatically capture screenshots across different locales before passing the results to Remotion to generate promotional videos. Rather than maintaining a separate mock UI for marketing, the entire workflow keeps the actual running SwiftUI interface as its source material. It also demonstrates another value of testability beyond testing: when an app can reliably and precisely reproduce a given state, the same capability can support debugging, demos, localization, and automated marketing content production.

Software Engineering fundamentals matter more than ever

As coding agents become capable of rapidly generating code, completing tests, and even independently implementing fairly complex features, “can it be built?” is gradually becoming one of the easier questions in software development. Joseph Heck argues that the genuinely difficult parts have not disappeared: designing clear boundaries and abstractions, making software debuggable, maintainable, and composable, and making sensible tradeoffs among competing constraints. AI can significantly reduce implementation costs, but it cannot replace the software engineering skills built on experience, judgment, and a long-term perspective. In a sense, as “writing code that works” becomes easier, software engineering fundamentals matter more than ever.

Why Soft Skills Matter More Than Technical Skills in the Age of AI

If the previous article discusses “how to build software well” in the age of AI, Mohammad Azam takes the question one step further: first, we need to decide “what should be built.” As AI continues to reduce the cost of implementation, understanding the business, clarifying requirements, asking the right questions, communicating and collaborating, and evaluating tradeoffs become even more important. AI can produce ten implementation approaches in seconds, but it doesn’t know why a particular business rule exists within a company, nor can it take responsibility for the final product on behalf of the developer. Technical skills have not lost their value—they remain the foundation for judging whether AI-generated results are sound. What may become scarcer in the future is not the ability to “write more code,” but the ability to understand the problem, make sound judgments, and ultimately solve the right problem.

Tool

GlyphKit: Precise Glyph Layout in SwiftUI with Vector Outlines

Displaying a character in SwiftUI is easy, but making a glyph precisely occupy a specified region is not. Text is designed primarily for text layout, where baselines, font metrics, and Dynamic Type can all influence the final result.

GlyphKit takes a different approach by treating glyphs as graphics: it extracts the vector outline (CGPath) of an individual character through Core Text and renders it with SwiftUI Canvas, providing more direct control over size and positioning. GlyphKit is not a replacement for Text. It is better suited to individual decorative glyphs, while complex graphemes, ligatures, and content that requires text accessibility should still be handled by a full text layout system.

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

Share

越来越慢的 App Review，拦住了谁？

网页版

App Store 审核变慢，已经是越来越多开发者能够明显感受到的变化。在 Vibe Coding 时代，App 的开发和迭代成本大幅降低，审核压力随之增加并不难理解。但问题在于，更慢的审核似乎只是被不断增长的提交数量拖垮，却没有相应提高诈骗 App 进入商店的门槛。

最近，Jeff Johnson 在 Mac App Store 中发现了一款颇为可疑的 Safari 扩展：截图疑似 AI 生成，展示着并不存在的“4.9 分”评分，部分五星评论甚至早于 App 的上架时间。继续调查后，他发现该扩展的开发者在 App Store 中拥有 41 款 App，过去一年至少产生了 368 次获批的审核提交，平均几乎每天一次。而在同一时间，著名开发者 Marco Arment 的新 App 却已经在审核队列中等待了 12 天。

这形成了一种颇为尴尬的局面：一方面，可疑甚至涉嫌诈骗的 App 能够通过审核并在排行榜上高歌猛进；另一方面，AI 又让快速开发、频繁迭代变得前所未有地容易，大量正常提交与高风险提交共同涌入同一套审核机制，持续消耗有限的审核资源。

一个紧迫的问题摆在眼前：App Review 是否还应该孤立地对待每一次提交？

Johnson 建议引入类似信用体系的机制，让长期遵守规则、保持良好审核记录的开发者获得更快的审核，将更多资源投入高频、批量和存在异常行为的账号。反对者则担心，这最终可能演变成对知名开发者或付费开发者的优待，进一步抬高新人进入 App Store 的门槛。

在 AI 大幅降低 App 生产成本之后，仅仅把每一次 submission 当作彼此孤立的对象进行审核，这种模式已经越来越难以为继。将开发者历史、提交频率、App 之间的相似度、metadata 异常等纳入风险评估，我认为并无不妥。信用良好不意味着免审，而是减少重复、低价值的检查；异常账号也不是禁止提交，而是接受更深入的审查。

或许 App Review 真正需要升级的，不只是审核效率，而是从单点“审核”迈向“行为判断”。

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

原创

ContentBuilder 解析：SwiftUI 类型检查性能提升的秘密

在 WWDC 2026 的 SwiftUI 新功能 Session 中，苹果工程师介绍了 SwiftUI 的一个新特性——ContentBuilder。从使用方式看，它似乎只是一个覆盖范围更广的 ViewBuilder：过去分别接受 ViewBuilder、ToolbarContentBuilder、CommandsBuilder 的 API，如今可以共享同一个 builder。苹果同时宣称，这项调整能够显著改善类型检查性能。本文将解析 ContentBuilder 的本质，探索性能提升背后的奥妙。

近期推荐

无界面 Xcode：利用 MCP 建立 AI 辅助开发的全自动流程 (Headless Xcode: From Prompt to Simulator with MCP)

Xcode 27 beta 5 新增了 xcrun mcp-server，让 Xcode 的 MCP 能力可以在不启动 Xcode UI 的情况下，以后台服务的形式提供给外部 Coding Agent。⁠Artem Novichkov 以 Claude Code 为例，完整展示了一条 Headless Xcode 工作流：从创建 Xcode 工程、生成 SwiftUI 代码、构建项目和渲染 Preview，到启动 Simulator、读取 accessibility hierarchy、执行交互，并最终结合截图与 OSLog 验证应用状态。这意味着，从 Prompt 到代码，再到运行和验证，一个不依赖 Xcode UI 的完整开发闭环已经初具雏形。

iOS 26: Data Detector

iOS 26 引入了全新的 DataDetector，为已经服役多年的 NSDataDetector 提供了一套更符合现代 Swift 风格的替代方案。⁠Anton Gubarenko 通过大量示例介绍了新 API 的使用方式：开发者可以直接通过 StringProtocol.dataDetectorMatches 获得 AsyncSequence，并使用 Swift 原生 Range 和强类型的语义结果识别文本中的邮箱、电话号码、日期、地址、金额、度量值、航班号、物流单号等内容。新 API 不仅使用起来更加自然，能够识别的语义对象也更加丰富。

用 ContinuousClock 替代 Date() 测量持续时间 (Measuring Elapsed Time in Swift with ContinuousClock)

很多开发者仍习惯使用 Date() 记录开始和结束时间，但 Date 并不是回答“这段操作持续了多久”的理想工具。⁠Kyle Browning 围绕 Swift 5.7 引入的 Clock 体系，介绍了两种更加可靠的时间测量方式：ContinuousClock 和 SuspendingClock。

ContinuousClock 单调递增，并包含设备休眠期间经过的时间，适合衡量真实世界中的 elapsed time；SuspendingClock 则会在设备休眠时暂停，更适合衡量实际运行时间。Kyle 给出了一个简单的建议：如果代码中的 Date() 是用来“计时”而不是“记录时间点”，通常就应该考虑换成 ContinuousClock。

用 XCUITest 自动生成 App 宣传视频 (From XCUITest to Promo Video)

每次修改 App 界面，都可能意味着 App Store 截图、宣传视频以及不同语言版本的素材需要重新制作。⁠Noam Efergan 提出了一个很有意思的解决思路：将营销素材也视为可以重复生成的 build artifacts。他通过 launch arguments 和固定的测试数据，让真实 App 可以随时进入确定的 UI 状态，再使用 XCUITest 自动完成不同 locale 下的截图，并将结果交给 Remotion 生成宣传视频。整个流程并没有为了营销重新制作一套 mock UI，而是始终以实际运行的 SwiftUI 界面作为素材来源。这也展示了 testability 在测试之外的另一层价值：当应用能够稳定、准确地重现某个状态时，同一套能力也可以服务于调试、演示、本地化以及营销内容的自动化生产。

AI 时代，软件工程基本功比以往任何时候都更重要 (Software Engineering fundamentals matter more than ever)

当 Coding Agent 已经能够快速生成代码、完成测试，甚至独立实现相当复杂的功能后，“能不能做出来”正在逐渐成为软件开发中更容易解决的问题。Joseph Heck 认为，真正困难的部分依然没有消失：如何设计清晰的边界与抽象，如何让软件具备可调试性、可维护性和可组合性，以及如何在各种约束之间做出合理的取舍。AI 可以显著降低实现成本，却无法替代这些建立在经验、判断和长期视角之上的软件工程能力。某种意义上，当“写出能工作的代码”越来越容易，Software Engineering fundamentals 反而变得更加重要。

为什么说在 AI 时代，“定义问题”比“写出代码”更重要？(Why Soft Skills Matter More Than Technical Skills in the Age of AI)

如果上一篇讨论的是 AI 时代“怎样把软件做好”，Mohammad Azam 则把问题向前推进了一步：我们首先需要判断“应该做什么”。当 AI 不断降低代码实现的成本，理解业务、澄清需求、提出正确的问题、沟通协作以及评估取舍的重要性反而更加突出。AI 可以在几秒钟内给出十种实现方案，却不知道公司的某条业务规则为何存在，也无法替开发者承担最终交付的责任。技术能力并没有因此失去价值——它仍然是判断 AI 生成结果是否合理的基础；只是未来更加稀缺的，或许不再是“能够写出多少代码”，而是理解问题、做出判断，并最终解决正确问题的能力。

工具

GlyphKit：在 SwiftUI 中用矢量轮廓精准控制字形排版

在 SwiftUI 中显示一个字符很简单，但要让字形精确地占据指定区域，却并不容易。Text 的首要目标是文本排版，基线、字体度量以及 Dynamic Type 都可能参与最终布局。

GlyphKit 选择把字形当作图形处理：通过 Core Text 提取单个字符的矢量轮廓（CGPath），再使用 SwiftUI Canvas 绘制，从而获得更直接的尺寸与位置控制。GlyphKit 并非 Text 的替代品。它更适合单个、装饰性字形；复杂字素、连字及需要文字辅助功能的内容，仍应交给完整的文本排版系统。

求贤

[深圳 / 上海 / 北京] 抖音研发 - 客户端渲染引擎研发工程师（iOS / 跨端渲染）

团队介绍

团队介绍：抖音研发部门负责多款大型产品的研发，包括但不限于抖音、西瓜视频、汽水音乐。 加入我们，你将有机会参与亿级用户场景的开发与架构工作，使用前沿的技术助力业务一起不断成长。

岗位描述

1. 负责客户端跨端渲染基础框架的功能迭代与性能优化，持续提升复杂界面的流畅度与稳定性；

2. 参与声明式 UI 框架在 iOS 上的能力建设，包括核心渲染能力、系统特性适配与配套研发设施；

3. 深入渲染链路开展性能分析与调优，定位并解决卡顿、掉帧、内存与启动等关键问题；

4. 参与渲染性能监控体系建设，结合监控数据推动问题的自动化分析、归因与治理；

5. 沉淀通用优化方案与技术体系，对外进行技术输出，提升公司客户端整体研发效率与技术影响力。

岗位要求

1. 本科及以上学历，计算机及相关专业；

2. 3年以上 iOS/Mac 客户端开发经验，熟悉 Apple SDK，熟练掌握 Swift/C++；

3. 熟悉 SwiftUI/Compose 等声明式UI框架的渲染机制，或有跨端UI框架的开发、落地经验；

4. 具备扎实的性能优化能力，熟练使用 Instruments、Time Profiler、Allocations、System Trace 等工具进行分析与调优；

5. 具有良好的代码驾驭能力与技术设计能力，能独立完成模块设计与复杂问题攻坚；

6. 良好的沟通协作能力与服务意识，责任心强、自驱力强、追求卓越。

联系方式

内推联系：邮箱 yexulei.swift@bytedance.com

联系时请备注「客户端渲染引擎 + 姓名 + 工作年限」

Apple Intelligence Has Passed Chinese Government Review and Is Coming to China

Read on web →

At WWDC 26, Apple unveiled a new Apple Intelligence architecture. Gemini was introduced on the cloud side, while Apple also confirmed that its third-generation Apple Foundation Models were built in collaboration with Google. For a while, this made me think that bringing Apple Intelligence to China might actually become even more difficult.

But things moved faster than expected. In July, Apple Intelligence appeared on the latest list of generative AI services registered with China’s Cyberspace Administration of China (CAC). Then, just two days ago, Apple confirmed that Alibaba’s Qwen would be involved in the Chinese version of Apple Intelligence, and the integration briefly appeared in Apple’s official documentation. Although the document was temporarily taken down the day after going live on August 8, its detailed setup instructions and privacy descriptions had already revealed a fairly complete picture of how the integration would work. This suggests that the official launch of Apple Intelligence in China is now entering its final countdown.

In addition to Alibaba’s Qwen, the registration information also revealed that Baidu will participate deeply as a partner in the AI search and visual search capabilities of the Chinese version of Apple Intelligence. In other words, Apple can not only adjust the underlying models and service providers by region, but also rely on more than one partner within the same market.

As countries and regions continue to strengthen their requirements around privacy, data, and AI services, regional differences are becoming almost unavoidable. China is becoming Apple’s first major example of a new approach: keeping the overall Apple Intelligence product experience and developer interfaces relatively consistent, while selecting different underlying models based on local regulations and ecosystems. This model is likely to appear in more markets over time and could become an important part of Apple Intelligence’s global expansion.

For developers using Apple Intelligence APIs, this is also good news. If Apple can continue to maintain consistency at the API layer, developers should theoretically not need to maintain completely different implementations for different markets. It would also allow apps that rely heavily on Apple Intelligence capabilities to reach a much broader audience.

Gemini and Qwen may not be the two most prominent names in the Agent scenarios I use day to day, but both perform quite well in areas such as world knowledge and language understanding. Given that Apple Intelligence is currently more focused on system-level assistance, and that these partners also bring mature model infrastructure and extensive cloud service experience, Apple’s choices seem quite reasonable.

Apple Intelligence has become one of Apple’s most important entry points into the AI era. Its current capabilities are still somewhat short of my personal expectations, but starting in 2026, it is at least beginning to reach substantially more users around the world. Rather than focusing only on how many tasks it can complete today, I am more interested in seeing how Apple will use WWDC 2027 to bring AI more deeply into its hardware, operating systems, and services ecosystem.

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

Controlling Orphans in SwiftUI Text: Uncovering the Undocumented avoidsOrphans

SwiftUI’s Text has a default behavior: when the last line of a paragraph contains only a single orphaned word or character, it automatically moves an entire word group from the previous line down to avoid leaving it alone. While this behavior is often helpful, it can also leave excessive whitespace on the preceding line, especially in narrow layouts or mixed Chinese–English text, disrupting the visual balance of the paragraph. UIKit allows developers to disable this behavior through NSParagraphStyle, but SwiftUI exposes no public API for doing so. This article uncovers an undocumented SwiftUI API that has existed for quite some time—avoidsOrphans—allowing developers to regain control over this behavior.

Recent Recommendations

An Even Closer Look at Protocols and Global Actors

As Swift’s concurrency model continues to evolve, some engineering decisions that once felt obvious are beginning to change alongside the language itself. In this article, Matt Massicotte goes beyond the familiar question of whether @MainActor belongs on a protocol or individual methods, using it as a starting point to explore API design in the era of Swift Concurrency. Rather than promoting a so-called “best practice,” Matt emphasizes a broader principle: isolation is a constraint, and constraints should arise from real requirements—not from habit.

Weekly Tuist News #1

As AI agents become increasingly integrated into the development workflow, engineering tools such as Tuist are becoming more important—even for independent developers.

Longtime Tuist community contributor Lee YoungJun has launched a new series, Weekly Tuist News, dedicated to tracking the Tuist ecosystem. Rather than simply summarizing release notes, the series combines community updates with the author’s hands-on experience. In its debut issue, he covers SwifterPM becoming the default dependency restoration method, new controls for target cache invalidation, and Tuist’s auth.md support for coding agents, along with practical observations from real-world usage.

Preview Multiple SwiftUI View States with #Preview(arguments:)

Most SwiftUI components have more than one meaningful state: empty, loading, error, permission-restricted, and so on. During development, we often end up maintaining multiple nearly identical #Preview declarations or placing every state into a single VStack. Xcode 27’s new #Preview(arguments:) API is designed specifically for this scenario, generating multiple independent previews from a collection of state data while allowing each one to be inspected individually in the Canvas.

In the article, Artem Novichkov also shares his approach to organizing previews: arguments should describe business states, not environments. Even as the API evolves, this separation between application state and runtime environment remains a valuable design principle.

Concentric Buttons with OS 27’s SwiftUI APIs

WWDC26 introduced GeometryProxy.concentricCornerRadii, allowing SwiftUI developers to access a container’s concentric corner radius information. However, ButtonBorderShape remains a closed type, making it impossible to create truly custom button border shapes directly. Alexander Weiß demonstrates how to leverage this new API together with onGeometryChange, a custom ViewModifier, and method overloading to build a concentric button solution that feels almost indistinguishable from a native SwiftUI API.

For new APIs such as GeometryProxy.concentricCornerRadii, it usually takes only a few seconds to understand what they do. The real challenge comes when using them in production, where implementation details and framework limitations quickly surface. Rather than serving as an API introduction, this article explores those practical considerations and the scenarios where the API can be effectively applied.

Swift, AI, and the future of software development

AI has become an indispensable part of many developers’ workflows, but beyond improving productivity, it is also quietly changing the relationship between developers and their code. In this article, Tibor Bödecs candidly reflects on his own experience over the past year: embracing AI for its efficiency while missing the satisfaction of writing code and deeply understanding problems; believing that AI will continue to reshape software development while hoping it remains a tool that augments human thinking rather than replacing it.

Over the past months, I’ve found myself struggling with many of the same questions as Tibor Bödecs. While AI has taken away some of the joy and created a subtle sense of distance between myself, the code, and the products I build, I’ve also been working relentlessly to gain greater control over it—to make it an extension of my own thinking, rather than allowing myself to become an extension of it.

Tools

Gitwyn: A Git Client Designed Around the Xcode Workflow

Although Xcode’s built-in Git support has improved significantly over the past few releases, it still falls short in both usability and functionality for many everyday workflows. Developed by Karthik K, Gitwyn is a native Git client designed around the Xcode workflow. Press ⌘⇧E in any Xcode project to review changes, organize staged files, generate commit messages, and push code—all without leaving Xcode or switching to another Git tool.

One of Gitwyn’s standout features is its ability to generate commit messages locally using on-device Apple Intelligence based on staged changes. No network connection is required, and your source code never leaves your Mac. More importantly, it streamlines the entire flow of reviewing diffs, organizing commits, generating descriptions, and pushing changes, keeping Git operations within the Xcode development context.

VersionedDocC: Bringing Version Management to Swift-DocC

For years, every WWDC I would immediately open Apple’s developer documentation and use the “API Changes” feature to compare different Xcode and SDK releases, tracking newly introduced, modified, and deprecated APIs. Unfortunately, this incredibly useful capability disappeared after the documentation website redesign in 2025. Although the old comparison URLs still exist, they no longer present complete API changes.

Developed by Kyle Ye, VersionedDocC brings this capability back to DocC. It adds a release orchestration layer on top of the existing Swift toolchain, generating stable URLs for different versions, providing a version selector, displaying public API differences between adjacent releases based on symbol graphs, and avoiding repeated builds of historical documentation through immutable caching. The project also includes a SwiftPM plugin, GitHub Action, and GitHub Pages workflow, with support for multi-platform symbol graphs, external modules, and standalone DocC catalogs.

Swift Subprocess 1.0

After a year of iteration, Swift’s official swift-subprocess project released version 1.0 this week. It is a cross-platform subprocess library built on Swift Concurrency, providing a unified way to launch commands, supply input, stream output, and manage process termination and cancellation across macOS, Linux, Windows, Android, and BSD.

It is particularly well suited for Swift CLIs, build systems, server applications, developer tools, and macOS automation. Note that version 1.0 requires Swift 6.2 and is not intended for regular iOS applications. It also deliberately leaves higher-level features such as sandboxing, command authorization, and pseudo-terminals (PTYs) to other layers.

swift-subprocess also fills an important missing piece for building native AI agents in Swift: reliably executing external tools, continuously receiving their output, and properly managing subprocess lifecycles. The model decides what to do, while Subprocess provides a more controllable, observable, and Swifty way to execute those decisions.

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

Share

Apple Intelligence 已通过中国政府审核，即将在中国提供服务

网页版

在 WWDC 26 上，苹果公布了新的 Apple Intelligence 架构，不仅在云端引入 Gemini，第三代 Apple Foundation Models 也确认由苹果与 Google 合作构建。这一度让我以为，Apple Intelligence 进入中国市场的难度反而进一步增加了。

但事情的发展比预想中更快。7 月，Apple Intelligence 已经出现在中国国家互联网信息办公室（CAC）公布的最新一批生成式 AI 服务备案名单中。而就在两天前，苹果又确认阿里巴巴 Qwen 将参与中国版 Apple Intelligence，并一度出现在苹果的官方文档中。虽然该文档在 8 月 8 日短暂上线后于次日被暂时撤回，但其中详细的操作指引和隐私说明，已经向外界揭示了相当完整的集成方式。这意味着，Apple Intelligence 在中国正式提供服务已经进入倒计时。

除了阿里巴巴的 Qwen，备案信息还披露，百度也将作为合作伙伴深度参与中国版 Apple Intelligence 的 AI 搜索与视觉搜索。这意味着，苹果不仅可以根据地区调整底层模型和服务提供商，而且这样的合作关系也并非只能由一家厂商承担。

随着各个国家和地区对隐私、数据以及 AI 服务监管要求的不断加强，区域化差异几乎已经不可避免。苹果正在中国率先实践一种新的方式：在保持 Apple Intelligence 整体产品体验和开发接口相对统一的同时，根据不同地区的法规与生态选择不同的底层模型。未来，这种模式很可能还会出现在更多市场，并成为 Apple Intelligence 全球化过程中相当重要的一部分。

对于使用 Apple Intelligence API 的开发者来说，这同样是一个好消息。如果苹果能够继续维持 API 层的一致性，开发者理论上无需为了不同市场维护完全不同的实现方案，也意味着那些以 Apple Intelligence 能力为重要特色的应用，将有机会触达更广泛的用户。

Gemini 和 Qwen 或许并不是我日常 Agent 使用场景中最耀眼的两个名字，但它们在世界知识、语言理解等方面都有相当不错的表现。考虑到 Apple Intelligence 当前更偏向系统级辅助能力，而这些合作伙伴又拥有成熟的模型基础设施和云服务经验，苹果这样的选择其实相当合理。

Apple Intelligence 已经成为苹果在 AI 时代最重要的入口之一。它目前的能力距离我的个人期待仍有一些距离，但至少从 2026 年开始，它正在真正覆盖全球更多用户。相比于今天它究竟能完成多少任务，我更期待 WWDC 2027 上，苹果会如何进一步让 AI 深入融入自己的硬件、系统与服务生态。

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

原创

在 SwiftUI Text 中控制孤行：挖掘未公开的 avoidsOrphans

SwiftUI 的 Text 有一项默认行为：当段落末行只剩一个孤词或孤字时，它会主动把上一行的完整词组一并推到末行，避免“落单”。这份体贴多数时候是对的，但代价是上一行可能留下一大片空白——在窄容器或中英混排的场景中，反而破坏了段落的均衡。麻烦在于，UIKit 允许开发者通过 NSParagraphStyle 关掉这项策略，SwiftUI 却没有提供任何公开接口。本文将挖掘 SwiftUI 中一个早已存在、却始终未曾公开的 API —— avoidsOrphans，让开发者重新拿回这项控制权。

近期推荐

再谈协议与全局 Actor 的设计权衡 (An Even Closer Look at Protocols and Global Actors)

随着 Swift 并发模型不断演进，一些过去被视为理所当然的工程取舍，也开始因语言能力的增强而发生变化。在本文中，⁠Matt Massicotte 并没有停留在讨论“@MainActor 应该放在 protocol 上还是方法上”，而是借此进一步探讨了 Swift 并发时代的 API 设计思路。相比给出一种所谓的“最佳实践”，Matt 更强调一种设计思路：隔离是一种约束，应当源于真实需求，而不是沿袭既有习惯。

Tuist 每周动态第一期 (Weekly Tuist News #1)

随着 AI Agent 越来越深入开发流程，Tuist 这类工程管理工具的重要性也在不断提升，对于独立开发者而言同样如此。

作为长期活跃于 Tuist 社区的开发者，⁠Lee YoungJun 推出了一个专门追踪 Tuist 生态的新系列 Weekly Tuist News。与单纯汇总 release notes 不同，这个系列还会结合社区动态以及作者在实际项目中的使用体验。在创刊号中，他介绍了 SwifterPM 成为默认依赖恢复方式、Target 缓存失效条件的新控制能力，以及 Tuist 面向 Coding Agent 的 auth.md 支持，并结合实际使用分享了自己的验证过程与观察。

使用 #Preview(arguments:) 轻松预览 SwiftUI 视图的多状态

大多数 SwiftUI 组件都不只有一种状态：空数据、加载中、错误、权限受限等。开发过程中，我们通常会维护一组重复的 #Preview，或将所有状态放进一个 VStack 中统一展示。Xcode 27 新增的 #Preview(arguments:) 正是为这一场景而设计，它能够根据一组状态数据自动生成多个独立的 Preview，并支持在 Canvas 中单独查看每一种状态。

⁠Artem Novichkov 在文中也分享了他组织 Preview 的思路：arguments 应该描述业务状态（State），而不是环境（Environment）。即使未来 API 继续演进，这种将业务状态与运行环境分离的设计理念依然具有长期参考价值。

用 iOS 27 新 API 实现 SwiftUI 同心圆角按钮 (Concentric Buttons with OS 27’s SwiftUI APIs)

WWDC 26 中，苹果给 SwiftUI 新增了 GeometryProxy.concentricCornerRadii，让开发者能够获取容器的同心圆角信息。不过，ButtonBorderShape 仍然是一个封闭类型，无法直接实现真正的自定义按钮边框。⁠Alexander Weiß 利用这一新 API，结合 onGeometryChange、自定义 ViewModifier 与方法重载，实现了一套使用方式几乎与系统 API 无异的同心按钮方案。

对于 GeometryProxy.concentricCornerRadii 这类新增 API，我们往往只需几秒钟就能知道它的作用；但真正应用到项目中时，才会发现还有不少实现细节和框架限制需要考虑。与其说这是一篇 API 介绍，不如说 Alexander 分享了它在实际使用中的注意事项，以及值得尝试的应用场景。

Swift、AI 与软件开发的未来展望 (Swift, AI, and the future of software development)

AI 已经成为许多开发者工作流中不可或缺的一部分，但它在提升效率的同时，也悄然改变着开发者与代码之间的关系。⁠Tibor Bödecs 在这篇文章中真诚分享了自己这一年来的困惑：一方面享受 AI 带来的高效率，另一方面又怀念亲手写代码、深入理解问题的过程；既相信 AI 会持续改变软件开发，也希望它始终只是帮助开发者思考与创造的工具，而不是取代思考本身。

在过去一段时间中，AI 给我带来的困惑与 Tibor Bödecs 很相似。尽管它让我失去了一些乐趣，对代码、对产品产生了某种疏离感，但我也一直不懈地尝试对 AI 建立更强的掌控力，让它更好地为我所用，成为我的外脑，而不是让我沦为它的辅助。

工具

Gitwyn：围绕 Xcode 工作流设计的 Git 客户端

尽管近几个版本中 Xcode 的 Git 功能已经有了明显改善，但无论是使用体验还是功能完整性，仍难以满足部分开发者的在不同场景下的需求。由 ⁠Karthik K 开发的 Gitwyn，是一款围绕 Xcode 工作流设计的原生 Git 客户端。在任意 Xcode 项目中按下 ⌘⇧E，即可查看改动、整理暂存内容、生成提交信息并推送代码，全程无需切换到终端或其他 Git 工具。

Gitwyn 的一项特色功能是利用设备端 Apple Intelligence，根据已暂存的代码自动生成提交信息。无需联网，也不会上传源码。相比单纯减少一次输入，它更希望将查看差异、组织提交、生成说明和推送代码整合为一段连续的开发流程，让 Git 操作尽可能留在 Xcode 的工作上下文中。

VersionedDocC：为 Swift-DocC 补上版本管理

过去几年，每逢 WWDC 召开，我通常都会第一时间打开苹果开发者文档，通过“API 变化（API Changes）”功能比较不同 Xcode 与 SDK 版本，查看 API 的新增、修改与弃用。遗憾的是，这项颇为实用的功能在 2025 年的文档网站改版后消失了。原有的差异查询地址虽然仍可访问，却已无法呈现完整的 API 变化。

Kyle Ye 开发的 VersionedDocC，恰好为 DocC 补上了这一能力。它在原有 Swift 工具链之上增加了一层发布编排：为不同版本生成稳定地址，提供版本选择器，依据符号图展示相邻版本的公开 API 变化，并通过不可变缓存避免反复构建历史文档。项目同时提供 SwiftPM 插件、GitHub Action 和 GitHub Pages 工作流，也支持多平台符号图、外部模块及独立 DocC 目录。

Swift Subprocess 1.0

历经一年迭代，Swift 官方项目 swift-subprocess 本周发布 1.0 正式版。它是一套基于 Swift Concurrency 的跨平台子进程库，可以在 macOS、Linux、Windows、Android 与 BSD 系统上，以统一方式启动命令、提供输入、流式读取输出，并管理进程的退出与取消。

它尤其适合 Swift CLI、构建工具、服务器程序、开发者工具与 macOS 自动化。需要注意的是，1.0 要求 Swift 6.2，不面向普通 iOS App，也未提供沙箱、命令授权或伪终端（PTY）等更高层能力。

swift-subprocess 也补上了 Swift 构建本地 Agent 所需的一块重要拼图：可靠执行工具、持续接收运行结果，并妥善管理子进程生命周期。模型决定“做什么”，Subprocess 则让“如何执行”变得更可控、更可观测，也更符合 Swift 的语言范式。

Hot Tea or Iced Coffee

Read on web →

Recently, the temperatures in my city have been breaking historical records. Since the end of July, we’ve been stuck in a stretch of scorching weather lasting more than ten days, with temperatures consistently above 30°C. While that may not sound particularly extreme on its own, paired with humidity exceeding 80%, it leaves behind a lingering sense of heat that never quite goes away—even after spending the entire day in an air-conditioned room set to 25°C.

I’ve found myself turning to tea and coffee to improve how I feel. Interestingly, only a cup of hot tea gives me the satisfying sensation of heat escaping with perspiration, while only an iced coffee brings an immediate, refreshing coolness. I suspect this isn’t simply a matter of physics. More likely, it’s a psychological association shaped by years of habit.

There’s an old Chinese saying: “A calm mind brings a cool body.” I can’t claim to have reached that level of serenity. For now, I still rely on these simple drinks to help me find a bit of balance between warmth and coolness.

Hopefully, this hot and humid summer will return to normal sooner rather than later.

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

Liquid Glass: A Field Guide to UIKit Compatibility Pitfalls

While Liquid Glass introduces a fresh interaction experience, it also makes UIKit compatibility significantly more complex. The same UI can behave very differently across iOS 18, iOS 26, and iOS 27, while different API combinations and implementation approaches may introduce their own compatibility pitfalls. Drawing from real-world project experience, Megabits summarizes common issues involving Sheets, Navigation, Popovers, Toolbars, and other UIKit components, while also explaining lower-level behaviors such as UIBarButtonItem, CABackdropLayer, and the Scroll Edge Effect, complete with practical solutions and runnable demos.

The Map, Drawn Twice

Apple’s UI rendering stack spans Core Graphics, Core Text, Core Image, Core Animation, and SwiftUI. Although developers work with these frameworks regularly, many never fully understand the distinct responsibility of each layer. In the inaugural issue of Apple UI Insider, Mihaela Mihaljević Jakić presents a conceptual map that traces the journey from Swift code to the final pixels on screen.

Mihaela adopts a fascinating validation approach: every illustration is rendered twice from the exact same scene description—once by a custom clean-room rendering engine, and once by Apple’s Core Graphics—before being compared pixel by pixel. Although nearly half of the pixels differ, the average pixel difference is only around 0.1%, making the two images visually almost indistinguishable. This methodology of understanding system behavior through independent implementations, reproducible experiments, and quantitative measurements is arguably even more compelling than the article itself, and makes the rest of the series especially worth looking forward to.

Finally found a use case for .fixedSize

.fixedSize is one of SwiftUI’s most overlooked modifiers. Many developers associate it only with niche use cases such as preventing text wrapping. Starting from a common layout requirement—making every card inside a horizontal ScrollView match the height of the tallest one—Omar Elsayed demonstrates how .fixedSize provides an elegant solution.

Perhaps .fixedSize has never become widely adopted because its name is rather abstract. What exactly is being “fixed”? And what does “size” actually refer to? If you’d like to better understand why it changes layout behavior, you may find my previous series, SwiftUI Layout: The Mystery of Size, helpful. It recreates fixedSize from scratch and breaks down the layout negotiation mechanism behind it.

Two Interesting Explorations of LazyVStack’s Layout Mechanism

On the Apple Developer Forums, alextar04 published two in-depth analyses of LazyVStack. One investigates blank screens and truncated cells during fast scrolling, while the other examines why GeometryReader reports multiple different sizes when used inside a LazyVStack (Thread 2). Beyond providing minimal reproducible examples, the author combines insights from the WWDC 26 Lazy Stack session, SwiftUI logging, and experimental observations to reconstruct how SwiftUICore—including symbol resolution and CA::Transaction validation—might estimate sizes and validate layouts, using these hypotheses to explain the observed behavior.

These two posts also highlight the design differences between List and LazyVStack from another perspective. The author suggests that, in order to support lazy layout, LazyVStack relies on size estimation under certain circumstances, which naturally leads to behavior different from List. This further illustrates why neither container is universally better—their strengths simply apply to different scenarios.

Swift on Windows: A Year of Refinement

A year ago, Swift on Windows had already proven itself capable of supporting real production applications. But being “functional” is not the same as being predictable. Over the past year, The Browser Company, together with Apple and the Swift community, has focused on strengthening the platform’s foundations: rebuilding the runtime build system with modern CMake, introducing the Experimental Swift SDK, formalizing both static and dynamic linking models, and improving runtime selection and distribution across multi-toolchain environments.

What truly advances the maturity of a cross-platform ecosystem is often not a headline-grabbing feature, but the engineering details that are easy to overlook: whether build configurations are reproducible and auditable, whether runtimes can be bound deterministically, whether tools can be distributed independently, and whether CI and developer environments behave consistently. This article offers an excellent overview of how Swift on Windows has evolved over the past year—not through flashy new capabilities, but through continuous refinement of its engineering foundations.

Memo Property: Reusing More Stateful Business Logic for SwiftUI Views

In TaskProperty, Rick Van Voorden demonstrated how custom DynamicProperty types can extract stateful business logic from SwiftUI views while remaining aligned with the view lifecycle. Building on that idea, this article leverages Swift’s latest Parameter Packs (Variadic Generics) to implement a React-like useMemo mechanism for SwiftUI: filtering, sorting, and other expensive computations are recomputed only when explicitly declared dependencies change, while cached results are reused for unrelated view updates.

One Model Object, Multiple Editing Flows: The Missing Layer Between Model and UI

Since the introduction of Observation, many developers have assumed that Combine is gradually becoming less relevant in SwiftUI. In this article, Sergey Tristan presents a different perspective. When multiple independent editing flows share the same model object, with each flow interested in only part of its state, Observation excels at efficiently detecting changes, while Combine is better suited for composing, transforming, and continuously synchronizing data. Rather than replacing one another, the two complement each other.

The article introduces a Projection layer between the model and the UI that transforms one or more continuously changing data sources into reactive representations tailored for different consumers. Whether or not you adopt this architecture, it raises an interesting question: as applications evolve to include increasingly independent yet interconnected editing flows, do we need an abstraction beyond DTOs, ViewModels, and Observation to organize these continuously evolving data flows?

Tools

Apple External Display Support Lookup

External display support across Apple devices can be surprisingly complicated. Capabilities vary by chip generation, hardware model, and even operating system version. Created by Parish Khan, RetinaDesk provides a convenient online lookup tool that lets you quickly check how many external displays a Mac, iPad, or iPhone supports, along with maximum resolution, refresh rate, extended display support, mirroring capabilities, and more.

For developers working with multi-display setups, Stage Manager, or external display features, this is a handy reference that makes it much easier to verify device capabilities without digging through Apple’s technical specifications.

Agent Island

Agent Island is an open-source local monitoring tool created by Tristan Tang. It continuously monitors the local session files generated by Claude Code and Codex, determines their current state in real time, and displays intuitive status updates and notifications through a Dynamic Island-style menu bar interface, so you no longer need to keep watching your terminal. It can also automatically execute predefined follow-up actions once your AI model usage window resets, helping long-running tasks resume seamlessly.

The project follows a local-first design, requiring no cloud services and uploading no conversation data. It also provides token usage statistics, quota reset countdowns, and weekly/monthly usage reports.

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

Share

热茶还是冰咖啡

网页版

最近我所在的城市，气温不断刷新历史纪录。从 7 月末开始，便陷入了持续十天以上、超过 30 摄氏度的高温酷暑。尽管从绝对数值上看并不算惊人，但配上超过 80% 的湿度，即便全天待在 25 度的空调房里，体内依然能攒出一股挥之不去的燥热。

我会通过喝茶、喝咖啡来改善“体感”。有意思的是，唯有热茶能带给我一种热量随汗水释放的通透感，而也唯有冰咖啡能带来片刻直截了当的清凉。我想，这未必是饮品本身的物理特性使然，或许更多是长期饮食习惯在心中留下的心理暗示。

中国有句老话叫“心静自然凉”。我自认还没达到这般超脱的心境，现阶段仍免不了借助这些杯中物，在冷热之间寻得一点平衡。

但愿这个闷热的夏天，能早点复归常态。

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

近期推荐

Liquid Glass：UIKit 适配踩坑实录

Liquid Glass 在带来全新交互体验的同时，也让 UIKit 的兼容性变得更加复杂。同一套 UI，在 iOS 18、iOS 26 与 iOS 27 上可能表现出截然不同的行为；不同的 API 组合与实现方式，也可能触发各式各样的兼容性问题。Megabits 结合真实项目经验，总结了 UIKit 下 Sheet、Navigation、Popover、Toolbar 等多个典型场景中的适配陷阱，并分析了 UIBarButtonItem、CABackdropLayer、Scroll Edge Effect 等底层行为，给出了对应的解决方案与可运行 Demo。

两度绘制的像素渲染地图 (The Map, Drawn Twice)

Apple 的 UI 渲染体系涉及 Core Graphics、Core Text、Core Image、Core Animation 与 SwiftUI 等多个层次，开发者虽然经常使用这些框架，却未必真正理解它们各自承担的职责。在 Apple UI Insider 的创刊号中，Mihaela Mihaljević Jakić 绘制了一张从 Swift 代码到最终像素的职责地图。

Mihaela 采用了一种很有意思的验证方式：每一张插图都由同一份场景描述生成两次，一次交给自己实现的 clean-room 渲染引擎，另一次交给 Apple 的 Core Graphics，再逐像素比较两者的输出。尽管约有一半像素存在差异，但平均像素差异仅约为 0.1%，视觉效果几乎完全一致。这种通过独立实现、可复现实验和量化结果来研究系统行为的方法，比文章本身介绍的内容更值得关注，也让人更加期待这一系列后续的研究。

终于为 .fixedSize 找到了合适场景 (Finally found a use case for .fixedSize)

.fixedSize 是 SwiftUI 中一个经常被忽视的 modifier，不少开发者对它的印象仍停留在避免文本折行等少数场景。⁠Omar Elsayed 从一个很常见的需求出发：如何让横向 ScrollView 中所有卡片都与最高的那一项保持相同高度，分享了自己借助 .fixedSize 找到解决方案的过程。

或许 .fixedSize 一直没有得到广泛使用，与它略显抽象的命名也有一定关系。究竟固定的是什么？对应的 size 又是什么？如果想深入理解它为何能够改变布局结果，可以参阅我之前写的《⁠SwiftUI 布局：尺寸》系列，其中通过实现 fixedSize 的复制品，拆解了它在 SwiftUI 布局协商中的工作机制。

关于 LazyVStack 布局机制的两次有趣探索

在 Apple Developer Forums 上，⁠alextar04 连续发布了两篇关于 LazyVStack 的分析帖。两篇帖子分别围绕快速滚动时可能出现的空白区域与 Cell 截断，以及 GeometryReader 在 LazyVStack 中获取到的尺寸为何会多次变化展开（⁠帖子 2）。作者不仅提供了最小复现工程，还结合 WWDC 26 关于 Lazy Stack 的介绍、SwiftUI 日志以及实验结果，尝试还原 SwiftUICore 底层（如符号计算与 CA::Transaction 提交验证）在估算尺寸、校验布局时可能采用的工作方式，并据此解释这些现象产生的原因。

这两篇帖子也从另一个角度展现了 List 与 LazyVStack 在设计理念上的差异。作者推测，LazyVStack 为了实现懒布局，会在部分场景下依赖尺寸估算等机制，因此与 List 呈现出不同的行为。这也说明了为什么两者并不存在绝对的优劣，而是⁠各自适用于不同的场景。

Swift on Windows：一年的打磨与完善 (Swift on Windows: A year of refinement)

Swift on Windows 在一年前已经能够支撑真实的生产应用，但“可以运行”并不等于“足够可预测”。⁠The Browser Company 与 Apple 及 Swift 社区将重点放在了基础设施的打磨上：使用现代 CMake 重构 Runtime 构建系统，推出 Experimental Swift SDK，明确静态与动态链接模型，并改善多工具链环境中的 Runtime 选择与分发问题。

真正推动跨平台成熟度提升的，往往不是某个引人注目的新特性，而是这些容易被忽视的工程细节：构建配置是否可审计、Runtime 能否精确绑定、工具是否可以独立分发，以及 CI 与开发环境能否始终保持一致。这篇文章很好地展示了 Swift 在 Windows 平台过去一年最重要的进步，更多来自工程能力的持续打磨，而非功能上的扩张。

MemoProperty：在 SwiftUI 中复用有状态业务逻辑 (Memo Property: Reusing More Stateful Business Logic for SwiftUI Views)

在 TaskProperty 中，Rick Van Voorden 展示了如何借助自定义 DynamicProperty，将带有生命周期和状态的业务逻辑从 View 中抽离出来。本文沿着相同的思路继续向前，结合 Swift 最新的参数包（Parameter Packs / Variadic Generics）等前沿语法，尝试在 SwiftUI 中实现一个类似 React useMemo 的机制：只有当显式声明的依赖发生变化时，才重新执行过滤、排序等计算，否则直接复用此前缓存的结果，避免 View 因无关状态变化而重复完成昂贵工作。

多流编辑下的状态同步：构建模型与 UI 之间缺失的“投影层” (One Model Object, Multiple Editing Flows: The Missing Layer Between Model and UI)

Observation 出现之后，不少开发者开始认为 Combine 在 SwiftUI 中已经逐渐失去价值。Sergey Tristan 的这篇文章则提供了一个不同的视角：当同一个模型对象需要被多个独立的编辑流程共享，并且每个流程只关心其中一部分状态时，Observation 负责高效地感知变化，而 Combine 更适合承担数据组合、转换与持续同步的职责，两者并非替代关系，而是可以各司其职。

文章提出了一个位于 Model 与 UI 之间的 Projection 概念，将一个或多个持续变化的数据源转换为不同消费者所需的响应式表示。无论是否认同这种架构，它都提出了一个值得思考的问题：当应用开始拥有越来越多独立却又相互关联的编辑流程时，是否需要一种不同于 DTO、ViewModel 或 Observation 的抽象来组织这些持续演化的数据流？

工具

Apple 外接显示器支持查询

苹果设备对外接显示器的支持一直比较复杂，不同芯片、不同机型，甚至不同系统版本之间都存在明显差异。由 Parish Khan 创建的 RetinaDesk 提供了一个在线查询工具，可以快速了解 Mac、iPad、iPhone 等设备支持的外接显示器数量、最高分辨率、刷新率，以及是否支持扩展显示、镜像模式等信息。

对于需要测试多屏显示、Stage Manager 或外接显示器相关功能的开发者，这也是一个很方便的参考工具，能够快速确认不同设备组合的能力边界，而无需逐一查阅 Apple 官方技术规格。

Agent Island

Agent Island 是一个由 ⁠Tristan Tang 开发的开源本地状态监视工具，它会持续读取 Claude Code 与 Codex 在本地生成的会话记录，实时判断当前状态，并通过菜单栏中的“灵动岛”样式组件提供直观的状态显示与提醒，让开发者无需一直盯着终端。它还支持在 AI 模型额度窗口重置后自动执行预设的后续操作，帮助长时间运行的任务更顺畅地衔接下去。

项目采用 Local-first 设计，不依赖云端服务，不上传任何会话内容，同时提供 Token 使用统计、额度重置倒计时、周/月报告等功能。

It’s Not That the Models Are Slower—The Tasks Have Become Bigger

Read on web →

Lately, even tasks that I consider relatively simple often take AI several minutes—or sometimes even tens of minutes—to complete. It gave me the impression that as models become more capable, they somehow have to become slower.

In reality, the main reason lies with me. Although today’s AI agents let us choose different models and reasoning levels, it’s much easier—and often more reliable—to simply hand even straightforward tasks to the most capable models. At the same time, modern agents no longer limit themselves to the small change you explicitly requested. They proactively expand their search, analyze whether the modification could affect other parts of the project, and try to identify potential issues before they happen. The models may be more powerful than ever, but they’re also taking on substantially more work for every task.

There’s another factor as well. As my trust in these models has grown, so has the scope of the tasks I assign to them. What used to be “refactor a function” or “improve a screen” has gradually become “implement a feature,” “build a module,” or even “create an entire product.” Without realizing it, I’ve started treating AI agents as genuine collaborators. The pace at which model performance improves simply hasn’t kept up with the way we now use them.

In other words, developers are no longer pursuing only “writing code faster.” Increasingly, we’re using AI to write better code, even if it takes longer.

The shift from question-answering to task delivery has happened in just a single year. As we grow accustomed to waking up and reviewing completed work, the real bottleneck is quietly moving elsewhere. We used to ask whether a model was capable of completing a task. Today, the more important questions are how to define a clear, verifiable objective, and how to reduce the cost of achieving it. AI is becoming more like a teammate, and the ability to organize and decompose work effectively is becoming the next competitive advantage.

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

Bluetooth without the delegate dance

Delegates remain a challenge many developers continue to face years after the introduction of Swift Concurrency. Not only do they often lead to cumbersome code organization, but under Swift 6’s strict concurrency checking they also become increasingly difficult to integrate naturally with modern concurrent code. Kyle Browning leverages Swift 6.2’s Custom Executor to bind CoreBluetooth’s callback queue directly to an Actor’s execution context, allowing delegate callbacks to run naturally within Actor isolation without additional locks, thread hopping, or synchronization logic.

Custom Executor allows an Actor’s tasks to run on a designated executor, making it a powerful tool for bridging traditional callback-based APIs with Swift Concurrency. If you’re facing similar migration or abstraction challenges, this implementation is well worth studying. I also explored this topic in depth using Core Data as an example in this article, explaining how to bind traditional serial queues to Actor executors for seamless integration with Swift Concurrency.

Working with Xcode on CI

As more developers adopt self-hosted macOS runners or cloud-based CI, reliably managing Xcode, Simulator Runtimes, and code-signing environments has become an essential part of engineering infrastructure. Dmitry Rodionov shares a collection of practical techniques for using the Xcode CLI in CI, including managing multiple Xcode installations with DEVELOPER_DIR instead of xcode-select, automating the installation and cleanup of Simulator Runtimes and Metal Toolchains, and reducing unnecessary recompilation during branch switching with Compilation Caching.

Squeeze every last bit of value out of GitHub Actions

Optimizing GitHub Actions doesn’t necessarily mean more aggressive caching, more complex workflows, or additional conditional logic. Instead, this article advocates a more valuable principle: every CI run should match the actual risk introduced by a change. Starting from the investigation of an apparently ordinary flaky test, Snow discusses how deterministic tests eliminate unnecessary reruns, how portable checks can be moved to Linux while leaving Xcode-dependent validation to macOS, and how Build, Test, or Build for Testing can be selected dynamically based on change risk to avoid wasting expensive runner time.

I particularly agree with one of the article’s core ideas: the goal of CI is not to “run more,” but to “answer the right questions.” Every expensive macOS build should validate a risk that a cheaper runner cannot, and every failure should provide actionable information that helps move the project forward.

Building adaptive non-modal panels in SwiftUI

Starting with WWDC26, iPhone-only apps running through iPhone Mirroring on a Mac or on an iPad enter a resizable environment. This means relying solely on horizontalSizeClass for layout decisions is becoming increasingly unreliable. Matthaus Woolard demonstrates how to build an adaptive non-modal panel by recording scene size and safe-area insets at the root using onGeometryChange, then choosing between bottom and side presentations based on the actual available width. One particularly useful technique is preserving the resolved layout cache during dragging, preventing adaptive content from changing size due to repeated measurements.

If your app is iPhone-only but still has users running it on iPad or macOS, layout adaptation deserves much more attention going forward. As discussed in From Size Class to Available Space, the era of resizable canvases no longer guarantees developers absolute control over interface layouts, instead giving users much greater control over how apps are presented.

SwiftUI @ContentBuilder - Faster Type Checking in Xcode 27

Xcode 27 introduces the new @ContentBuilder. Although it is currently just a type alias for ViewBuilder, Apple has begun recommending this new name in its latest SwiftUI APIs. Sagar Unagar explains the change and notes that, for most applications, there is no need to immediately replace every @ViewBuilder with @ContentBuilder, as existing code already benefits from the compiler improvements introduced in Xcode 27.

I haven’t written much SwiftUI code recently, so I haven’t yet experienced firsthand whether this change significantly improves compilation performance. That said, in previous projects I often noticed Xcode struggling with type inference and code completion whenever different builder content was mixed inside a ViewBuilder, especially with APIs like Table and Charts. If Xcode 27 truly improves these scenarios, then this change represents much more than just a new builder name.

Tool

tswift: A Lightweight Swift Runtime Built with Rust

Without relying on the Swift toolchain, LLVM, code generation, or any C dependencies, tswift can parse, semantically analyze, and execute Swift source code. Developed by Francis Chong, tswift implements the Swift frontend entirely in Rust, handling lexical, syntactic, and semantic analysis before interpreting Swift language semantics and standard library behavior through a tree-walking runtime.

Beyond the language runtime itself, the project is also exploring framework support. SwiftUI already has a basic rendering pipeline, while Charts currently implements 58 of 60 range-related members, can render Web SVG output, and can bridge to Apple’s native Charts framework on iOS.

Whether it’s the C-based miniSwift, the recent signs of the Swift compiler’s self-hosting progress, or the Rust-based tswift runtime, they all demonstrate that the Swift ecosystem is evolving toward a more open and diverse implementation landscape. As more implementation paths emerge, Swift’s cross-platform potential continues to grow beyond what many expected.

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

Share

不是模型变慢了，是任务变大了

网页版

最近，即便是一些我认为并不算复杂的工作，AI 交付结果也常常需要几分钟，甚至几十分钟。这让我产生了一种错觉：难道随着模型能力不断增强，速度只能越来越慢？

其实，真正的原因更多来自于我自己。虽然 Agent 提供了模型和思考强度的调整选项，但为了省事，也为了追求更高的成功率，我越来越习惯把一些原本并不复杂的任务直接交给高级模型。与此同时，如今的 Agent 也不会像过去那样只关注你要求修改的那一小块代码，而是会主动扩大搜索范围，分析改动是否会影响整个项目，并尝试提前发现潜在问题。模型虽然更强了，但完成一次任务所承担的工作也明显更多了。

除此之外，随着我对模型能力的信任不断提高，交给它的任务粒度也发生了变化。从最初修改一个函数、优化一个页面，到实现一个功能、完成一个模块，甚至直接开发一个产品，我已经不知不觉把 Agent 当成了一位真正的协作者。模型速度的提升，已经跟不上使用方式变化的速度。

换句话说，开发者追求的已经不再只是“更快地写代码”，而是借助 AI“更慢地写出更好的代码”。

从问答式，到交付式，只用了短短一年时间。当我们开始习惯一觉醒来接收成果时，真正的瓶颈也悄然发生了变化。过去，我们关心的是模型能不能完成任务；现在，更重要的问题变成了如何定义一个清晰、可验证的目标，以及如何降低实现目标的成本。模型越来越像团队成员，而高质量地组织和拆解工作，也正在成为新的效率竞争力。

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

近期推荐

用现代并发技术开发蓝牙应用 (Bluetooth without the delegate dance)

Delegate 仍是很多开发者在 Swift Concurrency 已经推出数年后不得不面对的问题：不仅代码组织繁琐，在 Swift 6 的严格并发检查下，也越来越难与现代并发代码自然协作。⁠Kyle Browning 利用 Swift 6.2 的 Custom Executor，将 CoreBluetooth 的回调队列与 Actor 的执行上下文绑定，使 Delegate 回调天然运行在 Actor 隔离环境中，无需额外的锁、线程切换或同步逻辑。

Custom Executor 可以让 Actor 中的任务运行在指定的执行器上，是连接传统回调 API 与 Swift Concurrency 的一项重要能力。如果你也面临类似的迁移或封装问题，不妨参考作者的实现思路。我也曾在⁠这篇文章中，以 Core Data 为例，详细介绍了如何利用 Custom Executor 将传统串行队列与 Actor 执行器绑定，实现与 Swift Concurrency 的自然融合。

CI 环境下的 Xcode 管理实践 (Working with Xcode on CI)

随着越来越多开发者采用自建 macOS Runner 或云端 CI，稳定地管理 Xcode、Simulator Runtime 与签名环境，已成为工程维护的重要组成部分。Dmitry Rodionov 围绕 Xcode CLI 在 CI 中的使用，总结了不少个人心得，例如使用 DEVELOPER_DIR 替代 xcode-select 管理多版本 Xcode、自动安装与清理 Simulator Runtime 和 Metal Toolchain，以及利用 Compilation Caching 减少分支切换带来的重复编译。

榨干 GitHub Actions 的最后一点价值

GitHub Actions 的优化，未必意味着更激进的缓存、更复杂的 Workflow，或更多的条件判断。这篇文章提出了一个值得借鉴的思路：让每一次 CI 执行都与实际风险相匹配。Snow 从一次看似普通的 Flaky Test 排查开始，逐步讨论了如何用确定性测试消除无意义的重跑、将可移植的检查迁移到 Linux、仅把真正依赖 Xcode 的验证留给 macOS，以及根据变更风险动态选择 Build、Test 或 Build for Testing，避免昂贵的 Runner 执行不必要的工作。

我很认同文中的一个观点：CI 的目标不是“跑得更多”，而是“回答正确的问题”。每一次昂贵的 macOS 构建，都应该验证一个更便宜的 Runner 无法验证的风险；每一次失败，也都应该提供足以推动修复的信息。

在 SwiftUI 中构建自适应非模态面板 (Building adaptive non-modal panels in SwiftUI)

从 WWDC 26 开始，iPhone-only 应用在通过 iPhone Mirroring 显示到 Mac，或在 iPad 上运行时，将进入可变尺寸环境。这意味着仅依赖 horizontalSizeClass 判断布局形态已经越来越不可靠。⁠Matthaus Woolard 介绍了如何构建一个自适应的非模态 Panel：通过 onGeometryChange 在场景根部记录窗口尺寸与 Safe Area，根据真实可用宽度决定面板显示在底部还是侧边。其中，在拖动期间保留已经解析的布局缓存，避免自适应内容因重复测量而出现尺寸跳变，是一个相当实用的技巧。

如果你的应用是 iPhone-only，并且仍有用户会在 iPad 或 macOS 上使用它，那么从今年开始就需要特别关注布局的适配。⁠可变画布 从某种意义上来说，不再保证开发者对界面布局拥有绝对控制权，而是将更多的选择权交到了用户手中。

SwiftUI @ContentBuilder：大幅提升 Xcode 27 编译效率 (SwiftUI @ContentBuilder - Faster Type Checking in Xcode 27)

Xcode 27 引入了新的 @ContentBuilder。虽然它目前仍只是 ViewBuilder 的类型别名，但 Apple 已开始在新的 SwiftUI API 中推荐使用这一名称。Sagar Unagar 介绍了这一变化，同时指出，对大多数应用来说，并没有必要立即将所有 @ViewBuilder 替换成 @ContentBuilder，已有代码在 Xcode 27 下同样能够受益于编译器的改进。

我最近并没有怎么写 SwiftUI 代码，因此还没有亲身体会到这个改动是否真正带来了编译效率上的提升。不过在之前的开发中，无论是 Table 还是 Charts，当将不同的 Builder 内容混写到 ViewBuilder 中时，Xcode 的类型推导和代码补全都会明显变慢。如果 Xcode 27 确实改善了这类场景，那么这次调整的意义就远不止一个新的 Builder 名称。

工具

tswift: 用 Rust 构建轻量 Swift 运行时

无需 Swift 工具链、LLVM、代码生成或 C 依赖，即可解析、语义分析并执行 Swift 源码。⁠Francis Chong 开发的 tswift 以纯 Rust 实现了 Swift 前端，完成词法、语法与语义分析，再通过树遍历运行时实现 Swift 的语言语义与标准库行为。

除语言运行时外，项目也在探索框架层面的支持：SwiftUI 已具备基础渲染能力，Charts 支持覆盖 58/60 个范围成员，可输出 Web SVG，并可下沉到 iOS 原生 Charts。

无论是 C 编写的 miniSwift、Swift 编译器近期展现出的⁠自举迹象，还是以 Rust 构建的 tswift，都展现出 Swift 生态正朝着更加开放、多元的实现方向发展。越来越丰富的实现路径，也让 Swift 的跨平台潜力呈现出超出预期的可能性。

When Inspiration Outruns the Results

Read on web →

Over the past few months, I’ve been refining my own AI-assisted workflow. Real progress has been made, but for long-running tasks, I’ve consistently lacked any quantifiable benchmark data. Thanks to competition among AI model providers, OpenAI recently lifted its 5-hour usage cap — which finally let me test my ideas without interruption, and compare the results and performance of different approaches head to head. Last week I burned through 6 or 7 accumulated limit resets across my two Pro accounts, and genuinely got a taste of “token freedom.”

Since each test run typically takes at least several dozen minutes, I found myself flooded with ideas while waiting and observing — new optimizations and tweaks kept popping into my head. This produced a strange phenomenon: while the old version was still running its test, the new version’s code was already written. My iteration speed had completely outpaced my test results. Some of those changes did turn out to work well, but once I calmed down, I had to face an uncomfortable truth — many of my “brilliant ideas” were really just assumptions I hadn’t thought through carefully.

At the time, caught in the false “flow state” that vibe coding produces, I didn’t notice this at all. It wasn’t until the test results showed a clear regression that I slammed on the brakes and actually stopped to reflect.

AI genuinely shortens the time it takes to validate an idea — but that convenience makes it easy to fall into a blind spot, skipping the deep thinking and logical groundwork that should happen before you start coding. Cheap, exhaustive testing shouldn’t become a substitute for real thought. Looking back, the intuition and experience we’ve built up are often far more efficient than AI’s blind trial-and-error at ruling out or refining ideas that were never going to work.

AI is an extraordinarily powerful tool — but where it should really earn its keep is in assisting execution, not replacing thinking.

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

Geometry, Compositing and Drawing Groups in SwiftUI

SwiftUI has three similarly-named modifiers with very different jobs — geometryGroup(), compositingGroup(), and drawingGroup(). They’re not only easy to confuse; most people don’t fully grasp the subtlety of what each one actually does.

Natalia Panferova breaks them down through three concrete scenarios: geometryGroup() lifts the interpolation up a level, fixing the problem of child views lacking a consistent transition state during animation; compositingGroup() establishes a compositing boundary for the graphical effects applied above it (like opacity or blend modes), so they treat multiple sublayers as a single unit rather than acting on each layer separately; drawingGroup() rasterizes multiple layers into a single offscreen image, trading space for performance — at the cost of having to regenerate that image every time the content changes.

One TaskGroup, Two Live Streams: a Swift 6 LLM Benchmark

By pulling all mutable run-state into a single actor, Wesley Matlock safely merges two independent async streams — model inference and system telemetry — into one ordered event stream.

Token counts, time-to-first-token latency, sample records, and all other run-time state live only inside the actor. Inside execute, a single withThrowingTaskGroup runs two things at once: a child task consumes the telemetry stream, sampling every 500ms and emitting RunEvents; a parent task runs the inference loop sequentially, where every await is a suspension point — the child task only gets a chance to run when the parent yields. The whole actor exposes just one AsyncThrowingStream to the outside. Because every access goes through actor isolation, the interleaving never conflicts — zero data races isn’t a matter of discipline, it’s something the compiler proves outright.

Syncing SwiftData with a Custom Backend Using HistoryObserver

Years ago, Apple gave SwiftData a history mechanism similar to Core Data’s Persistent History Tracking, letting developers track data-change events made to the same database from different sources in real time. But without a simple entry point that fit SwiftData’s design philosophy, the feature never saw much adoption. At WWDC 2026, Apple introduced HistoryObserver for SwiftData, making both triggering and incremental reads dramatically simpler. Mohammad Azam shows how this plays out in a real project, building a complete custom one-way sync pipeline with HistoryObserver.

The article walks through a simple room-measurement app: using withContinuousObservation to watch a change counter and trigger sync, using a persisted lastToken as a bookmark for incremental reads, and using isDeleted soft deletes paired with author tags to avoid the recursive self-triggering that hard deletes would otherwise cause. Mohammad works through each of the pitfalls you’ll hit building a sync engine, one by one, with a complete runnable example on GitHub.

Public Asset Symbol Constants in Swift Packages

Xcode auto-generates typed asset constants from .xcassets catalogs — things like Color(.skyBlue) / Image(.logo) — but these constants are always internal, so other Swift packages can’t use them. Xcode offers no public option, and there’s no way to turn this generation off from Package.swift either.

Ralf Ebert puts any assets meant for cross-package sharing into a Public/ subfolder inside .xcassets, then uses a Ruby script to scan every **/*.xcassets/Public/ and generate a <PackageName>+Generated.swift with a nested enum, re-exporting the internal symbols as public — so other libraries can simply call Image(.AppCommons.logo).

Previews and MCP

Xcode 27 exposes 47 tools through its MCP interface, and RenderPreview is the one responsible for rendering and screenshotting a SwiftUI Preview. But calling it requires the app to establish an STDIO connection via xcrun mcpbridge, which means the app can’t be sandboxed — a direct conflict with Mac App Store requirements.

Amy Delves‘s solution is to introduce a separate, unsandboxed XPC service dedicated to talking to Xcode’s MCP, while the main app stays sandboxed; the two communicate over XPC. The rendered result is read by the helper service and shipped back inline, sidestepping the fact that the main sandboxed app can’t reach file paths outside the sandbox.

I Found a Workaround for an App Store Connect Bug

Plenty of developers have run into this App Store Connect bug: pages keep redirecting back to /login even while you’re already logged in. After getting nowhere with Apple, Jeff Johnson compared the HTTP cookies of two requests in Chrome and tracked down the root cause: a session cookie named dc (dc=st) — on first login, that cookie hasn’t been set yet, so the server responds with a 302 redirect to the login page. The fix was to manually turn it into a permanent cookie expiring a year out. The whole diagnosis took under an hour.

What’s an Icon in 2026?

At WWDC 2025, Apple recommended using Icon Composer to build icons, with the rationale that icons should move from static images toward “more expressive,” multi-layered artworks. As a result, an icon no longer has one fixed appearance — it only takes on a particular form once “observed” on a specific device under specific settings. Take Apple’s Phone app icon as an example: the classic green background with a white handset now splits into several separate versions across dark mode, glass mode, and various tint colors.

Jim Nielsen argues that an icon’s value has always rested on being simple, consistent, and memorable. The further you push toward “expressiveness” by stacking on variants, the more you dilute the icon’s core job — instant recognition.

Tool

ImmersiveMap: Building a Native Immersive Map with SwiftUI and Metal

ImmersiveMap is a native map rendering engine for Apple platforms built by Artem Bobkin, implemented in Swift and Metal, and exposed through ImmersiveMapView as a declarative interface that fits naturally into SwiftUI conventions.

The project’s standout capability is a continuous transition between a spherical globe and a flat map. Beyond that, it covers vector tile (Vector Tile Source) parsing, label layout, 3D buildings, starfield and day/night effects, map styling, camera fly-to animations, and live markers that support clustering and dynamic movement. Developers can run it out of the box with the built-in tiles, or plug in Mapbox or a custom MVT (Mapbox Vector Tile) data source.

ImmersiveMap is a thorough demonstration of how to wrap a complex Metal rendering system behind a clean SwiftUI API. For developers who want to understand how a map engine, SwiftUI, and low-level graphics rendering work together, it’s a genuinely worthwhile open-source project to study.

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

Share

当灵感跑在了结果前面

网页版

过去几个月，我一直在优化自己的 AI 工作流。尽管颇有进展，但在长任务中，始终缺乏一些可以量化的 benchmark 数据。得益于 AI 模型公司之间的竞争，不久前 OpenAI 解除了 5 小时的额度限制，这让我终于能够不间断地测试自己的一些想法，并比较不同方案在效果与性能上的差异。上周，我把两个 Pro 账户攒下的 6、7 次额度都用掉了，着实体验了一把“Token 自由”的感觉。

由于每一个测试通常都需要跑上至少几十分钟，在等待、观测的过程中，我经常会灵感涌动，脑子里不断冒出各种优化和调整方案。这就产生了一个奇怪的现象：旧版本的测试还在运行时，新版本的代码已经写完了。迭代速度彻底跑在了测试结果前面。尽管其中确实有一些改动颇见成效，但冷静后也不得不面对一个残酷的事实——许多自以为是的“灵感”其实只是想当然，并没有经过审慎的思考。

然而，在那种由“Vibe Coding”产生的虚假“心流”状态下，当时的我并没有意识到这一点。直到测试结果出现明显的劣化，我才猛地踩下刹车，开始认真反思。

AI 的确极大地缩短了我们验证一个 Idea 的时间，但这种便利也容易让人陷入盲区，忽略了在动手前对构想进行深入思考与逻辑梳理的过程。不能让低成本的“穷举测试”取代真正的思考。回过头来看，我们积累的直觉与经验，在否决或调整那些不切实际的构想时，效率往往远高于 AI 的盲目试错。

AI 是一个极其强大的工具，但它最该发挥作用的地方是辅助执行，而非代替思考。

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

近期推荐

厘清 SwiftUI 中的三大视图组修饰符 (Geometry, compositing and drawing groups in SwiftUI)

SwiftUI 中三个名字相近却职责迥异的修饰符——geometryGroup()、compositingGroup()、drawingGroup()，它们不仅容易被混淆，而且很多人也不知道它们的精妙作用。

Natalia Panferova 用三个具体场景逐一拆解：geometryGroup() 通过将插值机制上提，解决子视图动画缺少一致过渡状态的问题；compositingGroup() 为其上层的图形效果（如 opacity、blend mode）划定合成边界，使其把多个子层级当作一个整体处理，而非逐层分别作用；drawingGroup() 则是把多个层级栅格化（rasterize）为一张离屏图像（offscreen image），以空间换性能，代价是每次内容变化都要重新生成这张图。

用 Swift 6 并发机制合并 LLM 与遥测双数据流 (One TaskGroup, Two Live Streams: a Swift 6 LLM Benchmark)

Wesley Matlock 通过将所有可变运行状态收进一个 actor，从而将模型推理与系统遥测两条独立的异步流，安全合并为一个有序事件流。

token 计数、首 token 延迟、采样记录等所有运行时状态只存在于 actor 内部。在 execute 中，一个 withThrowingTaskGroup 同时跑两条逻辑——子任务（child task）消费遥测流（telemetry stream），按 500ms 节奏采样并生成 RunEvent；父任务（parent task）则顺序执行推理循环，每次 await 都是一个挂起点（suspension point），父任务让出时子任务才有机会运行，整个 actor 对外只暴露一个 AsyncThrowingStream。因为所有访问都经过 actor 隔离，交替执行永不冲突——零竞争不是靠自觉，是编译器直接证明的。

利用 HistoryObserver 构建 SwiftData 自定义同步 (Syncing SwiftData with a Custom Backend Using HistoryObserver)

几年前，苹果便给 SwiftData 提供了 SwiftData History 机制，该机制与 Core Data 的 Persistent History Tracking 类似，让开发者实时掌握来自不同源对同一个数据库造成的数据变更事件，但由于缺少一个与 SwiftData 设计理念贴近的简单入口，该功能的利用率并不高。在 WWDC 2026 上，苹果为 SwiftData 引入 HistoryObserver，让触发、增量读取变得非常简单。Mohammad Azam 展示了该能力在真实项目中的应用，通过 HistoryObserver 搭出完整的自定义单向同步管线。

文章围绕一个房间测量小应用展开：用 withContinuousObservation 监听变更计数触发同步，用持久化的 lastToken 做书签实现增量读取，再用 isDeleted 软删除配合 author 标签避免硬删除引发的递归自触发。Mohammad 对打造同步引擎时会踩的坑，逐一给出解法，并附带完整可跑的 GitHub 示例。

在 Swift 模块包中共享公开的资源符号常量 (Public asset symbol constants in Swift packages)

Xcode 会从 .xcassets 自动生成类型化的资源常量，比如 Color(.skyBlue) / Image(.logo)，但这些常量是 internal 的，无法供其他 Swift 包使用，Xcode 既不提供 public 选项，也无法在 Package.swift 里关闭这套生成机制。

Ralf Ebert 把要跨包共享的资源放进 .xcassets 内的 Public/ 子目录，再用一个 Ruby 脚本扫描所有 **/*.xcassets/Public/，按包名生成一个嵌套 enum 的 <PackageName>+Generated.swift，把内部符号重新导出为 public——从而可以在其他库中通过 Image(.AppCommons.logo) 的方式来调用。

突破 Xcode 预览与 MCP 的沙盒限制 (Previews and MCP)

Xcode 27 提供的 MCP 接口一共暴露了 47 个工具，其中 RenderPreview 负责对 Preview 进行渲染与截图。但调用它的应用必须通过 xcrun mcpbridge 建立 STDIO 连接，这要求应用不能被沙盒化（sandboxed）——直接与上架 Mac App Store 的规则冲突。

Amy Delves 的解法是引入一个独立的、未沙盒化的 XPC 服务专门与 Xcode MCP 对话，主 App 本身仍保持沙盒化，两者通过 XPC 通信；渲染结果由 helper 服务读取后内联传回，从而绕开主 App 无法访问沙盒外文件路径的限制。

我找到了解决 App Store Connect 登录 Bug 的 workaround (I found a workaround for an App Store Connect bug)

不少开发者都遇到过 App Store Connect 的一个 Bug：在已登录状态下页面仍会跳转回 /login。Jeff Johnson 在与 Apple 沟通无果后，用 Chrome 对比两次请求的 HTTP Cookie，找到了问题根源：一个名为 dc 的 session cookie（dc=st）——首次登录时该 cookie 尚未写入，服务端因此返回 302 跳转到登录页。解决办法是把它手动改成一年后过期的永久 cookie，整个诊断过程不到一小时。

如何定义 2026 年的 App 图标？ (What’s an Icon in 2026?)

Apple 在 WWDC 2025 上推荐用 Icon Composer 制作图标，理由是让图标从静态图像走向“更具表现力”的多层作品——图标由此不再有唯一确定的样子，只有在具体设备、具体设置下被“观测”时才会呈现出某一种形态。以 Apple 电话 App 图标为例：绿底白话筒的经典形象，如今要分裂成深色模式、玻璃模式、多种着色的好几个版本。

Jim Nielsen 认为图标的价值本就建立在“简单、一致、易记”之上，越往“富有表现力”的方向堆叠变体，越是在稀释图标本该承担的即时辨识功能。

工具

ImmersiveMap：用 SwiftUI 与 Metal 构建原生沉浸式地图

ImmersiveMap 是 Artem Bobkin 开发的一款面向 Apple 平台的原生地图渲染引擎，用 Swift 与 Metal 实现，并通过 ImmersiveMapView 提供符合 SwiftUI 使用习惯的声明式接口。

项目最耀眼的能力，是球形地球与平面地图之间的连续过渡。此外，它还涵盖矢量瓦片（Vector Tile Source）解析、标签布局、3D 建筑、星空与昼夜效果、地图样式、相机飞行动画，以及支持聚合与动态移动的实时标记。开发者既可以直接使用内置瓦片运行，也可以接入 Mapbox 或自定义的 MVT（Mapbox Vector Tile）数据源。

ImmersiveMap 完整展示了如何把复杂的 Metal 渲染系统封装在简洁的 SwiftUI API 之下。对于想理解地图引擎、SwiftUI 与底层图形渲染如何协同工作的开发者来说，这是一份颇具参考价值的开源项目。

When Every Data Write Comes at a New Price

Read on web →

Recently, OpenAI’s Codex was found to have a logging issue: the program kept writing large volumes of logs to a local database, causing the files to grow continuously and generating far more disk writes than normal. Bugs like this are hardly new. A few years ago, most people would probably have deleted the files, restarted the app, and waited for the next release to fix it.

This time, however, the reaction was noticeably different. Instead of asking how much disk space remained, more people began wondering how much data had already been written to their SSDs, whether it might affect flash endurance, and how much more they would have to pay for the same amount of memory and storage when replacing their devices in the future.

The Codex bug may not be any more serious than other runaway logging incidents in the past. What has changed is that every pointless write suddenly seems to come at a price again.

As demand for AI compute continues to surge, memory manufacturers are increasingly prioritizing higher-margin, higher-demand products such as HBM, server memory, and enterprise SSDs. Consumer memory and SSDs are therefore receiving a smaller share of production capacity, while their prices continue to rise.

Memory and flash have always been cyclical industries, so price increases and declines are nothing unusual. What makes the current situation unsettling is that it no longer appears to be merely another inventory cycle. It is accompanied by a longer-term shift of industry resources toward AI infrastructure.

Even if prices eventually fall, consumers may not quickly return to the old assumption that large amounts of storage are practically free.

As storage stops feeling inexhaustible, developers may also need to reconsider their attitude toward resources.

When I first encountered computers, a common Apple II configuration had only 48 KB of memory. To make use of the additional 16 KB provided by an expansion card, developers had to arrange addresses, code, and data with great care, finding ways to make every byte count.

A game spanning tens of gigabytes today inevitably offers graphics, sound, world scale, and interactive complexity that would have been unimaginable in the Famicom/NES era. Yet its enormous size does not guarantee that it will be more enjoyable than a game measured in only tens of kilobytes.

This is not to say that modern software should not grow larger. What is worth examining is how, over many years, developers have grown accustomed to storage capacities increasing naturally and networks becoming ever faster. As long as there is still room for logs, caches, and temporary data, few people stop to ask why they exist or when they will be deleted.

Expensive SSDs will not automatically produce better software, nor will memory shortages suddenly make developers smarter. But once hardware can no longer be assumed to grow without limit, engineering questions that have long been overlooked begin to resurface.

I do not miss the days when developers had to struggle within a few dozen kilobytes.

What is worth recovering is not the scarcity itself, but an engineering habit that once felt natural and has gradually faded away:

knowing why every byte arrives—and when it will leave.

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 Task lifetime when an iOS device is locked

This Q&A comes from the Apple Developer Forums. The original poster found that a Swift Task making several sequential REST requests would sometimes complete normally after the device was locked, sometimes pause, and occasionally time out. DTS engineer Quinn “The Eskimo!” explains that Swift Concurrency runs entirely within the app process. Once iOS suspends that process, the worker threads executing the Task also stop, and the Task itself receives no additional background execution privileges.

This behavior can be especially confusing when networking is involved. If the app is suspended while a URLSession request is in progress, the request may fail because the connection becomes defunct. When the process resumes, developers may see a timeout or networking error rather than the Task continuing from where it paused and completing successfully. Quinn outlines four possible approaches: delay process suspension, stop in-flight requests before the app becomes eligible for suspension, allow requests to fail and implement retry and error recovery, or use a URLSession background session.

anyAppleOS in Swift 6.4

In the past, declaring availability for an API shared across Apple platforms required developers to list each platform and its corresponding OS version separately. Because version numbers differed across platforms for many years, these declarations were not only verbose but also prone to omissions and versioning mistakes. With Apple’s platforms adopting aligned major version numbers starting at 26, Swift 6.4 introduces anyAppleOS, allowing developers to describe APIs and code targeting Apple operating systems more concisely in @available, #available, and #if os(...).

Artem Mirzabekian⁠ introduces the new syntax and explains how it differs from platform-specific availability, canImport, and the platform declarations in Package.swift. He also shows how more specific availability rules can be combined with anyAppleOS when support arrives later on certain platforms or is unavailable altogether.

The Anatomy of a Reusable SwiftUI View

More developers are trying to make the APIs of their reusable SwiftUI views feel as close as possible to Apple’s own designs, but there is often no clear methodology for putting that goal into practice. Alexander Weiß⁠ shares his approach: first determine whether a component is semantic, describing a functional concept, or prescriptive, carrying a clearly defined visual form. From there, define its semantics, valid states, data flow, and interaction behavior. Components should also follow SwiftUI’s state-management conventions, use immutable values, Binding, and State appropriately, and treat accessibility, environment values, and stable view identity as part of the design rather than focusing only on the shape of the call site.

Using Card, Tag, and Rating as examples, the article demonstrates concrete implementations involving initializers, custom View Styles, and environment values. The central idea is not simply to imitate the appearance of Apple’s APIs, but to make custom components genuinely fit into the SwiftUI ecosystem through their composition model, state flow, interaction behavior, accessibility support, and environmental adaptation.

The hidden cost of unstable SwiftUI environment defaults

The @Entry macro makes custom environment values easier to declare, but directly using a reference-type instance as the default, such as @Entry var logger = AppLogger(), can cause unnecessary view updates. Whenever SwiftUI cannot find an injected value higher in the hierarchy and falls back to the default, it may create a new AppLogger. Although these objects behave identically, they are not the same instance, so SwiftUI may treat the environment value as changed and re-evaluate views that read it. Starting with Xcode 27, the compiler warns about this pattern, making a previously subtle issue easier to catch.

Natalia Panferova⁠ uses _printChanges() to demonstrate the issue directly and offers two solutions: keep the default instance in stable external storage, or declare the environment value as Optional and inject it explicitly at the app entry point.

I also analyzed this issue in SwiftUI Environment: Concepts and Practice⁠. The root cause lies in how the @Entry macro generates the default environment value, allowing the default expression to be evaluated repeatedly whenever fallback access occurs.

Make Vertical Parallax for ScrollView in SwiftUI

Early 2D games created rich visual depth at very little cost by moving different image layers at different speeds. In SwiftUI, however, the difficult part of implementing scroll-based parallax is usually not calculating the offset, but continuously obtaining each view’s position within a ScrollView. In the past, this often required a combination of GeometryReader, custom coordinate spaces, and state propagation, resulting in more code and potentially causing unnecessary view updates when handled poorly.

The introduction of visualEffect has greatly reduced the complexity of building these effects. codelaby⁠ demonstrates how to read a view’s geometry directly inside visualEffect and apply an offset based on its scroll position, without maintaining additional state or changing the view’s original layout.

Tools

swift-span-algorithms: Adding Algorithmic Capabilities to Span

When working with contiguous memory, Swift developers traditionally had two main choices. Types such as Array and ContiguousArray own their storage and are safe and convenient, but may involve copying, reference counting, or additional allocation. Pointer types such as UnsafeBufferPointer offer low overhead and greater control, but require developers to ensure that the underlying memory remains valid and that every access stays within bounds.

Introduced in Swift 6.2, Span<Element> fills the gap between these approaches. It is a non-owning view over contiguous memory: it does not retain the underlying storage, but relies on compiler-enforced lifetime tracking and bounds checks to provide safe access. In Swift 6.2, however, Span does not yet offer the same breadth of algorithms available to Collection and Sequence.

David Retegan⁠ created swift-span-algorithms to fill that gap. The library adds searching, comparison, trimming, chunking, sliding windows, splitting, cursor-based operations, and other utilities for Span, RawSpan, MutableSpan, and InlineArray. It is designed around zero hidden allocations and constant additional space, extending Span’s algorithmic capabilities while continuing to respect its lifetime constraints.

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

Share

当每一次写入都有了新价格

网页版

最近，OpenAI 的 Codex 被发现存在一个日志写入问题：程序会持续向本地数据库写入大量日志，导致文件不断膨胀，并产生远超正常水平的磁盘写入。类似的 Bug 过去并不少见。放在几年前，人们大概只是删除文件、重启应用，然后等待下一个版本修复。

但这一次，大家的反应明显不同。比起“还剩多少磁盘空间”，更多人开始关心 SSD 已经累计写入了多少数据，会不会影响闪存寿命，以及未来更换设备时，需要为同样容量的内存和存储多付多少钱。

Codex 的 Bug 未必比过去那些失控的日志程序更加严重。真正发生变化的是：每一次无意义的写入，似乎都重新有了价格。

随着 AI 算力需求迅速增长，存储器厂商越来越倾向于优先保障 HBM、服务器内存和企业级 SSD 等利润更高、需求更旺盛的产品。消费级内存和 SSD 能够分配到的产能因此受到挤压，价格也不断走高。

内存和闪存本来就是典型的周期性行业，价格上涨和下跌并不罕见。但这一轮变化令人不安的地方，在于它似乎不再只是一次简单的库存周期，而是伴随着产业资源向 AI 基础设施长期倾斜。

即使价格最终仍会回落，消费者恐怕也很难迅速回到过去那种“大容量近乎免费”的心理预期。

当存储不再显得取之不尽时，开发者或许也应该转变对资源时的态度。

在我最开始接触电脑时，Apple II 常见的内存配置只有 48 KB。为了使用扩展卡额外提供的 16 KB 空间，开发者需要仔细安排地址、代码和数据，想方设法把每一个字节都利用起来。

今天一个数十 GB 的游戏，必然拥有 FC 时代无法想象的画面、声音、世界规模和交互复杂度。然而，巨大的容量并不能保证它带来的乐趣一定超过一个只有几十 KB 的游戏。

这并不是说现代软件不应该变大。真正值得思考的是，在过去很多年中，开发者已经习惯了存储容量会自然增长、网络会不断变快。日志、缓存和临时数据只要暂时还放得下，就很少有人追问它们为什么存在，又将在什么时候被删除。

昂贵的 SSD 不会自动创造优秀的软件，内存短缺也不会让开发者突然变得更加聪明。但当硬件不再被默认会无限增长时，那些曾经被忽视的工程问题便会重新浮出水面。

我并不怀念那个需要在几十 KB 中反复腾挪的时代。

真正值得重新拾起的，并不是资源匮乏，而是那种曾经十分自然、后来却逐渐消失的工程习惯：

知道每一个字节为什么到来，也知道它将在什么时候离开。

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

近期推荐

iOS 设备锁定后，Swift Task 能运行多久？(Swift Task lifetime when an iOS device is locked)

这是一篇来自 Apple Developer Forums 的问答。提问者发现，一个会串行执行多个 REST 请求的 Swift Task，在设备锁定后有时能够正常完成，有时会暂停，甚至出现超时。DTS 工程师 Quinn “The Eskimo!” 解释道，Swift Concurrency 完全运行在应用进程中；一旦 iOS 挂起进程，执行 Task 的工作线程也会停止，Task 本身并不会获得额外的后台运行能力。

这种机制在网络请求中尤其容易造成困惑。应用被挂起时，正在进行的 URLSession 请求可能因连接失效而失败；进程恢复后，开发者看到的可能是请求超时或网络错误，而不是 Task 从暂停处继续并顺利完成。Quinn 给出了四种处理方向：设法延缓进程挂起、在应用即将被挂起时停止请求、允许请求失败并做好重试与错误恢复，或者使用 URLSession 的后台会话。

Swift 6.4 中的 anyAppleOS (anyAppleOS in Swift 6.4)

过去，为跨 Apple 平台共享的 API 声明可用性时，开发者需要分别列出各个平台及其对应的系统版本。由于不同平台的版本号长期不一致，这类声明不仅冗长，也容易出现遗漏或版本填写错误。随着 Apple 各平台从 26 开始统一版本号，Swift 6.4 引入了 anyAppleOS，允许开发者在 @available、#available 和 #if os(...) 中，以更简洁的方式描述适用于 Apple 操作系统的 API 与代码。

Artem Mirzabekian⁠ 介绍了这一新语法，并梳理了它与平台专属可用性、canImport 以及 Package.swift 平台声明之间的区别，同时说明了如何结合更具体的可用性规则，处理部分平台延后支持或完全不可用的情况。

可复用 SwiftUI 视图的设计剖析 (The Anatomy of a Reusable SwiftUI View)

越来越多的开发者在构建可复用 SwiftUI 视图时，都希望其 API 尽可能贴近 Apple 官方的设计方式，但具体如何落地，往往缺少一套清晰的方法。Alexander Weiß⁠ 给出了自己的设计思路：首先判断组件属于描述功能概念的语义型组件，还是具有明确视觉形态的规定型组件，再梳理其语义、合法状态、数据流与交互行为。同时，组件还应遵循 SwiftUI 的状态管理方式，正确使用不可变值、Binding 与 State，并将无障碍支持、环境值和视图身份稳定性纳入设计，而不只是关注 API 的调用形式。

文章通过 Card、Tag 和 Rating 三个示例展示了初始化方法、自定义 View Style 和环境值等具体实现。这套方法的核心并非简单模仿 Apple API 的外形，而是让自定义组件在组合方式、状态流转、交互行为、无障碍支持和环境适配等方面真正融入 SwiftUI 体系。

SwiftUI 环境默认值不稳定的隐性成本 (The hidden cost of unstable SwiftUI environment defaults)

@Entry 宏让自定义环境值的声明更加便捷，但如果直接将引用类型实例作为默认值，例如 @Entry var logger = AppLogger()，就可能带来不必要的视图更新。每当 SwiftUI 没有找到上层注入的值而回退到默认值时，都可能重新创建一个 AppLogger。这些对象虽然功能相同，却不是同一个实例，因此 SwiftUI 会认为环境值发生了变化，进而重新计算读取它的视图。Xcode 27 开始会针对这种写法发出警告，让这个过去不易察觉的问题更早暴露出来。

Natalia Panferova⁠ 使用 _printChanges() 直观展示了这一问题，并给出两种解决方式：将默认实例保存在稳定的外部存储中，或者将环境值声明为 Optional，再由应用入口显式注入。

我在《SwiftUI Environment：理念与实践》中也分析过这一问题。其根源在于 @Entry 宏生成默认环境值的方式，使默认表达式可能在回退访问时被重复求值。

使用 visualEffect 为 SwiftUI ScrollView 创建纵向视差效果 (Make Vertical Parallax for ScrollView in SwiftUI)

早期的二维游戏通过让不同图层以不同速度移动，用很低的成本便营造出了富有层次感的视觉效果。但在 SwiftUI 中实现滚动视差，真正麻烦的通常不是计算偏移量，而是持续获取每个视图在 ScrollView 中的位置。过去，这类效果往往需要结合 GeometryReader、自定义坐标空间和状态传递来完成，不仅代码量较大，处理不当还可能引发额外的视图更新。

visualEffect 的引入大幅降低了这类效果的实现难度。codelaby⁠ 展示了如何直接在 visualEffect 中读取视图的几何信息，并根据滚动位置应用 offset，无须额外维护状态，也不会改变视图原有的布局。

工具

swift-span-algorithms: 给 Span 补上算法能力

在处理连续内存时，Swift 过去主要有两类选择：使用 Array、ContiguousArray 等拥有存储的容器，安全易用，但可能伴随复制、引用计数或额外分配；使用 UnsafeBufferPointer 等指针类型，成本低、控制力强，却需要开发者自行保证内存仍然有效，并避免越界访问。

Swift 6.2 新增的 Span<Element> 填补了两者之间的空白。它是一段连续内存的非拥有视图：不持有底层存储，却能借助编译器追踪生命周期，并通过边界检查提供安全访问。不过，在 Swift 6.2 中，Span 尚未拥有 Collection、Sequence 那般完整的算法能力。

David Retegan 开发的 swift-span-algorithms 正是对这一缺口的补充。它为 Span、RawSpan、MutableSpan 和 InlineArray 提供查找、比较、修剪、分块、滑动窗口、切分及游标（Cursor）等操作。整个库零以无隐藏分配和常数级额外空间为设计目标，在扩展算法能力的同时，仍然遵守 Span 的生命周期约束。

When Linux Becomes “Air”: Containers, Agents, and a “Desktop War” That No Longer Matters

Read on web →

A week ago, Microsoft released the public preview of native Windows 11 container support that requires no Docker. Combined with Apple’s recent 1.0 release of its container manager (Apple Container), both major desktop operating systems have now deeply integrated Linux containers as first-class citizens of the system.

This has sparked an interesting debate. Some see it as Linux’s ultimate victory: it never truly won the desktop market, yet it is now everywhere. Others ask the opposite question: when both Windows and macOS can run Linux containers smoothly and with little overhead, is this really a victory for Linux — or the beginning of its complete “commoditization” and “invisibility”?

These two views may seem contradictory, but they both point to the same fact: the role of Linux is changing.

In the past, when we talked about an operating system, we were usually talking about a complete platform — one with its own desktop, applications, development model, user habits, and ecosystem boundaries. Windows is a platform, macOS is a platform, and Linux distributions are, of course, platforms too. Around these platforms, people debated market share, user experience, compatibility, and that “Year of the Linux Desktop” joke that has been recycled for decades.

But containers have changed the structure of the question.

In modern software development, Linux increasingly appears not as “the operating system you are using,” but as “the default runtime environment.” Developers rarely say “I deployed to Linux.” They are far more likely to say “I deployed to Kubernetes,” “I’m running on the cloud,” or “I used a container image.”

This shift will become even more pronounced in the age of AI agents. As agents evolve from simple chat assistants into tools that actually execute tasks, what they need is no longer just a conversational interface, but a lightweight, instantly bootable, fully isolated, and easily disposable execution environment. Containers are a natural fit for this role. And as more and more tasks are carried out through agents, the interface where humans interact directly with the operating system is quietly losing weight — the outcome of the decades-long “desktop war” matters less and less.

Linux, then, is outgrowing its identity as a “platform.” It never won the desktop market share battle, yet it has made its way into the foundation of nearly every modern computing system. It never convinced everyone to switch to Linux, yet it has compelled every platform to support the way Linux runs.

The highest form of victory is not having everyone chant your name, but having everyone depend on you — while barely remembering you’re there. This is a victory where silence speaks louder than words.

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

Debugging Notes on Two SwiftUI Animation Bugs

Easy-to-use animation has always been one of SwiftUI’s defining features. But the nature of a declarative framework is a double-edged sword: once an animation misbehaves, tracking down the cause is often trickier than in an imperative framework. This post records two SwiftUI animation bugs I ran into over the past two weeks—less a set of solutions than an account of the hunt itself, shared in the hope that the thought process proves useful the next time you face something similar.

Recent Recommendations

Task Property: Reusing Stateful Business Logic for SwiftUI Views

When encapsulating stateful business logic in SwiftUI, what comes to mind first? Putting it in the view? Writing a modifier? Rick Van Voorden offers a less common but distinctly SwiftUI-flavored perspective: using DynamicProperty to extract stateful business logic out of the view, encapsulating it as reusable dynamic properties and letting views return to a purer declarative expression.

The TaskProperty in the project is merely a helper primitive for managing the lifecycle of asynchronous Tasks within custom dynamic properties. It is practical, but not what the README really wants to emphasize. Starting from the question of “how to reuse stateful business logic,” the author gradually demonstrates that DynamicProperty is not just the mechanism behind @State, @Binding, and @Environment—it can also serve as a way to organize and reuse stateful business logic.

Articles about custom DynamicProperty are rare, and what distinguishes this one is that it does not stop at API instruction. Instead, it brings the question back to the organization of business logic itself: is there shareable stateful logic mixed into your Views? Could that logic be extracted into custom dynamic properties that sit closer to the SwiftUI lifecycle?

Why My SwiftUI Map Bounced in Heading-Follow Mode?

Emre Degirmenci ran into a classic SwiftUI + MapKit boundary problem in a TCA-based map application: in heading-follow mode, the map kept jittering, the camera jumped, and the tracking state even exited unexpectedly. Interestingly, the same Map component worked fine in another app built with MVVM, which shifted the question from “an implementation mistake” to “whether the state synchronization model is sound.”

The root cause is that MapKit generates high-frequency camera updates in heading-follow mode, while the original implementation wrote those updates back to the TCA Store through two-way binding, creating a loop of “MapKit drives → state updates → state drives MapKit again” that broke the system’s own continuous animation logic. The fix was to leave camera changes under MapKit’s own control and intervene explicitly only when necessary, thereby avoiding conflicts between state and system-driven behavior.

SwiftUI 3D is Flat

In UIKit / AppKit, Core Animation’s CATransformLayer provides a genuinely shared 3D space with depth sorting, so many developers naturally assume that SwiftUI’s rotation3DEffect and projectionEffect are built on a similar 3D scene. But Mihaela Mihaljević Jakić shows through an experiment that SwiftUI has no unified 3D space or depth-buffering mechanism. After 3D transformations, multiple views remain “independent 2D projections,” which leads to typical occlusion errors—for example, a back face covering a front face.

This behavior is not a defect; it looks more like a deliberate design choice in SwiftUI: constraining 3D capabilities to the projection level of individual views rather than introducing a full 3D scene and hierarchy system.

Introducing the Safari MCP server for web developers

In today’s AI coding agent ecosystem, browser automation has long been dominated by the Chrome / Chromium stack as the de facto standard (Playwright, Puppeteer, CDP, etc.), with Safari mostly serving as a compatibility-verification environment.

The Safari MCP server (Safari Technology Preview 247) aims to change that: it exposes Safari’s browser session capabilities to agents, giving them direct access to the DOM, network requests, console logs, screenshots, and page state, so that debugging and analysis can happen in Safari’s real runtime environment. This moves Safari into the main path of the agent toolchain, rather than relying on indirect inference from Chromium or cross-browser switching for verification.

noUI()

As AI agent tools work their way deeper into development and content-production workflows, the role of UI is being reexamined. Starting from a DOS-style command interface, Jordan Morgan poses a question worth pondering: when more and more operations can be performed directly by agents through natural language, does UI still need to exist in the form of an “explicit interface”?

The part of the article that fascinated me most is the interactive terminal interface the author built with JavaScript and CSS. This design is not merely an example or a demo—it embeds the article’s argument itself into an operable UI, drawing readers into the discussion of UI’s changing form precisely through the act of “using an interface.” Here, UI is not just a vehicle of expression; it becomes part of the argument.

What does Activity Monitor measure?

Since AI agents entered everyday development workflows, many developers have had a similar experience: the Mac’s fans spin up more often and memory pressure rises noticeably, yet the CPU / Energy figures shown in Activity Monitor often fail to match that intuition.

Through controlled experiments with powermetrics and a variety of real workloads, Howard Oakley shows that the CPU % in Activity Monitor is closer to a simple sum of each CPU core’s active residency than to a “utilization percentage” in the traditional sense; GPU % is likewise only an approximation of active residency; and Energy Impact mainly reflects a CPU-level power estimate—it neither includes the GPU nor captures how energy consumption changes over time particularly well.

Tools

Quiver: Learning Linear Algebra and Classical Machine Learning with Swift

Wayne Bishop has long maintained Swift Algorithms & Data Structures, an e-book on algorithms and data structures for Swift developers. In its latest fifth edition, the book has extended beyond traditional algorithms and data structures into vectors, matrices, and similarity computation; Quiver pushes that path further into numerical computing, statistics, and classical machine learning.

Quiver is a pure Swift, zero-dependency library for linear algebra, statistics, and classical machine learning. It directly extends the Swift standard library’s Array, emphasizing value semantics, Codable, Sendable, and lightweight on-device execution on Apple platforms. Its goal is not to replace the Python numerical ecosystem, but to give Swift developers an entry point for understanding linear algebra, training small models, and bringing the results back into an App—all in a familiar language. In the later chapters of Swift Algorithms & Data Structures, Wayne uses Quiver as the companion tool for the math and machine-learning fundamentals.

SwipeCell v3: A Native SwiftUI Swipe Menu

At WWDC 2026, SwiftUI’s new swipeActionsContainer() finally let swipe menus step outside of List, serving ScrollView, lazy stacks, and more custom containers. Unfortunately, this capability currently requires system versions corresponding to anyAppleOS 27.

SwipeCell was the first third-party library I wrote six years ago, when I had just entered Swift development. The old versions were naive, but they also accompanied me through the changes in SwiftUI’s swipe interactions over the years. I recently gave it a complete rewrite and released v3: the new API is more SwiftUI-idiomatic, the configuration is more complete, the interaction feel has been re-polished, and macOS support has been added.

SwipeCell v3 is currently published on the v3-beta branch and remains in beta. You are welcome to try it out and report any issues you encounter.

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

Share

当 Linux 成为“空气”：容器、Agent 与不再重要的“桌面之争”

网页版

一周前，微软推出了无需 Docker 的 Windows 11 原生容器支持的公开预览；再结合苹果不久前发布的容器管理器（container）1.0 正式版，一时间，两大主流桌面操作系统都将 Linux 容器深度集成为了系统的一等公民。

这件事引发了一场有趣的讨论。有人认为，这是 Linux 的最终胜利：虽然它始终没能真正赢下桌面市场，但它已经无处不在；也有人提出反问：当 Windows 和 macOS 都能相对顺畅、轻量地运行 Linux 容器时，这究竟是 Linux 的胜利，还是它被彻底“工具化”和“隐形化”的开始？

这两种说法看似相反，其实都触碰到了同一个事实：Linux 的角色正在发生变化。

过去，我们谈论操作系统时，通常是在谈论一个完整的平台。它有自己的桌面、应用、开发模型、用户习惯和生态边界。Windows 是一个平台，macOS 是一个平台，Linux 发行版当然也是一个平台。围绕这些平台，人们讨论份额、体验、兼容性，以及那个已经被反复调侃了几十年的“Linux 桌面元年”。

但容器改变了这个问题的结构。

在现代软件开发中，Linux 越来越少以“你正在使用的操作系统”的形式出现，而是以“默认运行环境”的形式存在。开发者不一定会说“我部署到了 Linux”，他们更可能说“我部署到了 Kubernetes”、“我跑在云上”、“我用了一个容器镜像”。

这种变化在 AI Agent 时代会更加明显。随着 Agent 从简单的聊天助手转向能够真正执行任务的工具，它们需要的不再只是一个对话界面，而是一个轻量、秒级启动、完全隔离且易于销毁的执行环境。容器天然适合承担这种角色。而当越来越多的任务经由 Agent 完成，人与操作系统直接交互的界面，其权重也在悄然下降——那场持续了数十年的“桌面之争”，胜负已经愈发不重要了。

所以，Linux 正在超越“平台”这个身份。它没有成为桌面操作系统份额的赢家，却进入了几乎所有现代计算体系的底层。它没有让所有人都改用 Linux，却让所有平台都不得不支持 Linux 的运行方式。

不是让所有人都高喊你的名字，而是让所有人都离不开你，却又想不起你。这种胜利无声胜有声。

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

原创

两个 SwiftUI 动画 Bug 排查小记

易用的动画一直是 SwiftUI 的主要特色之一。但声明式框架的特性是一把双刃剑：动画一旦出现异常，排查往往比命令式框架更棘手。本文记录了过去两周里，我在开发中遇到的两个与 SwiftUI 动画有关的 Bug。与其说是解决方案，不如说是一段排查的心路——希望能为你面对类似问题时开阔一点思路。

近期推荐

利用属性机制重构状态化业务逻辑 (Task Property: Reusing Stateful Business Logic for SwiftUI Views)

在 SwiftUI 中封装带状态的业务逻辑，你第一时间会想到什么方式？放进视图？写成 modifier？Rick Van Voorden 提供了一个不太常见但很有 SwiftUI 味道的视角：利用 DynamicProperty 将状态化业务逻辑从 View 中抽离出来，封装为可复用的动态属性，让 View 回归更纯粹的声明式表达。

项目中的 TaskProperty 只是一个辅助原语，用于在自定义动态属性中管理异步 Task 的生命周期。它很实用，但并不是这篇 README 真正想强调的重点。作者从“如何复用 Stateful Business Logic”这个问题出发，逐步展示了 DynamicProperty 不只是 @State、@Binding、@Environment 背后的机制，也可以成为组织和复用状态化业务逻辑的一种方式。

关于自定义 DynamicProperty 的文章并不多，而本文的特点在于，它没有停留在 API 使用教学上，而是把问题放回业务逻辑组织本身：你的 View 中是否混入了可共享的状态逻辑？这些逻辑是否可以被抽取为更贴近 SwiftUI 生命周期的自定义动态属性？

SwiftUI 地图在航向跟随模式下为何会抖动？(Why My SwiftUI Map Bounced in Heading-Follow Mode?)

Emre Degirmenci 在一个基于 TCA 的地图应用中遇到了一个典型的 SwiftUI + MapKit 边界问题：在 heading-follow 模式下，地图出现持续抖动、相机跳动，甚至定位状态异常退出。有意思的是，同样的 Map 组件在另一个 MVVM 架构的应用中却没有问题，这使得问题从“实现错误”转向了“状态同步模型是否合理”。

核心原因在于 MapKit 在 heading-follow 模式下会产生高频相机更新，而原实现通过双向绑定将更新数据回写到 TCA Store，造成了“MapKit 驱动 → 状态更新 → 再驱动 MapKit”的回路，破坏了系统自身的连续动画逻辑。修复方式为让相机变化保持由 MapKit 自身控制，只在需要时进行显式干预，从而避免状态与系统驱动之间的冲突。

SwiftUI 3D is Flat

在 UIKit / AppKit 中，Core Animation 的 CATransformLayer 提供了真正的共享 3D 空间与深度排序能力，因此不少开发者会自然地认为 SwiftUI 的 rotation3DEffect、projectionEffect 也建立在类似的 3D 场景之上。但 Mihaela Mihaljević Jakić 通过一个实验指出：SwiftUI 并不存在统一的 3D 空间或深度缓冲机制。多个视图在 3D 变换后的结果仍然是“各自独立的 2D 投影”，因此会出现典型的遮挡错误，例如“背面覆盖正面”。

这种行为并非缺陷，而更像是 SwiftUI 有意的设计选择：将 3D 能力限制在单个 view 的投影层面，而不是引入完整的 3D 场景与层级体系。

Safari 推出面向 Web 开发者的 MCP (Introducing the Safari MCP server for web developers)

在当前 AI coding agent 生态中，浏览器自动化长期以 Chrome / Chromium 体系为事实标准（Playwright、Puppeteer、CDP 等），Safari 通常更多作为兼容性验证环境。

Safari MCP server（Safari Technology Preview 247）试图改变这一点：它将 Safari 浏览器会话能力暴露给 agent，使其可以直接访问 DOM、网络请求、控制台日志、截图以及页面状态，从而在 Safari 的真实运行环境中完成调试与分析。这使 Safari 开始进入 agent toolchain 的主路径，而不再只是依赖 Chromium 的间接推断或跨浏览器切换验证。

AI 时代下的“无 UI”趋势思考 noUI()

在当前 AI agent 工具逐渐深入开发与内容生产流程的背景下，UI 的角色正在被重新审视。Jordan Morgan⁠ 从 DOS 风格的命令界面切入，提出一个值得思考的问题：当越来越多的操作可以直接由 agent 通过自然语言完成时，UI 是否仍然需要以“显式界面”的形式存在？

文章中最吸引我的部分，是作者基于 JavaScript 与 CSS 构建了一个可交互的终端界面。这个设计并不仅仅用于示例或演示，而是将文章的论述本身嵌入到一个可操作的 UI 中，使读者在“使用界面”的过程中进入对 UI 形态变化的讨论之中。UI 在这里不只是表达载体，也成为论证的一部分。

重新认识 Mac 活动监视器的各项性能指标 (What does Activity Monitor measure?)

在 AI agent 逐渐进入日常开发流程之后，很多开发者都会有类似的体验：Mac 风扇更频繁启动、内存压力明显上升，但 Activity Monitor 中显示的 CPU / Energy 数值却往往与直观感受并不一致。

Howard Oakley 通过 powermetrics 与多种真实负载对照实验指出，Activity Monitor 中的 CPU % 更接近各 CPU core active residency 的简单叠加，而非传统意义上的“利用率百分比”；GPU % 同样只是 active residency 的近似表达；而 Energy Impact 则主要反映 CPU 层面的功耗估算，既不包含 GPU，也没有很好地刻画时间维度上的能耗变化。

工具

Quiver：用 Swift 学线性代数与经典机器学习

Wayne Bishop 长期维护的《Swift Algorithms & Data Structures》是一部面向 Swift 开发者的算法与数据结构电子书。在最新的第五版中，这本书已经从传统算法、数据结构延伸到向量、矩阵和相似度计算；而 Quiver 则把这条路径继续推进到数值计算、统计和经典机器学习。

Quiver 是一个纯 Swift、零依赖的线性代数、统计与经典机器学习库。它直接扩展 Swift 标准库的 Array，强调值语义、Codable、Sendable，以及在 Apple 平台上的轻量端侧运行。它的目标不是替代 Python 数值生态，而是为 Swift 开发者提供一个用熟悉语言理解线性代数、训练小型模型，并将结果带回 App 的入口。Wayne 在《Swift Algorithms & Data Structures》后续章节中，也正是以 Quiver 作为数学与机器学习基础内容的配套工具。

SwipeCell v3：SwiftUI 原生的侧滑菜单

WWDC 2026 上，SwiftUI 通过新的 swipeActionsContainer() 终于让侧滑菜单走出了 List，可以服务于 ScrollView、懒加载栈以及更多自定义容器。但遗憾的是，这项能力目前需要 anyAppleOS 27 对应的系统版本才能使用。

SwipeCell 是我六年前刚进入 Swift 开发时写下的第一个第三方库。旧版本很稚嫩，但也陪我见证了 SwiftUI 侧滑交互这些年的变化。最近我对它做了彻底的重写，推出了 v3 版本：新的 API 更 SwiftUI 化，配置更完整，交互手感也重新打磨，并加入了 macOS 支持。

目前 SwipeCell v3 发布在 v3-beta 分支，仍处于 beta 阶段，欢迎试用，也欢迎反馈使用中的问题。

求贤

资深 iOS / Swift 工程师

Speak：YC 孵化、OpenAI 多轮投资的 AI 语言学习独角兽。

工作地：上海。

一家在海外多个市场长期验证、商业化成熟的 AI-native 语言学习公司，正在从 0 -> 1 组建中国核心工程团队。团队小而美、不内卷，重度使用 AI(Cursor / Claude Code 等)，看重工程 owner 意识和 agentic engineering 工作方式。

作为中国团队的早期核心 iOS，你将全程参与技术选型,搭建国内 iOS 完整基建、对接本土支付 / 登录 / 合规 SDK、优化 AI 语音实时交互体验,并与全球团队英文协作。

期待你具备:

• 5 年以上 iOS 原生(Swift)开发经验,有上线的消费级产品

• 扎实的原生 iOS 深度(性能、稳定性、架构、弱网优化等)

• AI-native 工作流(日常用 Cursor / Claude / Copilot 等)

• 书面英文胜任 PR / Slack / 文档,口语 B1+、能清晰表达技术想法

• 有国内 App Store 上架 / 本土 SDK 经验者优先;音视频 / RTC / 语音方向加分

👉 详细参见

有意向者欢迎投递英文简历至 a.suen@usespeak.com

SPI Joins Apple, and Swift Moves Toward Self-Hosting

Read on web →

A few days ago, Swift Package Index (SPI) announced that it had joined Apple. The two sides will work together to build a comprehensive package registry for Swift developers. At the same time, SPI’s existing capabilities, including package discovery, compatibility checking, and documentation hosting, will continue to be provided, and package authors will not need to adjust their current publishing workflows in the short term.

This also adds a new footnote to the observation I made in #135⁠ that “SwiftPM has only just reached its second chapter”: the retreat of CocoaPods merely pushed SPM into the default position, while SPI joining Apple truly opens the next act of Swift package ecosystem infrastructure.

If SwiftPM answered the question of “whether packages can be conveniently depended on,” and SPI answered “whether packages can be found and evaluated,” then joining Apple moves the conversation further toward “whether packages can be published, identified, and distributed in a trustworthy way.” Looking at the medium term, three points are especially worth watching:

• SPI will evolve from a third-party indexing service into an important entry point for the official package registry;

• The Swift package ecosystem may gradually reduce its implicit dependence on GitHub as a source of hosting, distribution, and identity;

• Xcode may establish closer integration with SPI’s search, compatibility checking, and documentation capabilities.

Another exciting development for Swift developers last week was Erik Eckstein’s announcement on the Swift forums that the Swift project will drop the requirement that the compiler “must be buildable using only a C++ host toolchain⁠.” In other words, starting from the main branch, building the Swift compiler will require an existing Swift toolchain. This also means that mandatory compiler paths that previously had to remain implemented in C++ can now gradually be written in Swift. The officially mentioned scope includes core components such as the Parser, AST, Type Checker, and mandatory SIL passes.

This does not mean that the Swift compiler has already been completely rewritten in Swift, nor does it mean that the C++ parser will disappear immediately. More precisely, this is an important threshold for the Swift compiler as it moves toward bootstrapping and self-hosting: Swift is no longer limited to peripheral tools, optional features, or individual optimization passes, but can now enter the compiler’s core paths.

Bootstrapping itself does not simply prove the strength or weakness of a language, but it does represent a form of engineering maturity: whether the language, compiler, standard library, package manager, and cross-platform build system are strong enough to support their own continued evolution. For a language that hopes to expand its influence beyond Apple platforms, this step carries both symbolic significance and practical value.

Looking at SPI joining Apple alongside the Swift compiler moving toward self-hosting, it becomes clear that they point to the same thing: Swift is filling in its ecosystem infrastructure. The former concerns package discovery, identity, signing, and trusted distribution, while the latter improves the maintainability and evolution capacity of the language toolchain itself. Whether Swift can truly break out depends not only on how much influence Apple has over it, but on whether Apple and the Swift community can continue to show an open and enterprising attitude, and whether they can make the toolchain, package ecosystem, and cross-platform experience complete enough. On these two developments, I am willing to remain optimistic.

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

Bring Swift to The APPLE II

The Apple II was one of Apple’s most important early products and continues to influence many developers today. Many people once used BASIC or Apple Pascal on it, but what would it feel like to write Swift on this machine? Yeo Kheng Meng⁠ created SwiftII, a Swift-like mini development environment that allows an old machine with a 1 MHz 6502 CPU and around 64 KB of memory to write and run Swift-like programs.

What makes the article fascinating is not only “getting a Swift-like language running on the Apple II,” but also the many engineering trade-offs imposed by hardware limitations: limited memory space, conflicts between the language card and ProDOS, keyboard and display differences across Apple II models, and why the project ultimately had to be distributed as multiple disk images. The author also candidly shares the process of AI-assisted development. Even with the help of Claude Code and Codex, key architectural trade-offs, scope control, and hardware testing strategies still had to be handled by the author. This article offers both retro-computing engineering details and the compromises involved in bringing modern language design into an extremely constrained environment.

Building an over-the-air update system for native Swift with WebAssembly, from scratch

Building an OTA update mechanism for native Swift iOS apps is a controversial but valuable direction. In this article, Jack Solomon⁠ demonstrates a WebAssembly-based approach: compile Swift functions into WASM, load and execute them inside an iOS app through WasmKit, and then download new WASM modules from a server, allowing the app to change its runtime behavior without rebuilding or replacing the signed binary.

The article breaks down the Swift-to-WASM toolchain, WASI, @_cdecl exports, reactor modules, passing parameters through linear memory, and why hot-updating SwiftUI views requires dynamic replacement and a serializable view description tree. Jack also packaged this approach into a Swift SDK: patch-swift⁠.

It should be noted that this type of solution touches the boundaries of App Store Review rules around downloading and executing code, so actual usage still requires careful evaluation of the scenario and compliance risks.

SwiftUI Is One Graph

Mihaela Mihaljević Jakić⁠ published two long articles about SwiftUI’s underlying mechanisms over the past week, and they are worth reading together. The first, SwiftUI Is One Graph, starts from observed behavior and Apple patents to explain that SwiftUI is not simply doing View Tree diffing, but is more like a demand-driven attribute graph: View structs themselves are disposable descriptions, while what truly persists is the attribute graph and the state, dependencies, layout, and animation propagation within it.

The second article, “The SwiftUI Oracle: Measuring a Clean Room Against the Real Thing,” goes further by showing how to validate this understanding. The author implements a clean-room engine called PureView that does not depend on SwiftUI, then treats real SwiftUI as an oracle and uses differential testing of layout, animation, pixel rendering, and more to validate the model.

Mihaela’s workflow is highly inspiring for AI agents. Agents do not need to rely solely on language models to guess whether SwiftUI behavior is correct; they can generate or modify an implementation, run tests, and let real SwiftUI provide comparable results. This kind of “unit test”-like feedback loop can turn the understanding of a black-box framework into engineering signals that can be continuously verified and iterated on.

SwiftUI: Intercept-able Picker / Menu / Context Menu

In many scenarios, developers want to perform some synchronous operation before components such as Menu, Picker, or contextMenu are presented, such as recording how many times a menu is opened, updating state, or temporarily deciding whether presentation should be allowed. SwiftUI, however, does not provide a corresponding callback. In this article, Itsuki shares an implementation approach: bridge to a native View that hosts SwiftUI content, execute menuWillOpen when the corresponding gesture is triggered, and then decide whether to actively present the menu using AppKit APIs such as NSMenu.popUpContextMenu.

This article once again highlights a practical issue with SwiftUI: many seemingly simple interaction controls, once they go beyond what the system modifiers expose, still require understanding the underlying AppKit / UIKit layer to truly solve.

_UIPortalView: From Live Mirroring to Liquid Glass-Style Effects

Artem Mirzabekian⁠ shared an interesting private UIKit component, _UIPortalView. Backed by CAPortalLayer, it can project the rendered result of a sourceView to another location on the screen in real time, without duplicating the View hierarchy or repeatedly generating snapshots. Compared with static snapshots, Portal is more like a “live window” at the compositing layer: the source view remains the single source of state, while changes to text, animations, layout, or subviews can be reflected synchronously elsewhere.

The article also connects _UIPortalView with Liquid Glass-style effects: through matchesPosition, clipping, offsets, and 3D transforms, it can achieve real-time mirroring, reflections, lenses, shared backgrounds, edge distortion, and other effects.

Taking control of toolbar items in SwiftUI

The new SwiftUI Toolbar APIs introduced at WWDC 26 strike a better balance between system adaptivity and explicit developer control. In this article, Majid Jabrayilov⁠ introduces several new control capabilities: using visibilityPriority to specify the display priority of toolbar items, explicitly creating collapsed menus with ToolbarOverflowMenu, pinning important actions to the trailing edge of the top bar with .topBarPinnedTrailing, and using toolbarMinimizeBehavior to control how the navigation bar, tab bar, bottom bar, and others minimize during scrolling.

The same set of toolbar items may be presented differently on iOS, iPadOS, and macOS. The value of the new APIs is that they do not undermine the original cross-platform adaptive nature of SwiftUI Toolbar, while still allowing developers to express more clearly which actions should be shown first, which actions can be intentionally placed into overflow, and how toolbars should respond to scrolling.

Tools

iOS-Simulator-Camera-Extend: Adding a “Truly Usable Camera” to iOS Simulator

iOS Simulator has long lacked real camera capabilities. Features involving QR code scanning, OCR, faces, video calls, or AVCaptureSession often require a physical device or mocked logic. Developed by Shuyu Guo, iOS-Simulator-Camera-Extend recreates the core idea of SimCam: through a macOS-side frame source, DYLD_INSERT_LIBRARIES hooks inside Simulator, and AVFoundation swizzling, the app under test can access the Mac camera, desktop, images, videos, and QR code feeds in the simulator without code changes or a different bundle id.

Even more interestingly, it also provides another path based on a CMIO System Extension, allowing macOS apps such as QuickTime, FaceTime, Zoom, and OBS to see a SimCam Virtual Camera. In other words, the same frame source can be fed both to an app running inside iOS Simulator and used as a macOS virtual camera, making it very useful for debugging, demonstrations, and automated testing of camera-related features.

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

Share

SPI 加入 Apple，Swift 迈向自举

网页版

几天前，Swift Package Index（SPI）宣布已加入 Apple。双方将共同建设一个面向 Swift 开发者的综合 package registry；与此同时，SPI 现有的包发现、兼容性检查、文档托管等能力仍会继续提供，包作者在短期内也无需调整现有的发布流程。

这也让 #135⁠ 中“SwiftPM 才刚到第二章”的判断得到了新的注脚：CocoaPods 的退场只是把 SPM 推上了默认位置，而 SPI 加入 Apple，才真正揭开了 Swift 包生态基础设施建设的下一幕。

如果说 SwiftPM 解决的是“能不能方便地依赖包”，SPI 解决的是“能不能找到并评估包”，那么这次加入 Apple 则把问题进一步推进到了“能不能可信地发布、识别和分发包”。从中期来看，有三点尤其值得观察：

• SPI 将从第三方索引服务，演进为官方 package registry 的重要入口；

• Swift 包生态可能逐步降低对 GitHub 作为托管、分发与身份来源的隐性依赖；

• Xcode 有机会与 SPI 的搜索、兼容性检查和文档能力建立更紧密的集成。

上周，另一件让 Swift 开发者振奋的事情是，Erik Eckstein 在 Swift 论坛上宣布，Swift 项目将取消“必须能够仅使用 C++ 宿主工具链构建编译器”的要求。换句话说，从 main 分支开始，构建 Swift 编译器将需要已有的 Swift 工具链参与；这也使得编译器中那些过去必须保持 C++ 实现的强制路径，现在可以逐步用 Swift 编写。官方提到的范围包括 Parser、AST、Type Checker，以及 mandatory SIL passes 等核心部分。

这并不意味着 Swift 编译器已经完全用 Swift 重写，也不意味着 C++ parser 会马上消失。更准确地说，这是 Swift 编译器迈向自举和自托管的重要门槛：Swift 不再只是用于外围工具、可选功能或个别优化 pass，而是可以进入编译器的核心路径。

自举本身并不能简单证明一门语言能力的高低，但它代表了一种工程成熟度：语言、编译器、标准库、包管理器和跨平台构建系统，是否已经强大到足以支撑自身的持续演进。对于一个希望在 Apple 平台之外继续扩展影响力的语言来说，这一步的象征意义和实际价值都不小。

把 SPI 加入 Apple 与 Swift 编译器迈向自托管放在一起看，会发现它们指向的是同一件事：Swift 正在补齐生态基础设施。前者关乎包的发现、身份、签名和可信分发，后者则提升了语言工具链自身的可维护性与演进能力。Swift 能否真正破圈，关键并不只在于 Apple 在其中拥有多大的影响力，而在于 Apple 与 Swift 社区是否能持续展现开放、进取的态度，并把工具链、包生态和跨平台体验打磨到足够完整。就这两件事而言，我愿意保持乐观。

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

近期推荐

在 Apple II 上跑 Swift (Bring Swift to The APPLE II)

Apple II 是苹果早期最重要的产品之一，至今仍影响着许多开发者。很多人都曾在它上面使用 BASIC 或 Apple Pascal，但如果在这台机器上写 Swift，又会是什么体验？Yeo Kheng Meng⁠ 实现了一个 Swift 风格的迷你开发环境 SwiftII，让一台搭载 1 MHz 6502 CPU、64 KB 级别内存的老机器也能编写和运行类似 Swift 的程序。

文章精彩的地方不只是“让 Apple II 跑上类 Swift 语言”，还包括大量围绕硬件限制的工程取舍：有限的内存空间、语言卡和 ProDOS 的冲突、不同 Apple II 机型的键盘与显示差异，以及为什么最终要拆成多张磁盘镜像发布。作者也坦诚分享了 AI 辅助开发的过程。即便有 Claude Code 和 Codex 的帮助，关键的架构取舍、范围控制和硬件测试策略仍然需要作者自己把关。本文既有复古计算机的工程细节，也有现代语言设计在极小环境中的取舍。

基于 WebAssembly 实现 Swift App 热更新 (Building an over-the-air update system for native Swift with WebAssembly, from scratch)

为原生 Swift iOS App 构建 OTA 更新机制，是一个有争议但也很有价值的方向。Jack Solomon⁠ 在这篇文章中展示了基于 WebAssembly 的实现思路：将 Swift 函数编译成 WASM，再通过 WasmKit 在 iOS App 内加载执行，随后从服务器下载新的 WASM 模块，让 App 在不重新构建、不替换已签名二进制的情况下改变运行结果。

文章拆解了 Swift to WASM 的工具链、WASI、@_cdecl 导出、reactor module、线性内存传参，以及 SwiftUI 视图热更新为什么需要 dynamic replacement 和可序列化的视图描述树。Jack 也将这套思路包装成了 Swift SDK：patch-swift⁠。

需要注意的是，这类方案触及 App Store 审核规则中关于下载和执行代码的边界，实际使用时仍需要谨慎评估场景和合规风险。

理解 SwiftUI 的底层核心：属性图 (SwiftUI Is One Graph)

Mihaela Mihaljević Jakić 在过去一周连续发表了两篇关于 SwiftUI 底层机制的长文，值得放在一起阅读。第一篇 SwiftUI Is One Graph 从实际行为和 Apple 专利出发，解释 SwiftUI 并不是简单的 View Tree diff，而更像是一个 demand-driven attribute graph：View struct 本身只是可丢弃的描述，真正持续存在的是属性图，以及其中的状态、依赖、布局和动画传播。

第二篇 《The SwiftUI Oracle: Measuring a Clean Room Against the Real Thing》则进一步展示了如何验证这种理解。作者实现了一个不依赖 SwiftUI 的 clean-room 引擎 PureView，再把真实 SwiftUI 当作 oracle，通过布局、动画、像素渲染等 differential testing 去验证自己的模型。

Mihaela 的工作流对 AI agent 很有启发。Agent 不需要只靠语言模型去猜 SwiftUI 行为是否正确，而是可以生成或修改实现，然后运行测试，让真实 SwiftUI 给出可比较的结果。这种类似“单元测试”的反馈闭环，能把对黑盒框架的理解变成可以持续验证和迭代的工程信号。

在 SwiftUI 中实现可拦截回调的菜单与选择器 (SwiftUI: Intercept-able Picker / Menu / Context Menu)

很多场景下，开发者都希望能在 Menu、Picker、contextMenu 等组件弹出前执行一些同步操作，比如统计打开次数、更新状态，或者临时决定是否允许展示。但 SwiftUI 并没有提供对应的回调。Itsuki⁠ 在这篇文章中分享了自己的实现思路：通过桥接一个承载 SwiftUI 内容的原生 View，在对应手势触发时先执行 menuWillOpen，再决定是否使用 NSMenu.popUpContextMenu 等 AppKit API 主动展示菜单。

本文再次体现了 SwiftUI 的一个现实问题：很多看似简单的交互控制，一旦超出系统 modifier 暴露的能力，仍然需要理解底层 AppKit / UIKit 才能真正解决。

解析 UIPortalView：从视图实时投影到流体玻璃特效 (_UIPortalView: From Live Mirroring to Liquid Glass-Style Effects)

Artem Mirzabekian⁠ 分享了 UIKit 中一个有趣的私有组件 _UIPortalView。它由 CAPortalLayer 支持，可以把某个 sourceView 的渲染结果实时投射到屏幕上的另一个位置，而不需要复制一份 View 层级，也不需要反复生成 snapshot。相比静态快照，Portal 更像是合成层上的“实时窗口”：源视图仍然是唯一状态来源，而文本、动画、布局或子视图变化都可以同步反映到另一处显示。

文章还把 _UIPortalView 和 Liquid Glass 效果联系起来：通过 matchesPosition、裁剪、偏移和 3D transform，可以实现实时镜像、反射、镜头、共享背景和边缘扭曲等效果。

掌控 SwiftUI 工具栏新 API (Taking control of toolbar items in SwiftUI)

WWDC 26 带来的新 SwiftUI Toolbar API，让系统自适应和开发者显式控制之间取得了更好的平衡。Majid Jabrayilov 在这篇文章中介绍了几项新的控制能力：通过 visibilityPriority 指定 toolbar item 的显示优先级，用 ToolbarOverflowMenu 明确创建折叠菜单，借助 .topBarPinnedTrailing 将重要操作固定在顶部栏尾部，以及使用 toolbarMinimizeBehavior 控制导航栏、标签栏、底部栏等在滚动时的最小化行为。

同一组 toolbar items 在 iOS、iPadOS 和 macOS 上可能会有不同的展示方式。新 API 的价值在于，它们没有破坏 SwiftUI Toolbar 原本的跨平台自适应能力，却让开发者可以更明确地表达哪些操作应该优先显示、哪些操作可以主动放进 overflow，以及工具栏应该如何响应滚动。

工具

iOS-Simulator-Camera-Extend：给 iOS Simulator 补上“真实可用的相机”

iOS Simulator 一直没有真正的相机能力，涉及扫码、OCR、人脸、视频通话、AVCaptureSession 的功能，往往只能上真机或写模拟逻辑。由 Shuyu Guo⁠ 开发的 iOS-Simulator-Camera-Extend 复刻了 SimCam 的核心思路，通过 macOS 端帧源、Simulator 内 DYLD_INSERT_LIBRARIES hook 与 AVFoundation swizzle，让被测 App 无需改代码、无需换 bundle id，就能在模拟器里拿到 Mac 摄像头、桌面、图片、视频和二维码画面。

更有意思的是，它还提供了另一条 CMIO System Extension 链路，让 QuickTime、FaceTime、Zoom、OBS 等 macOS 应用也能看到一台 SimCam Virtual Camera。也就是说，同一份帧源既可以喂给 iOS Simulator 里的 App，也可以作为 macOS 虚拟摄像头使用，对相机相关功能的调试、演示和自动化测试都很实用。

Is Anyone Else Excited by Swift’s Progress as a Language?

Read on web →

Last week, a Reddit post titled “Is anyone else excited by Swift progress as the language?⁠” sparked a lively discussion. At WWDC 2026, Apple made it clear that Swift is now being used in key WebKit components, the QUIC networking stack, font rendering, drivers, and firmware—and, as the original poster claimed, it has started making its way into the core operating system kernel beginning with the 27 releases. The original poster saw this as Apple finally delivering on the promise it made in 2014 when it introduced Swift as a “high-level systems programming language.” The discussion soon expanded beyond whether that promise had been fulfilled to topics such as cross-platform support, language governance, the tooling experience, and whether Swift is becoming too large and ambitious.

Despite its remaining shortcomings, I still appreciate the progress Swift has made over the years. This week’s recommendations happen to offer several different perspectives on that progress: Swift 6.4 continues to fill in practical gaps in the concurrency model; KernelKit reveals the infrastructure Apple is laying for Swift in the kernel; and SwiftOS demonstrates Embedded Swift taking on an entire operating system and real-world service workloads. Swift’s progress is no longer measured only by the number of language features it has gained, but also by the growing range of work it can handle—and many of those use cases are no longer merely experimental.

Personally, since Swift 6, I have tried to adopt new language features wherever possible. For new projects, I have already raised the minimum required Swift compiler version to 6.2, and as my understanding deepens, I may raise it further. Some features involving concurrency, ownership, and isolation can feel awkward at first. Once their design goals become clear, however, they often turn out not to increase cognitive load, but to reduce it: correctness that once depended on conventions, comments, and developer experience can now be expressed as constraints the compiler is able to verify. The result is code that is easier to reason about, clearer in intent, and able to prevent many safety issues before it ever runs.

In the age of AI, a language’s ergonomic advantages may no longer determine adoption as decisively as they once did. As the cost of generating code falls, the real differentiators are more likely to be the ecosystem, tooling, available deployment targets, and whether the compiler can provide consistently reliable feedback. But that does not make language design less important—it simply changes how its value appears. As AI participates in writing more of our code, strong type systems, explicit ownership semantics, and strict concurrency checking become machine-verifiable guardrails. AI can produce code faster; the language and compiler help us determine which of that code deserves to be trusted.

Swift has always occupied a somewhat contradictory position. The Apple ecosystem gives it a large, stable field of application, yet it has also caused the language to be seen for years as something that “belongs only to Apple.” That ecosystem is both the hardest boundary for Swift to cross as it expands outward and the solid foundation that ensures continued investment, steady evolution, and protection from fading into irrelevance. Today, developments such as the official Android SDK, the WebAssembly SDK, and the Windows Working Group suggest that this boundary is gradually moving outward. Of course, tooling, package ecosystems, and the overall developer experience on non-Apple platforms still have a long way to go.

Does Swift still make me feel excited? Perhaps not exactly. But I genuinely enjoy where the language is today. Compared with the grand vision of a decade ago, I prefer the current pace: turning those promises into engineering reality, one step at a time.

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

From Size Class to Available Space: Is horizontalSizeClass Still Reliable?

Starting with WWDC 26, iPhone apps mirrored to a Mac through iPhone Mirroring will support freely resizable windows. At the same time, iPhone-only apps running on iPad will also enter a variable-size environment. The impact of this update goes far beyond simply allowing iPhone apps to resize. It is changing how many developers have long understood the layout system. Traits that were once commonly used as the basis for layout decisions, such as horizontalSizeClass, are no longer suitable as the primary indicator of window width. So, is this change a sudden shift in direction, or the inevitable result of Apple’s years-long evolution of its layout system? This article explores that question.

Recent Recommendations

Swift 6.4: What’s New in Concurrency

In this article, Antoine van der Lee⁠ reviews a series of improvements Swift 6.4 brings to concurrency, including support for asynchronous cleanup in defer, cancellation shields that ensure critical cleanup or rollback operations can finish, warnings for ignored throwing Task instances, and typed error support for Task. In addition, Result can now directly wrap asynchronous throwing operations, while ~Sendable and the weak let introduced in Swift 6.3 make the modeling of Sendable types more precise.

Compared with the more sweeping changes made to the concurrency model before Swift 6.2, these additions introduce relatively little new cognitive overhead. Instead, they refine the existing model and address practical engineering concerns involving cleanup, cancellation, error handling, and type modeling.

Apple Internals: Swift in the Kernel

Swift has now been around for more than a decade. As the creator of the language, has Apple begun using it to develop operating system kernels? Josh Maine of Calif analyzed the macOS 27 and iOS 27 kernelcaches, along with the Xcode 27 Beta toolchain, and discovered that Apple has added an internal SDK called KernelKit, separate Mach-O platform identifiers for different operating systems, and an Embedded Swift runtime statically linked into a macOS kernel extension.

However, this does not mean that XNU is being rewritten in Swift. At present, Swift appears only at the kernel-extension layer. The runtime included in macOS is not yet referenced by any other component, while iOS has so far completed only the platform and toolchain groundwork. The infrastructure looks more like Apple laying down the toolchain, runtime, and linking environment before introducing actual Swift kernel components. In any case, it brings us one step closer to seeing real kernel components written in Swift.

Touch to Pixels: UI Pipeline Internals on iOS

What exactly happens inside the system after you tap an iOS interface but before the pixels on the screen change? Starting with a single touch event, Jacob Bartlett⁠ follows the entire journey through the touchscreen hardware, XNU, IOKit, backboardd, the app’s Run Loop, UIKit, and Core Animation. He traces how the event reaches our code, and how the resulting UI update passes through the Render Server, GPU, and frame buffer before finally becoming pixels on the display. Understanding this complete journey from Touch to Pixels not only gives us a clearer mental model of the iOS UI system, but also helps when diagnosing common performance issues such as main-thread blocking, stuttering animations, and dropped frames.

Dynamic Text in SwiftUI

Imagine an app with a global preference that determines whether every screen displays a user’s full name or nickname. The most direct approach is to add a conditional check everywhere a username appears, but the entire preference breaks down as soon as one new feature forgets to handle it. Robb Böhnke solves this by using a BCP 47 private-use subtag to encode the preference into Locale, then reading it through a custom FormatStyle when Text is actually rendered. This approach works around SwiftUI’s lack of a dynamic Text initializer and turns logic that could easily be forgotten at individual call sites into application-wide default behavior.

SwiftUI SensoryFeedback Cache Key Pitfall: Do Not Store Continuous Values

Can dynamically adjusting haptic feedback intensity with a Slider in SwiftUI really cause memory usage to grow rapidly? It sounds surprising, but the issue genuinely exists from iOS 17 through iOS 26. Kyle Ye discovered that the internal implementation in these versions included continuous values such as intensity in the feedback generator’s cache key. Every tiny change in intensity could therefore correspond to a new UIImpactFeedbackGenerator instance, causing the cache to grow continuously.

Kyle filed an FB late last year and was notified this June that the issue had been fixed. Rather than patching the problem by introducing a cache-specific key, iOS 27 redraws the model boundary: it completely separates the “stable identity” represented by FeedbackType from the per-play dynamic parameters stored in the new Payload. The public API remains unchanged, but the cache behavior is corrected at the data-model level.

What makes this fix worth studying is not merely that it resolves the memory-growth issue, but that it demonstrates an important principle of API design: stable information describing an object’s identity should not be mixed with dynamic parameters that affect only a single operation. It also reminds us that simply conforming to Hashable does not make a type inherently suitable for use as a cache key. Rather than repeatedly excluding exceptional fields at the point of use, drawing clear semantic boundaries in the data model is usually the more reliable design.

Architecting a Conversion Engine in Swift

When an application needs to convert among formats such as Markdown, HTML, rich text, and PDF, how can it prevent conversion logic from growing quadratically as more formats are added? Arthur Van Siclen explains the solution he developed for Minimal: introduce an Intermediate Representation, or IR, so that each format only needs its own Parser and Renderer. With six formats, this reduces the number of conversion relationships from 30 to 12.

Its treatment of lossy conversion is particularly worth learning from. Different formats do not have equivalent expressive capabilities, so Minimal uses Concession to explicitly record formatting that was downgraded, content that was dropped, or data that was truncated during conversion, rather than pretending that every conversion can be lossless.

Tools

SwiftOS: Building a Real Operating System with Embedded Swift

SwiftOS is a 64-bit ARM operating system written almost entirely from scratch in Embedded Swift. Its author, Andrey Sapunov, began with a straightforward idea: rather than learning operating-system concepts only from books, why not build one and truly understand how kernels, memory, processes, and devices work together? His choice of Swift was not merely a matter of language preference. He wanted to preserve predictable code generation and low-level control while using Swift’s type system, ownership model, and modern engineering tools to make systems code safer and easier to express.

SwiftOS follows a distinctly modern systems architecture: AArch64, MMU-based process address-space isolation, a custom syscall ABI, a capability-oriented authorization model, static linking, a signed read-only base image, and a native Swift userland. It already includes an in-kernel TCP/IP stack, can run nginx and Node.js, and is deployed on a real Hetzner Cloud ARM instance—the project’s website is hosted by SwiftOS itself.

We may still need more time before Swift is widely used within Apple’s operating system kernels. But SwiftOS proves at least one thing: Embedded Swift is no longer limited to firmware and bare-metal examples. It is capable of supporting an operating system with process isolation, user-space programs, a network stack, and real service workloads.

Loupe: Giving AI Agents Runtime Evidence for Native Apple UIs

Loupe, created by Won Heo, is a runtime diagnostics and E2E verification tool for Apple platforms. It is particularly useful when AI coding agents such as Codex and Claude Code participate in native UI development. Loupe does not replace xcodebuild, XCTest, or other tools responsible for building and testing an application. Instead, by injecting or linking a runtime into a debug build, it adds a runtime UI evidence layer on top of them. From the app that is actually running, it can collect UIKit and AppKit view structures, accessibility information, screenshots, logs, URLSession network activity, and state such as Defaults and Feature Flags, then expose querying and auditing capabilities through its CLI.

An agent can begin with a compact observation of the UI, inspect specific nodes in greater detail as needed, perform simulator-visible actions such as tap, swipe, drag, and type, and record before-and-after snapshots, diffs, and traces. It can also make probe-like runtime changes to selected UIKit properties and constraints, quickly verify whether an adjustment works, and then return to the source code to implement the actual fix. This turns questions such as “Does it look right?”, “Does the interaction work?”, and “Has the layout drifted?” from screenshot-driven guesswork into a reviewable and reproducible chain of evidence.

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

Share

Swift 还让你 Excited 吗？

网页版

上周，Reddit 上一篇题为《Is anyone else excited by Swift progress as the language?》的帖子引发了不少讨论。WWDC 2026 上，Apple 明确表示，Swift 已被用于 WebKit 关键组件、QUIC 网络栈、字体渲染、驱动与固件。发帖者据此认为，Swift 正在向核心操作系统内核迈进，并将这一幕视为 2014 年”高级系统编程语言”承诺的兑现。评论区的讨论则很快从“是否兑现了承诺”，延伸到跨平台支持、语言治理、工具链体验，以及 Swift 是否正在变得过于庞大等话题。

尽管问题依然不少，我仍然很欣赏 Swift 这些年的进展。本期推荐的内容也恰好提供了几个不同的观察切面：Swift 6.4 继续补齐并发模型中的工程细节，KernelKit 展示了 Apple 为内核 Swift 铺设的基础设施，SwiftOS 则让 Embedded Swift 承担起一个完整操作系统与真实服务负载。Swift 的进步已不只体现为语言特性越来越多，更体现在它能够胜任的工作种类不断增加，而且其中不少已经走出了实验阶段。

就我个人而言，从 Swift 6 开始，我几乎都在尽可能地使用新的语言能力。在新项目中，我已经将 Swift 编译器的最低版本要求设置为 6.2；随着理解不断深入，未来可能还会继续提高。一些涉及并发、所有权和隔离的特性，初看时确实有些拗口，但真正理解其设计目标后往往会发现：它们不是在增加心智负担，而是在把过去依赖约定、注释和经验维持的正确性，转变为编译器可以检查的约束。代码因此更容易推理，意图也更加清楚，许多安全问题则在运行之前就被挡了下来。

在 AI 时代，一门语言的人体工学优势，或许不再像过去那样单独决定开发者是否愿意采用它——生成代码的成本下降后，真正拉开差距的更可能是生态、工具链、可部署的平台，以及编译器能否持续提供可靠反馈。但语言设计的重要性并未因此减弱，反而换了一种方式体现：当越来越多代码由 AI 参与生成时，强类型系统、明确的所有权语义和严格的并发检查，都会成为可机器验证的护栏。AI 可以更快地产生代码，而语言和编译器负责告诉我们，哪些代码值得信任。

Swift 的处境也始终带着一种矛盾。Apple 生态为它提供了稳定且庞大的应用场景，却也长期让外界将其视为一门“只属于 Apple”的语言。这个生态既是 Swift 向外扩张时最难跨越的边界，也是它能够得到长期投入、稳步演进，不至于轻易被时代淘汰的坚实后盾。如今，官方 Android SDK、WebAssembly SDK 和 Windows 工作组等进展表明，这条边界正在逐渐向外移动；当然，非 Apple 平台上的工具链、包生态和开发体验仍有很长的路要走。

要说 Swift 现在是否仍让我感到 Excited，倒也未必；但我确实很 Enjoy 它当前的状态。相比十年前的宏大愿景，我更喜欢今天这种把承诺一点点变成工程现实的节奏。

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

原创

从 Size Class 到可用空间，horizontalSizeClass 还可靠吗？

从 WWDC 26 开始，iPhone 应用在 iPhone Mirroring 到 Mac 时，其窗口尺寸将支持自由调整。与此同时，iPhone-only 应用在 iPad 上运行时，也会进入可变尺寸环境。这次更新带来的影响远不止“iPhone 应用可以调整尺寸”这么简单。它正在改变许多开发者长期以来对布局系统的理解。一些过去常被用作布局依据的 trait，例如 horizontalSizeClass 已不再适合作为窗口宽度的主要判断依据。那么，这种变化究竟是一次突然出现的转向，还是 Apple 多年布局下的必然演进？本文将对此进行探讨。

近期推荐

Swift 6.4 并发新特性 (Swift 6.4: What’s New in Concurrency)

Antoine van der Lee 在本文中梳理了 Swift 6.4 为并发编程带来的一系列改进，包括支持在 defer 中执行异步清理、通过取消屏蔽确保关键的清理或回滚操作得以完成、为被忽略的可抛错 Task 增加警告，以及为 Task 引入类型化错误支持。此外，Result 现在可以直接封装异步可抛出操作，~Sendable 和 Swift 6.3 引入的 weak let 也让 Sendable 类型的表达更加准确。

相较于 Swift 6.2 之前对并发模型较为大刀阔斧的调整，这些变化不会带来太多新的心智负担，更多是在现有模型之上补齐细节，解决实际工程中清理、取消、错误处理和类型建模等方面的问题。

探索苹果系统内核中的 Swift (Apple Internals: Swift in the Kernel)

Swift 已经诞生十余年。作为这门语言的创造者，苹果是否已经开始将它用于操作系统内核的开发？来自 Calif 的 Josh Maine 通过分析 macOS 27、iOS 27 的 kernelcache 与 Xcode 27 Beta 工具链发现，Apple 新增了名为 KernelKit 的内部 SDK、对应不同系统的 Mach-O 平台标识，以及一套静态链接在 macOS 内核扩展中的 Embedded Swift 运行时。

不过，这并不意味着 XNU 正在被 Swift 重写。目前，Swift 只出现在内核扩展层；macOS 中的运行时尚未被其他组件实际调用，而 iOS 现阶段也只是完成了平台和工具链层面的准备。整套基础设施更像是 Apple 在正式引入 Swift 内核组件之前，先行铺设工具链、运行时与链接环境。无论如何，这意味着距离真正使用 Swift 编写内核组件又近了一步。

从触摸到像素：iOS 渲染管线底层探秘 (Touch to Pixels: UI Pipeline Internals on iOS)

当手指点击 iOS 界面后，到屏幕上的像素发生变化之前，系统内部究竟经历了什么？Jacob Bartlett⁠ 从一次触摸事件出发，沿着触摸屏硬件、XNU、IOKit、backboardd、应用 Run Loop、UIKit 与 Core Animation，一路追踪事件如何抵达我们的代码，以及界面更新如何经过 Render Server、GPU 和帧缓冲区，最终转化为屏幕上的像素。了解这条从 Touch 到 Pixels 的完整链路，不仅能帮助我们建立对 iOS UI 系统的整体认识，也有助于分析主线程阻塞、动画卡顿和掉帧等常见的界面性能问题。

SwiftUI 动态文本渲染 (Dynamic Text in SwiftUI)

设想一个场景：应用里有一个全局开关，决定所有界面显示用户的全名还是昵称。最直接的做法，是在每一处显示用户名的地方都加上判断，但只要有一个新功能忘记处理，这个开关就会失效。Robb Böhnke 的解法是借用 BCP 47 的私有子标签，将这项偏好编码进 Locale，再通过自定义 FormatStyle，在 Text 真正渲染时读取并选择对应的名称。这种做法绕过了 SwiftUI 缺少动态 Text 初始化 API 的限制，也把容易遗漏的调用端逻辑变成了应用范围内的默认行为。

SwiftUI SensoryFeedback Cache Key 经验教训：不要存储连续值

在 SwiftUI 中用 Slider 动态调整触觉反馈强度，竟然可能导致内存快速增长？听起来不可思议，但这个问题确实存在于 iOS 17 至 iOS 26 中。Kyle Ye 发现，这些版本的内部实现将 intensity 这样的连续值纳入了反馈生成器的缓存键。强度值的每一次细微变化，都可能对应一个新的 UIImpactFeedbackGenerator 实例，最终导致缓存不断膨胀。

Kyle 在去年年底提交了 FB，并于今年 6 月收到问题已修复的通知。iOS 27 的解决方案并不是增加一个缓存专用 Key 来打补丁，而是重新划分模型边界：将代表“稳定身份”的 FeedbackType，与每次播放使用的动态参数 Payload 彻底拆开。公开 API 保持不变，缓存逻辑却从数据模型层面得到了修正。

这次修复值得关注的地方，不只是解决了内存增长问题，更体现了 API 设计中的一个重要原则：描述“对象身份”的稳定信息，不应与只影响单次操作的动态参数混在一起。它也提醒我们，一个类型即使满足 Hashable，也不代表它天然适合作为缓存键。相比在使用处不断排除特殊字段，从数据模型层面划清语义边界，通常是更可靠的设计。

Swift 构建文档转换引擎的架构设计 (Architecting a Conversion Engine in Swift)

当应用需要在 Markdown、HTML、富文本、PDF 等多种格式之间互相转换时，如何避免转换逻辑随着格式数量呈平方级增长？Arthur Van Siclen⁠ 介绍了他在 Minimal 中的解决方案：设计一套中间表示 IR，让每种格式只需分别实现 Parser 和 Renderer，从而将六种格式之间的 30 条转换关系减少为 12 条。

其中，对“有损转换”的处理尤其值得借鉴。不同格式的表达能力并不对等，Minimal 通过 Concession 显式记录转换过程中发生的格式降级、内容丢弃或截断，而不是假设所有格式之间都能无损转换。

工具

SwiftOS：用 Embedded Swift 写一个真正的操作系统

SwiftOS 是一个几乎完全使用 Embedded Swift 从零编写的 64 位 ARM 操作系统。作者 Andrey Sapunov⁠ 的出发点很朴素：与其只从书本上理解操作系统，不如亲手实现一个，真正弄清内核、内存、进程与设备如何协作。选择 Swift 也不只是出于语言偏好，而是希望在保持代码生成可预测和底层控制能力的同时，借助 Swift 的类型系统、所有权模型和现代工程工具，让系统代码更安全、更容易表达。

SwiftOS 选择了一条颇为现代的系统路线：AArch64、基于 MMU 的进程地址空间隔离、自定义 syscall ABI、能力导向的授权模型、静态链接、签名只读基础镜像，以及原生 Swift userland。它已经实现了内核态 TCP/IP 栈，能够运行 nginx 和 Node.js，并运行在真实的 Hetzner Cloud ARM 实例上——项目官网就是由 SwiftOS 自己托管的。

或许，我们还需要更多时间，才能看到 Swift 被大规模用于苹果的系统内核。但 SwiftOS 至少证明了一件事：Embedded Swift 已经不只能够编写固件和裸机示例，它也足以支撑一个拥有进程隔离、用户态程序、网络栈和真实服务负载的操作系统。

Loupe：为 AI Agent 补上 Apple 原生 UI 的运行时证据

Loupe 是由 Won Heo⁠ 发起的 Apple 平台运行时诊断与 E2E 验证工具，尤其适合 Codex、Claude Code 这类 AI Coding Agent 参与原生界面开发时使用。它并不替代 xcodebuild、XCTest 或其他负责构建和测试的工具，而是通过向调试中的 App 注入或链接运行时，补上其后的 UI 证据层：从真正运行的 App 中采集 UIKit/AppKit 视图结构、可访问性信息、截图、日志、URLSession 网络活动，以及 Defaults、Feature Flags 等状态，再通过 CLI 提供查询与审计能力

Agent 可以先获取紧凑的 UI 观察结果，再按需深入检查具体节点，执行 tap、swipe、drag、type 等模拟器可见操作，并记录操作前后的快照、差异与 trace；它还可以对部分 UIKit 属性和约束进行运行时探针式修改，快速验证调整是否有效，再回到源码完成真正的修正。这让“看起来对不对、点起来通不通、布局有没有漂移”不再只依赖截图与猜测，而是成为一条能够复查和留痕的证据链。

WWDC 26: AI Watched It for You — Now What?

Read on web →

With the rise of AI Agent workflows, many developers this year have started letting AI handle the summarizing and highlight-picking, absorbing WWDC announcements at a much faster pace. Apple has been accommodating too — releasing all Sessions, transcripts, and sample code at once, making it even easier for AI to process everything.

For me personally, what used to be a manual ritual of extracting interface files and comparing old and new APIs has become a single instruction in an Agent workflow. From a pure efficiency standpoint, that’s a real, tangible gain.

But information distilled at speed can’t always capture the nuance and precision that Apple engineers embed in a Session. Many Sessions are still worth sitting down with — carefully, even repeatedly.

AI accelerates how fast you acquire information. It doesn’t deepen how well you understand it. Information flowing into an AI’s context window is not the same as knowledge taking root in your own mind.

Your viewing habits can evolve with the times. Your standards for yourself shouldn’t.

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 ☕️

WWDC 2026

Roundups

• WWDC 26 Group Lab Q&A by Anton Gubarenko

  At this year’s Group Labs, Apple engineers answered questions from developers live on stage. Anton has compiled summaries from the Swift, SwiftUI for Beginners, SwiftUI Advanced, Performance, VisionOS, AI, Icon Composer, and Camera and Photo Labs.

• (Some) Unanswered Swift Group Questions by Matt Massicotte

  Time limits and voting mechanics meant not every question at the Swift Group Lab got answered. Matt picked out a selection of those that didn’t make it and offered his own take — covering Swift 6 migration, Approachable Concurrency, default MainActor isolation, @preconcurrency, Sendable / ~Sendable, and unstructured tasks.

• What’s new in Swift 6.4 at WWDC26 by Khoa Pham

  A walkthrough of the Swift 6.4 changes that make code more concise and expressive.

• What’s Coming in Swift 6.4 by Wade Tregaskis

  Wade rounds up the Swift Evolution proposals marked as implemented in Swift 6.4, spanning concurrency, ownership, the standard library, accessors, package management, and compiler diagnostics.

• What’s New in SwiftData for iOS 27 by Mohammad Azam

  SwiftData may not have received a headline-grabbing overhaul this year, but the new enum predicates, sectioned queries, composite predicates, .codable attribute, and ResultsObserver all address real pain points and meaningfully round out the developer experience.

• What is new in SwiftUI after WWDC26 by Majid Jabrayilov

  Majid surveys the SwiftUI additions from WWDC26 — many of them long-requested by the community. The one disappointment: with the exception of @State, most new APIs don’t offer backward compatibility.

• iOS 27: Notable UIKit Additions by Jordan Morgan

  SwiftUI keeps moving forward, but Apple hasn’t let up on UIKit either. This year’s UIKit API updates focus mainly on adapting to new system capabilities and aligning with what’s new in SwiftUI.

Documentation

• WWDC.ai by Superwall

  A site designed to help developers and AI agents quickly get up to speed on Apple’s developer updates. It offers Session summaries, an Ask AI interface, and a Skill for direct use in code assistants.

• iOS/MacOS: Apple Beta Doc Retriever by Itsuki

  An open-source iOS/macOS app that lets developers browse Beta-tagged documentation and APIs, making it easy to spot what’s changed between OS versions.

• WWDC Quick Look by SwiftGG

  A comprehensive archive of every Session from WWDC 2020 to today, with linked Sessions, video timestamps, and key code snippets. Also ships a Skill for use with AI tools.

• Ask WWDC by Matt Spear

  A natural-language Q&A search tool for WWDC content. Ask a question, get a concise answer along with the relevant Sessions.

New Features

• SwiftUI’s @State is now a macro by Artem Mirzabekian

  @State was originally designed with value types in mind. Once the Observation framework arrived in iOS 17, a gap became apparent: @State lacked the lazy initialization behavior that @StateObject provided for reference types. WWDC26 finally closes that gap. What’s particularly worth noting is that Apple didn’t touch the property wrapper implementation — instead, they introduced a same-named macro to handle the change. This approach may offer a useful blueprint for managing future compatibility challenges.

• WWDC26: The Evolution of Presentation Transitions in SwiftUI by codelaby

  SwiftUI gains a crossFade transition for sheet and fullScreenCover in WWDC26. The downside: custom presentation transitions are still not on the table.

• Custom scroll layouts with swipe actions in SwiftUI on iOS 27 by Natalia Panferova

  Starting in iOS 27, swipeActions is no longer exclusive to List. The new swipeActionsContainer() modifier brings swipe action support to LazyVStack, LazyVGrid, and custom Layout types inside a ScrollView. The new onPresentationChanged callback also fires when a row’s swipe actions expand or collapse — handy for tracking the active item, syncing state, or triggering additional logic.

• Using Claude with Apple Foundation Models by Artem Novichkov

  WWDC26 brings a significant expansion to the Foundation Models framework: beyond Apple’s on-device model, LanguageModelSession can now connect to server-side models conforming to the LanguageModel protocol. This article demonstrates how to integrate Claude via Anthropic’s ClaudeForFoundationModels package.

• SwiftUI’s New .prominent Tab in iOS 27 Is Not a Floating Action Button by Sagar Unagar

  iOS 27 introduces Tab(role: .prominent), which gives a tab stronger visual emphasis in the system tab bar. Sagar’s reminder: this is meant to highlight the most important navigation destination in your app — not to replace a Floating Action Button, a navigation bar “+” button, or an action that opens a sheet.

Issues & Solutions

• Installing simulator runtimes from the command line by Donny Wals

  If you’ve installed Xcode 27 and the iOS Simulator Runtime won’t download through the Xcode UI, xcodebuild from the command line is your workaround.

• Using Xcode 27’s Agent Skills in Claude, Codex, and Cursor by Antoine v.d. SwiftLee

  Xcode 27 ships with a set of official Apple-provided Agent Skills covering SwiftUI, UIKit, testing, and more. They can also be exported for use in Claude, Codex, Cursor, and other tools.

Recent Recommendations

• Swift at Apple: Migrating the TrueType Hinting Interpreter by Scott Perry

  Apple’s team shares their experience rewriting the TrueType hinting interpreter from C to memory-safe Swift: the new implementation is pixel-identical to the original while running 13% faster on average. The article goes deep on noncopyable types, Span, and projection types as tools for system-level performance work.

The TrueType hinting interpreter is the bytecode engine embedded in TrueType fonts. It reads hinting instructions and adjusts glyph control points accordingly, helping text render more crisply at specific sizes and on lower-resolution pixel grids.

• Scaling iOS application development with Tuist by Michael Gerasymenko and Ashutosh Dubey

  The Delivery Hero Logistics team shares how they used Tuist to scale a large iOS codebase — keeping their Xcode and Swift Package Manager workflow intact while adding Swift-defined project structure, explicit dependency graphs, binary caching, and selective testing. The result: local clean build time dropped from 2.5 minutes to 0.5 minutes, with CI builds and unit test runs cut by 2.5x.

The real point of the article isn’t “Tuist makes builds faster.” It’s about how Tuist helps teams make large iOS projects more maintainable.

• Keeping Up With Swift Forums Using Codex by Alejandro Martinez

  Alejandro walks through building a personal workflow that automatically tracks Swift Forums activity every day using Codex Automations and a Swift CLI: the CLI handles forum data and state sync, while Codex takes care of understanding context, generating summaries, and driving further exploration. A practical example of “AI-driven, programs as tools” automation design.

• Container 1.0

  Apple officially released Container 1.0 a few days ago. As an OCI container solution built for Apple silicon, it offers stronger isolation, faster startup, and a more native macOS experience compared to Docker. That said, the ecosystem is still young, and tooling continues to mature.

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

Share

WWDC 26：AI 帮你看完了，然后呢？

网页版

随着 AI Agent 工作流的普及，今年不少开发者开始让 AI 代劳汇总、筛选重点，以更快的节奏消化 WWDC 上推出的新能力。苹果也很配合——一次性放出全部 Session、文字稿与示例代码，进一步降低了 AI 处理这些内容的门槛。

对我个人而言，往年手动提取 interface 、逐一比对新旧 API 的操作，如今已变成 Agent 工作流里的一条指令。从效率角度来说，这是实实在在的进步。

但快速提炼出的信息，往往无法精准、完整地还原苹果工程师在 Session 中传递的关键细节。很多 Session 仍值得静下心来，仔细甚至反复观看。

AI 提升的是获取资讯的速度，而非理解的深度。资讯进了 AI 的上下文，不等于知识进了我们自己的脑子。

观看习惯可以与时俱进，但对自己的要求，不该跟着一起打折。

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

WWDC 2026

汇总

• WWDC 26 Group Lab Q&A by Anton Gubarenko

  今年的 Group Lab 中，来自 Apple 的专家围绕开发者提出的各类问题进行了现场解答。Anton 分别汇总了 Swift、SwiftUI 初学者、SwiftUI 进阶、性能、VisionOS、AI、Icon Composer、Camera and Photo 等主题 Lab 的问答内容。

• (Some) Unanswered Swift Group Questions by Matt Massicotte

  由于时间和投票机制限制，Swift Group Lab 中并非每个问题都能被现场回答。Matt 选取了一些未获回答的问题并给出个人解读，内容主要集中在 Swift 6 迁移、Approachable Concurrency、默认 MainActor 隔离、@preconcurrency、Sendable / ~Sendable，以及非结构化任务等方向。

• What’s new in Swift 6.4 at WWDC26 by Khoa Pham

  这篇文章梳理了 Swift 6.4 中让代码更简洁、更具表现力的一系列变化。

• What’s Coming in Swift 6.4 by Wade Tregaskis

  这篇文章整理了 Swift 6.4 中已标记为 implemented 的 Swift Evolution 提案，覆盖并发、所有权、标准库、访问器、包管理和编译器诊断等多个方向。

• What’s New in SwiftData for iOS 27 by Mohammad Azam

  尽管 SwiftData 今年看起来没有特别巨大的更新，但新增的枚举谓词、分段查询、复合谓词、.codable 属性和 ResultsObserver 都面向具体痛点，进一步补齐了 SwiftData 的使用体验。

• What is new in SwiftUI after WWDC26 by Majid Jabrayilov

  Majid 对今年 WWDC26 上 SwiftUI 相关新功能做了梳理，其中不少都是开发者长期期待的能力。略显遗憾的是，除了 @State 外，大多数新 API 并未提供向前兼容支持。

• iOS 27: Notable UIKit Additions by Jordan Morgan

  SwiftUI 继续发展，但 Apple 并没有放慢对 UIKit 的维护。今年的 UIKit API 更新更多围绕系统新特性适配，以及与 SwiftUI 的新能力对齐展开。

文档

• WWDC.ai by Superwall

  一个帮助开发者或 AI 代理快速了解 Apple 开发者更新的网站，提供 Session 摘要、Ask AI 能力，并提供 Skill⁠ 方便在代码助手中直接使用。

• iOS/MacOS: Apple Beta Doc Retriever by Itsuki

  一款 iOS/macOS 开源应用，可帮助开发者查看带有 Beta 标注的文档和 API，快速了解新旧系统版本间的差异。

• WWDC Quick Look by SwiftGG

  汇总了自 WWDC 2020 至今的所有 Session 内容，包含关联 Session、视频跳转和关键代码片段，也提供了 Skill⁠ 方便 AI 工具使用。

• Ask WWDC by Matt Spear

  一个面向 WWDC 内容的问答搜索工具，可以根据自然语言问题快速定位相关 Session，并整理出简短答案和重点内容。

新功能

• SwiftUI’s @State is now a macro by Artem Mirzabekian

  @State 在 SwiftUI 早期主要面向值类型，但随着 Observation 框架在 iOS 17 引入，@State 不具备类似 @StateObject 的实例懒加载能力这一问题逐渐显现。WWDC26 终于补上了这块短板。尤其值得关注的是，Apple 并没有直接调整属性包装器的实现，而是通过同名宏来完成改造，这或许也提供了一种未来处理兼容性问题的新思路。

• WWDC26: The Evolution of Presentation Transitions in SwiftUI by codelaby

  WWDC26 中，SwiftUI 为 sheet / fullScreenCover 新增了 crossFade 转场效果。遗憾的是，目前仍未提供自定义转场能力。

• Custom scroll layouts with swipe actions in SwiftUI on iOS 27 by Natalia Panferova

  从 iOS 27 开始，swipeActions 不再是 List 的专属能力。新增的 swipeActionsContainer() 可以让 ScrollView 中的 LazyVStack、LazyVGrid 或自定义 Layout 支持滑动操作；新的 onPresentationChanged 回调也可以在某一行的滑动操作展开或收起时触发，便于记录当前活跃项、联动状态或执行额外逻辑。

• Using Claude with Apple Foundation Models by Artem Novichkov

  Foundation Models framework 在 WWDC26 上获得了一个重要扩展：除了 Apple 的端侧模型，LanguageModelSession 现在也可以接入符合 LanguageModel 协议的服务端大模型。文章展示了如何使用 Anthropic 的 ClaudeForFoundationModels 将 Claude 接入 Apple Foundation Models。

• SwiftUI’s New .prominent Tab in iOS 27 Is Not a Floating Action Button by Sagar Unagar

  iOS 27 中，SwiftUI 新增的 Tab(role: .prominent) 可以让某个 tab 在系统 tab bar 中获得更强的视觉强调。Sagar 提醒，这项能力应该用于突出应用中最重要的导航目的地，而不是替代 Floating Action Button、导航栏 “+” 按钮或弹出 sheet 的操作入口。

问题与解决

• Installing simulator runtimes from the command line by Donny Wals

  如果开发者在安装 Xcode 27 后遇到 iOS Simulator Runtime 无法通过 Xcode UI 正常下载的问题，可以改用 xcodebuild 从命令行安装运行时。

• Using Xcode 27’s Agent Skills in Claude, Codex, and Cursor by Antoine v.d. SwiftLee

  Xcode 27 内置了一组 Apple 官方提供的 Agent Skills，涵盖 SwiftUI、UIKit、测试等场景，并提供了导出能力，方便在 Claude、Codex、Cursor 等工具中使用。

• EnableMacosAI by 海空蒼

  一个用于在中国销售的 macOS 设备上启用完整 Apple Intelligence 的工具。

近期推荐

• Swift at Apple: Migrating the TrueType Hinting Interpreter by Scott Perry

  Apple 安全团队分享了将 TrueType hinting interpreter 从 C 迁移到 Swift 的经验：在保持像素级一致的前提下，新的内存安全 Swift 实现平均比原 C 实现快 13%，文章也深入介绍了非可复制类型、Span、projection type 等在系统级性能优化中的实践。

TrueType hinting interpreter 是 TrueType 字体渲染系统中的提示指令解释器，它会读取字体中的 hinting 字节码，并根据这些指令调整字形控制点，让文字在特定字号和屏幕像素网格上显示得更清晰。

• Scaling iOS application development with Tuist by Michael Gerasymenko and Ashutosh Dubey

  Delivery Hero Logistics 团队分享了如何用 Tuist 扩展大型 iOS 工程：在保留 Xcode 和 Swift Package Manager 工作流的同时，通过 Swift 代码定义项目结构、显式依赖图、二进制缓存和选择性测试，将本地 clean build 从 2.5 分钟降到 0.5 分钟，并让 CI 构建和单测耗时缩短 2.5 倍。

文章的重点不只是“Tuist 可以加快构建”，而是展示了它如何帮助团队把大型 iOS 工程变得更可维护。

• Keeping Up With Swift Forums Using Codex by Alejandro Martinez

  Alejandro 分享了如何用 Codex Automations 和 Swift CLI 构建一个每天自动跟进 Swift Forums 的个人工作流：由 CLI 处理论坛数据和状态同步，Codex 负责理解上下文、生成摘要和推进后续探索，展示了一种“AI 驱动、程序作为工具”的实用自动化设计。

• Container 1.0

  Apple 几天前正式发布了 Container 1.0。作为面向 Apple silicon 的 OCI 容器方案，它相比 Docker 在隔离、启动速度和 macOS 原生体验上更有优势。当然，由于生态仍新，相关功能和工具链还在持续完善中。

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 获得真实运行反馈”的探索样本，它值得关注。