When Build in Public Goes Back Underground

Read on web →

Over the past few months, the community has seen a growing number of cases where AI is used to quickly reverse-engineer commercial products or create pixel-perfect replicas of popular apps. With enough tokens to burn, building a free “shadow version” no longer seems particularly difficult.

At the same time, many indie developers who embrace Build in Public are facing a new challenge: while the original product is still being refined, imitators can take the screenshots and ideas its creator has shared on social media, feed them to AI, and launch a clone before the original is even ready. Some do it out of technical curiosity and experimentation; others simply want to showcase what AI tools can produce. But there are also those who see it as an easy shortcut.

Watching this trend unfold, I can’t help feeling a little uneasy.

Cloning and imitation have existed for decades, but AI has dramatically reduced the time and cost required for implementation. An original creator may spend months discovering an idea worth pursuing, while an imitator can look at the finished result, skip much of the trial and error, and produce something remarkably similar in appearance and functionality in a very short time.

Competition, of course, needs challengers, and AI can be just as helpful to original creators. If lower implementation costs push teams to innovate faster, improve the experience, or offer better value, that is something consumers should welcome. After all, copying an interface or a feature set is not the same as copying the product itself. The design judgments hidden in the details and the deep understanding of users’ needs cannot be reproduced through a pixel-perfect clone alone.

But not every creator has enough time and resources to wait for the market to recognize those differences. For an established commercial product, a few AI-generated clones may not pose much of a threat. For an indie developer still trying to find a place in the market, however, a lead of just a few weeks or months can matter enormously.

Build in Public used to be a way for indie developers to build a community and gather feedback by sharing their ideas, designs, and development process. More importantly, it encouraged people to share ideas, experiments, and even failures with other developers while their products were still rough and unfinished.

That kind of culture didn’t just appear out of nowhere. It was built gradually over the years.

But when publicly shared information also becomes a shortcut for others to find targets to clone and bypass the exploration process, the risks of sharing begin to change. If more developers conclude that staying quiet until a product is ready is safer than sharing openly, Build in Public may genuinely start turning back into Build in Private.

That is what makes me most uneasy.

What we stand to lose may not just be a few original products that never make it to market, but the hard-won culture among indie developers of sharing unfinished ideas with one another—and inspiring each other in the process.

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

AI-Friendly Frameworks: As Abstraction Moves Up, How Can Verification Keep Pace?

With the rise of AI Coding, a growing number of people have begun to favor the idea that imperative frameworks like UIKit may be better suited to Coding Agents than SwiftUI. The reasoning is intuitive—UIKit’s logic is direct and explicit: create objects, set properties, add them to the hierarchy, establish constraints. Every step operates on something concrete. SwiftUI, by contrast, folds a great deal of implementation detail behind declarative syntax, where state, environment, identity, layout, and rendering together determine the final result. Once the rendered result deviates from expectations, an Agent is left facing a black box, trying to infer what happened internally from limited external observations.

But perhaps the problem is not abstraction itself. Rather, as abstraction moves up, we have neglected the other half of the work: observation and verification. When abstraction hides lower-level details, we need mechanisms at the new level that can make intent explicit and verify that it has been preserved.

Recent Recommendations

Revisiting “Split Isolation”

In a non-Sendable type with no actor isolation of its own, adding @MainActor to only some methods gives the same instance different isolation requirements. Matt Massicotte calls this pattern “split isolation.” Many developers, including Matt himself, have considered it a poor design.

In this article, Matt revisits his earlier assessment: while split isolation should still generally be avoided, it can have value in certain situations. In particular, when only a small amount of independent functionality depends on MainActor, or when migrating to Swift 6 and trying to prevent isolation requirements from rapidly spreading through a large existing codebase, adding @MainActor locally can be a reasonable or even necessary trade-off. Whether to use split isolation depends on whether it is obscuring the type’s true isolation requirements or deliberately expressing a localized constraint.

The Task Is Not the Unit of Work: Ownership, Isolation, and Cancellation Beyond async/await

SwiftUI’s .task automatically cancels a task when the view disappears. That’s convenient, but it can also make it all too easy for developers to tie the lifetimes of various business operations to the UI lifecycle. A disappearing screen, however, does not necessarily mean that the user’s intent has become irrelevant.

⁠Bruno Valente Pimentel points out that a Task is a unit of execution, but not necessarily a unit of product work; an Actor solves isolation, but does not decide who should own the work; structured concurrency can propagate cancellation, but cannot determine whether that parent-child relationship matches the product’s semantics. Rather than first asking “Where should I put my Task?”, Bruno suggests first defining the operation’s intent, owner, resource, and lifetime, and only then choosing the appropriate implementation mechanism. The compiler can help us ensure concurrency safety, but it cannot decide for us when a piece of work truly “stops mattering.”

A SwiftUI calendar with custom days and event indicators

When implementing a calendar UI, drawing the date grid is often not the difficult part. The real challenges lie in the state and edge cases behind it: separating the currently displayed date from the selected range; consistently using Calendar for date arithmetic and day boundaries; correctly handling the first weekday, month boundaries, daylight saving time, and non-Gregorian calendars; making taps and drags work together for continuous range selection; avoiding repeated scans of the event list in every cell; and preventing unnecessary cell view reconstruction. Szymon Lorenz shares what he learned while developing the calendar component for ⁠SwiftUIComponents, an open-source project that also provides Android compatibility through ⁠Skip Fuse.

SwiftUI Profiling with Instruments: 100,000 Calendar Events

When a SwiftUI app with a large dataset starts to stutter, is the problem in the database, data processing, or view updates? Maciej Szamowski stress-tested hora Calendar with a database containing 100,000 events. Using Instruments’ SwiftUI, Hangs, Hitches, and Time Profiler tools, he found that a large amount of main-thread time during stalls was being spent on SwiftUI graph updates, shifting the optimization focus away from the database and toward data preparation and the view update path.

Both of these calendar articles adopt similar optimization principles for improving rendering performance: avoid making individual cells perform repetitive work that can be handled at a higher level. Prepare data and interaction context upstream → let downstream Views receive values that are as stable and as close to their final presentation form as possible → keep information unrelated to rendering out of the SwiftUI observation/update graph.

Why your fastlane snapshot screenshots are all in English(and how to check every language)

When using fastlane snapshot to generate localized App Store screenshots in bulk, you may encounter a frustrating problem: the language directories are all created correctly, yet every screenshot still appears in English. What makes the issue particularly troublesome is that there is no single cause, making it difficult to diagnose.

Manuel Lorenzo Parejo⁠ lists five areas to investigate: when setupSnapshot is called; how snapshot is launched; localize_simulator; whether the App Bundle contains the corresponding .lproj; and whether residual app state is affecting the language setting. He also provides the free shotfleet check command, which recognizes text in screenshots and compares it against the app’s own localized strings, allowing you to verify in bulk whether the generated screenshots actually use the expected language.

Tools

Redlamp: A Native RAW Editor Built by a Photography Enthusiast with AI

Redlamp is an open-source macOS RAW photo editor built with Swift and Metal under the MPL-2.0 license, with a development-panel workflow familiar to Lightroom users. Its creator, Pedro Gomes, is both an engineer and a photography enthusiast who has ⁠long wanted more tools that fit the way he prefers to work.

Even though AI has played a significant role in developing the project, Redlamp still reflects clear personal intent and judgment. Pedro chose to make the photo library database a rebuildable index while keeping important information alongside the photos themselves. When measurements showed that an optimization around mask edges was sacrificing detail, he narrowed the scope where the algorithm would be applied. Decisions like these give Redlamp a distinct authorial imprint.

The project’s blog documents many of the ideas and trade-offs that emerged during development, while the repository also makes its collaboration rules and verification mechanisms for coding agents public. Pedro is exploring how multiple agents can participate in the continuous development of complex native software—and how to determine whether the results they deliver are actually reliable.

AnnotateIt: Closing the Loop from Annotation to Create ML Training on Mac

For developers who want to train custom Object Detection models with Create ML, the training itself is often not the most troublesome part. Data preparation is where much of the time goes: the Create ML app itself does not provide annotation tools, so developers typically need another tool to draw bounding boxes and then organize the results into a data format Create ML can use.

AnnotateIt brings these steps together in a single Mac app. After annotating images, you can train an Object Detector locally using Apple Create ML. The resulting model can then be applied to new images and videos to generate suggested annotations, which can be reviewed and corrected manually. For Swift developers, this not only lowers the barrier to experimenting with local Object Detection, but also connects “annotation → training → prediction → correction” into a complete workflow.

In the official parking-lot example, a model trained on 292 images completes in under a minute. The entire process requires neither a Python environment nor a cloud GPU, and the data can remain entirely on the local machine.

InnoDI: Turning the Dependency Graph into a Verifiable Build Artifact

InnoDI, developed by ⁠Ethan Parker, is a dependency injection framework built around Swift Macros. It turns the initialization and parameter-passing logic that would otherwise be written manually in an object graph into explicit dependency declarations, while generating container initializers and type-safe test override interfaces. Macros handle local diagnostics, an SPM Build Plugin validates the dependency graph across files and modules, and a companion CLI can inspect and analyze that graph.

InnoSquad’s InnoFlow, InnoRouter, and InnoNetwork follow a similar philosophy, reducing implicit behavior through explicit boundaries and repeatable verification: declare constraints up front wherever possible, and leave runtime behavior to unified execution policies.

In the age of AI Coding, framework authors need to rethink who their consumers are. “Making code easier for developers to write” may no longer be the only top priority. When the cost of learning is no longer borne entirely by human developers, “making the intent and behavior of code easier to verify” is rapidly becoming more important.

SimAgentation: Annotate the iOS Simulator in Your Browser and Hand the Work to AI

When using AI to adjust an interface, accurately expressing “this is what needs to change” can often take more effort than describing the change itself. SimAgentation, developed by citron, lets developers interact with the iOS Simulator from a browser (IOSurface -> VideoToolbox -> WebCodecs), select UI elements or draw a box around a region, and write modification requests directly. The tool sends the feedback, along with element information, source-code search hints, full-screen screenshots, and cropped screenshots, to a coding assistant through MCP, while displaying the processing status in the browser.

The optional SimAgentationPlus adds .simTag() for attaching names, files, and line numbers to views. This shares some similarities with the element-anchor approach I used in FlowCanvas: combining visual output with structured information so that AI can understand the target of feedback more precisely.

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

Share

当 Build in Public 重新转入地下

网页版

过去一段时间，社区里频繁出现用 AI 快速逆向商业产品或像素级复刻热门应用的案例。只要 Token 充足，搭建一个免费的“影子版本”似乎已不再是难事。

与此同时，许多坚持“公开构建”（Build in Public）的独立开发者也遭遇了新的挑战：原创产品尚在打磨之中，一些仿制者仅凭作者在社交媒体上披露的设计截图和思路，便借助 AI 抢先一步上线了“克隆品”。有的源于技术探索与好奇，有的只是想展示 AI 工具的生产力，但也不乏投机取巧的捷径心态。

看着这股风气，我始终感到一丝不安。

复刻与模仿在过去几十年中一直都存在，但 AI 大幅压缩了实现所需要的时间与成本。原创者可能花费数月才找到一个值得做的方向，模仿者却可以观察最终结果，跳过大量试错，在极短时间内做出一个外观和功能都颇为相似的版本。

商业竞争当然需要鲶鱼，AI 对原创者同样有所帮助。如果更低的实现门槛能够促使原创团队加快创新、改善体验，或者提供更具性价比的服务，自然是消费者乐于看到的结果。更何况，复制界面与功能并不等于复制产品本身，那些隐藏在细节中的设计判断和对用户需求的理解，并不是一次像素级复刻就能获得的。

但并不是每个原创者都有足够的时间和资源，等待市场认识到这些差异。对于成熟的商业产品，几个 AI 仿制品或许不足以构成真正的威胁；但对于仍在寻找市场位置的独立开发者，几周甚至几个月的时间差就可能非常重要。

曾经，通过 Build in Public 分享创意、设计与开发过程，是独立开发者建立社区、获得反馈的一种方式。更重要的是，它让大家愿意在产品还不成熟的时候，就拿出自己的想法、尝试甚至失败，与其他开发者交流。

这种氛围并不是天然存在的，而是这些年一点点形成的。

但当公开的信息同时成为别人寻找复刻目标、快速跳过探索阶段的捷径，分享所需要承担的风险也发生了变化。如果越来越多的开发者发现，在产品真正准备好之前，保持沉默比公开分享更加安全，那么 Build in Public 或许真的会重新变成 Build in Private。

这才是最让我不安的地方。

我们失去的可能不只是几个尚未问世的原创产品，而是独立开发者好不容易形成的、愿意彼此展示不成熟想法并相互启发的交流氛围。

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

原创

AI-Friendly Framework：当抽象上移，验证如何跟上？

随着 AI Coding 的普及，不少人开始倾向一种观点：UIKit 这样的命令式框架，可能比 SwiftUI 更适合 Coding Agent。理由很直观——UIKit 的逻辑直接明确：创建对象、设置属性、加入层级、建立约束，每一步都有具体操作的实体；而 SwiftUI 把大量实现细节收束在声明式语法之后，状态、环境、身份、布局与渲染共同决定了最终结果。一旦呈现效果偏离预期，Agent 只能对着黑盒，从有限的外部现象去反推内部究竟发生了什么。

但问题或许并不在抽象本身，而在于抽象之后我们漏掉了另一半工作：观察与验证。当抽象隐藏了底层细节，我们必须在新的层级上，补齐能够固定并验证意图的手段。

近期推荐

重审「局部隔离」的利弊与权衡 (Revisiting “Split Isolation”)

在一个本身没有 actor isolation、且 non-Sendable 的类型中，只给部分方法添加 @MainActor，会让同一个实例同时具有不同的隔离要求。Matt Massicotte 将这种模式称为 “split isolation”。包括 Matt 自己在内，不少开发者都认为这并非一个好的设计。

在本文中，Matt 重新审视了自己过去的判断：split isolation 虽然仍应尽量避免，但在特定场景仍有存在价值。尤其在只有少量独立功能依赖 MainActor，或者正在向 Swift 6 迁移、不希望隔离要求迅速扩散到大量既有代码时，局部添加 @MainActor 也可能是一种合理甚至必要的权衡。是否采用 split isolation，关键在于它是在掩盖类型真正的隔离需求，还是在有意识地表达一个局部约束。

超越 async/await：Task 不是业务工作的基本单元 (The Task Is Not the Unit of Work: Ownership, Isolation, and Cancellation Beyond async/await)

SwiftUI 的 .task 会随着视图消失自动取消任务，这很方便，但也很容易让开发者顺手将各类业务操作的生命周期绑定到 UI 的生命周期。不过，页面消失并不意味着用户的意图已经失效。

⁠Bruno Valente Pimentel 指出：Task 是执行单元，却不一定是产品工作的单元；Actor 解决 isolation，却不会决定谁应该拥有这项工作；结构化并发能够传播 cancellation，却无法判断这种父子关系是否符合产品语义。相比先考虑“Task 应该放在哪里”，Bruno 建议首先明确操作的 intent、owner、resource 和 lifetime，然后再选择具体的实现机制。编译器可以帮助我们保证并发安全，但无法替我们决定一项工作什么时候才真正“不再重要”。

SwiftUI 日历组件的边界与状态设计 (A SwiftUI calendar with custom days and event indicators)

实现一个日历 UI，真正麻烦的往往不是画出日期网格，而是处理背后的状态与边界条件：如何将当前显示日期与选择范围分离；统一通过 Calendar 处理日期运算和 day boundary；正确应对 first weekday、跨月份、夏令时以及非 Gregorian Calendar；点击与拖动如何共同完成连续的范围选择；避免每个 cell 重复扫描事件列表；避免不必要的 cell 视图重建等挑战。Szymon Lorenz 分享了他为 ⁠SwiftUIComponents 开发日历组件的经验，这个开源项目通过 ⁠Skip Fuse 还提供了 Android 端的兼容性。

100,000 个事件下的 SwiftUI 性能排查实战 (SwiftUI Profiling with Instruments: 100,000 Calendar Events)

当一个包含大量数据的 SwiftUI 应用出现卡顿时，问题究竟来自数据库、数据处理，还是视图更新？Maciej Szamowski 使用包含 100,000 个事件的测试数据库对 hora Calendar 进行压力测试，通过 Instruments 的 SwiftUI、Hangs、Hitches 和 Time Profiler，发现卡顿期间大量主线程时间消耗在 SwiftUI graph updates 上，从而将优化重点从数据库转向了数据准备和视图更新路径。

前后两篇有关日历的文章在改善渲染性能上都采用了类似的优化原则：尽量不要让 cell 自己承担那些可以在更高层级完成的重复工作。上层准备数据和交互上下文 → 下层 View 接收尽可能稳定、接近最终展示形式的值 → 与 rendering 无关的信息不要进入 SwiftUI observation/update graph。

排查 fastlane snapshot 多语言截图全部变成英语的问题 (Why your fastlane snapshot screenshots are all in English)

使用 fastlane snapshot 批量生成 App Store 多语言截图时，有时会遇到一个让人头痛的问题：语言目录都正确创建了，截图内容却全部显示为英语。真正麻烦的是，导致这一现象的原因并不唯一，排查起来也比较困难。

Manuel Lorenzo Parejo⁠ 列出了五个排查点：setupSnapshot 的调用时机；snapshot 的启动方式；localize_simulator；App Bundle 中是否包含对应的 .lproj；残留的 App 状态是否影响语言设置。同时还提供了免费的 shotfleet check 命令，通过识别截图文字并与 App 自身的本地化字符串进行比对，批量检查生成的截图是否真的使用了预期语言。

工具

Redlamp：一位摄影爱好者借助 AI 打造的原生 RAW 编辑器

Redlamp 是一款采用 Swift 和 Metal 开发的开源 macOS RAW 照片编辑器，使用 MPL-2.0 许可证，沿用了 Lightroom 用户熟悉的显影面板与操作习惯。作者 Pedro Gomes 既是一名工程师，也是一名摄影爱好者，⁠一直希望有更多符合自己使用方式的工具选择。

在这个大量借助 AI 进行开发的项目中，仍能看到鲜明的个人意图与判断：Pedro 选择让照片库的数据库成为可重建的索引，将重要信息保存在照片旁；也会在测量发现蒙版边缘优化损失了细节后，收紧算法的适用范围。这些具体取舍，让 Redlamp 带有鲜明的作者印记。

项目博客记录了不少开发过程中的思考，代码库也公开了面向编程代理的协作规则与验证机制。Pedro 正在探索，如何让多个代理在持续迭代中参与复杂原生软件的开发，以及如何判断它们交付的成果是否可靠。

AnnotateIt：在 Mac 上完成从标注到 Create ML 训练的闭环

对想用 Create ML 训练自定义 Object Detection 模型的开发者来说，训练本身往往不是最麻烦的部分。真正耗时的是数据准备：Create ML 应用本身不提供标注功能，开发者通常需要借助其他工具画框，再将结果整理成 Create ML 可以使用的数据格式。

AnnotateIt 把这些步骤放进了同一个 Mac 应用。完成图片标注后，可以直接通过 Apple Create ML 在本地训练 Object Detector；训练得到的模型又可以用于新的图片和视频，辅助生成标注并由人工继续修正。对于 Swift 开发者而言，它不仅降低了尝试本地 Object Detection 的门槛，也把「标注 → 训练 → 预测 → 修正」连接成了一套完整的工作流。

在官方的停车场示例中，292 张图片的模型训练不到一分钟即可完成。整个过程不需要配置 Python 环境或云端 GPU，数据也可以始终留在本机。

InnoDI：让依赖图成为可验证的构建产物

⁠Ethan Parker 开发的 InnoDI 是一套基于 Swift Macro 的依赖注入框架。它将对象图中原本需要手工编写的初始化与参数传递逻辑转化为显式的依赖声明，并生成容器初始化器和类型安全的测试替换接口。Macro 负责局部诊断，SPM Build Plugin 验证跨文件、跨模块的依赖图，配套 CLI 则可以对这张图进行检查和分析。

InnoSquad 的 InnoFlow、InnoRouter 和 InnoNetwork 也延续了类似思路，通过明确边界和可重复验证来减少隐式行为：把能够声明的约束提前声明，把运行时行为交给统一的执行策略管理。

在 AI Coding 时代，框架作者需要重新思考框架的消费者。“让开发者更容易编写代码”或许已不再是唯一的首要目标。当学习成本不再完全由人类开发者承担，“让代码的意图和行为更容易被验证”的重要性正在迅速提高。

SimAgentation：在浏览器中为 iOS 模拟器标注并交办 AI

使用 AI 调整界面时，如何准确表达“这里需要修改”，往往比描述修改本身更费力。citron 开发的 SimAgentation 让开发者在浏览器中操作 iOS 模拟器（IOSurface -> VideoToolbox -> WebCodecs），选中界面元素或框选区域，直接写下修改意见。工具会将反馈连同元素信息、源码搜索线索、整屏截图和局部截图，通过 MCP 交给编码助手，并在浏览器中显示处理状态。

可选的 SimAgentationPlus 则支持通过 .simTag() 为视图补充名称、文件和行号。这与我在 FlowCanvas 中采用的元素锚点思路有相通之处：将画面与结构化信息结合，让 AI 更准确地理解反馈对象。

Swift Server Has Another Google

Read on web →

Last week, Google Cloud introduced a Swift SDK for server-side development. It covers more than a hundred Google Cloud services, including Cloud Storage, IAM, Secret Manager, and AI, while providing essential cloud capabilities such as authentication, retries, and pagination. Google is very clear about its positioning: this is a Swift SDK built for servers, containers, and DevOps, not a client-side tool for iOS apps to access cloud services directly.

Unlike the mobile Firebase SDK, which largely provides modern Swift APIs on top of an existing foundation, this server-side SDK was designed from the outset for modern Swift and server-side use cases. When used with Vapor or Hummingbird, it allows developers to access core GCP resources and AI services such as Gemini in a more native way that fits naturally with Swift’s concurrency model.

The announcement has been met with both excitement and caution from the community. But I don’t think there’s any need to celebrate it as “Google finally recognizing Swift.” The involvement of a large company has never been a guarantee of long-term commitment. A decade ago, IBM invested heavily in server-side Swift and led the development of Kitura, only to gradually step away. Google’s own heavily backed Swift for TensorFlow project has also long since ceased development. These precedents remind us that the arrival of another tech giant is hardly a reason to declare the beginning of some new era for Swift Server.

Google is now willing to bring Swift into its official Cloud API Client Libraries ecosystem and take on the long-term, unglamorous work of API updates, code generation, authentication, compatibility, and more. Rather than seeing this as a new beginning for Swift Server, I think it makes more sense to view it as a natural outcome of years of development.

Swift today is also very different from what it was a decade ago. It has accumulated years of development across server-side use cases, Linux, networking, and other areas, while more recently continuing to expand toward platforms such as Windows and Android. Its cross-platform capabilities no longer depend on the efforts of any single company, nor are they merely experiments taking place outside Apple’s ecosystem.

Perhaps what is truly worth celebrating is precisely that Google Cloud supporting Swift no longer feels all that surprising. Once a language and its ecosystem reach a certain level of maturity, official support from a major cloud provider should simply be a normal part of its development.

In any case, welcome aboard, Google.

Previous Issue｜Newsletter Archive

This Week’s Sponsor

Transcribatron —— on-device meeting notes for developers

$8.99 once. No subscription, no account, no backend. Transcribatron transcribes on-device, syncs two-way with your Obsidian vault, and ships an MCP server so Claude Code can query your meetings. Use your own API key or a local model.

Try free on iOS/macOS →

Original

Letting AI See SwiftUI: Xcode Preview MCP in Practice — Pitfalls and Hopes

Xcode 26.3 marked the first time Apple opened its own capabilities to external agents through MCP. Many of those capabilities were already reachable through the CLI, but Preview rendering was entirely new. Xcode 27 went a step further with a headless MCP server, making these tools even easier to call, so I wove Preview rendering deeply into my AI workflows. Along the way I ran into a few pitfalls, and came away with some reflections and hopes.

Recent Recommendations

Using Swift’s ‘some’ keyword beyond SwiftUI

The widespread use of some View has led many developers to overlook the potential of some in other contexts. ⁠John Sundell brings it back into the context of Swift generics and API design, demonstrating its uses and advantages in both parameter and return positions. For example, in a parameter position, func saveToWatchLater<T: Sequence>(_ videos: T) can be simplified to func saveToWatchLater(_ videos: some Sequence<Video>).

Beyond that, some can provide a statically determined return type without exposing the concrete implementation type, making it possible in some cases to avoid introducing AnyXXX-style type erasure simply to hide implementation details.

Iterative data loading in Swift

When a screen needs to make dozens of asynchronous requests, striking a balance between loading data and providing timely UI feedback is not easy. Majid Jabrayilov uses AsyncSequence to divide data loading into multiple stages, returning the accumulated results after each step so that the UI can update progressively as data arrives. Within each stage, related requests can still be performed concurrently using async let. For data-heavy screens, iterating between stages while running tasks concurrently within each stage can be an effective approach.

Modifier Order Is Matrix Order

SwiftUI developers know that the order of Modifiers affects the final result, but this understanding often remains rooted in practical experience rather than rigorous theory and logical verification. Mihaela Mihaljević Jakić reexamines the execution order of Modifiers such as offset, rotationEffect, and scaleEffect from the perspective of matrix transformations. By comparing actual rendering results from ImageRenderer with calculations using CGAffineTransform, she turns this rule of thumb into a principle that can be understood and derived through matrix operations.

Rules can evolve into algorithms, and algorithms can reduce the cost of generation and verification. Mihaela’s article does more than explain “how it should be written”; it also verifies “whether SwiftUI actually works this way.” The results may have applications that extend even further.

How to reduce token usage in Claude Code, Codex, and Cursor

Compared with writing code, analyzing logs and locating errors are areas where AI Agents can demonstrate their strengths even more clearly. But complete command output consumes more tokens and takes up valuable context space. ⁠Antoine van der Lee introduces a simple but effective optimization: instead of exposing an Agent directly to complete, unprocessed command output, filter and compress it with scripts or tools before it enters the context, retaining only the information that is genuinely useful for making the next decision.

⁠Daniel Saidi shares a similar practice, significantly reducing Claude Code’s token usage by optimizing Xcode Build output. As Agents work for longer periods and take on larger tasks, reducing this redundant information that is “generated by machines and consumed by machines” may gradually become an area worth optimizing in its own right within Agent workflows.

Automating accessibility audits for SwiftUI apps with XCTest

When these accessibility testing APIs were designed, the team behind them probably did not anticipate that they would find an even broader range of applications in the AI Agent era. ⁠Natascha Fadeeva demonstrates how to use performAccessibilityAudit in UI Tests to automatically check common accessibility issues such as contrast, element descriptions, Hit Region, and Dynamic Type, while limiting audit types and filtering known issues to incorporate these checks into an ongoing automated testing workflow.

Rather than asking a model to determine on its own whether an interface meets accessibility requirements, a clear and repeatable verification mechanism provided by the system allows an Agent to proactively run checks after modifying the UI and continue adjusting the code based on the results.

Some Thoughts on Development - Code Review

As the amount of code an Agent can generate in a single pass continues to grow, whether to review it and how to review it have become questions every developer has to confront. ⁠Wei Wang argues that in the AI era, Code Review should move away from code as the intermediate artifact and toward both ends of the process: upward into requirements and specs, ensuring that the goals, boundaries, and acceptance criteria understood by the Agent align with the human’s actual intent; and downward into the final product, using evidence such as tests, screenshots, and screen recordings to confirm that the implementation truly meets the requirements. The code in between, meanwhile, can increasingly be left to Agents to review one another. The article also demonstrates the Review Loop that the author uses in Prowl, where different Agents cycle through implementation, review, fixes, and re-review until the exit conditions are met.

WWDC 2027 Wishlist

You read that right. ⁠Harshil Shah has written down his hopes for next year’s WWDC 2027 more than half a year in advance. His wishlist covers SwiftUI, cross-device syncing, photo permissions, Liquid Glass, Camera, TestFlight, Xcode, Apple Watch, and more. His questions about the long-term relationship between SwiftUI and UIKit are particularly thought-provoking: now that AI Agents have dramatically reduced the cost of writing code, is SwiftUI’s concise syntax still as important an advantage as it once was? And with Apple continuing to introduce new capabilities for both UI frameworks, is their long-term coexistence and interweaving simply the future?

Tools

Argent: Let AI Coding Assistants Participate in App Runtime and Verification

Argent is an open-source tool from Software Mansion that brings simulator interaction, runtime inspection, and native performance profiling together in a single toolset. It also supports recording and replaying interaction flows, allowing AI assistants to follow the same path when comparing behavior before and after a change.

In addition to performing taps, swipes, text input, and screenshots, reading the interface hierarchy, reproducing issues, and verifying changes, Argent integrates native performance profiling based on Xcode Instruments. It provides information about CPU hotspots, UI stalls, memory leaks, and more, giving code improvements actual runtime data to work from.

Argent uses mixed licensing: the source code is licensed under Apache 2.0, while some native binary components use a proprietary license.

App Store Screenshots Generator

App Store Screenshots, developed by Parth Jadhav, is a Skill designed for AI Agents that can generate an editable store screenshot editor from app information and raw screenshots, then export all the sizes required by the App Store and Google Play.

It provides 18 preset visual styles, supports continuous canvases spanning multiple screenshots, device frames, multiple languages, and RTL, and covers devices including iPhone, iPad, Mac, Apple Watch, Apple TV, CarPlay, and Android. Rather than producing one-off static images, it generates an interactive Next.js-based editor, allowing developers to continue adjusting copy, layouts, and assets, while saving the project state for further revisions.

Survey

Survey on AI Coding Tool Usage Among Apple Developers

⁠⁠SwiftGG is conducting a survey on AI coding tool usage among developers in the Apple ecosystem, aiming to understand developers’ real-world usage habits, how these tools are changing their workflows, and what they expect from future development experiences. The results will be compiled into a report and shared publicly with the developer community.

If you’re using Xcode along with various AI Coding tools, consider spending around 15 minutes sharing your real-world experience. Broader participation will help the final data more accurately reflect how Apple developers actually work in the AI era.

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

Share

Swift Server，又多了一个 Google

网页版

上周，Google Cloud 推出了面向服务端的 Swift SDK。它覆盖 Cloud Storage、IAM、Secret Manager、AI 等一百多个 Google Cloud 服务，并提供认证、重试、分页等完整的云端基础能力。Google 对它的定位非常明确：这是为 Server、Container 和 DevOps 准备的 Swift SDK，而不是给 iOS 应用直接访问云服务使用的客户端工具。

与移动端 Firebase SDK 更多是在既有基础上提供现代 Swift API 不同，这款服务端 SDK 从一开始就面向现代 Swift 和服务端场景设计，让开发者在配合 Vapor 或 Hummingbird 时，能够以更加原生、符合 Swift Concurrency 模型的方式调用 GCP 核心资源与 Gemini 等 AI 服务。

面对这一消息，社区既有期待，亦不乏审慎。但我觉得大可不必用「Google 终于认可 Swift」这样的方式来庆祝。大公司的加入从来不等于长期承诺。十年前 IBM 也曾积极投入 Server-side Swift，并主导开发 Kitura，最终却逐渐退出；Google 自己曾经大力投入的 Swift for TensorFlow 也早已停止发展。这些前车之鉴提醒我们，不必因为一家大型科技公司的加入，就急着宣布 Swift Server 进入了某个新时代。

Google 现在愿意把 Swift 纳入官方 Cloud API Client Libraries 体系，承担 API 更新、代码生成、认证、兼容性等长期而琐碎的维护工作，与其说这是 Swift Server 的新起点，不如说是多年发展的一个自然结果。

今天的 Swift 与十年前也已经不同。Swift 在 Server、Linux、Networking 等方向积累多年，近年来又持续向 Windows、Android 等平台扩展。它的跨平台能力不再依赖某一家公司的推动，也不再只是 Apple 生态之外的实验。

或许真正值得高兴的，恰恰是 Google Cloud 支持 Swift 这件事已经不再那么令人意外。当一门语言和它的生态发展到一定阶段，大型云服务商为它提供官方支持，本来就应该是一件普通的事情。

无论如何，欢迎 Google 加入。

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

原创

让 AI 看见 SwiftUI：Xcode Preview MCP 的实践、陷阱与期待

Xcode 26.3 是苹果第一次通过 MCP 把自身能力开放给外部 Agent。其中不少能力此前借助 CLI 也能获得，但 Preview 渲染是头一回出现。到了 Xcode 27，苹果又提供了 headless MCP server，调用起来更加顺手，于是我把 Preview 渲染大量嵌进了自己的 AI 工作流。一路用下来，踩了一些坑，也多了一些感悟和期待。

近期推荐

走出 SwiftUI 的 some 关键字 (Using Swift’s ‘some’ keyword beyond SwiftUI)

由于 some View 的使用太过普遍，以至于很多开发者都忽略了 some 在其他场景中的应用潜力。⁠John Sundell 将它放回 Swift 泛型与 API 设计的语境，展示了 some 在参数与返回值中的用途与优势。例如，在参数位置，可以从 func saveToWatchLater<T: Sequence>(_ videos: T) 简化为 func saveToWatchLater(_ videos: some Sequence<Video>)。

除此之外，some 还可以在不暴露具体实现类型的情况下提供静态确定的返回类型，从而在一些场景中避免为了隐藏实现细节而引入 AnyXXX 式的类型擦除。

Swift 迭代式数据加载 (Iterative data loading in Swift)

当一个页面需要发起几十个异步请求时，如何在数据加载与及时的 UI 反馈之间取得平衡并不容易。Majid Jabrayilov 使用 AsyncSequence 将数据加载拆分成多个阶段，每完成一步便返回当前累积的结果，让 UI 可以随着数据到达逐步更新；而在每个阶段内部，仍然可以使用 async let 并发完成相关请求。对于数据密集型页面，阶段之间迭代、阶段内部并发不失为一种有效的思路。

SwiftUI Modifier 顺序背后的矩阵规律 (Modifier Order Is Matrix Order)

SwiftUI 开发者都知道 Modifier 的顺序会影响最终结果，但这种认知更多停留在实践层面，而缺乏严谨的理论和逻辑验证。Mihaela Mihaljević Jakić 从矩阵变换的角度重新解释了 offset、rotationEffect 和 scaleEffect 等 Modifier 的执行顺序，并通过 ImageRenderer 的实际渲染结果与 CGAffineTransform 的计算进行验证，将这条经验法则变成了一套可以通过矩阵运算理解和推导的规则。

规则可以演化成算法，算法可以降低生成和验证的成本。Mihaela 的这篇文章不只是解释「应该怎么写」，还在验证「SwiftUI 实际上是不是这么做的」，而这样的成果或许还有更大的应用空间。

优化 AI 编程助手的 Token 消耗 (How to reduce token usage in Claude Code, Codex, and Cursor)

相较于写代码，AI Agent 分析日志、定位错误的能力更能凸显其优势。但完整的输出会消耗更多 token，还会挤占宝贵的上下文空间。⁠Antoine van der Lee 介绍了一个简单但有效的优化思路：不要让 Agent 直接面对未经处理的完整命令输出，而是在进入上下文之前，通过脚本或工具对其进行过滤和压缩，只保留真正有助于下一步判断的信息。

⁠Daniel Saidi 也分享了类似的实践，通过优化 Xcode Build 的输出大幅减少 Claude Code 的 token 使用。随着 Agent 工作时间和任务规模不断增长，减少这些「机器产生、机器消费」的冗余信息，或许会逐渐成为 Agent 工作流中一个值得专门优化的环节。

用 XCTest 自动化无障碍检查 (Automating accessibility audits for SwiftUI apps with XCTest)

在设计这些辅助功能测试 API 时，设计团队恐怕没有想到，它们会在 AI Agent 时代获得更广阔的应用空间。⁠Natascha Fadeeva 介绍了如何使用 performAccessibilityAudit 在 UI Test 中自动检查对比度、元素描述、Hit Region、Dynamic Type 等常见的 accessibility 问题，并通过限定检查类型和过滤已知问题，将这些检查纳入持续的自动化测试流程。

相比让模型自行判断界面是否符合 accessibility 要求，由系统提供明确、可重复执行的验证机制，可以让 Agent 在修改 UI 后主动运行检查，并根据结果继续调整代码。

一些关于开发的杂谈话题 - 代码审核

随着 Agent 单次生成的代码量越来越大，是否审查、如何审查，已经成为摆在每个开发者面前的问题。⁠王巍 认为，AI 时代的 Code Review 应该从代码这个中间产物向两端移动：向上进入需求和 spec，确保 Agent 理解的目标、边界和验收标准与人的真实意图一致；向下进入最终产物，通过测试、截图、录屏等证据确认实现是否真正满足要求。至于中间的代码，则可以更多交给 Agent 相互审核。文章还展示了作者在 Prowl 中实践的 Review Loop：由不同 Agent 在实现、审核、修复和再次审核之间循环，直到满足退出条件。

WWDC 2027 Wishlist

你没有看错，⁠Harshil Shah 提前大半年写下了对明年 WWDC 2027 的期许。他的清单涵盖 SwiftUI、跨设备同步、照片权限、Liquid Glass、Camera、TestFlight、Xcode 和 Apple Watch 等多个方面。其中关于 SwiftUI 与 UIKit 长期关系的疑问尤其值得开发者思考：在 AI Agent 大幅降低代码编写成本之后，SwiftUI 简洁语法的优势是否还像过去那样重要？当 Apple 仍在同时为两个 UI 框架提供新能力时，两者长期交织共存是否就是未来的答案？

工具

Argent：让 AI 编程助手参与应用的运行与验证

Argent 是 Software Mansion 推出的开源工具，将模拟器交互、运行时检查与原生性能分析整合在同一套工具中，并支持录制、回放操作流程，让 AI 助手能够沿着相同路径检查修改前后的表现。

除了执行点击、滑动、输入和截图，读取界面结构，帮助复现问题和验证修改结果外，Argent 还集成了基于 Xcode Instruments 的原生性能分析能力，提供 CPU 热点、界面卡顿与内存泄漏等信息，让代码改进有实际运行数据作为依据。

Argent 使用混合许可：源码采用 Apache 2.0，部分原生二进制组件采用专有授权。

App Store Screenshots Generator

Parth Jadhav ⁠开发的 App Store Screenshots 是一个面向 AI Agent 的 Skill，可以根据应用信息和原始截图生成一套可继续调整的商店截图编辑器，并统一导出 App Store 和 Google Play 所需的各种尺寸。

它提供 18 种预设视觉风格，支持跨越多张截图的连续画布、设备边框、多语言和 RTL，并覆盖 iPhone、iPad、Mac、Apple Watch、Apple TV、CarPlay 以及 Android 等设备。生成结果并非一次性的静态图片，而是一个基于 Next.js 的可交互编辑器，开发者仍可以继续调整文案、布局和素材，并将项目状态保存下来反复修改。

调研

Apple 开发者 AI 编程工具使用情况调查

⁠⁠SwiftGG 正在开展一项面向 Apple 生态开发者的 AI 编程工具使用情况调查，希望了解开发者目前使用 AI Coding 工具的真实习惯、由此带来的工作流变化，以及对未来开发体验的期待。最终结果将整理成报告并向开发者社区公开。

如果你正在使用 Xcode 以及各种 AI Coding 工具，不妨花大约十几分钟分享一下自己的实际体验。更广泛的参与，也能让最终的数据更准确地反映 AI 时代 Apple 开发者真实的工作方式。

The Month iPhone Duo Gives Developers

Read on web →

Xcode 27.1 beta, which includes the iPhone Duo simulator, was released on September 18—just five weeks before the device officially goes on sale on October 23. Curiously, Xcode 27.2 beta, which does not include Duo support, had already arrived by then. To prepare for Apple’s newest device, developers actually have to use the lower-numbered version of Xcode. This unusual “two-track beta” situation may stem from Duo having its own OS version and Apple’s need to maintain secrecy before the announcement, but the tradeoff is that developers have been left with a preparation window of only about a month.

In Device Hub, developers can open, close, rotate, and fold the virtual device. But any experienced engineer knows that while a simulator can reproduce geometry and poses, it cannot reproduce affordances or real-world physical interactions.

During this period without feedback from actual hardware, developers can easily drift toward one of two extremes: either feeling lost and becoming reluctant to venture beyond the safest choices, or staring at a virtual window and dreaming up specialized interactions that seem clever on screen but turn out to be awkward and frustrating when the device is actually held in the hand.

With the countdown already underway, a more pragmatic approach is to first draw a reasonable boundary around what “adapting” really means—to distinguish between “good enough” and “actually good.”

Apple has made it clear that existing apps can run on Duo without being rebuilt, but “it runs” obviously does not mean “it has been adapted.” Making sure an app presents itself naturally and reliably on the new device is the baseline for being “good enough” at launch. What an experience that is truly “good” on a foldable device looks like, however, may only begin to reveal itself once the hardware is actually in developers’ hands.

October 23 may not be the end of the Duo adaptation process. It may be the day it truly begins.

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

ArrangementView: Think Before You Arrange

When I first saw the ArrangementView API, something about it felt vaguely awkward, though I couldn’t quite put my finger on why. It wasn’t until I actually used it in Xcode 27.1 beta that the feeling began to take shape. After reading more of Apple’s materials and putting the API back into the context of the iPhone Duo, I realized that this discomfort came from two places. Part of it was simply that I hadn’t understood where the API was meant to fit; once I did, that part made sense. The other part came from the API itself—and remained even after I understood its design.

To use ArrangementView well, then, it helps to think one step further before reaching for it: What exactly is the relationship between the content? Which decisions can be left to the container, and which trade-offs still belong to the app? Think before you arrange.

Recent Recommendations

What’s new in Swift 6.4’s from Apple’s engineers

Taking the answers Apple engineers gave at the WWDC26 Swift Group Lab as his starting point, Xiangyu cross-checks each one against Evolution proposals, compiler source code, and official documentation. He clarifies which capabilities have actually shipped and which are still in transition, and corrects several version and implementation details from the live answers.

The most thought-provoking topic is “if we could do it over again.” In early Swift Concurrency, nonisolated async functions automatically left the caller’s actor and ran on the global concurrent executor. After years of real-world use, the Swift team now believes it makes more sense for them to stay on the caller’s actor by default. Had they been designing from scratch, that is what they would have shipped from day one. Although this behavior still requires explicit opt-in in Swift 6.4, it clearly shows how Swift Concurrency keeps recalibrating its defaults based on real migration experience.

withTaskCancellationShield: Swift 6.4 new feature

withTaskCancellationShield (SE-0504), introduced in Swift 6.4, lets a block of code run unaffected by its task’s existing cancellation state, which makes it well suited to wrap-up and cleanup logic that must complete. It does not undo the cancellation itself. Instead, code inside the shield (including any child tasks created there) temporarily cannot “see” the cancellation, and once execution leaves the shield, the original cancellation state becomes visible again. Because the API relies on the concurrency runtime that ships with the operating system, it is only available on the 27-series OSes and, unfortunately, cannot be back-deployed.

Omar Elsayed offers a transitional workaround: create an unstructured task and await its value. Cancellation does not automatically propagate to the new task, and awaiting its value ensures the current task waits for the cleanup to finish before moving on, so the result closely approximates the real shield. Omar also stresses that this is only a stopgap. It adds overhead and requires captured values to be Sendable. Once your minimum deployment target allows it, you should switch to the official API.

Running iOS Background Tasks Reliably, Part 2

In Part 1, Irving Popovetsky drew on long-term, on-device observation to develop a set of practices for making BGTaskScheduler more reliable. One problem, however, remained unsolved: when a user goes a long time without opening the app, the execution opportunities granted to background tasks gradually dwindle.

This time, he found a breakthrough in a single remark from WWDC20: the system does not throttle silent pushes based on how often an app is used. So he set up a Cloudflare Worker that writes a WakePing record to the CloudKit public database every hour, then uses a CKQuerySubscription to trigger a silent push that wakes the app. The whole process requires no device token management and touches no user data. After several months in production, syncs still fire almost exactly on the hour, even after three consecutive weeks without opening the app. This certainly doesn’t turn iOS background execution into a true cron, but it is an excellent demonstration of how combining BGTaskScheduler, CloudKit, and background notifications can meaningfully improve the reliability of background work.

Dissecting Xcode 27’s mcpbridge: Apple Skipped swift-sdk and Built Its Own MCP Stack

Although Apple also takes part in maintaining the official Swift MCP SDK, Xcode 27’s own MCP implementation takes a different path entirely. Snow Wu exported and examined the symbol tables of mcpbridge, mcp-server, and related private frameworks, and found that nearly everything, from JSON-RPC and the MCP semantic layer to command-line argument parsing, is built in-house.

This “start from scratch” approach isn’t merely about avoiding third-party dependencies. mcpbridge itself doesn’t even contain any tool definitions. It only handles protocol translation and routing between external agents and Xcode, while the actual tool capabilities remain inside Xcode. Combined with a three-process architecture, XPC communication, and a three-layer permission gate, it becomes clear that Apple isn’t simply embedding an MCP server in Xcode. Rather, it treats MCP as a system architecture problem: how to let untrusted external agents safely connect to a GUI application with complex state.

Apple Watch brings distributed system headaches to your app

When both iPhone and Apple Watch can read and modify the same state, what you’re dealing with is effectively a small distributed system: two independent nodes that may lose contact at any moment, keep modifying data on their own, and reconnect only hours or even days later. Jacob Bartlett revisits Watch Connectivity from this perspective, using the CAP theorem to dissect the trade-offs behind each WCSession API. sendMessage requires the counterpart to be immediately reachable, sacrificing availability during a partition in exchange for real-time, acknowledged interaction. updateApplicationContext and transferUserInfo, by contrast, tolerate temporary inconsistency in favor of availability; the former keeps only the latest state, while the latter delivers every change in order.

This perspective also turns “which Watch Connectivity API should I use?” from a question of interface capabilities into a question of product semantics. Login state, settings sync, recording controls, and other kinds of data have different requirements for consistency and availability, and different features within the same app can perfectly well make different choices.

iPhone Duo & AnyOS 27 Adaptation

• codelaby introduces the Reserved Regions API added in iOS 27.1, and shows how to obtain the crease (division) and camera occlusion regions through GeometryProxy. For custom layouts that system containers can’t handle automatically, it offers a reliable way to keep important content out of the crease and camera areas.

• Antoine van der Lee takes a practical, adaptation-first approach, systematically walking through the new capabilities: the iPhone Duo Simulator, resizable layouts, ArrangementView, Reserved Regions, hinge state, and the vertical toolbar. The core idea is not to design a separate interface for Duo, but to first make your app genuinely adapt to variable space, then use Duo-specific APIs to enhance special cases.

• Ronnie W. discovered that macOS 27 re-decides how SwiftUI toolbar items are grouped: even with ToolbarSpacer, items you intended to keep separate may still be merged into the same navigation island. The fix is refreshingly direct: when you need precise control over grouping, let AppKit’s NSToolbarItemGroup take over the macOS toolbar structure.

• Anton Gubarenko compiled Apple engineers’ answers to developer questions from two iPhone Duo Group Labs (Part 2), covering a wide range of practical issues including adaptive layout, fold postures, the vertical toolbar, multiple windows, the camera, accessibility, and the Simulator. The advice running through it all is remarkably consistent: treat Duo as an iPhone with more variable space, rely first on system containers and adaptive layout, and only intervene with creases, hinges, and specific postures when truly necessary.

• Sarunw explains how the system decides whether a toolbar item on iPhone Duo goes into the horizontal or vertical toolbar: provide both an icon and a title so the system can choose the presentation based on available space, and only when the default judgment isn’t right should you use axisBehavior to explicitly specify .horizontalOnly or .verticalPreferred.

Tools

PaintKit: A Swift Raster Drawing and Image Processing Engine

Developed by Josh Lin, PaintKit is a standalone Swift raster drawing engine extracted from the ItsPaint project. It covers pixel storage and blending, rasterization, brushes and shapes, selections, undo, text rendering, and image and PDF encoding/decoding. The engine is built on premultiplied-alpha RGBA8 pixels, and every edit returns the region that actually changed, so both screen refreshes and undo records only need to process the pixels that matter. Undo history isn’t simply capped by operation count either; it is managed by actual memory usage through local pixel patches. PaintKit has no dependencies on AppKit, SwiftUI, or third-party libraries, adopts Swift 6 strict concurrency, and most of its functionality can be verified with swift test without launching an app or an Xcode project.

ItsPaint is the complete application and real-world proving ground for PaintKit. It is a lightweight, native macOS drawing and screenshot annotation tool offering 13 tools, including pencil, brush, shapes, text, selection, pixelate, and spotlight. It supports 15 shapes, nine export formats, and PDF annotation, and can remove simple backgrounds without using machine learning models or network services. ItsPaint is also open source and available as a free download on the App Store.

SwiftFairy: A SwiftUI Review Tool That Keeps Agents from Forgetting What They’ve Read

A macOS tool built by Natalia Panferova and Matthaus Woolard that provides Swift and SwiftUI code review for coding agents through a local MCP server.

Rather than writing a large set of rules into a Skill or AGENTS.md and hoping the agent recalls them at the right moment, SwiftFairy hands “finding problems” over to deterministic static analysis. It parses code into a partial graph, matches it against declarative issue patterns, pinpoints findings to specific lines, and then passes the corresponding explanations and fix examples to the agent. Knowledge only enters the context when an issue is actually hit, which both keeps the agent from “forgetting what it read” and reduces token usage.

Much of SwiftFairy’s value also comes from the rules themselves. The knowledge is currently organized into “Scrolls,” with the first batch covering Proper SwiftUI, Performant Swift Charts, and Modern Swift. The content draws on the two authors’ years of books and articles, as well as Natalia’s experience working on Apple’s core SwiftUI team. Compared with having another LLM do the review, SwiftFairy is more like adding a layer of domain-aware, reproducible static review to the agent workflow.

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

Share

iPhone Duo 留给开发者的一个月

网页版

包含 iPhone Duo 模拟器的 Xcode 27.1 beta 于 9 月 18 日发布，距离 10 月 23 日正式发售仅五周。颇为微妙的是，彼时不含 Duo 支持的 Xcode 27.2 beta 已先行推出——想适配苹果最新的设备，反而要使用版本号更低的 Xcode。这种“双轨 Beta”或源于 Duo 独立的系统版本与发布前的保密需要，代价则是开发者的准备窗口被压缩到了一个月左右。

开发者可以在 Device Hub 中开合、旋转、折叠这台虚拟设备。但任何有经验的工程师都清楚：模拟器能够还原几何形态与姿态，却无法还原可供性与真实的物理交互。

在缺乏实体反馈的这段真空期，开发者很容易滑向两个极端：要么无所适从，不敢越雷池一步；要么对着虚拟窗口凭空构想出许多看似精巧、在真实握持下却别扭难用的专属交互。

面对紧迫的倒计时，更务实的做法是先为“适配”划定理性的边界，分清什么是“够用”，什么是“好用”。

Apple 已明确表示，现有应用即使不重新构建也可以在 Duo 上运行，但“能够运行”显然不等于“已经适配”。确保应用在新设备上自然、稳定地呈现，是上市前“够用”的及格线；至于什么才是真正属于折叠设备的“好用”体验，恐怕要等设备来到开发者手中后，才会逐渐浮现答案。

10 月 23 日，或许才是 Duo 适配真正开始的那一天。

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

原创

ArrangementView：谋而后定

第一次看到 ArrangementView 的 API 时，我有一种说不出的别扭感。直到在 Xcode 27.1 beta 中实际使用后，这种感觉才逐渐清晰。查阅更多的苹果资料，再把它放回 iPhone Duo 的使用场景，我发现这份别扭其实来自两个方面：一部分源于我对它的定位不够清楚，理解之后便释然了；另一部分则来自 API 本身，即便想明白了，依然存在。

因此，想用好 ArrangementView 需要在使用前多想一步：内容之间究竟是什么关系？哪些结果可以交给容器，哪些取舍仍须由应用承担？谋而后定。

近期推荐

What’s new in Swift 6.4’s from Apple’s engineers

Xiangyu 以 WWDC26 Swift Group Lab 上 Apple 工程师的现场答疑为线索，逐一对照 Evolution 提案、编译器源码与官方文档，厘清了哪些能力已经落地、哪些仍处于过渡阶段，并订正了现场回答中若干版本与实现细节上的出入。

其中最耐人寻味的，是“如果重来一次”这个话题：早期的 Swift Concurrency 会让 nonisolated async 函数自动离开调用者所在的 actor，转到全局并发执行器（Global Concurrent Executor）上运行；经过数年的实践，Swift 团队认为，让它默认留在调用者的 actor 上才更为合理——若能从头设计，他们希望一开始便是如此。尽管这一行为在 Swift 6.4 中仍需显式启用，却清晰地展现了 Swift Concurrency 如何依据真实的迁移经验，不断校准自身的默认选择。

withTaskCancellationShield: Swift 6.4 new feature

Swift 6.4 引入的 withTaskCancellationShield（SE-0504）可以让一段代码不受所属任务已有取消状态的影响，非常适合必须完成的收尾和清理逻辑。它并不会撤销取消本身，只是让屏蔽范围内的代码（包括其中创建的子任务）暂时“看不到”取消状态；离开屏蔽区域后，原有取消状态会重新可见。由于该 API 依赖随系统分发的并发运行时（Concurrency Runtime），因此只能在 27 系列系统上使用，很遗憾无法向下部署。

Omar Elsayed 在文中给出了一个过渡方案：创建一个非结构化任务（Unstructured Task）并 await 其 value。由于取消状态不会自动传播到这个新任务，而等待 value 又能让当前任务等到清理结束后再继续，因此可以实现近似的效果。Omar 也强调，这只是权宜之计：不仅存在额外开销，还要求捕获的值满足 Sendable；待最低部署版本提升后，仍应改用正式 API。

Running iOS Background Tasks Reliably, Part 2

在 Part 1 中，Irving Popovetsky 通过长期的真机观察，总结出一套提升 BGTaskScheduler 可靠性的实践，但有一个问题始终无解：当用户较长时间不打开 App，后台任务获得的执行机会便会逐渐衰减。

这一次，他从 WWDC20 的一句提示中找到了突破口——系统不会依据 App 的使用频率来限制静默推送（Silent Push）。于是，他让 Cloudflare Worker 每小时向 CloudKit 公共数据库（Public Database）写入一条 WakePing 记录，再借助 CKQuerySubscription 触发静默推送唤醒 App。整个过程无需维护设备令牌（Device Token），也不触及任何用户数据。经过数月的实际运行，即便连续三周未打开 App，同步依然能近乎准点地按小时触发。这当然无法让 iOS 的后台执行变成真正的 cron，却很好地示范了如何将 BGTaskScheduler、CloudKit 与后台通知（Background Notification）组合起来，切实提升后台任务的可靠性。

拆解 Xcode 27 mcpbridge：Apple 没有用 swift-sdk，而是自研了一整套 MCP 栈

尽管 Apple 也参与了维护官方的 Swift MCP SDK，但 Xcode 27 自身的 MCP 实现却另辟蹊径。Snow Wu 导出并核对了 mcpbridge、mcp-server 及相关私有框架的符号表，发现从 JSON-RPC、MCP 语义层到命令行参数解析，Xcode 几乎全部采用自研实现。

这种“另起炉灶”并不只是为了规避第三方依赖。mcpbridge 本身甚至不包含任何工具定义，只负责在外部 Agent 与 Xcode 之间完成协议转换与路由，真正的工具能力仍由 Xcode 提供。再结合三进程架构、XPC 通信与三层权限闸门，可以看出 Apple 并不只是在 Xcode 里嵌入一个 MCP Server，而是将 MCP 视为一个系统架构问题：如何让不可信的外部 Agent 安全地接入一个状态复杂的 GUI 应用。

Apple Watch brings distributed system headaches to your app

当 iPhone 与 Apple Watch 都能读取并修改同一份状态时，你面对的其实已是一个小型分布式系统：两个独立节点随时可能失联，各自继续修改数据，并在数小时甚至数天后才重新连接。Jacob Bartlett 从这一视角重新审视 Watch Connectivity，借 CAP 理论剖析各个 WCSession API 背后的取舍：sendMessage 要求对端即时可达，以牺牲分区时的可用性换取实时、可确认的交互；updateApplicationContext 与 transferUserInfo 则容忍短暂的不一致，优先保证可用性，前者只保留最新状态，后者按序投递每一次变更。

这种视角也让“该选择哪个 Watch Connectivity API”从接口能力问题变成了产品语义问题：登录状态、设置同步、录音控制等数据，对一致性和可用性的要求并不相同，同一个 App 的不同功能完全可以做出不同选择。

iPhone Duo 和 AnyOS 27 适配

• codelaby 介绍了 iOS 27.1 新增的 Reserved Regions API，以及如何通过 GeometryProxy 获取折痕（division）和摄像头遮挡（occlusion）区域。对于系统容器无法自动处理的自定义布局，它提供了一种避免重要内容落入折痕或摄像头区域的可靠方式。

• Antoine van der Lee 从实际适配出发，系统梳理了 iPhone Duo Simulator、可调整布局、ArrangementView、Reserved Regions、铰链状态和垂直工具栏等新能力。核心思路并不是为 Duo 单独设计一套界面，而是先让应用真正适应可变空间，再用 Duo 专属 API 对特殊场景进行增强。

• Ronnie W. 发现 macOS 27 会重新决定 SwiftUI Toolbar 的分组，即使使用 ToolbarSpacer，原本希望分开的项目仍可能被合并进同一个 navigation island。文章给出的解决方案相当直接：在需要精确控制分组时，让 AppKit 的 NSToolbarItemGroup 接管 macOS 工具栏结构。

• Anton Gubarenko 整理了两场 iPhone Duo Group Lab 中 Apple 工程师对开发者问题的回答（第二部分），涵盖自适应布局、折叠姿态、垂直工具栏、多窗口、摄像头、无障碍以及 Simulator 等大量实际问题。贯穿其中的建议十分一致：把 Duo 当作拥有更多可变空间的 iPhone，优先依赖系统容器和自适应布局，只有确有需要时再介入折痕、铰链和特定姿态。

• Sarunw 解释了 iPhone Duo 上系统如何决定 Toolbar Item 应进入水平还是垂直工具栏：为项目同时提供图标和标题，让系统根据空间选择表现形式；只有在默认判断不合适时，才通过 axisBehavior 明确指定 .horizontalOnly 或 .verticalPreferred。

工具

PaintKit：Swift 栅格绘图与图像处理引擎

Josh Lin 开发的 PaintKit，是 ItsPaint 项目中一套可以独立使用的 Swift 栅格绘图引擎，涵盖像素存储与混合、光栅化、画笔与形状、选区、撤销、文字渲染，以及图片和 PDF 编解码等能力。引擎以预乘 Alpha 的 RGBA8 像素为基础，每次编辑都会返回实际发生变化的区域，使画面刷新和撤销记录都只需处理必要的像素；撤销历史也不是简单限制操作次数，而是通过局部像素补丁按实际内存占用管理。PaintKit 不依赖 AppKit、SwiftUI 或第三方库，采用 Swift 6 严格并发模式，大部分功能无需启动应用或 Xcode 工程即可通过 swift test 验证。

ItsPaint 则是 PaintKit 的完整应用与实践验证。它是一款面向 macOS 的轻量级原生绘图及截图标注工具，提供铅笔、画笔、形状、文字、选区、像素化和聚光灯等 13 种工具，支持 15 种形状、九种导出格式和 PDF 标注，在不使用机器学习模型与网络服务的情况下移除简单背景。ItsPaint 同样开源，并可在 App Store 免费下载。

SwiftFairy：让 Agent 不再“读过就忘”的 SwiftUI 审查工具

由 Natalia Panferova 与 Matthaus Woolard 打造的 macOS 工具，通过本地 MCP 服务器为编码 Agent 提供 Swift 与 SwiftUI 代码审查。

与把大量规则写进 Skill 或 AGENTS.md、再期待 Agent 在正确的时候想起它们不同，SwiftFairy 将“发现问题”交给确定性的静态分析：它把代码解析为局部图，与声明式的问题模式进行匹配，将发现精确定位到代码行，再把对应的解释和修复示例交给 Agent。知识只在真正命中问题时才进入上下文，既避免了 Agent “读过就忘”，也减少了 Token 消耗。

SwiftFairy 的价值也很大程度来自规则本身。目前这些知识以“卷轴”（Scrolls）的形式组织，首批包括 Proper SwiftUI、Performant Swift Charts 与 Modern Swift，内容来自两位作者多年积累的书籍与文章，以及 Natalia 曾参与 Apple SwiftUI 核心团队工作的经验。与让另一个 LLM 来 Review 相比，SwiftFairy 更像是在 Agent 工作流中加入了一层具有领域知识、结果可重复的静态审查。

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 平台之外扩展数据处理能力的路径。