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

Read on web →

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

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

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

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

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

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

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

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

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

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

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

Swift Blog Carnival: Tiny Languages

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

So far, three entries have been published:

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

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

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

Indicating Selection in macOS Menus Using SwiftUI

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

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

Building List Replacement in SwiftUI

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

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

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

AppIntents meet MCP

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

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

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

Ride the Lightning Air: Building Interactive WidgetKit Widgets

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

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

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

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

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

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

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

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

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

Tools

Bad Dock: Animate Your Dock Icon

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

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

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

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

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

Share

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

网页版

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

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

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

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

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

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

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

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

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

近期推荐

Swift Blog Carnival: Tiny Languages

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

目前已有三篇投稿：

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

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

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

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

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

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

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

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

AppIntents meet MCP

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

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

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

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

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

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

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

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

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

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

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

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

工具

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

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

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

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

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

Read on web →

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

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

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

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

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

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

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

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

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

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

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

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

Localization in Swift Packages

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

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

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

SwiftUI Coordinator Pattern: Navigation Without NavigationLink

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

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

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

Teach your AI to write Swift the Hacking with Swift way

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

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

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

The Principles and Practices of AI Agents

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

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

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

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

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

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

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

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

Tools

Slots: A Macro for Improving Custom SwiftUI Component Design

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

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

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

Explore SwiftUI: A Visual Reference for Native Components and Modifiers

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

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

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

Book

SwiftUI Architecture: Patterns and Practices for Building Scalable Applications

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

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

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

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

Share

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

网页版

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

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

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

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

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

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

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

近期推荐

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

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

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

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

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

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

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

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

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

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

AI Agent 的道与术

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

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

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

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

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

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

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

工具

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

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

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

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

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

书籍

SwiftUI Architecture: Patterns and Practices for Building Scalable Applications

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

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

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

A Wall Away, Worlds Apart

Read on web →

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

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

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

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

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

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

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

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

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

Swift 6.3 Released

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

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

Designing a type-driven JSON in Swift

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

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

Swift Native AI Agent Development Series

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

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

Talking Liquid Glass with Apple

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

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

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

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

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

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

Package Traits in Xcode

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

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

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

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

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

Adjusting line height in SwiftUI on iOS 26

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

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

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

Tools

Cove: A Swift 6 Native macOS Open Source Database Client

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

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

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

Share

一墙之隔，不同的时空

网页版

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

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

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

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

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

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

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

本期推荐

Swift 6.3 Released

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

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

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

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

Swift 原生 AI Agent 开发实践系列

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

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

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

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

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

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

Package Traits in Xcode

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

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

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

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

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

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

工具

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

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

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

Is My App Stuck in Review?

Read on web →

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

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

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

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

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

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

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

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

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

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

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

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Original

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

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

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

Recent Recommendations

Expanding Animations in SwiftUI Lists

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

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

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

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

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

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

A Vision for Networking in Swift

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

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

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

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

Preparing Your iOS Codebase for AI Agents

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

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

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

iOS Conf SG 2026 Videos

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

Tools

TaskGate: Managing Actor Reentrancy

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

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

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

pico-bare-swift

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

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

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

Share

我的 App 审核被卡了？

网页版

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

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

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

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

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

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

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

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

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

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

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

原创

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

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

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

近期推荐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

iOS Conf SG 2026 视频

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

工具

TaskGate：解决 Actor 重入的工具

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

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

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

pico-bare-swift

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

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

Apple at 50 and Me at 51

Read on web →

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

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

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

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

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

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

Happy Birthday, Apple!

Previous Issue｜Newsletter Archive

This Week’s Sponsor

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

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

⚡️ Get BoltAI — 25% off ->

Original

Why I’m Still Thinking About Core Data in 2026

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

Recent Recommendations

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

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

Faster iOS Subscriptions with ASC CLI and RevenueCat MCP

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

JetBrains Swift Developers Survey

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

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

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

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

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

What you should know before Migrating from GCD to Swift Concurrency

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

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

A 9-Step Framework for Choosing the Right Agent Skill

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

As Antoine points out, not every task should be delegated directly to an LLM, and not every capability needs to become an agent tool. The framework evaluates factors such as task determinism, execution cost, reusability, and security considerations, providing a structured way to reason about when and how to extend an AI agent’s capabilities.

Tools

DataStoreKit

This is a particularly interesting open-source project developed by Anferne Pineda. It leverages SwiftData’s custom store capability to re-implement a SQLite-backed persistence engine while preserving SwiftData’s higher-level developer experience. The project maps SwiftData models, predicates, and queries to SQLite schemas, SQL execution, snapshots, and persistent history management.

DataStoreKit also introduces several noteworthy capabilities. For example, it supports predicate queries on collection types such as arrays and dictionaries by mapping them to JSON structures stored in SQLite. It also exposes a SQL passthrough layer, allowing developers to bypass #Predicate when necessary and directly execute SQLite queries or maintenance operations.

This is one of the few projects that explores SwiftData’s DataStore extensibility at significant depth, demonstrating how SwiftData can function as a data abstraction layer rather than a complete persistence engine. The project is still in an early stage and its APIs and capabilities may evolve, but it is already well worth watching.

Playwright for Swift

Developed by Miguel Piedrafita, swift-playwright brings the mature browser automation capabilities of Playwright into the Swift ecosystem. Developers can control Chromium, Firefox, and WebKit directly from Swift code to perform tasks such as page navigation, clicking, form input, screenshots, and JavaScript execution. The API design also closely mirrors the official Playwright interface.

Under the hood, the project does not re-implement a browser automation framework. Instead, it wraps the Playwright protocol on the Swift side while continuing to communicate with browsers through the Node.js Playwright driver. For developers interested in building testing tools, CLI utilities, or even AI agents using Swift, this project offers a compelling entry point.

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

Share

50 岁的苹果和 51 岁的我

网页版

再有不到半个月，Apple 将迎来 50 岁生日。Tim Cook 也发表了一篇短文，致敬过去半个世纪的历程。不过，由于苹果一直以来始终引领潮流的形象，很多人并没有意识到它已经是 IT 产业中名副其实的元老。与它年龄相当的 IT 巨头，如今仍留在一线牌桌上的寥寥无几。

作为一个只比苹果大一岁的科技爱好者，从 Apple II 到如今的 iPhone、MacBook，苹果的产品几乎伴随我走过了大半人生。严格来说，我并不算真正的果粉——不会因为没能第一时间买到新品而遗憾，也几乎不再熬夜看发布会，更说不出新产品的具体参数。但回顾过去，在每一个人生节点上，我都会很自然地选择苹果的产品，并在近几年成为了苹果开发生态中的一员。

其实我也没有完全想明白，苹果对我持久的吸引力究竟来自哪里。是因为很早就开始使用它的产品？是它的创新、体验和气质？还是 Jobs 的人格魅力？说实话，如今的选择已经完全出于习惯和本能，就像老友间的默契，早已不需要什么特别的理由。

当然，苹果的成长之路并非一帆风顺，其间也有过低谷。但有一点必须承认：它在过去 50 年间的企业定位几乎没变——为个人和社会创造强大的工具。即便在最新一轮 AI 浪潮中，苹果看似失去了先机，但作为连接人与数字世界的“最后一厘米”的核心参与者，它仍然具备在 AI 时代留在牌桌中央的资本。毕竟，我们生活在物质世界中，需要实打实的硬件设备和个人化服务来享受技术进步的成果。

50 岁的苹果或许能给更多企业带来启示：与其模仿它“炫酷”、“创新”的外表，不如学习它的专注与坚持。成为与用户长久互相陪伴的伙伴，或许才是它成功的真正密码。

大概率再过十年，当苹果 60 岁、我 61 岁的时候，我仍然用着一台苹果电脑。

生日快乐，苹果！

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

本期赞助

原生 AI 聊天应用 — 极速、隐私优先、100+ 专业功能

一个原生应用，100+ AI 模型，支持 Mac、iOS 和 Android。极速响应、键盘驱动、非 Electron。限时优惠，使用码 FATBOBMAN25 立享 75 折。

⚡️ 获取 BoltAI — 75 折优惠 ->

原创

2026 年，为什么我仍在思考 Core Data

到 2026 年，Core Data 已经问世 21 年，尽管仍有不少开发者在使用它，但在今天的 Swift 项目里，它越来越像个“时代遗留”。并发得靠 perform 一层层套，模型声明堆满样板代码，字符串谓词随时等你踩坑。这篇文章不是要为 Core Data 辩护，也不是要说服新的开发者回到 Core Data。它更像是一篇问题整理：在 2026 年，为什么仍有人坚持使用 Core Data；而如果要继续使用它，我们今天真正需要解决的问题又是什么。

近期推荐

苹果工程师谈应用安全与内存保护 (Fortify Your App: Essential Strategies to Strengthen Security Q&A)

在苹果开发者中心举办的一场安全专题活动中，多位苹果工程师围绕应用安全与内存安全进行了近六小时的分享与问答，内容涵盖现代应用面临的安全挑战，以及 Apple 平台提供的一系列防护技术。Anton Gubarenko 将这场活动中的大量开发者问答整理成文，讨论了第三方库安全评估、UserDefaults 与 plist 数据存储的风险、Keychain 与文件保护策略、Swift unsafe API 的使用边界，以及如何在 Xcode 中启用 Enhanced Security 等能力。对于希望了解 Apple 平台安全机制与实践建议的开发者来说，这是一份信息密度很高的问答整理，其中包含不少来自苹果工程师的一手信息。

用 CLI 与 MCP 自动化配置 iOS 订阅 (Faster iOS Subscriptions with ASC CLI and RevenueCat MCP)

为应用添加订阅功能本身并不复杂，但在 App Store Connect 与 RevenueCat 两个后台之间来回配置，过程往往相当繁琐。Rudrank Riyam 介绍了一种更高效的做法：使用 ASC CLI 在终端中一次性创建订阅产品，再让 AI 代理通过 RevenueCat 的 MCP Server 自动完成 entitlements、offerings 与 paywall 的配置，从而将原本依赖控制台点击的流程迁移到 CLI + AI Agent 的自动化工作流中。

JetBrains 面向 Swift 开发者的调查 (JetBrains Swift Developers Survey)

JetBrains 最近发布了一份面向 Swift 开发者的调研问卷，邀请开发者分享当前使用的开发工具、工作流程以及在 Swift 生态中的痛点。尽管官方并未说明调研的具体用途，但社区中已经出现不少猜测：这项调查可能与 JetBrains 重新评估 Swift 开发工具支持有关。

在 JetBrains 于 2022 年宣布停止维护 AppCode 之后，Swift 开发者基本回到了以 Xcode 为核心的工具链。此次调研也引发了一些讨论——有人期待 JetBrains 重新探索 Swift tooling 的可能性，也有人认为这更可能与 Kotlin Multiplatform 或 Swift 构建工具链相关。如果你对 Swift 开发工具生态的未来方向感兴趣，不妨参与这份调查。

不依赖编译器识别 Swift Protocol 的方法 (How Well Can You Detect a Swift Protocol Without the Compiler?)

在 Swift 项目中，Protocol 几乎无处不在，但如果不依赖编译器或完整构建环境，仅通过源码文本判断一个文件是否定义或使用了协议，结果会有多可靠？Xiangyu Sun 在这篇文章中系统评估了多种检测策略，例如使用 SourceKit/LSP、SwiftSyntax AST、关键字正则匹配，以及通过 extension Foo: Bar、any / some 等语法信号进行启发式判断，并对这些方法的准确率与适用场景进行了比较。

文章最有意思的部分在于作者发现：简单的命名约定可以显著提升静态分析效果。如果团队统一使用 *Protocol 后缀命名协议类型（如 PaymentServiceProtocol），很多原本存在歧义的检测方法都会变得更加可靠。作者还进一步讨论了这种约定在 AI 辅助开发中的价值：通过在文件级别预分类协议文件，可以在向 LLM 提供上下文时显著减少 token 消耗，并提高分析效率，这是一个颇具启发性的视角。

迁移到 Swift Concurrency 前需要注意的细节 (What you should know before Migrating from GCD to Swift Concurrency)

从 GCD 迁移到 Swift Concurrency 并非简单的语法替换。在这篇文章中，Soumya Ranjan Mahunt 指出：Swift Concurrency 在任务调度、执行顺序以及并发语义上与 GCD 存在一些关键差异，例如 Task 的调度并不保证与 GCD 相同的 FIFO 执行顺序，而 actor 也并不是 DispatchQueue 的直接替代，其执行行为可能受到任务优先级和调度策略的影响。此外，文中还讨论了一些在实际迁移过程中容易被忽视的问题，例如 DispatchGroup 在 Swift Concurrency 中并没有完全等价的 API，以及在旧系统版本中使用 assumeIsolated 可能遇到的兼容性问题。

选择 AI Agent Skill 的九步框架 (A 9-Step Framework for Choosing the Right Agent Skill)

随着 AI Agent 在开发工作流中的应用越来越广泛，如何为 Agent 设计合适的“技能”（Skill / Tool）也逐渐成为一个新的工程问题。Antoine van der Lee 提出了一个用于判断何时应该为 Agent 创建技能的九步框架，帮助开发者在自动化能力、可维护性以及系统复杂度之间取得平衡。Antoine 指出，并非所有任务都适合直接交给 LLM，也并非所有能力都需要实现为 Agent 工具。文章从任务确定性、执行成本、可复用性以及安全性等角度出发，提供了一套相对系统的评估思路。

工具

DataStoreKit

这是一个很有意思的开源项目，由 Anferne Pineda 开发。它基于 SwiftData 的自定义 store 能力，在保留 SwiftData 上层开发体验的同时，重新实现了一套面向 SQLite 的底层存储后端，包括从 SwiftData 模型、谓词到 SQLite schema、SQL、快照与持久化历史的映射和执行。

DataStoreKit 提供了一些值得关注的特性，例如支持对数组、字典等集合类型数据进行谓词查询，底层以 JSON 形式映射到 SQLite；同时也提供了 SQL 直通能力，让开发者在 #Predicate 之外，能够直接利用 SQLite 的能力完成查询或维护操作。

这是目前为数不多、且实现深度较高的 SwiftData DataStore 自定义实践，展示了 SwiftData 作为数据表现层而非完整持久化引擎的另一种可能性。项目目前仍处于较早期阶段，API 和能力边界可能还会继续调整，但已经非常值得持续关注。

Playwright for Swift

Miguel Piedrafita 开发的 swift-playwright，将 Playwright 这套成熟的浏览器自动化能力带入了 Swift 生态。开发者可以直接使用 Swift 代码驱动 Chromium、Firefox 和 WebKit，完成页面导航、点击、输入、截图、执行 JavaScript 等常见操作，整体 API 风格也尽量贴近官方 Playwright。

从实现方式上看，它并不是重新实现一套浏览器自动化框架，而是在 Swift 侧封装了 Playwright 协议，底层依然通过 Node.js 的 Playwright driver 与浏览器通信。对于希望使用 Swift 构建测试工具、CLI，甚至 AI Agent 的开发者来说，这个项目提供了一个颇具吸引力的切入点。

活动

LET’S VISION 2026 -- Born to Create · Powered by AI

• 👀 70+ 展商现场体验

• 🤖 AI 创新产品 / AI Agent

• 🥽 XR / 空间计算沉浸体验

• 🎤 创作者与开发者分享

如果你是开发者、设计师、产品经理、创作者，还是对 AI 和未来科技感兴趣的探索者，都很值得来逛逛。

• 📅 2026.3.28 – 3.29

• 📍 上海 · 漕河泾会议中心

八五折门票获取入口 👇

MacBook Neo: The Starting Point of Apple’s Return to Campus

Read on web →

Last week, Apple launched several new hardware products. Unlike previous launch events, this release was unusually low-key. Initially, I was only interested in the newly announced monitor, but after seeing numerous tech media outlets criticizing the MacBook Neo’s specs, I couldn’t help but pay closer attention to it. Looking past the superficial “downgrades”, I saw Apple’s clear determination to return to the education market through its precise pricing strategy.

Over a decade ago, Apple was a dominant player in the education hardware market. A significant portion of students who grew up using Apple devices on campus naturally transitioned into long-term consumers of Apple’s hardware and software after entering the workforce. However, as Google continuously ramped up its investments in Chromebooks and Apple lacked a price-competitive alternative, this K-12-centric market was gradually taken over by competitors (Chromebooks once captured nearly 60% of the U.S. K-12 education market). This not only cost Apple a portion of its revenue but, more importantly, weakened the brand affinity it had established among teenagers surrounding desktop and laptop computing forms. Compared to tablets, laptops still hold distinct advantages in teaching experience, use cases, durability, and centralized IT management.

In today’s service-first era, hardware is deeply intertwined with ecosystems. Chromebooks have long cultivated a massive cohort of young users accustomed to using Google Docs. As these users grow older and accumulate data, even if they eventually have the purchasing power to buy Apple devices, it becomes incredibly difficult to deeply lock them into Apple’s service ecosystem, let alone cultivate true brand loyalty.

The precise pricing of the Neo changes this dynamic. A starting price of $599 and an education discount of $499 give more children the opportunity to start using Apple devices and owning an Apple ID in school, thereby following Apple’s “predetermined path” to gradually purchase more products and services. As for the widely criticized “downgraded specs”—the A18 Pro chip is more than sufficient for daily K-12 scenarios. It isn’t lacking in performance; this is exactly where it is meant to be positioned. Apple traded a mobile chip for aggressive pricing headroom—a very shrewd calculation.

The subscription-based Apple Creator Studio also demonstrates Apple’s ambition to build long-term relationships with a broader audience within its ecosystem. For schools, cheap hardware combined with a powerful creative software suite forms a perfect closed loop. The MacBook Neo’s hardware performance may not be top-tier, but it is enough to provide a stable, usable experience over a typical 4- to 5-year device lifecycle, allowing users to gradually assimilate into Apple’s service system. From this perspective, the MacBook Neo acts more like an “ecosystem anchor” tossed by Apple to Gen Z and Gen Alpha.

Too many consumers and tech reviewers focus entirely on whether Apple’s products are cool or innovative, forgetting Apple’s roots—the education hardware market is deeply embedded in its DNA. Its success today stems from decades of past accumulation, and now it needs to fill the void left over the past dozen years. For the readers of this newsletter, the Neo is highly unlikely to be your cup of tea. But that doesn’t prevent it from being a highly targeted and ambitious product—one that isn’t designed to make a quick buck, but rather serves as Apple’s long-term bet on its ecosystem landscape for the next two decades.

Previous Issue｜Newsletter Archive

This Week’s Sponsor

Notepad.exe — Your First Stop for Swift Experiments

New Swift 6 syntax to try? Xcode is too heavy, Playground too slow. Notepad.exe gets you from idea to running code in 30 seconds — no project setup. Multi-toolchain support, simulator integration, just open and code.

🚀 Download for macOS →

Original

Why Does Passing NSManagedObjectContext Across Isolation Domains No Longer Error in Swift 6.2? The Real Change Isn’t in the Compiler

When a piece of concurrency-related code fails to compile in older versions of Xcode but compiles successfully in the latest Xcode 26 (Swift 6.2), what would be your first guess? Many developers might initially assume that Swift’s concurrency analysis—such as Region-Based Isolation—has evolved again. But the reality is not that simple. In this article, I document a rather interesting debugging journey I recently encountered: starting from a failing test, constructing a minimal reproducible example, and tracing the issue all the way down to the Core Data SDK interface. Eventually, I discovered that the key change was not entirely in the Swift compiler itself, but in how the framework is imported. In the new SDK, NSManagedObjectContext is now annotated with macros like NS_SWIFT_SENDABLE, giving it Sendable semantics in Swift.

Although SwiftData is the most important persistence framework for the future of the Apple ecosystem, Core Data—the foundation beneath it—has not been neglected by Apple. Over the past few years, Apple has been quietly improving its compatibility and concurrency behavior in Swift 6, which is a very encouraging sign.

Recent Recommendations

What’s new in Swift: February 2026 Edition

Karen Chu and Dave Lester compiled the latest developments in the Swift ecosystem for February 2026 on the official blog. The post not only highlights Swift’s strong presence at FOSDEM—the world’s largest open source conference—but also showcases several notable open-source updates and Swift Evolution proposals. Among them, SE-0506 particularly caught my attention. The proposal introduces an Options parameter to withObservationTracking, allowing developers to precisely control whether they observe changes before mutation (willSet), after mutation (didSet), or even lifecycle events such as deinit. Additionally, withContinuousObservationTracking enables stable, automatic continuous observation without the need to manually re-register observers recursively.

The acceptance of SE-0506 is significant. It not only completes the timing control and continuity capabilities of state observation, but also marks the maturity of Swift’s native Observation system. It is no longer merely a companion feature for SwiftUI, but has evolved into a robust foundation capable of supporting industrial-grade, high-performance state-flow scheduling across Swift applications.

macOS Input Method Development Guidelines for 2026

Based on years of experience developing macOS input methods, ShikiSuen, the author of the vChewing Input Method, provides a comprehensive overview of the historical baggage of InputMethodKit (IMK) and the various issues it exposes under Swift 6’s strict concurrency checks. The article explores challenges such as NSConnection naming conventions, sandbox requirements, MainActor isolation conflicts, ARC congestion caused by frequent language switching (CapsLock), and even NSWindow memory leaks under the macOS 26 Liquid Glass mechanism. Rather than simply criticizing these legacy frameworks, the author proposes a set of engineering practices that resemble a “risk-control model”: reducing controllers to simple forwarding layers, moving business logic into weak-referenced sessions, using self-checking memory guards, and avoiding IMKCandidates entirely.

Notably, ShikiSuen implemented these ideas in an open-source library called IMKSwift. It provides an @MainActor-isolated IMKInputSessionController base class designed for Swift 6+, covering many concurrency pitfalls in the original IMKInputController. If you are developing macOS desktop applications or input methods, this library allows you to write type-safe, modern Swift code without manual hacks or data-race warnings.

SwiftUI, Swift Effects: A Beautiful Onion Architecture

Handling data loading states in SwiftUI is something almost every application has to deal with. The common states—loading, loaded, and failed—are often intertwined with side effects such as network requests, caching, and logging, which can quickly make view code messy. In this article, Salgara proposes an approach inspired by Onion Architecture. By combining ViewState with Effect Handlers, side effects such as Fetch, caching, and logging are separated into composable layers. AsyncSequence and injectable Effect Handlers then drive state transitions, allowing the UI to render purely based on state. In this design, the view layer remains clean while data and side effects flow through a clearly structured “effect pipeline.” The architecture also provides strong testability—tests can intercept effects and simulate data sources to validate state transitions.

Salgara openly acknowledges that this architecture is still experimental: prototype-first, and treating everything as a view (Everything as a View). As more developers explore architectures that better align with SwiftUI’s design philosophy, such experiments may not only benefit SwiftUI itself but also enrich the broader landscape of declarative programming rather than merely replicating patterns from other UI frameworks.

Spec-Driven Development: After AI Starts Writing Code

With the growing adoption of AI coding agents such as Cursor and Claude Code, developers are facing a new challenge: when AI can generate thousands of lines of code across dozens of files in minutes, how can humans effectively review it? And how should we deal with issues like context decay and hallucinations as conversations grow longer? A new development paradigm is emerging in response: Spec-Driven Development (SDD). In this model, developers no longer focus primarily on writing code directly. Instead, they define clear specifications (Specs), and AI generates implementations based on those specifications.

Snow explores this idea through a four-part series. Starting with the limitations of “Vibe Coding,” the articles outline a specification-centered development workflow and examine the evolving role of specifications in future software engineering. In this vision, code may no longer be the center of a project—it may simply become a byproduct of well-defined specifications.

As AI increasingly handles implementation details, the center of software engineering may shift from “writing code” to “expressing intent.” SDD attempts to establish a strong layer of constraints between human ambiguity and AI’s indiscriminate code generation.

Building a Mini Linker for SwiftUI Previews

Among the many tools provided by mcpbridge in Xcode 26.3, RenderPreview can directly return screenshots of SwiftUI previews, making them easier for AI to analyze. For developers who cannot yet use Xcode 26.3 mcpbridge, the approach and accompanying tools introduced by Hesham Salman offer a similar capability. The technical highlight lies in using SwiftSyntax to construct a declaration dependency graph, then applying BFS to determine the minimal set of source files required by a given preview. This avoids the need to compile the entire App target, significantly reducing build time.

The real value of this article lies in its approach: using SwiftSyntax + BFS to quickly identify the code segments required by a preview. In the past, SwiftSyntax had a relatively high barrier to entry, but in the age of AI-assisted development it is increasingly becoming foundational infrastructure for understanding code structure. Even if you are not as experienced with SwiftSyntax as Hesham Salman, once you understand its basic capabilities you can leverage AI to implement similar ideas—tools that previously were often built only by developers deeply familiar with compiler tooling.

Swift at scale: building the TelemetryDeck analytics service

When discussing Swift on Server, many people still focus on a simple question: can it be used in production? TelemetryDeck provides a more concrete answer—not only can it be used, it is already powering an analytics service that processes data from over 16 million users each month. In this article, Daniel Jilg explains why the team chose Swift + Vapor for their backend stack and shares valuable lessons from operating a production system. These include using Codable to simplify API encoding and validation, keeping DTOs close to controllers, and recognizing that seemingly mundane practices—like cache TTLs, API versioning, and monitoring—often become the true moat in large-scale production systems.

Get Rid of Your SwiftGen Dependency

For many years, developers relied on tools like SwiftGen to solve a longstanding issue in Apple’s resource system: resource access was stringly typed. Whether it was localization keys, image names, or color assets, typos often went unnoticed until runtime. Asser Osama points out that with the introduction and maturation of String Catalogs (.xcstrings) and Asset Catalog Symbols, Xcode can now automatically generate resource symbols during compilation. For many modern projects, this built-in capability may already replace the need for SwiftGen.

It is worth noting that removing the dependency assumes your project runs entirely within the standard Xcode ecosystem. Resource symbol generation is an internal feature of the Xcode build system rather than a capability of the Swift compiler or Swift Package Manager. For teams using non-standard build systems such as Bazel or Buck, SwiftGen may still remain the more portable and controllable option.

Tools

SwiftUI Agent Skill

Written by Paul Hudson, this SwiftUI Agent Skill aims to help developers produce smarter, simpler, and more modern SwiftUI code. The project gained over 1k stars within just two days of release.

Over the past few weeks, this newsletter has recommended several skills created by well-known developers. While these skills encapsulate the authors’ experience, I still don’t recommend using them blindly. At the very least, read them thoroughly before adopting them. A skill is essentially a condensed form of insights accumulated across dozens or even hundreds of articles. Only by understanding the underlying design ideas—and adapting them to your own development habits and project needs—can you truly unlock their value.

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

Share

Macbook Neo：苹果重回校园的起点

网页版

上周，苹果推出了若干新款硬件产品。与以往的发布会不同，这次发布显得异常低调。起初我只对其中新发布的显示器感兴趣，但在看到不少数码媒体对 Macbook Neo 配置的吐槽后，也不由得多留意了这款产品。相较于其“减配”的表象，我更从其精准的定价中看到了苹果重返教育市场的决心。

十几年前，苹果还曾是教育硬件市场的重要参与者。那些在校园中使用苹果设备成长起来的学生，也有相当一部分在进入社会后顺理成章地成为苹果软硬件的长期消费者。但随着谷歌持续加大在 Chromebook 上的投入，而苹果又缺乏更具价格竞争力的产品，这一以 K12 为核心的市场逐渐被对手占据（Chromebook 曾一度拿下美国基础教育市场近 60% 的份额）。这不仅让苹果损失了一部分收入，更重要的是削弱了其在青少年群体中、围绕台式机与笔记本这种计算形态所建立的品牌亲和力。相比平板设备，笔记本在教学体验、适用场景、耐用性以及 IT 集中管理等方面依然具有明显优势。

在服务优先的今天，硬件往往与生态深度绑定。Chromebook 早早培养出一大批习惯使用 Google Docs 的年轻用户。随着年龄增长与数据的积累，即便他们日后具备购买苹果设备的能力，也很难再与苹果的服务生态形成深度绑定，更难形成真正的品牌信仰。

Neo 精准的定价改变了这一局面。$599 的起售价、$499 的教育优惠，让更多孩子有机会在学校就开始使用苹果设备、拥有 Apple ID，从而顺着苹果“预设”的轨迹，逐步购买更多产品与服务。至于被广泛批评的”减配”——A18 Pro 芯片对 K12 日常使用场景而言完全足够，它缺的不是性能，而是定位本就如此。苹果用移动端芯片换来了激进的定价空间，这是一笔算得很清楚的账。

采用订阅制的 Apple Creator Studio，同样展现了苹果希望让更多人与其生态建立长期联系的野心。对于学校而言，廉价硬件+强大的创作软件套件，构成了闭环。Macbook Neo 的硬件性能或许不算强劲，但足以在每台设备约 4–5 年的生命周期中提供稳定、可用的体验，让使用者逐步融入苹果的服务体系。从这个角度来看，MacBook Neo 更像是苹果抛向 Z 世代与 Alpha 世代的一枚“生态锚点”。

太多消费者和数码博主过于聚焦于苹果产品是否炫酷、是否有创新，却忘记了苹果的来时路——教育硬件市场深植于它的基因之中，今天的成功源于数十年前的积累，而现在它需要补上最近十几年的空缺。对于本周报的读者来说，Neo 大概率不是你的菜。但这并不妨碍它成为一款极具针对性、也颇具野心的产品——不是用来赚快钱的，而是苹果为未来二十年的生态版图所做的一次长期押注。

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

本期赞助

Notepad.exe — Swift 新特性的第一个实验场

Swift 6 出了新语法？Xcode 太重，Playground 又太慢。Notepad.exe 让你在 30 秒内写代码、跑结果，专注验证想法本身。支持多版本工具链切换，集成模拟器，随开随用。

🚀 立即使用 →

原创

跨域传递 NSManagedObjectContext 为什么在 Swift 6.2 中不再报错？真正的变化不在编译器

当同一段与并发有关的代码在旧版 Xcode 中无法通过，却在新版 Xcode 26（Swift 6.2）中顺利编译时，你第一时间会想到什么？很多人最初的判断可能是 Swift 编译器的并发分析（如 Region-Based Isolation）又进化了，但现实并没有这么简单。本文记录了我最近遇到的一次非常有意思的排查过程：从测试失败出发，通过构建最小复现用例，一步步追溯到 Core Data 的 SDK interface，最终发现，问题的关键并不完全在 Swift 编译器本身，而是框架的导入语义发生了变化——在新的 SDK 中，NSManagedObjectContext 获得了 NS_SWIFT_SENDABLE 等宏标注，使其在 Swift 中拥有了 Sendable 语义。

尽管 SwiftData 是未来苹果生态最重要的持久化框架，但作为其基础的 Core Data 并没有被苹果冷落。在过去几年中，苹果一直在默默改善其在 Swift 6 中的兼容性和并发体验，这是一个很好的现象。

近期推荐

Swift 语言 2 月新动态 (What’s new in Swift: February 2026 Edition)

Karen Chu 和 Dave Lester 在官方博客上整理了 2026 年 2 月 Swift 社区的生态动态。内容不仅涵盖了 Swift 在 FOSDEM（全球最大开源会议）上的活跃表现，还推介了多项重磅的开源进展与 Swift Evolution 提案。其中的 SE-0506 尤为让我惊喜。该提案为 withObservationTracking 增加了 Options 参数，开发者现在可以精确控制是观察变化前（willSet）、变化后（didSet）还是对象的生命周期（如 deinit）。并且通过 withContinuousObservationTracking 无需再手动递归注册，即可实现稳定、自动循环的连续事件追踪。

SE-0506 提案的通过意义重大。它不仅完美补齐了状态追踪的时机控制和连续性能力，更标志着 Swift 原生的 Observation 已经彻底成熟——它不再仅仅是 SwiftUI 的“专属附庸”，而是真正蜕变为了 Swift 语言中足以应对各种工业级、高性能状态流调度的核心基础设施。

写在 2026 年的 macOS 输入法开发规范

vChewing 维音输入法 的作者 ShikiSuen 基于多年深耕 macOS 输入法的开发经验，全面梳理了 InputMethodKit (IMK) 的历史包袱，以及它在 Swift 6 严格并发检查下暴露出的种种痛点。文章深入探讨了 NSConnection 的命名规范、启用沙盒的必要性、MainActor 隔离冲突，以及高频中英切换（CapsLock）导致的 ARC 拥堵、macOS 26 Liquid Glass 机制下 NSWindow 内存不释放等棘手问题。面对苹果“上古框架”与现代 Swift 并发模型的碰撞，作者没有停留在抱怨上，而是提出了一套像“风险控制模型”一样的工程规范——将控制器退化为纯转发层、把业务逻辑剥离到弱引用 Session、使用内存自查自尽、彻底避开 IMKCandidates 等。

可贵的是，ShikiSuen 基于上述思路开发并开源了 IMKSwift 库。它为 Swift 6+ 提供了 @MainActor 完整隔离的 IMKInputSessionController 基类，完美覆盖了原生 IMKInputController 的并发地雷区。如果你需要开发 macOS 桌面端应用或输入法，这个库能让你无需手动 Hack，就能写出类型安全、无 data-race 警告的现代代码，非常值得学习与使用。

SwiftUI 的洋葱式架构：Swift Effects 实践 (SwiftUI, Swift Effects: A Beautiful Onion Architecture)

在 SwiftUI 中处理数据加载状态几乎是每个应用都会面对的问题：loading、loaded、failed 三种状态往往伴随着网络请求、缓存、日志记录等副作用逻辑，很容易让视图代码逐渐变得臃肿。Salgara 在本文中提出了一种类似 Onion Architecture 的思路：通过 ViewState + Effect Handlers 将 Fetch、缓存、日志等副作用拆分为多个可组合层级，并利用 AsyncSequence 与可注入的 Effect Handler 驱动状态变化，使 UI 仅根据状态进行渲染。这样一来，视图保持纯粹，而数据获取与副作用则沿着一条清晰的“Effect 管道”逐层流动。同时，这种结构也天然具备良好的可测试性——测试代码可以直接拦截并模拟数据源返回值，从而验证完整的状态转换流程。

Salgara 坦言，这种架构目前仍然是实验性的：原型优先，并尝试将一切视为视图（Everything as a View）。随着越来越多开发者从不同角度思考并尝试构建更符合 SwiftUI 特性的架构，这类探索不仅可能让 SwiftUI 本身受益，也有机会反过来丰富整个声明式编程范式，而不再只是复制其他 UI 框架的既有实践。

Spec-Driven Development：当 AI 写代码之后

随着 Cursor、Claude Code 等 AI 编程智能体（Agent）的普及，开发者们正面临一个新的痛点：当 AI 能在几分钟内跨越几十个文件生成上千行代码时，人类该如何有效审查？又该如何应对 AI 在长流程中逐渐出现的“上下文遗忘（Context Decay）”与幻觉问题？为此，一种新的开发范式正在逐渐成形：Spec-Driven Development（SDD）。在这一模式下，开发者的主要任务不再是直接编写代码，而是定义清晰的规格（Spec），再由 AI 根据这些规格生成实现。

Snow 通过四篇文章系统梳理了这一思路：从 “Vibe Coding” 的局限出发，介绍以规格为核心的开发流程，并进一步探讨规格在未来软件工程中的角色——代码或许不再是项目的中心，而只是规格的衍生物。

在 AI 逐渐承担实现细节的时代，软件工程的重心或许正在从“写代码”转向“表达意图”。SDD 尝试在人类的模糊意图与 AI 的无差别生成之间，建立一层强有力的约束。

为 SwiftUI Preview 构建一个 Mini Linker (Building a Mini Linker for SwiftUI Previews)

在 Xcode 26.3 的 mcpbridge 提供的众多工具中，RenderPreview 可以直接返回 SwiftUI Preview 的截图，方便 AI 进行分析。对于暂时无法使用 Xcode 26.3 mcpbridge 的开发者，Hesham Salman 在本文中介绍的思路以及配套工具，同样可以实现类似的能力。其技术亮点在于利用 SwiftSyntax 构建声明依赖图，再通过 BFS 找出当前 Preview 真正需要的最小源文件集合，从而避免编译整个 App Target 带来的构建等待。

本文的精华在于思路：利用 SwiftSyntax + BFS 快速定位 Preview 依赖的代码片段。过去 SwiftSyntax 的使用门槛较高，但在 AI 辅助开发逐渐普及的今天，它正逐渐成为理解代码结构的重要基础设施。即便你不像 Hesham Salman 那样熟练掌握该工具，了解其基本能力后，也可以借助 AI 将类似思路落地——而这类工具在过去往往只属于少数熟悉编译器工具链的开发者。

Swift 的规模化实践：TelemetryDeck 的分析服务 (Swift at scale: building the TelemetryDeck analytics service)

很多人讨论 Swift on Server 时，关注点往往停留在“能不能用”，而 TelemetryDeck 给出的则是一个更实际的答案：不仅能用，而且已经支撑起一项面向开发者、每月处理超过 1600 万用户数据的 analytics 服务。Daniel Jilg 在这篇文章中回顾了团队为何选择 Swift + Vapor 构建后端，并分享了不少来自生产环境的经验：例如如何借助 Codable 简化 API 编解码与校验、为什么应让 DTO 更贴近 controller、以及为何缓存 TTL、API 版本管理和错误监控这些“老生常谈”，在规模化的生产环境中往往才是真正的护城河。

是时候告别 SwiftGen 了吗？ (Get Rid of Your SwiftGen Dependency)

很长一段时间，开发者需要依赖类似 SwiftGen 这样的工具来解决 Apple 资源系统中的一个老问题：资源访问是字符串类型（stringly-typed）。无论是 localization key、图片名称还是颜色资产，一旦拼写错误，往往只能在运行时才会暴露问题。Asser Osama 指出，随着 String Catalog（.xcstrings）与 Asset Catalog Symbols 的引入与逐步完善，Xcode 已经能够在编译阶段自动生成资源符号，这种原生能力在不少现代项目中或许已经足以替代 SwiftGen。

需要说明的是，“移除依赖”的前提是项目完全运行在标准的 Xcode 生态中。Xcode 的符号生成属于构建系统内部机制，而不是 Swift 编译器或 Swift Package Manager 的能力——这意味着对于使用 Bazel、Buck 等非标准构建系统的团队来说，SwiftGen 仍然可能是更可移植、更可控的选择。

工具

SwiftUI Agent Skill

由 Paul Hudson 编写的 SwiftUI Agent Skill，旨在帮助开发者编写更智能、更简洁、更现代的 SwiftUI 代码。该项目发布仅两天便获得了 1k+ Star。

在过去几周中，本周报已经推荐了不少知名开发者编写的各类 Skill。尽管这些 Skill 都凝聚了作者的经验，但我仍不建议开发者直接“拿来即用”。至少应在采用前完整阅读一遍：Skill 更像是作者对自己数十甚至上百篇文章经验的提炼，而不是可以直接替代思考的“最佳实践”。开发者在理解其背后的设计思路后，再根据自己的开发习惯与项目需求进行取舍，这样才能更大地发挥它们的价值。

活动

LET’S VISION 2026，开票啦！

作为在中国举办、面向全球的 Apple 生态下的大会，今年的 LET’S VISION 将会有约 20 场演讲、超过 80 个展位，欢迎前往官网和票务平台了解更多信息。

• 时间及地点：03.28 - 03.29，上海·漕河泾会议中心

• 活动官网

• 获取门票

OpenClaw Is Impressive — I Just Don’t Really Need It (Yet)

Read on web →

On the morning of March 1st, I received a message from OpenClaw. It was part of a scheduled task I had set up after installing it: on the first day of every month, it sends me a summary of the main tasks it executed on my behalf over the past month.

Reading through that rather sparse report, I found myself pausing. At this stage, I don’t think I actually need a personal AI agent. To be honest, if it hadn’t sent that message yesterday, I might have almost forgotten it was even there.

After the OpenClaw project name was finalized, I still couldn’t quite resist the stream of flashy demos filling my social media timeline. I dug out an idle Mac mini M4 and followed the setup guides to get everything running. During the first few days, I spent some time studying how others were using it, trying to see whether it could naturally fit into my own life and workflow.

Eventually, though, I came to realize that—at least given my current workload and habits—many traditional tools that have already matured are more than sufficient for my needs. Even when I do need an agent loop on mobile devices, using more focused, single-purpose tools often results in less configuration overhead and a lower cognitive burden overall.

A year ago, few people would have expected that CLI tools would see a resurgence at a time when GUIs have long been the default. In a similar way, before OpenClaw gained traction, hardly anyone anticipated the sudden emergence of so many OpenClaw-like projects. I have little doubt that most people will eventually have their own personal AI assistants. OpenClaw presents one possible vision of that future—very much from a hacker’s perspective. But what form these assistants will ultimately take, and how they will balance privacy, security, and efficiency, remains an open question.

From one angle, having an intelligent assistant does seem pretty cool. Still, life without one feels just as calm and comfortable. For now, I’ll let 🦞 rest quietly on my mini—until the day I truly need to wake it up.

Previous Issue｜Newsletter Archive

This Week’s Sponsor

Notepad.exe — A Notepad for Developers

Notepad.exe is a lightweight coding scratchpad for macOS, built for experiments, snippets, and rapid prototyping. Open it, write your code, and run it — no project setup required.

🚀 Download for macOS →

Recent Recommendations

Building Lists: A High-Performance Diffable Data Source Framework

After integrating UICollectionViewDiffableDataSource with TCA, Hesham Salman noticed more than 100 UI stalls per minute. A deeper investigation revealed that NSDiffableDataSourceSnapshot heavily relies on Objective-C’s NSOrderedSet under the hood. In a reactive architecture where state updates frequently, repeated snapshot reconstruction leads to substantial hashing costs and Objective-C bridging overhead. To address this, Hesham built a pure Swift alternative, ListKit. By leveraging ContiguousArray, a two-level diff algorithm, and lazily constructed reverse indices, snapshot construction performance improved by several hundred times.

In imperative frameworks, developers can precisely control refresh timing, so diff performance issues may not be immediately obvious. But as reactive programming increasingly makes its way into UIKit, traditional assumptions and techniques must adapt to new refresh patterns. Yesterday’s “best practice APIs” can quietly become today’s performance bottlenecks.

SwiftUI Charts caused major stutter in my app — replacing it with Path fixed everything

There is no doubt that Swift Charts provides a clean declarative API and polished visual output, making it a go-to choice for many developers. However, even years after its release, when dealing with large datasets and high-frequency interactions, its reliance on numerous fine-grained view components can amplify SwiftUI’s diffing and layout costs, resulting in noticeable performance degradation. After reassessing his needs, Oscar Berggren replaced Charts with a custom Shape built on Path, completely eliminating drag-related stutters.

As highlighted in the ListKit article above, when high-frequency state updates (such as gesture-driven refreshes) combine with heavyweight view construction (hundreds of LineMark instances), performance bottlenecks become almost inevitable. In such cases, stepping back to lower-level drawing APIs like Path often yields more predictable and stable results.

We added an MCP server to our macOS app and learned a lot the hard way

Adding MCP support to a macOS app sounds like just exposing a few more interfaces — until you actually try it. Charidimos Chaintoutis discovered this firsthand while implementing native Swift MCP support for unclutr: the gap between “works in dev” and “users can configure, diagnose, and install it” is wider than expected.

The article details challenges around stdio transport, client handshakes, launcher configuration, and macOS sandbox restrictions—particularly the friction between sandboxing and spawning external processes. These constraints ultimately forced them to disable MCP support in the Mac App Store version and offer it only in the direct-download build. The security model they arrived at is especially instructive: separating read and write tools, requiring explicit deletion calls, enforcing absolute paths, supporting dry runs, and always moving files to Trash rather than permanently deleting them. These are lessons learned the hard way.

Array expression trailing closures in Swift

In this article, Artem Mirzabekian introduces the accepted Swift Evolution proposal SE-0508. The proposal removes a long-standing syntactic special case: array and dictionary type expressions previously could not be followed directly by trailing closures. With this restriction lifted, building collections using result builders (for example, let items = [String] { "First"; "Second" }) becomes far more natural. It also enables calling callAsFunction directly after array literals, such as ["a", "b", "c"] { $0.uppercased() }.

At first glance, this may seem like a minor syntactic refinement. In reality, it eliminates inconsistencies between collection types and other types, further smoothing Swift’s surface. Language progress does not always come from bold new features—sometimes it comes from patiently sanding down long-standing rough edges.

Mastering Geometry in SwiftUI - GeometryReader, GeometryProxy & onGeometryChange

For a long time, developers relied almost exclusively on GeometryReader to obtain a view’s size or position. However, GeometryReader is itself a layout container that expands to fill all available space. This “greedy” behavior often causes unexpected layout issues for those unfamiliar with its mechanics. In this comprehensive article, Sagar Unagar revisits SwiftUI’s geometry system from an architectural perspective. He compares the traditional GeometryReader + PreferenceKey pattern, the Layout protocol introduced in iOS 16, and the .onGeometryChange modifier introduced in iOS 18. Rather than merely listing APIs, the article explains how geometry fits into SwiftUI’s proposal-driven layout system.

If you approach SwiftUI with a command-style mindset and attempt to “control” layout directly, it will likely feel awkward. But once your mental model aligns with its negotiation-based design, you begin to see that SwiftUI’s expressive ceiling is much higher than it first appears.

Tools

Xcode Assistant Copilot Server

Xcode 26.3 introduced support for Codex and Claude Code, officially bringing agent capabilities into the IDE workflow. But not every developer uses those services. Developed by Fernando Romiti, Xcode Assistant Copilot Server offers an alternative for GitHub Copilot subscribers. It is a Swift-based local service that translates Xcode’s OpenAI-compatible requests into GitHub Copilot API calls. However, it should not be mistaken for a simple protocol adapter.

In its default mode, it acts as a transparent proxy, forwarding Xcode’s /v1/chat/completions requests to Copilot. Once Agent mode is enabled and MCP is configured, it runs a full local agent loop. When the Copilot model issues tool calls, the server intercepts them, executes the corresponding operations locally (via xcrun mcpbridge or permitted CLI tools), appends the results to the conversation, re-queries the model, and continues this cycle until a final response is produced and returned to Xcode.

Foundation Models SDK for Python

Foundation Models SDK for Python is a recently released open-source project from Apple. Through a Swift bridge, it enables developers to directly invoke Apple Intelligence foundation models running on macOS (on-device) from a Python environment.

In modern LLM application development, evaluation is critical. Developers need to run large test suites to measure the impact of prompt adjustments and tool-calling strategies. Data-driven analysis of this kind has long been dominated by the Python ecosystem. This SDK fills that gap: developers can export real transcripts (JSON) from Swift, then reproduce on-device inference behavior in Python and perform batch analysis, scoring, clustering, and error attribution as if processing ordinary datasets.

In effect, Apple is signaling a standardized workflow for AI application development: Swift handles on-device integration and user experience, while Python powers offline evaluation and iterative optimization.

vphone-cli: Running a Real iPhone on Your Mac

When Apple introduced Apple Intelligence in 2024, it also unveiled PCC (Private Cloud Compute), a privacy-focused infrastructure running on Apple Silicon servers. Its significance lies not merely in “offloading AI to the cloud”, but in extending the iPhone’s security model to server-side environments. Apple even released research materials and virtual research environments to allow security researchers to audit PCC nodes locally.

Starting with cloudOS 26, Apple added components related to vphone600ap in PCC firmware. The community quickly took notice. Building on in-depth reverse engineering work by Hyungyu Seo and others, Lakr developed vphone-cli, which operationalizes this virtualization mechanism. By leveraging private APIs from Virtualization.framework, it creates a fully functional virtual iPhone research environment on macOS. Unlike the Xcode Simulator, this setup runs real iOS firmware, executing the full boot chain from start to finish.

What makes this development fascinating is not merely jailbreak research or firmware analysis, but the broader signal it sends: Apple appears to be externalizing the iOS security architecture it has refined for over a decade, extending it to reshape its cloud computing infrastructure.

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

Share

OpenClaw 不错，但我好像没有那么需要

网页版

3 月 1 日早上，我收到了 OpenClaw 发来的信息。这是我在安装它之后设置的一个定时任务：每个月的第一天，向我汇报过去一个月它为我执行过的主要任务汇总。看着汇总中寥寥数语，我不由得陷入了思考——现阶段，我似乎真的还不需要一个个人智能体。说实话，如果不是它昨天发来的这条消息，我几乎已经忽略了它的存在。

在 OpenClaw 项目名称正式确定之后，我还是没能抵挡住社交媒体时间线上那些炫酷演示的诱惑，翻出了一台闲置的 Mac mini M4，照着教程折腾了起来。最初几天，我也认真研究过其他人的使用场景，尝试将它融入自己的生活和工作流中。但后来我逐渐意识到，至少以我目前的工作强度和使用习惯来看，一些已经足够成熟的传统工具，依然可以很好地满足我的需求。即便需要在移动设备上进行 Agent loop，直接使用功能更聚焦的单一用途产品，反而能减少配置和使用上的心智负担。

一年前，或许没有多少人会想到，在 GUI 已经成为默认形态的今天，CLI 会重新迎来一轮回潮。同样，在 OpenClaw 火爆之前，也很少有人预料到，如今会涌现出如此多的 OpenClaw-like 项目。我并不怀疑，未来大多数人都会拥有属于自己的个人智能助手。OpenClaw 以一种相当极客的方式，展示了其中的一种可能性；但智能体助手最终会以怎样的形态存在，又将如何在隐私、安全与效率之间取得平衡，直到现在依然没有一个确定的答案。

从某种角度来看，拥有一个智能助手确实挺酷；但没有它，也丝毫不影响我享受当下的平静与安逸。就让 🦞 在我的 mini 里好好休息吧，等到我真正需要唤醒它的那一天。

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

本期赞助

Notepad.exe — 随开随用的代码草稿本

轻量级 macOS 代码草稿工具，专为代码实验、片段记录和快速原型而生。打开即用，写代码、跑代码，零项目配置。

🚀 免费下载 →

近期推荐

Diffable 的性能陷阱与 ListKit 破局 (Building Lists: A High-Performance Diffable Data Source Framework)

Hesham Salman 在将 UICollectionViewDiffableDataSource 与 TCA 配合使用后，发现原生 DiffableDataSource 导致了每分钟 100 多次的卡顿。深入分析后，他发现 NSDiffableDataSourceSnapshot 底层其实重度依赖 Objective-C 的 NSOrderedSet。在响应式架构中，由于状态的高频刷新，Snapshot 的频繁重建引发了巨大的哈希计算与 Obj-C 桥接开销。为此，Hesham 开发了一个纯 Swift 实现的替代品 ListKit。通过使用 ContiguousArray、双层 Diff 算法以及延迟构建反向索引，将构建 Snapshot 的速度提升了数百倍。

在命令式框架中，由于开发者可以精确控制刷新时机，因此 Diff 的效率问题可能暴露得并不明显。但随着越来越多的开发者将响应式编程引入 UIKit，一些传统的思维或技巧需要根据新的刷新机制来做调整，过去的“最佳实践 API”可能正在成为新的性能瓶颈。

SwiftUI Charts 性能避坑：回归底层 Path 绘制 (SwiftUI Charts caused major stutter in my app — replacing it with Path fixed everything)

毋庸置疑，Swift Charts 提供了简洁的声明式体验与精致的视觉呈现，自发布以来便成为不少开发者绘制图表的首选。然而，即便在推出多年之后，当面对包含高频交互的大数据集场景时，其基于大量细粒度 View 组合的实现方式，仍可能放大 SwiftUI 的 diff 与布局成本，从而引发性能问题。Oscar Berggren 在评估自身需求后，放弃使用 Charts，为折线绘制改用自定义 Shape + Path，成功消除了拖拽过程中的卡顿。

正如前文 ListKit 所揭示的，当高频状态变更（例如手势驱动的刷新）叠加在重量级对象构建（大量 LineMark）之上时，性能瓶颈往往不可避免。此时，适度回归更底层的绘制 API（如 Path），反而能够带来更稳定、可控的表现。

纯 Swift MCP Server 开发与分发踩坑实录 (We added an MCP server to our macOS app and learned a lot the hard way)

为 macOS 应用添加 MCP 能力，听起来不过是多暴露几个接口——直到你真正去做。Charidimos Chaintoutis 在为应用 unclutr 实现纯 Swift 的 MCP 支持时发现，从“开发环境可运行”到“用户可配置、可诊断、可分发”之间，仍有相当长的一段距离。

文章记录了他在 stdio 通信、客户端握手、launcher 配置以及 macOS 沙盒（Sandbox）限制等方面遇到的问题，尤其是沙盒环境下外部进程唤起的权限冲突，最终迫使他们在 Mac App Store 版本中关闭 MCP 功能，仅在直装版本中提供支持。此外，在“如何安全地让 AI 操作用户文件”这一点上，作者总结出的实践经验尤为值得参考：读写工具分离、删除必须显式调用、强制绝对路径、支持 Dry Run、统一使用 Trash 而非硬删除。这些设计都是在踩过足够多坑之后才能得到的经验。

解锁数组与字典的尾随闭包语法 (Array expression trailing closures in Swift)

Artem Mirzabekian 在本文中介绍了一个已经通过的提案：SE-0508。该提案移除了 Swift 语法中的一个“历史特例”：数组与字典类型表达式此前无法直接跟随 trailing closure。随着这一限制被解除，利用 Result Builder 构建集合类型（例如 let items = [String] { "First"; "Second" }）将变得更加自然，同时也允许在数组字面量后直接触发 callAsFunction（如 ["a", "b", "c"] { $0.uppercased() }）。

这看似只是一次语法层面的细节调整，却进一步消除了集合类型与普通类型之间的解析差异，让语言在表达一致性上更进一步。有时候，语言的进步并非来自宏大的新特性，而是来自对那些存在多年的小瑕疵的持续打磨。

重塑 SwiftUI 布局心智：告别 GeometryReader 滥用 (Mastering Geometry in SwiftUI - GeometryReader, GeometryProxy & onGeometryChange)

很长一段时间里，开发者若想获取视图的尺寸或位置，几乎只能依赖 GeometryReader。然而，GeometryReader 本质上是一个会占满所有可用空间的布局容器，这种“贪婪”的特性，常常让不熟悉其行为的开发者陷入布局困境。Sagar Unagar 在本文中系统梳理了 SwiftUI 几何体系的演进路径与心智模型，对比了传统的 GeometryReader + PreferenceKey 组合、iOS 16 引入的 Layout 协议，以及 iOS 18 带来的 .onGeometryChange 修饰符。从架构视角解释了几何信息在 proposal-driven 布局系统中的位置，而不仅仅是 API 的使用方法。

在 SwiftUI 中，如果你始终试图用命令式思维去“控制”布局，它往往会显得别扭；但当你的理解与其协商式布局机制对齐时，你会发现它的表达能力远比想象中更高。

iOS 开发 2015-2025

这是一部用十年时光写就的个人技术编年史，也是一份关于 iOS 生态演进的珍贵记录。从 2015 年的 Auto Layout 适配、组件化浪潮，到 2025 年的 Liquid Glass 与 AI Agent，戴铭 以亲历者的视角，串联起技术变迁、社区故事与工程实践。文中既有对底层原理的深挖（如 dyld、Runtime、性能优化），也有对技术前辈的深切回望。作者认为：底层原理永远不过时；不要被新技术焦虑绑架；技术在变，但学习的方法没变。保持好奇与学习，方能坦然面对更多的十年。

工具

Xcode Assistant Copilot Server

Xcode 26.3 引入了对 Codex 与 Claude Code 的支持，将智能体能力正式带入 IDE 工作流。但并非每位开发者都使用这些服务。由 Fernando Romiti 开发的 Xcode Assistant Copilot Server 则为 GitHub Copilot 订阅者提供了一条替代路径。它是一个基于 Swift 实现的本地服务，将 Xcode 的 OpenAI 兼容请求转译为 Copilot API 调用。但不要将其误解为一个简单的接口转换层。

在默认模式下，它确实充当透明代理，将 Xcode 的 /v1/chat/completions 请求转发至 GitHub Copilot API；然而一旦启用 Agent 模式并配置 MCP，它便会在本地运行完整的 agent loop。当 Copilot 模型发起 tool call 时，Server 会在本地拦截调用，通过 xcrun mcpbridge 或允许的 CLI 工具执行相应操作，将执行结果追加至对话上下文，再次请求模型推理，直至生成最终响应，最后才将结果返回给 Xcode。

Foundation Models SDK for Python

Foundation Models SDK for Python 是苹果官方近期推出的一个开源项目。它在底层通过 Swift 桥接，让开发者能够直接在 Python 环境中调用 macOS 本地（On-Device）的 Apple Intelligence 基础模型。

在现代大模型应用开发中，评测（Evaluation）是极其重要的一环。开发者需要运行大量的测试用例，用各种测试集去验证 Prompt 调整或工具调用的准确率，而这些数据驱动的工作在业界一直是由 Python 生态主导。该 SDK 恰好填补了这一空白：开发者可以无缝实现从 Swift 端导出真实运行的 transcript（JSON），然后在 Python 端利用该 SDK 原生复现端侧的推理过程，并像处理普通数据一样进行批量分析、打分、聚类与误差归因。

这基本等于 Apple 在向开发者明示一种标准化的 AI 应用开发范式：Swift 负责线上体验与端侧集成；Python 负责离线评测与迭代优化。

vphone-cli：在 Mac 上运行一台真实的 iPhone

2024 年 Apple 发布 Apple Intelligence 时，同步推出了 PCC（Private Cloud Compute）：一套运行在 Apple Silicon 服务器上的隐私计算基础设施。它的特别之处不只是”把 AI 请求放到云端处理”，而是把 iPhone那套安全模型延伸到了服务器侧。为此，Apple 还罕见地开放了研究材料和虚拟研究环境，允许安全研究员在本地审计 PCC 节点的软件栈。

从 cloudOS 26 开始，苹果在 PCC 固件中新增了与 vphone600ap 相关的组件。社区的极客们敏锐地抓住了这个契机，基于 Hyungyu Seo 等人 对该虚拟化机制的硬核逆向研究，Lakr 开发的 vphone-cli 将其彻底工程化：通过调用 Virtualization.framework 的私有 API，直接在 Mac 上搭出一套完整的虚拟 iPhone 研究环境。和 Xcode 模拟器不同，这里跑的是真实的 iOS 固件，完整的启动链会从头走一遍。

有意思的地方不只是越狱或固件研究本身，更在于从 PCC 到这一类虚拟化工具所透露出的底层方向：Apple 正在把它十多年来在移动端积累的 iOS 安全架构，彻底外溢并重塑云端计算基础设施。

活动

LET’S VISION 2026，开票啦！

作为在中国举办、面向全球的 Apple 生态下的大会，今年的 LET’S VISION 将会有约 20 场演讲、超过 80 个展位，欢迎前往官网和票务平台了解更多信息。

• 时间及地点：03.28 - 03.29，上海·漕河泾会议中心

• 活动官网

• 获取门票

The Spring Festival Gala, Robots, AI, and LLMs

Read on web →

As a television program with over a billion viewers, the China Central Television’s Spring Festival Gala is undoubtedly an exceptional showcase platform. In this year’s Gala, multiple Chinese robotics manufacturers presented their products in various performances, among which Unitree’s humanoid robots caught the most attention. During the show, multiple models of these humanoid robots executed a series of highly complex martial arts and dynamic movements. Compared to the more static, stationary displays of last year, the complexity and stability of their movements have seen a significant leap—a progress that has drawn attention from global media.

Following the Gala, discussions on social media showed a clear divide. Alongside the amazement at the technological progress, there was no shortage of skeptical voices dismissing the performance as “pre-programmed,” “lacking AI,” or “impractical.” To a certain extent, this reflects the public’s underestimation of the sheer complexity of robotics—especially a lack of awareness regarding the difficulties of motion control, real-time feedback systems, and system-level integration.

One point needs clarification: pre-trained does not equal “record-and-playback.” It is true that humanoid robots currently employ highly orchestrated movement sequences in such performances, but this shares a similar logic with the training of human dancers or athletes. Extensive offline training and rehearsal form the foundation of the movements, but during actual execution, the “body” must still rely on dynamic balance and real-time corrections to cope with real-world disturbances. It is precisely this fault tolerance and real-time repair capability that allows humanoid robots—a naturally unstable bipedal system—to pull off highly dynamic, continuous movements.

Meanwhile, the explosion of Large Language Models (LLMs) in recent years has led many to mistakenly equate LLMs with AI as a whole. In reality, AI, a field with decades of history, encompasses far more than just language understanding. Especially when interacting with the real physical world, the usage of specialized models—such as computer vision, path planning, motion control, and reinforcement learning—in industrial and physical systems still vastly exceeds that of LLMs. In the realm of robotics, the true ceiling of a system’s capability is typically determined by its perception systems, control systems, and low-latency feedback algorithms, rather than its language reasoning abilities.

Even if stronger “cognitive abilities” are introduced to humanoid robots in the future, the better path may not necessarily be directly plugging in an LLM. Instead, it will likely involve building World Models that inherently understand the laws of physics, paired with control systems capable of low-latency responses—two areas that happen to be inherent weaknesses of LLMs. The challenges of Embodied AI are fundamentally different from pure text reasoning.

As for the issue of “practicality,” kung fu or dancing indeed hardly correspond directly to real-world job scenarios. However, it is precisely these movements—which demand extreme balance, coordination, and dynamic response—that provide the perfect validation ground for highly complex and unstable systems like humanoid robots. They function as engineering stress tests, demonstrating the maturity of mechanical design, electronic control, and algorithmic integration, rather than proving short-term commercial viability.

Personally, I remain cautious about the future market size for humanoid robots. There is often a significant chasm between technological breakthroughs and widespread commercial adoption. Nevertheless, judging by the magnitude of progress showcased at this year’s Gala, it is reasonable to conclude that within the next decade, robots or smart machines integrating into our daily work and living environments is no longer just sci-fi imagination. Whether you like “robots” or not, the trajectory of technological evolution is unmistakably clear: we will eventually need to coexist with them.

As for the apocalyptic scenario of “robots enslaving humanity,” I’m not worried about that for now. My more realistic concern is this: if they encounter a bug at work and swing a punch at me, I genuinely couldn’t take the hit.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

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

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

How to Migrate to @Observable Without Breaking Your App

As more apps raise their minimum deployment target to iOS 17, @Observable is replacing ObservableObject as the new state management foundation. However, when a project has deeply relied on ObservableObject + @Published, migration is far from a simple macro substitution. Pawel Kozielecki draws on a real-world migration experience to systematically walk through the correct usage of property wrappers in the new system — using @State for lifecycle management, @Bindable for two-way bindings, and plain properties for read-only access — while highlighting easily overlooked details such as @ObservationIgnored and computed property tracking blind spots. The real challenge of migration was never about syntax; it’s about truly understanding who owns the view model’s lifecycle.

Testing with Event Streams

Although Swift Testing offers a rich assertion API, in practice you’ll find there’s no single tool that fully corresponds to XCTest’s ability to verify that multiple callbacks are triggered in order (fulfillment + enforceOrder). confirmation requires nesting and cannot directly validate trigger order. Matt Massicotte proposes an approach that better fits Swift’s concurrency model: using AsyncStream to collect events, wrapped in a lightweight EventStream type — yielding event identifiers when callbacks fire, then calling collect at the end to retrieve the full event sequence for comparison against an expected array. As for why not just use a plain array, Matt provides a compelling answer: when @Sendable constraints or inconsistent actor isolation are involved, writing directly to an array creates concurrency safety issues, whereas the AsyncStream-based approach naturally conforms to the concurrency model.

If You’re Not Versioning Your SwiftData Schema, You’re Gambling

SwiftData’s declarative syntax and automatic migration capabilities make it easy to fall into the trap of thinking “the framework will handle everything.” The reality is that once your model structure changes — adding fields, renaming, adjusting relationships — without an explicit schema version and migration plan, you’re left relying on implicit inference. When that inference fails, the result is rarely a graceful migration; more often it’s crashes, data loss, or an app that won’t launch. Mohammad Azam offers direct, pragmatic advice: explicitly declare Schema versions; prepare migration paths for future structural changes; and treat migration design as part of model design, not an afterthought.

This advice applies equally to Core Data. Even when a model is fully compatible with lightweight migration, creating a corresponding model version file for each release (whenever structural changes occur) not only helps track the model’s evolution but also enables clear, controlled rollback when issues arise. Using explicit versioning to govern model evolution is fundamentally about establishing safety boundaries for long-term maintenance.

How to build a simple CLI tool using Swift

There’s an interesting phenomenon in the age of AI Coding: CLI tools are experiencing a renaissance — more and more developers are building CLI tools to power their MCP and Agent workflows. Natascha Fadeeva walks through how to build structured command-line tools using Swift Package Manager and Apple’s official ArgumentParser library: defining root commands and subcommands, handling async network requests, and compiling to a standalone distributable binary. For iOS developers already fluent in Swift, this path is more natural than maintaining a bash or Python script, and easier to evolve alongside the project.

Navigation Notes – Agentic coding

As an experienced developer, Joseph Heck observes that as AI becomes capable of executing tasks, generating code, and driving changes autonomously, the developer’s role shifts from “line-by-line implementer” to “path navigator.” The truly scarce skill is no longer coding speed, but navigation — how developers maintain their sense of direction in complex codebases and multi-agent environments. Joseph offers several practical suggestions: always include “ask me about anything ambiguous” in your prompts; have the agent draft a plan and get your approval before implementation; provide deterministic feedback loops (unit tests, compiler errors) that allow the agent to self-correct; and distill frequently reused instructions into Skill files.

Heck avoids amplifying the “AI will disrupt developers” narrative, instead emphasizing a more grounded reality: agentic coding amplifies existing engineering capabilities. If you’re already good at modular design and abstraction, AI will accelerate you. If your sense of boundaries is fuzzy, AI will just create chaos faster.

Setting up a delivery pipeline for your agentic iOS projects

When code generation, modification, and refactoring begin to be driven by agents, is the traditional CI/CD pipeline still sufficient? Donny Wals opens with a real experience: his app crashed mid-workout at the gym, he handed the crash report to an agent for analysis, and by the time he finished training, a PR was waiting. After merging, a TestFlight build landed shortly after. Around this experience, he systematically outlines how to build a reliable delivery pipeline for agentic iOS projects — one that keeps automated changes controllable, verifiable, and releasable.

The article’s focus isn’t on any specific tool, but on pipeline design itself. Donny emphasizes that code generated by agents is fundamentally “a change that hasn’t been reviewed line by line,” which makes clear quality gates all the more important: automated testing, continuous integration, and the release pipeline must bear ultimate responsibility for delivery. Agents can significantly accelerate implementation, but engineering discipline cannot be relaxed in kind — when velocity increases, control mechanisms become even more critical.

Tracking Token Usage in Foundation Models

Apple’s Foundation Models run on-device with a context window of just 4,096 tokens — once exceeded, the conversation cannot continue. iOS 26.4 introduces token usage tracking APIs to help developers monitor context consumption in real time. Artem Novichkov covers four key metrics: total model context capacity (contextSize), token consumption for Instructions, consumption for individual Prompts, and cumulative usage for the full conversation Transcript. The article also highlights an easily overlooked detail: when a Tool is introduced, its name, description, and argument schema are serialized and counted toward the token budget — the same Instructions jump from 16 to 79 tokens once a Tool is attached. For on-device models, token observability will become essential infrastructure for optimizing the user experience.

Tools

App Store Connect CLI

App Store Connect CLI is an unofficial App Store Connect command-line tool developed by Rudrank Riyam, covering the full release pipeline: TestFlight management, build uploads, code signing, screenshot automation, localization sync, app review submission, notarization, and financial report downloads. The tool was designed from the ground up with agent scenarios in mind and includes dedicated documentation for agent-oriented workflows. If your release pipeline centers on TestFlight, metadata, submission, signing, and CI automation, ASC is worth considering as a lightweight alternative to fastlane.

GRDB 7.10.0: Android, Linux, and Windows Support

GRDB 7.10.0 is a milestone release: it formally introduces support for Android, Linux, and Windows, and adds the ability to use SQLCipher (encrypted databases) via Swift Package Manager — two long-awaited features from the community. This marks a meaningful evolution for Swift’s most mature SQLite wrapper, from an Apple-platform tool into a truly cross-platform data layer solution.

Gwendal Roué notes in the release announcement that because Xcode does not yet support package traits, SwiftPM will still download unused dependencies; until this is resolved, SQLCipher support will continue to require a fork.

Swift System Metrics

Swift System Metrics provides Swift applications — particularly server-side projects — with unified system-level metrics collection: CPU utilization, memory usage, file descriptor counts, and more, exposed through a standardized Metrics interface that integrates with existing monitoring systems such as Prometheus. It is not a standalone monitoring system, but rather an infrastructure component driven by the Swift Server Work Group, designed to align with the Swift Metrics ecosystem and bring system resource metrics into the same observability stack as application-level metrics. The 1.0 release signals API stability and production readiness. For teams building Swift backend services or investing in Swift observability, this is a foundational piece of the puzzle.

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

Share

春晚、机器人、AI 与 LLM

网页版

作为一个观众数量超十亿的电视节目，央视春晚无疑是极佳的展示平台。今年春晚中，多家中国机器人厂商在不同节目中展示了其产品，其中讨论度最高的当属宇树（Unitree）的人形机器人。在表演环节，多款型号的人形机器人完成了大量较为复杂的武术与动态动作展示。与去年偏静态、偏站桩式的呈现相比，今年的动作复杂度与稳定性确实有明显提升，这一点也得到了全球媒体的关注与报道。

春晚之后，社交媒体上的讨论呈现出明显分化。除了对技术进步的惊叹之外，“预编程”、“没有 AI”、“缺乏实用性”等质疑声音同样不少。这在一定程度上反映了公众对机器人技术复杂度的低估——尤其是对运动控制、实时反馈系统和系统级整合难度的认知不足。

需要澄清的一点是：预训练并不等于“录制-回放”。当前人形机器人在此类表演中的确采用了高度规划的动作流程，这与人类舞者、运动员的训练逻辑有相通之处——大量的离线训练与调试构成了动作的基础，但在实际执行过程中，身体仍需依赖动态平衡与即时修正来应对真实环境的扰动。正是这种容错与实时修复能力，才让人形机器人这个天然不稳定的双足系统得以完成高动态的连续动作。

与此同时，近年来大语言模型（LLM）的爆发，让不少人将 LLM 与 AI 等同起来。事实上，AI 作为一个已有数十年发展的领域，远远不止语言理解这一分支。尤其是面对真实的物理世界时，视觉识别、路径规划、运动控制、强化学习等专用模型在工业与实体系统中的使用量，依然远高于 LLM。在机器人领域，真正决定能力上限的往往是感知系统、控制系统以及低延迟反馈算法，而不是语言推理能力。

即便未来为人形机器人引入更强的”认知能力”，更适合的路径也未必是直接接入 LLM，而可能是构建能理解物理规律的世界模型（World Models）与具备低延迟响应能力的控制系统——这两点恰恰是 LLM 的固有短板。具身智能（Embodied AI）的挑战，与纯文本推理存在本质差异。

至于“实用性”的问题，功夫或舞蹈确实难以直接对应现实工作场景。但恰恰是这些对平衡性、协调性与动态响应要求极高的动作，为人形机器人这种高度复杂且不稳定的系统提供了极佳的验证场景。它们更像是工程能力的压力测试，展示的是机械设计、电子控制与算法系统整合的成熟度，而非短期商业落地能力。

我个人对于人形机器人未来的市场规模仍然持审慎态度。技术进步与商业普及之间往往存在不小的鸿沟。但从今年春晚所呈现的进步幅度来看，可以合理判断：在未来十年内，机器人或智能机器以某种形式融入日常工作与生活场景，已不再是科幻想象。无论你是否喜欢“机器人”，技术演进的趋势已经十分明确，我们终将需要与它们共存。

至于“机器人奴役人类”的情景，我暂时并不担心。我更现实的担忧是：如果它们在工作中出现 Bug，给我一拳，我真的挨不住。

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

近期推荐

如何在不破坏 App 的前提下迁移到 @Observable (How to Migrate to @Observable Without Breaking Your App)

随着越来越多的应用将最低系统版本提升至 iOS 17，@Observable 正在取代 ObservableObject 成为新的状态管理基础设施，但当项目已经深度依赖 ObservableObject + @Published 时，迁移远非简单替换宏即可完成。Pawel Kozielecki 结合一次真实的迁移踩坑经历，从底层机制差异出发，系统梳理了新体系下属性包装器的正确使用方式——用 @State 管理生命周期、用 @Bindable 处理双向绑定、只读场景直接使用普通属性，并特别指出了 @ObservationIgnored、计算属性追踪盲点等容易被忽视的细节。迁移的难点从来不在语法层面，而在于真正厘清“谁拥有 view model 的生命周期”这一根本问题。

验证多个回调按顺序触发 (Testing with Event Streams)

尽管 Swift Testing 提供了丰富的断言 API，但在实际使用中你会发现，并没有一个工具能够完全对应 XCTest 中“验证多个回调按顺序触发”（fulfillment + enforceOrder）的能力。confirmation 既需要嵌套使用，也无法直接校验触发顺序。对此，Matt Massicotte 提出了一种更符合 Swift 并发模型的思路：使用 AsyncStream 收集事件，并封装为一个轻量级的 EventStream 类型——当回调触发时 yield 事件标识，测试结束后通过 collect 获取完整事件序列，再与预期数组进行对比。对于“为什么不直接使用数组”这一疑问，Matt 也给出了充分理由：在存在 @Sendable 约束或 actor 隔离不一致的场景下，直接写入数组会触发并发安全问题，而基于 AsyncStream 的方案则天然符合并发模型的约束。

务必为 SwiftData 模型显式声明 Schema 版本 (If You’re Not Versioning Your SwiftData Schema, You’re Gambling)

SwiftData 的声明式写法与自动迁移能力很容易让人产生“框架会替我处理一切”的错觉，但现实是，一旦模型结构发生变化（字段新增、重命名、关系调整），如果没有显式的 schema version 与 migration plan，就只能依赖隐式推断。一旦推断失败，结果往往不是优雅的迁移，而是崩溃、数据丢失，甚至导致应用无法启动。Mohammad Azam 的建议直接而务实：显式声明 Schema 版本；为未来的结构变化预留迁移路径；将“迁移设计”视为模型设计的一部分，而不是事后补救。

本文的观点同样适用于 Core Data。即便模型完全兼容轻量迁移，为每个发行版本创建对应的模型版本文件（只要发生结构修改），不仅有助于追踪模型演化轨迹，也能在出现问题时实现清晰而可控的回滚。用明确的版本机制约束模型演进，本质上是在为长期维护建立安全边界。

用 Swift 开发 CLI 工具 (How to build a simple CLI tool using Swift)

一个有趣的现象是，在 AI Coding 时代，CLI 正在重焕青春——越来越多的开发者通过构建 CLI 工具来承载自己的 MCP 与 Agent 工作流。Natascha Fadeeva 介绍了如何用 Swift Package Manager 和 Apple 官方的 ArgumentParser 库构建结构化的命令行工具：定义主命令与子命令、处理异步网络请求、最终编译为可独立分发的二进制文件。对于已经熟悉 Swift 的 iOS 开发者来说，这条路径比维护一套 bash/Python 脚本更自然，也更容易随项目一起演进。

在 AI 编程时保持方向感 (Navigation Notes – Agentic coding)

作为一个拥有丰富经验的开发者，Joseph Heck 认为当 AI 能够主动执行任务、生成代码甚至推动改动时，开发者的角色从“逐行实现者”转变为“路径规划者”。真正稀缺的能力不再是写代码的速度，而在“导航”——也就是开发者在复杂代码与多代理环境中如何保持方向感。Joseph 给出了几条建议，例如：在提示词中始终加入”对任何模糊之处向我提问”；先让 Agent 制定计划并获得确认，再开始实施；提供确定性的反馈回路（单元测试、编译器错误），让 Agent 能够自我修正；以及将反复使用的指令集沉淀为 Skill 文件等。

Heck 并没有过度渲染“AI 颠覆开发者”的叙事，而是强调一种更冷静的现实：agentic coding 会放大已有的工程能力。如果你本来就善于模块划分与抽象设计，AI 会加速你；如果边界感模糊，AI 只会更快制造混乱。

为 Agent 驱动的 iOS 项目构建可靠交付管线 (Setting up a delivery pipeline for your agentic iOS projects)

当代码的生成、修改与重构开始由 Agent 驱动时，传统的 CI/CD 流程是否仍然足够？Donny Wals 以一次真实经历展开：健身时应用崩溃，他将 Crash Report 交给 Agent 分析，训练结束后 PR 已经准备就绪，合并后 TestFlight 构建随即落地。围绕这一实践，他系统梳理了如何为“agentic iOS 项目”构建一条可靠的交付管线（delivery pipeline），确保自动化改动依然可控、可验证、可发布。

文章的重点并不在某个具体工具，而在流程设计本身。Donny 强调，Agent 生成的代码本质上仍属于“未经人工逐行审查的改动”，因此更需要明确的边界与质量闸口：自动化测试、持续集成与发布流程必须承担最终的交付责任。Agent 可以显著提升实现速度，但工程纪律不能随之放松——速度提升之后，控制机制反而更为关键。

实时掌握 Foundation Models 的上下文消耗 (Tracking Token Usage in Foundation Models)

Apple 的 Foundation Models 运行在设备端，上下文窗口仅 4096 个 token，一旦超出便无法继续对话。iOS 26.4 新增了 token 用量追踪 API，帮助开发者实时掌握上下文消耗情况。Artem Novichkov 系统介绍了四个关键指标：模型上下文总容量（contextSize）、Instructions 的 token 消耗、单条 Prompt 的消耗，以及完整对话记录（Transcript）的累计用量。文章还揭示了一个容易被忽视的细节：当引入 Tool 时，其名称、描述与参数 Schema 会被序列化并计入 token，同一段 Instructions 在附加 Tool 后 token 数从 16 跃升至 79。对于设备端模型而言，token 的可观测性将成为优化体验的基础设施。

工具

App Store Connect CLI

App Store Connect CLI 是由 Rudrank Riyam 开发的非官方 App Store Connect 命令行工具，功能覆盖 TestFlight 管理、构建上传、代码签名、截图自动化、本地化同步、应用审核提交、notarization，以及财务报告下载等完整发布链路。它从设计阶段就强调 Agent 场景，并提供了面向 Agent 的实践文档。若你的发布流程重心在 TestFlight、元数据、提审、签名与 CI 自动化，ASC 可以作为 fastlane 的轻量替代方案之一。

GRDB 7.10.0: 新增 Android、Linux、Windows 支持

GRDB 7.10.0 是一个具有里程碑意义的版本更新：本次正式引入对 Android、Linux、Windows 的支持，并新增通过 Swift Package Manager 使用 SQLCipher（加密数据库）的能力——这两项功能都长期受到社区期待。这意味着这个 Swift 生态中最成熟的 SQLite 封装库，正在从 Apple 平台工具演进为真正的跨平台数据层解决方案。

Gwendal Roué 在 版本公告 中也特别说明，由于 Xcode 尚未支持 package traits，SwiftPM 目前仍会下载未实际使用的依赖；在相关问题解决之前，SQLCipher 支持将以 fork 形式长期维护。

Swift System Metrics

Swift System Metrics 为 Swift 应用（尤其是服务端项目）提供了统一的系统级指标采集能力，例如 CPU 使用率、内存占用、文件描述符数量等，并通过标准化的 Metrics 接口对外暴露，便于接入 Prometheus 等现有监控体系。它并非一个独立的监控系统，而是由 Swift Server Work Group 推动的基础设施组件，旨在与 Swift Metrics 生态对齐，使系统资源指标与应用级指标纳入同一可观测体系。1.0 的发布意味着 API 已趋于稳定，具备生产环境使用条件。对正在构建 Swift 后端服务、或持续完善 Swift 可观测性能力的团队来说，这是一个基础设施层面的关键拼图。

Wishing Everyone a Happy Year of the Horse!

Read on web →

This Chinese New Year ushers in the Bingwu Year (丙午) — a once‑in‑60‑years “Red Horse Year” (赤马年) .

In the traditional Chinese stem‑branch calendar, the Heavenly Stem Bing (丙) and the Earthly Branch Wu (午) both belong to the Fire element. This double‑fire combination creates an exceptionally rare “Fire Horse” pattern. Since fire is associated with the colour red, this Year of the Horse is also called the “Red Horse Year” (红马年) . This red horse embodies pure vitality and soaring spirits, symbolising a year full of boundless energy and enterprising drive.

At this once‑in‑60‑years auspicious moment, I wish all my readers: good health (CPU at full power), a soaring career (performance optimised), smooth sailing in everything (bug‑free runtime), and immediate success (compilation passed)! 🎉

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

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

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

Swift Concurrency from Zero to Hero | Reading List

Setting AI aside—since it still struggles to handle complex Swift 6 concurrency code at an expert level—even as tools rapidly evolve, you shouldn’t remain a passive observer. A systematic and comprehensive understanding of Swift Concurrency—its concepts, usage patterns, and historical evolution—is essential for building safer and more resilient applications from the ground up. In this article, Alex Ozun organizes a structured learning roadmap for Swift Concurrency, divided by difficulty levels. Each stage is accompanied by publicly available, free resources, with complexity gradually increasing. The goal is simple: complete the journey and move from Zero to Hero.

A Modern iOS Project Setup in 15 Steps

For many developers, starting a new project means repeating a series of tedious setup steps. In this thread, Ertem Biyik outlines a modern engineering baseline for iOS projects in 15 steps: using Tuist to manage dependencies and project generation, centralizing configuration through xcconfig, simplifying onboarding with a Makefile, and validating builds with GitHub Actions. He also recommends standardizing AI context with AGENTS.md and leveraging sosumi.ai for LLM-friendly Apple documentation.

Micelio: Growing Software Like Nature Grows Forests

As AI becomes deeply embedded in development workflows, many traditional tools are starting to show their limitations. Using the metaphor of a mycelium network, Pedro Piñera argues that Git’s model—capturing what changed but rarely preserving why it changed—may no longer be sufficient in an AI-first world. This article presents his systematic reflection on a “post-Git era” and introduces an experimental approach to agent-first collaboration. The accompanying open-source forge project, Micelio, centers around sessions as the core unit to capture context and reasoning, shifting code hosting from storing diffs to storing decisions. Though still early-stage, the problem framing and engineering direction are worth watching.

Copy-on-Write in Swift - How It Works and Why It Optimizes Memory

Copy-on-Write (COW) is a fundamental mechanism in Swift and a key reason value types can achieve strong semantics without sacrificing performance. Sagar Unagar explains how Swift balances value semantics and runtime efficiency through a “struct wrapper + reference storage” model: reads share storage, while writes trigger a real copy only when the reference is no longer unique, detected via isKnownUniquelyReferenced. The article also demonstrates how to implement COW in custom types.

Taking First Steps into Metal Shaders

For many SwiftUI developers, Metal can feel distant and complex. In this article, Letizia Granata walks through the basics of working with shaders—from understanding CPU/GPU responsibilities to adding a .metal file in Xcode and applying a simple shader effect in SwiftUI. Rather than diving into rendering pipelines or graphics theory, the focus is on getting something running, lowering the barrier to entry for experimentation.

Setting Up a Backend Server for Our Landmarks App

Landmarks is Apple’s classic SwiftUI tutorial app, but its reliance on local JSON data leaves a gap between example and real-world architecture. Kyle Browning builds a simple backend using Vapor to serve data via API, transforming the static demo into a client-server structure. The article covers model definition, routing, data responses, and integration with SwiftUI—less about complex business logic and more about extending a teaching example into something closer to production reality.

In the Background: Spotlight Indexing

After a system update, Macs often run hot and sluggish for a few days—commonly attributed to Spotlight reindexing. But how exactly does Spotlight scan files, decide when to rebuild its index, and manage system resources in the background? Howard Oakley analyzes logs and empirical data to explore Spotlight’s triggering mechanisms, process behavior, and impact on I/O and performance, offering a deeper technical look at macOS internals.

Tools

ScreenStateKit: A Better MVVM for the SwiftUI Concurrency Era

If you appreciate TCA’s unidirectional data flow and predictable state management but don’t want to fully refactor your existing MVVM architecture, ScreenStateKit may offer a pragmatic middle ground. Anthony Tran splits the traditional ViewModel into two clearly defined components: a @MainActor-isolated ScreenState that holds UI state, and a Swift actor-based ScreenActionStore that handles business logic and async tasks. All mutations flow through strongly typed Actions, bringing compile-time concurrency safety and TCA-like discipline to MVVM. Built-in loading/error handling, duplicate request prevention (ActionLocker), parent-child state propagation, and pagination support round out the design. Anthony also provides a detailed design article explaining the architecture and its rationale.

GitHub Directory Downloader

If you’ve ever cloned an entire repository just to download a single folder from GitHub, this tool is for you. Developed by Stewart Lynch, this native macOS app lets you paste any GitHub repository or directory URL (including tree/branch/path formats), automatically detect the default branch, recursively download the selected directory, and preserve its original structure.

SimTag: Branch Context for Your iOS Simulators

In parallel development workflows, it’s easy to lose track of which branch is running in which iOS Simulator. Developed by Aryaman Sharda, SimTag overlays a lightweight label on each Simulator window, showing the git branch and commit corresponding to the running build. For developers using worktrees, reviewing PRs, or collaborating with AI tools, it helps reduce cognitive friction and prevents debugging the wrong branch.

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

Share

祝大家马年新春快乐！

网页版

今年的中国农历年是丙午年，是一个60年一遇的“赤马年”。

在干支纪年中，天干“丙”与地支“午”五行皆属火，双火叠加，形成了极为罕见的“火马”格局。因火色为赤，故此马年又称“红马年”。这匹“红马”承载着最纯粹的阳刚之气与蓬勃活力，预示着接下来的一年将充满奔放的能量与昂扬的进取心。

在这个 60 年一遇的吉庆节点，我在此祝各位读者新的一年：身体健康（CPU 满血），事业驰骋（性能优化），万事顺遂（无 Bug 运行），马到成功（编译通过）！ 🎉

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

近期推荐

Swift 并发进阶阅读路线图 (Swift Concurrency from Zero to Hero | Reading List)

暂不说 AI 目前还很难像专家一样处理 Swift 6 并发相关的复杂代码，即便工具能力突飞猛进，作为使用者的你也不该只当旁观者：系统、全面地理解 Swift 并发的概念、用法与历史脉络，才能从源头构建更安全、更强健的应用。Alex Ozun 在本文中按难度划分关卡，整理了一份“从入门到进阶”的 Swift Concurrency 阅读路线图：每一关都配套了公开且免费的参考资料，难度也会逐级递增，希望你在完成这条主线之后，能从 Zero 走到 Hero。

15 步打造现代 iOS 项目 (A Modern iOS Project Setup in 15 Steps)

对于不少开发者而言，新项目的开始往往伴随着重复而琐碎的配置工作。Ertem Biyik 在这条串贴中用 15 个步骤梳理了一套现代 iOS 项目的工程化基线：以 Tuist 为核心管理依赖与生成，通过 xcconfig 统一环境配置与构建参数，借助 Makefile 简化初始化流程，并在 GitHub Actions 中完成 lint 与构建校验；同时，他还建议使用 AGENTS.md 统一 AI 上下文，并配合 sosumi.ai 获取更利于 LLM 阅读的 Apple 文档。

Micelio：后 Git 时代的代码托管工具 (Micelio: Growing Software Like Nature Grows Forests)

AI 深度参与开发流程后，许多传统工具开始显露出“水土不服”。Pedro Piñera 以“菌丝网络（mycelium）”为隐喻，指出随着 AI agent 参与开发的规模与频率不断提升，Git 这种只记录 what changed、却难以保留 why it changed 的历史模型，正在变得不够充分。本文是他对“后 Git 时代”的一次系统性思考，也是对“agent-first 协作方式”的公开实验。配套的开源 git forge Micelio 项目尝试以 session 为核心单元捕获上下文与推理，将代码托管的重心从“存 diff”转向“存决策”。项目仍处于早期阶段，但其问题意识与工程方向，都值得持续关注。

Swift 写时复制 (Copy-on-Write in Swift - How It Works and Why It Optimizes Memory)

写时复制（COW）是 Swift 的核心机制之一，也是值类型在保证语义一致性的同时获得良好性能的关键。Sagar Unagar 结合集合类型的内部实现，解释了 Swift 如何通过“结构体外壳 + 引用存储”的方式实现读共享、写分离：只有在发生写入且检测到非唯一引用时，才会借助 isKnownUniquelyReferenced 触发真正的拷贝。文章同时展示了自定义类型实现 COW 的基本模式。

Metal Shader 入门 (Taking First Steps into Metal Shaders)

对于大多数 SwiftUI 开发者而言，Metal 往往显得遥远而复杂。Letizia Granata 通过本文带你从 0 开始接触 Shader：从理解 GPU 与 CPU 的分工，到在 Xcode 中添加 .metal 文件，再到编写并在 SwiftUI 中应用一个最简单的 shader 效果。Letizia 没有深入渲染管线或图形学细节，而是聚焦“如何真正跑起来”，帮助读者跨过入门门槛。

为 Landmarks 构建 Vapor 后端 (Setting Up a Backend Server for Our Landmarks App)

Landmarks 是 Apple 在 SwiftUI 教程中提供的经典示例应用，但由于它使用本地 JSON 数据，与真实项目的客户端—服务器架构仍存在差距。Kyle Browning 使用 Vapor 为 Landmarks 构建了一个简单的后端服务，将静态示例升级为通过 API 获取数据的完整结构。文章围绕模型定义、路由配置、数据响应以及与 SwiftUI 前端的对接展开，重点不在复杂业务逻辑，而在于示范如何把一个“教学示例”扩展为更贴近真实世界的项目。

Spotlight 后台索引机制解析 (In the Background: Spotlight Indexing)

系统更新后的几天里机器发热、卡顿，很多人都知道这与 Spotlight 的重新索引有关，但它在后台如何扫描文件、何时触发重建索引、又如何调度系统资源，却鲜少被系统性梳理。Howard Oakley 基于日志与实测数据，对 Spotlight 索引的触发机制、进程行为以及对 I/O 与性能的影响进行了细致分析，提供了一次关于 macOS 内部运行机制的深入技术观察。

工具

ScreenStateKit：并发时代的 MVVM 演进

如果你欣赏 TCA 的单向数据流与可预测状态管理，却又不想在现有 MVVM 项目中彻底重构架构，那么 ScreenStateKit 状态管理库也许是一个折中方案。作者 Anthony Tran 将传统 ViewModel 拆分为两个职责清晰的部分：一个运行在 @MainActor 上、只负责持有 UI 状态的 ScreenState，以及一个以 Swift actor 实现、专门处理业务逻辑与异步任务的 ScreenActionStore，所有状态变更都通过强类型 Action 作为唯一入口，从而在保持 MVVM 结构直观性的同时，引入类似 TCA 的单向数据流与编译期并发安全。配合内建的加载与错误状态管理、重复请求防护（ActionLocker）、父子状态传播与分页支持。Anthony 亦撰写了一篇详尽的设计说明文章，对其架构理念与实践细节进行了系统阐述。

GitHub 子目录下载工具

如果你曾为了下载 GitHub 上的某个示例目录而被迫 git clone 整个仓库，这款 GitHub Downloader 显然正是为此而生。它是 Stewart Lynch 开发的一款原生 macOS 应用，允许你粘贴任意 GitHub 仓库或子目录 URL（包括 tree/branch/path 形式），自动识别默认分支，递归下载所选目录内容，并完整保留其原始层级结构。

SimTag：为模拟器标注分支上下文

在并行开发成为常态的今天，面对多个外观几乎相同的 iOS Simulator，开发者很容易迷失：到底哪个分支正在运行？是否调试了错误的构建版本？Aryaman Sharda 开发的 SimTag 会在每个 Simulator 窗口上叠加一个轻量标识，显示当前构建对应的 git 分支与提交信息。对于习惯使用 worktrees、进行 PR 审查或结合 AI 协作开发的团队来说，这是一个能够显著减少认知摩擦、避免“调错分支”的实用小工具。

Xcode Enters the Agent Era

Read on web →

Although Apple had already incorporated AI-assisted programming capabilities in the initial version of Xcode 26, the experience felt more like ChatGPT being awkwardly embedded into the IDE: the functionality existed, but felt disconnected. Compared to the then-popular Cursor, it seemed like a product from a different era. As AI CLI tools like Claude Code gradually matured, Xcode appeared to fall further behind, leading many developers to question whether it could still serve as a “primary IDE” in the AI age.

The arrival of version 26.3, with almost no advance notice, responded to these doubts with concrete action. By integrating Claude Code/Codex, Apple’s answer was direct: with the right strategy, Xcode remains a highly promising development environment within the Apple ecosystem. This time, Xcode didn’t simply add a CLI tool panel; instead, it introduced a native set of Xcode Tools (MCP), coordinated with official technical documentation for Swift 6, SwiftUI, SwiftData, and more, creating a highly consistent experience aligned with the latest practices. Even for developers already proficient with CLI + XcodeBuildMCP + various Skills, this native solution remains highly competitive—especially with its near-zero configuration cost, which is significant for the vast majority of developers.

More notably, the Xcode Tools provided in this update don’t just serve Xcode itself; they can also function as standard MCP to provide capabilities for other AI tools. This open approach doesn’t entirely align with the outside world’s impression of Apple’s usual style.

Of course, from today’s vantage point, we cannot yet assert that Xcode has returned to the first tier. But what’s certain is that 26.3 has sent a very clear signal: Apple is willing to collaborate with mainstream tools and services to create development experiences that truly align with the times. For this reason, I have higher expectations for the next iteration of Siri—likely in iOS 27, Apple will provide more standardized interfaces for the system and apps beyond the existing Intent framework, allowing AI to integrate more naturally into the entire ecosystem.

Xcode + Agent is just the beginning.

Apple + Agent is the future worth paying more attention to.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

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

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Original

Xcode 26.3 + Claude Agent: Model Swapping, MCP, Skills, and Adaptive Configuration

Xcode 26.3 directly provides support for Claude Code/Codex. Finally, developers can conveniently use native AI Agents in Xcode. Over the past few days, I’ve conducted a series of experiments with the new version, including how to use the latest models, configure MCPs/Skills/Commands, and write adaptive CLAUDE.md. This article uses Claude Code as an example to share some tips beyond the documentation.

Recent Recommendations

From Pixel Capture to Metadata: Reimagining Screen Recording Architecture on macOS

Video is replacing text as a more popular form of expression, and good tools accelerate creation. Sintone, developer of the macOS screen recording software ScreenSage Pro, provides an in-depth retrospective on implementing “finished editing upon recording completion” based on ScreenCaptureKit and Metal. From solving the cryptic SCK -3821 error to migrating from ObservableObject to @Observable to optimize timeline performance, this article openly shares the entire process from pixel capture to high-performance composition.

Which Method is Fastest for Checking if a String is in a Whitelist: Set, Array, Enum, Dictionary, or Switch?

In Swift, checking whether a string belongs to a set of keys can be written as Set.contains, Array.contains, RawRepresentable enum’s init?(rawValue:), switch with multiple cases, or even using a Dictionary for mapping. They may look similar, but when placed in performance-sensitive paths, the results might not fully align with intuition. Helge Heß conducted a simple benchmark test: Set.contains leads without suspense, followed by enum(rawValue:) and Dictionary (very close to each other); while switch, which many would instinctively overestimate, actually ranks after enum, with Array.contains finishing last. As a small experiment, these results might be just what we need to calibrate our intuition about Swift performance.

Migrating an iOS app from Paid up Front to Freemium

Paid download and free + in-app purchase are two fundamentally different business models, and as apps evolve, developers may need to transition between them. In this article, Donny Wals shares his complete experience converting the Practical Core Data app from a $4.99 paid download to freemium. The article not only covers StoreKit 2 technical implementation details (purchase flow, state management, family sharing), but more valuably, his deep thinking on business decisions: while the paid barrier can filter for serious users, it also blocks many potential users from experiencing the product’s value. For educational or utility indie apps, freemium may be a better balance between user growth and revenue.

On-demand resources in iOS app

App size has always been a concern for developers, especially when apps contain large amounts of images, audio, or other resources. Although Apple introduced On-Demand Resources (ODR) in iOS early on to address this challenge, this feature has a weak presence and is often overlooked by developers. In this article, Majid Jabrayilov systematically reviews ODR’s working mechanism and usage, including resource grouping, tag management, download lifecycle, and collaboration with system caching strategies.

While Apple is promoting Background Assets as a more modern solution, ODR still has unique value in scenarios requiring immediate response for on-demand downloads and fine-grained resource control.

Objectively Better, Observably Trickier

When fully embracing the Observation framework, developers need to be aware that its working mechanism differs from Combine’s @Published, and simple replacement often introduces subtle issues. Danny Bolella summarizes four common pitfalls during migration: non-lazy initialization when @State holds reference types, update loss caused by nested @Observable objects, changes in array element binding methods, and conflicts with other property wrappers. The article provides solutions through clear code examples and repeatedly emphasizes a core principle: updates only trigger when properties currently being accessed (getter called) by the view change. Understanding and adapting to this “lazy observation” mindset is key to correctly using the Observation framework.

Add an Open Recent Menu to a SwiftUI app

“Open Recent” is a standard macOS app feature, but for SwiftUI developers, correctly implementing this functionality is not intuitive. In this article, Mark Szymczyk demonstrates through a concise example how to use NSDocumentController to integrate system-level recent file management capabilities into your app: automatic list maintenance, menu updates, and seamless coordination with document lifecycle. For document or utility apps, this is a low-cost detail optimization that can significantly enhance the “native feel.”

Tools

Radioform: A Native, Open-Source macOS Audio Equalizer

macOS has long lacked a system-level audio equalizer. Radioform, developed by Matthew Porteous, fills this gap. The project employs a layered architecture of SwiftUI menu bar App + Swift Host + CoreAudio HAL Driver + C++ DSP, completely decoupling UI from real-time audio processing. The DSP portion implements 10-band parametric EQ, parameter smoothing, limiting, and real-time safety control; the engineering also includes complete CI, code signing notarization, and DMG release workflow. This isn’t a “just make it work” demo, but a production-grade audio engineering template approaching long-term maintainability.

CircuitPro: Native macOS PCB Design Tool

This is a domain rarely explored by macOS native apps: PCB design. CircuitPro is a PCB EDA tool for macOS, aiming to make schematic, layout, and component library workflows more aligned with Apple platform conventions. (The project is still in early development stages)

What attracts me most about the project is the custom-built CanvasKit. It’s more like a 2D interaction engine for EDA scenarios rather than just a regular canvas component: the top layer is declarative CanvasView, the middle layer is the state hub CanvasController, and the bottom layer is input routing, render tree, and tool system. More critically, snapping, input handling, and wiring engine are all made into protocol-based pluggable points, allowing schematics and layout to share the same infrastructure while retaining their respective routing rules.

Even if you’re not interested in PCB design itself, CircuitPro is worth attention, especially for its engineering practices in SwiftUI + AppKit hybrid architecture.

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

Share

Xcode 迈入 Agent 时代

网页版

尽管在 Xcode 26 的最初版本中，苹果就已经加入了一定的 AI 辅助编程能力，但当时的体验更像是把 ChatGPT 生硬地嵌入到 IDE 中：功能存在，却彼此割裂。与当时风头正盛的 Cursor 相比，它更像是两个时代的产物。随着 Claude Code 等 AI CLI 工具逐渐成熟，Xcode 更显得步伐迟缓，甚至让不少开发者开始怀疑：在 AI 时代，它是否还能胜任“主力 IDE”的角色。

26.3 版本的到来，几乎没有任何预热，却用实际行动回应了这些质疑。通过集成 Claude Code / Codex，苹果给出的答案很直接：只要策略得当，Xcode 依然是苹果生态中极具潜力的开发环境。这一次，Xcode 并没有简单地塞进一个 CLI 工具面板，而是引入了一套原生的 Xcode Tools（MCP），并配合 Swift 6、SwiftUI、SwiftData 等官方技术文档，形成了高度一致、贴合最新实践的整体体验。即便对于已经熟练使用 CLI + XcodeBuildMCP + 各类 Skills 的开发者而言，这套原生方案依然具备很强的竞争力——尤其是几乎为零的配置成本，这对绝大多数开发者来说意义重大。

更值得注意的是，这次提供的 Xcode Tools 并不只是服务于 Xcode 本身，它们同样可以作为标准 MCP，为其他 AI 工具提供能力支持。这种开放姿态，并不完全符合外界对苹果一贯风格的印象。

当然，站在今天这个时间点，我们还不能断言 Xcode 已经重新回到了第一阵营。但可以肯定的是，26.3 释放了一个非常明确的信号：苹果愿意与主流工具和服务协作，去打造真正符合时代的开发体验。也正因为如此，我对下一阶段的 Siri 抱有更高的期待——很可能在 iOS 27 中，苹果会在现有 Intent 体系之外，为系统和应用提供更多标准化接口，让 AI 更自然地融入整个生态。

Xcode + Agent 只是起点。

Apple + Agent，才是更值得关注的未来。

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

原创

Xcode 26.3 + Claude Agent：模型替换、MCP、Skill 与自适应配置

Xcode 26.3 版本中苹果直接提供了对 Claude Code/Codex 的支持。自此，开发者终于可以在 Xcode 中方便的使用原生 AI Agent 了。 这两天我针对新版本进行了一系列尝试，包括如何使用最新模型、配置 MCPs/Skill/Command、以及编写自适应的 CLAUDE.md。本文以 Claude Code 为例，分享一些文档之外的技巧。

近期推荐

macOS 录屏软件开发实录：从像素抓取到元数据重现

视频正在取代文字成为更受欢迎的表达方式，而好工具是创作的加速器。macOS 录屏软件 ScreenSage Pro 的开发者 Sintone 深度复盘了如何基于 ScreenCaptureKit 和 Metal 实现“录完即剪完”。从解决 SCK -3821 诡异报错，到由 ObservableObject 迁移至 @Observable 优化时间线性能，本文毫无保留地分享了从像素抓取到高性能合成的全过程。

哪种方式判断字符串是否在白名单里最快：Set、Array、Enum、Dictionary 还是 switch?

在 Swift 里，判断一个字符串是否属于某个键集合，可以写成 Set.contains、Array.contains、RawRepresentable enum 的 init?(rawValue:)、switch 多分支，甚至用 Dictionary 来做映射。看起来差别不大，但真要放进性能敏感路径，结果可能并不完全符合直觉。Helge Heß 做了一次简单的基准测试：Set.contains 毫无悬念地领先，其次是 enum(rawValue:)和 Dictionary（两者非常接近）；而很多人下意识会高估的 switch，反而排在 enum 之后，Array.contains 则垫底收场。作为一个小实验，这个结果或许正好可以拿来校准一下我们对 Swift 性能的直觉。

从一次性付费到 Freemium (Migrating an iOS app from Paid up Front to Freemium)

付费下载和免费 + 应用内购买是两种截然不同的商业模式，随着应用发展，开发者可能需要在两者之间转换。Donny Wals 在本文中分享了他将 Practical Core Data 应用从 $4.99 付费下载转为 freemium 的完整经历。文章不仅涵盖了 StoreKit 2 的技术实现细节（购买流程、状态管理、家庭共享），更有价值的是他对商业决策的深入思考：付费门槛虽然能筛选出认真的用户，但也阻挡了大量潜在用户体验产品价值的机会。对于教育类或工具类独立应用，freemium 可能是用户增长和收入之间更好的平衡点。

iOS 应用中的按需资源 (On-demand resources in iOS app)

应用体积一直是开发者需要关注的问题，尤其是在应用包含大量图片、音频或其他资源时。尽管苹果很早就在 iOS 中提供了 On-Demand Resources（ODR）来应对这一挑战，但这一功能的存在感并不强，常被开发者忽略。在本文中，Majid Jabrayilov 系统性地回顾了 ODR 的工作机制与使用方式，包括资源分组、标签管理、下载生命周期，以及与系统缓存策略之间的协作关系。

虽然苹果在推广 Background Assets 作为更现代的方案，但 ODR 在需要即时响应的按需下载、细粒度资源控制等场景下仍有其独特价值。

Observation 四个常见陷阱 (Objectively Better, Observably Trickier)

在全面拥抱 Observation 框架时，开发者需要警惕其工作机制与 Combine 的 @Published 并不相同，简单替换往往会引入隐蔽的问题。Danny Bolella 总结了迁移过程中四个常见陷阱：@State 持有引用类型时的非惰性初始化、嵌套 @Observable 对象导致的更新丢失、数组元素绑定方式的变化，以及与其他属性包装器产生的冲突。文章通过清晰的代码示例逐一给出解决方案，并反复强调一个核心原则：只有视图当前正在访问（调用 getter）的属性发生变化时，才会触发更新。理解并顺应这种“惰性观察”的思维方式，是正确使用 Observation 框架的关键。

在 macOS 应用中实现 Open Recent 菜单 (Add an Open Recent Menu to a SwiftUI app)

“Open Recent” 是 macOS 应用的标准功能，但对于 SwiftUI 开发者来说，正确实现这个功能并不直观。在本文中，Mark Szymczyk 通过一个简洁的示例，展示了如何利用 NSDocumentController 为应用接入系统级的最近文件管理能力：自动维护列表、更新菜单，以及与文档生命周期的无缝协作。对于文档型或工具类应用，这是一个低成本、却能明显提升“原生感”的细节优化。

工具

Radioform：一个原生、开源的 macOS 音频均衡器

macOS 一直缺少系统级的音频均衡器，由 Matthew Porteous 开发的 Radioform 填补了这个空白。该项目采用 SwiftUI 菜单栏 App + Swift Host + CoreAudio HAL Driver + C++ DSP 的分层架构，把 UI 与实时音频处理彻底解耦。DSP 部分实现了 10 段参数 EQ、参数平滑、限幅与实时安全控制；工程上也有完整 CI、签名公证与 DMG 发布流程。不是“能跑就行”的 Demo，而是接近可长期维护的生产级音频工程样板。

CircuitPro：macOS 原生的 PCB 设计工具

这是一个 macOS 原生应用较少涉足的领域：PCB 设计。CircuitPro 是一款面向 macOS 的 PCB EDA 工具，目标是把原理图、布局与元件库流程做成更符合 Apple 平台习惯的体验。（项目仍处于早期开发阶段）

项目里最吸引我的是自研的 CanvasKit。它更像一个面向 EDA 场景的 2D 交互引擎，而不只是普通画布组件：上层是声明式 CanvasView，中层是状态中枢 CanvasController，底层是输入路由、渲染树与工具系统。更关键的是，吸附、输入处理、连线引擎都被做成了协议化插拔点，让原理图和布局共享同一基础设施，同时保留各自的路由规则。

即便你对 PCB 设计本身不感兴趣，CircuitPro 也很值得关注，尤其是它在 SwiftUI + AppKit 融合架构上的工程实践。

求贤

了解二次元的 iOS 工程师

本公司是二次元文生图头部企业（总部新加坡），招聘岗位为大陆全职 remote。求职者需要了解二次元文化，懂得二次元用语（黑话）。

岗位职责 (Responsibilities):

• 我们正在寻找一位经验丰富的 iOS 工程师（中高级），负责主导我们 iOS 应用的开发与优化工作。

• 理想的候选人应具备深厚的 Swift 技术功底，出色的测试与团队协作能力，并拥有现代 iOS 架构及工具链的实战经验。

任职要求 (Requirements):

• 3 年以上 iOS 开发经验，主要使用 Swift，同时具备一定的 Objective-C 代码维护能力。

• 至少 1 年的 SwiftUI 和 SPM (Swift Package Manager) 实战经验，熟悉其生态系统及最佳实践。

• 熟悉 iOS 15+ 新特性，能够针对不同的 iOS 版本和设备屏幕尺寸进行适配及性能优化。

• 掌握单元测试和 UI 自动化测试 (XCTest, XCUITest)，有能力编写可维护的代码，以确保项目的稳定性和可扩展性。

• 精通 Git 工作流（Git Flow, 主干开发/Trunk-Based Development），并具备基本的代码审查 (Code Review) 技能。

• 理解基础的 iOS 应用模块化设计、多种单页面架构模式以及性能优化方法，并具备在项目中落地的能力。

加分项/优先考虑 (We will give priority to who):

• 拥有跨平台开发经验（满足以下任意一项即可）：

  • 6 个月以上的任意前端技术栈经验 (TypeScript/JavaScript, React, React Native)。

  • 6 个月以上使用 Kotlin 及相关框架的 Android 开发经验。

  • 6 个月以上的任意后端开发框架经验。

• 拥有至少 6 个月的 iOS 基础设施工具或框架搭建经验，包括代码质量提升（Linting, 静态分析, CI/CD）、效率优化（模块化，Gradle 组件化*）、以及性能调优（启动速度、帧率、离线模式、多线程）。

• 拥有 1 年以上 SDK 开发经验，包括通用库开发，如图片加载库 (SDWebImage, Kingfisher)、富文本编辑器、网络层或持久化层 (SQLite, Realm, Core Data)。

• 具备 UI/UX 相关经验：

  • 熟悉 Apple 人机交互指南 (HIG)，能够在理解跨平台设计差异的同时，实现符合 Apple 设计标准的 UI。

  • 拥有扎实的动画和交互动效开发经验，熟悉 Core Animation, UIKit Dynamics 等。

  • 有深色模式 (Dark Mode) 及主题切换功能的开发经验。

• 具备极强的审美感知力，拥有绘画、摄影或设计相关的技能或爱好（附带作品集者优先）。

• 拥有完整的 App 生命周期经验：曾独立开发、发布并维护过支持多国/多语言的 iOS 应用。

• 积极参与技术社区，例如：

  • 具有主动学习和分享的心态，有进行技术演讲的经验。

  • 有技术写作经验（博客、文章）。

  • 有开源项目贡献经历。

• 有使用 AI 编程工具的经验，如 Claude, ChatGPT, GitHub Copilot, Cursor 或 Windsurf。

• 具备流利的英语沟通能力或持有日语 N2 证书。

联系人

xx2bab@gmail.com

Shifting Light, Unchanging Haystacks

Read on web →

Two weeks ago, taking the opportunity of attending iOS Conf SG 2026, I visited the National Gallery Singapore and had the pleasure of viewing the special exhibition “Into the Modern: Impressionism from the Museum of Fine Arts, Boston”. Although I have seen many excellent exhibitions in the past, this experience resonated with me in a distinct and unexpected way.

The National Gallery Singapore is formed by merging two historically significant national monuments—the former Supreme Court and the City Hall. Architects connected these two classical structures with a minimalist metal and glass roof, creating a striking sense of place architecturally: history and modernity intertwined within the same physical space. The ongoing exhibition “Into the Modern”, which features over one hundred original works by masters such as Monet, Renoir, Manet, Cézanne, and Degas, elevates this cross-temporal dialogue to the realm of art.

The exhibition does not simply follow a chronological timeline; instead, it uses “modernity” as its core narrative thread, unfolding layer by layer through themes like “Cities and Change”, “Light and Moments,” and “Class and Leisure”. Although the “modern” here refers to the late 19th century, the urban renewal of Paris, the evolution of lighting techniques, and the rise of new forms of leisure depicted in the paintings all demonstrate, from multiple dimensions, the rhythm of social progress in that era. In this space where time and geography cross, the exhibition goes far beyond the mere level of “viewing art.” For someone like me, who is swept along daily by the torrent of “new tech” information on social media, this was a rare moment of tranquility and introspection.

Returning to reality, in just the past few days, the names of the hottest AI projects have shifted from Clawdbot to Moltbot, and then rapidly evolved into OpenClaw. From a microscopic perspective, we seem to be living in an era of change measured in minutes and seconds. However, if we were to look back at the current AI fever from a longer time scale years from now, we might discover that the world did not undergo the radical, fundamental mutations that we perceive while caught in the current.

Immersed in this environment, it is inevitable that we feel excitement—or even anxiety—over the endless stream of new technologies and tools. Perhaps, beyond these emotions, what we need is a deeper sense of grounding. History repeatedly reminds us that any “high tech” has its temporal limitations. Just as Monet repeatedly depicted the same haystack under different times and lighting conditions: the painting techniques may evolve, but the core object remains unchanged. What truly changes is often the way of seeing, the depth of understanding, and the creator’s own state of mind.

When facing the “present and future”, perhaps we can afford to be less frantic in our pursuit of change, and more composed in our contemplation of the moment.

Previous Issue｜Newsletter Archive

This Week’s Sponsor

Need to debug HTTPS on your iPhone?

Try Proxyman! The best-in-class macOS that helps you capture/debug HTTP(s) with a few clicks. Support iOS devices and Simulator.

🚀 Get Started Now →

Recent Recommendations

DebugReplaceableView and Swift 6.2’s Multiple Type Erasers

You may still find Xcode Previews less than ideal, but Apple has been actively optimizing this experience over the past few years with notable progress. Starting with Xcode 16, views are automatically converted to AnyView via @_typeEraser in preview and debug modes to provide richer debugging information. From Xcode 26 onwards, the enhanced @_typeErasernow supports multiple type erasers, converting views to DebugReplaceableView on macOS/iOS 26+ platforms. This enables hot-swapping of views without rebuilding the entire view hierarchy, further improving preview performance. In this article, Kyle Ye dives deep into the compiler source code to analyze the implementation, explaining how the compiler automatically selects the appropriate type eraser based on platform availability.

Tiered Caching in Swift

When you need to balance performance, memory footprint, and data consistency simultaneously, a single caching strategy often falls short. In this article, Kyle Browning provides a practical guide to implementing tiered caching in Swift: organizing memory and disk caches into a clear hierarchical structure, combined with flexible cache policies (such as cacheThenFetch, cacheElseFetch, etc.) to enable data to flow smoothly between different access cost tiers.

SwiftUI: Realtime, Multi-User Content Collaboration With CloudFlare +YJS-Swift

Despite the availability of numerous services and frameworks, implementing real-time collaborative editing remains a significant engineering challenge. In this article, Itsuki demonstrates how to build a low-cost, scalable, multi-user real-time collaborative content editing system in SwiftUI using Cloudflare Durable Objects + WebSocket Hibernation API + YJS-Swift.

Particularly noteworthy is the author’s detailed explanation of how to properly maintain text cursor and selection positions when receiving remote content updates in SwiftUI—this is closely aligned with real-world product development and clearly represents hard-won experience from actual implementation.

Swift Actors: 6 pitfalls that will catch even experienced developers

Actors are one of the most important—and most easily misunderstood—features in Swift’s concurrency model. Reality, however, is far more complex than it appears. In this article, Rafał Dubiel summarizes 6 Actor pitfalls that even experienced developers commonly encounter: state inconsistency caused by reentrancy, the performance cost of Actor hopping, thread-safety vulnerabilities when @MainActor interacts with Objective-C callbacks, the risks of misusing @unchecked Sendable, misconceptions about nonisolated, and the counterintuitive fact that Actors don’t guarantee execution order.

Rafał doesn’t stop at conceptual warnings—he explains through concrete scenarios why these issues genuinely exist and why they’re so easy to overlook.

Designing a Scalable App-Wide Theming System in SwiftUI

Implementing app-wide theming in SwiftUI may seem like a simple “style management” problem, but it easily touches on deeper design decisions involving state propagation, dependency injection, and view refresh boundaries. Sagar Unagarapproaches this from a real-world requirement, demonstrating a comprehensive theming system design based on SwiftUI’s Environment: using EnvironmentKey to make themes accessible like built-in environment values, and replacing scattered hardcoded values with semantic Design Tokens.

Sagar’s focus isn’t just on “how to do it,” but on “which approach is more maintainable in the long run”—this solution doesn’t depend on any specific library, with its core philosophy being “semantic + reactive,” easily extensible to fonts, spacing, corner radius, and other design elements.

Call Once

“Ensuring a closure executes only once” sounds like a basic requirement, but in real systems, it’s often not as simple as adding a boolean flag. In this article, Paul Samuels demonstrates how to encapsulate this behavior using @propertyWrapper, progressively evolving the solution: from a basic version supporting only () -> Void, to introducing generics for return values, and finally leveraging Swift’s Parameter Packs (each Argument) to support arbitrary function signatures.

This is a thought-provoking article whose value lies not only in the final CallOnce implementation, but in demonstrating how to progressively combine multiple Swift language features to solve a seemingly simple yet representative engineering problem.

Tools

SwiftUI-Agent-Skill: Making AI Write More Reliable SwiftUI Code

If you’re using AI coding assistants (like Claude Code, Cursor, or Codex), you’ve likely encountered this problem: AI-generated SwiftUI code uses deprecated APIs, or deviates from best practices in state management and view organization—even when you’ve repeatedly emphasized these requirements in your base rules.

SwiftUI-Agent-Skill, released by Antoine van der Lee, is designed to bridge this “last mile” gap. It provides AI tools with expert-level SwiftUI guidance covering state management trade-offs, modern API replacements, performance and maintainability checks, and iOS 26+ Liquid Glass usage boundaries—turning “the places where SwiftUI code most commonly goes wrong” into a reusable, executable review workflow.

In addition to this skill, Antoine also provides skills for Swift Concurrency and Core Data.

I recommend that developers don’t just configure these into their AI environment and call it done—these skill documents themselves are structured summaries of practical experience in specific domains. Reading through them carefully benefits not just your AI, but elevates your own understanding as well.

PierreDiffsSwift: Render Beautiful Code Diff Views in macOS Apps

PierreDiffsSwift, developed by James Rochabrun, helps developers render beautiful, syntax-highlighted code diff views in macOS applications.

The library provides an out-of-the-box solution: built on the @pierre/diffs JavaScript library, wrapped into SwiftUI-native views via WKWebView, supporting syntax highlighting for 40+ languages, Split/Unified view modes, inline word-level change highlighting, and automatic dark/light theme switching.

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

Share

变幻的光影，不变的干草堆

网页版

两周前，借着参加 iOS Conf SG 2026 的契机，我造访了新加坡国立美术馆，并有幸参观了《走进现代：波士顿美术博物馆印象派大师展》。尽管此前也看过不少优秀的展览，但这次经历仍带来了某种不同寻常的触动。

新加坡国立美术馆由两座极具历史分量的国家古迹——前最高法院与前市政厅——合并而成。设计师以极简的金属与玻璃屋顶将两座古典建筑连接在一起，在建筑层面便营造出一种强烈的临场感：历史与现代在同一物理空间中彼此交织。而正在展出的特展《Into the Modern》，汇集了莫奈、雷诺阿、马奈、塞尚、德加等 25 位大师的一百余幅原作，则将这种跨越时间的对话进一步推向了艺术层面。

展览并未简单依循时间线展开，而是以“现代性”为核心叙事线索，通过“城市与变革”“光影与瞬间”“阶级与休闲”等主题层层铺陈。尽管这里的“现代”指向的是 19 世纪末，但画作中所呈现的巴黎城市改造、光影技法的演变，以及新兴休闲与娱乐方式的兴起，无不从多个维度展现了那个时代社会前行的节奏。在这样一个时空交错的场域中，展览早已超越了单纯“观看艺术品”的层次。对于每天都被社交媒体时间线中海量“新技术”信息裹挟的我而言，这无疑是一段难得的平静与反思时刻。

回到现实，仅仅在过去的几天里，大热 AI 项目的名字就从 Clawdbot 变成 Moltbot，又迅速演化为 OpenClaw。从微观视角看，我们仿佛正身处一个以分秒计量的变革时代；但若在若干年后，从更长的时间尺度重新审视当下的 AI 热潮，或许会发现，世界并未如洪流之中的我们所感知的那样，发生着本质上的突变。

身处其中，我们难免会因层出不穷的新技术、新工具而兴奋，甚至焦虑。或许，在这种情绪之外，更需要一种更深层的定力。历史反复提醒我们，任何“高技术”都具有其时间局限性。正如莫奈在不同时间、不同光线下反复描绘同一座干草堆：绘画技法在变化，但核心对象始终未变；真正发生变化的，往往是观看方式、理解层次与创作者自身的心境。

在面对“现在与未来”时，也许我们可以少一些追逐变革的慌张，多一些凝视瞬间的从容。

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

本期赞助

调试 iOS 网络请求总是被证书配置难住？

Proxyman 是一款为 iOS 开发者打造的现代 HTTP 抓包工具。支持 SSL 代理、GraphQL、WebSocket 及强大的脚本注入功能。告别笨重的传统工具，体验专为 macOS 优化的极致调试效率。

🚀 立即试用 →

近期推荐

SwiftUI 调试背后的多重类型擦除机制 (DebugReplaceableView and Swift 6.2’s Multiple Type Erasers)

或许你可能对 Xcode 的 Preview 仍不甚满意，但其实在过去几年间，苹果一直在这方面积极地进行着优化工作，并且取得了不少的进展。比如，从 Xcode 16 开始，便在预览和调试模式下，通过 @_typeEraser 自动将视图转换为 AnyView 以增加更多的调试信息。而从 Xcode 26 开始，通过增强 @_typeEraser 使其支持多重类型擦除器，在 macOS/iOS 26+ 平台上将视图转换成 DebugReplaceableView，实现视图的热替换而无需重建整个视图层级，进一步改善预览性能。在本文中，Kyle Ye 从编译器源码层面深入剖析了这一机制的实现原理，解释了编译器如何根据平台可用性自动选择合适的类型擦除器。

Swift 中的分层缓存设计 (Tiered Caching in Swift)

在需要同时兼顾性能、内存占用与数据一致性的场景中，单一缓存策略往往很快就会捉襟见肘。这篇文章中，Kyle Browning 以实践视角系统介绍了分层缓存（Tiered Caching）在 Swift 中的实现思路：通过将内存缓存与磁盘缓存组织成清晰的层级结构，配合灵活的缓存策略（如 cacheThenFetch、cacheElseFetch 等），让数据在不同访问成本之间有序流动。

基于 Cloudflare 的 SwiftUI 实时协作编辑实践 (SwiftUI: Realtime, Multi-User Content Collaboration With CloudFlare +YJS-Swift)

尽管市面上已经存在不少现成的服务与框架，实时协作编辑在工程层面依然是一道不低的门槛。本文中，Itsuki 系统性地展示了如何在 SwiftUI 中，借助 Cloudflare Durable Objects + WebSocket Hibernation API + YJS-Swift，构建一个低成本、可扩展、支持多用户实时协作的内容编辑系统。

尤其值得一提的是，作者详细分享了在 SwiftUI 接收远程内容更新时，如何正确维护文本光标与选区位置的处理技巧——这一部分非常贴近真实产品开发，明显属于“踩过坑之后才会写出来”的经验。

Swift Actor 的 6 个常见陷阱 (Swift Actors: 6 pitfalls that will catch even experienced developers)

Actor 是 Swift 并发模型中最重要、也最容易被“想当然”使用的语言特性之一，然而现实远比这复杂。Rafał Dubiel 在本文中总结了 6 个即使是资深开发者也常踩的 Actor 陷阱：可重入性导致的状态不一致、Actor Hopping 的性能代价、@MainActor 与 Objective-C 回调交互时的线程安全漏洞、@unchecked Sendable 的滥用风险、nonisolated 的误解，以及 Actor 并不保证执行顺序这一反直觉的事实。

Rafał 并未停留在概念层面的提醒，而是结合具体场景解释这些问题为何真实存在、又为何容易被忽视。

SwiftUI 全局主题系统的可扩展设计 (Designing a Scalable App-Wide Theming System in SwiftUI)

在 SwiftUI 中实现全局主题（Theming），看似是个“样式管理”问题，实则很容易牵扯到状态传播、依赖注入以及视图刷新边界等更深层的设计选择。Sagar Unagar 从一个现实需求出发，系统展示了一套基于 SwiftUI Environment 的全局主题系统设计：通过 EnvironmentKey 让主题像内置环境值一样访问，以语义化的 Design Tokens 取代散落各处的硬编码值。

Sagar 关注的并不仅是“如何做”，而是“哪种方式在长期更可控”——这套方案不依赖特定库，核心思想是“语义化 + 响应式”，可以轻松扩展到字体、间距、圆角等设计要素。

在 Swift 中实现“只执行一次”的优雅方式 (Call Once)

“确保闭包只执行一次”听起来像是一个再基础不过的需求，但在真实系统里，这往往并不只是加一个布尔值那么简单。Paul Samuels 在本文中展示了如何用 @propertyWrapper 封装这一行为，并逐步演进：从只支持 () -> Void 的基础版本，到引入泛型支持返回值，最终借助 Swift 的 Parameter Packs（each Argument）实现对任意函数签名的支持。

这是一篇偏思考型的文章，其价值不仅在于最终的 CallOnce 实现，更在于展示了如何将多个 Swift 语言特性逐步组合起来，解决一个看似简单却颇具代表性的工程问题。

工具

SwiftUI-Agent-Skill：让 AI 写出更“靠谱”的 SwiftUI 代码

如果你正在使用 AI 编程助手（如 Claude Code、Cursor、Codex），很可能遇到过类似的问题：AI 生成的 SwiftUI 代码使用了过时的 API，或在状态管理、视图组织上偏离最佳实践——即便你已经在基础规则中反复强调过这些要求。

Antoine van der Lee 发布的 SwiftUI-Agent-Skill，正是为了解决这一“最后一公里”的落差。它为 AI 工具提供了一套专家级的 SwiftUI 指导规范，涵盖状态管理取舍、现代 API 替换、性能与可维护性检查，以及 iOS 26+ 的 Liquid Glass 使用边界等内容，把“SwiftUI 最容易写歪的地方”整理成可复用、可执行的审查流程。

除了这套 skill 外，Antoine 还提供了面向 Swift Concurrency 和 Core Data 的 skill。

我建议开发者不要只是把它们简单配置进 AI 环境中就结束了——这些 skill 文档本身就是对某一领域实践经验的结构化总结。认真读一遍，受益的不只是 AI，你自己也会随之进阶。

PierreDiffsSwift：在 macOS 应用中渲染精美的代码 Diff 视图

James Rochabrun 开发的 PierreDiffsSwift，帮助开发者在 macOS 应用中渲染漂亮的、带语法高亮的代码 Diff 视图。

该库提供了一个开箱即用的解决方案：基于 @pierre/diffs JavaScript 库，通过 WKWebView 封装成 SwiftUI 原生视图，支持 40+ 种语言的语法高亮、Split/Unified 两种视图模式、行内单词级变更高亮，以及深色/浅色主题自动切换。

Skip Goes Open Source: A High-Stakes Bet from “Selling Tools” to “Selling Trust”

Read on web →

Just two months after announcing that the Fuse edition would be free for indie developers, Skip Tools made another bold move: making its core engine, skipstone, completely free and open source. This decision marks a fundamental shift in Skip’s business model—from selling a product to relying on services and community sponsorships. The change reflects both the pressure of an underperforming commercial strategy and the team’s willingness to take risks. In an era dominated by AI and a largely entrenched developer tooling landscape, Skip chose to actively pivot rather than stand still.

Many technically strong and distinctive products fail to gain traction not because of their technology, but because of a lack of trust. As Skip itself points out, companies fear a “rug pull”: if the vendor shuts down or gets acquired, the products and tech stacks built on top of that tool may need to be rebuilt from scratch. By going open source, Skip aims to eliminate this trust barrier—placing itself on equal footing with other cross-platform tools, while also activating the community to help grow the ecosystem.

That said, while the community has largely praised Skip’s open-source decision, concerns remain. After giving up license keys as a stable revenue stream, can sponsorship alone sustain long-term development? History shows that while some open-source business models succeed, many do not. This concern is hardly unfounded. At the time of writing this issue—just days after the open-source announcement—discussion on social media was lively, yet Skip had only a handful of individual sponsors on GitHub. The gap between enthusiastic conversation and real financial support appears wider than expected. This may also explain why Skip ultimately chose to go open source: if developers cannot be convinced to pay for the tool, at least they might be persuaded to use it.

An interesting shift has emerged amid this mix of optimism and anxiety. The conversation has quietly moved from “Why pay for Skip instead of using free KMP?” to “Do you prefer writing Swift or Kotlin?” This change is significant. It suggests that Skip has successfully reframed the competition—from a debate over business models to one centered on language ecosystems. In doing so, the competitive arena expands from a single company to the entire Swift community. In this language-level contest, Skip has—perhaps intentionally, perhaps not—repositioned itself from a central protagonist to underlying infrastructure.

From the beginning, Skip was driven by the belief that there was a real commercial opportunity with sufficient returns. Without such expectations, it is unlikely that either the company or the community alone could have pushed Swift forward on non-Apple platforms so quickly. This path closely resembles how The Browser Company aggressively promoted Swift on Windows in pursuit of building the Arc browser.

As a Swift developer, I sincerely hope this pivot delivers the results Skip is aiming for. Open source is both an experiment in trust and an investment in the ecosystem. If you, too, hope to see Swift thrive beyond iOS, consider starting by becoming a individual sponsor ($10/month). This is not just support for Skip—it is a vote for the broader Swift cross-platform ecosystem. How far open-source Skip can go ultimately depends on how many people are willing to move from being observers to active participants.

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

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

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Original

isolated(any) and #isolation: Letting Swift Closures Automatically Inherit Isolation

Swift 6 introduces many new features and keywords to its concurrency model. While some of them may rarely be used in day-to-day development, lacking an understanding of these concepts can leave you stuck in specific scenarios—even with AI assistance. This article walks through a real concurrency issue encountered during development and testing, demonstrating how @isolated(any) and the #isolation macro can be used to let functions inherit isolation automatically, allowing the compiler to infer the execution context of closures.

Recent Recommendations

A Deep Dive into SwiftData migrations

As apps evolve, changes to data models are almost inevitable, and performing safe data migrations remains a significant challenge for many developers. In this article, Donny Wals provides a comprehensive overview of SwiftData’s migration system, covering everything from basic versioning to complex custom migration strategies. He also shares several particularly valuable recommendations: even a V1 model should be wrapped in a VersionedSchema to prepare for future changes; new schema versions should be introduced only between App Store release cycles, rather than being modified repeatedly during development; and for lightweight migrations, even when SwiftData can handle them automatically, it is still advisable to explicitly define them in a SchemaMigrationPlan to make intentions clearer and easier to test.

One of the highlights of the article is its detailed explanation of when to use willMigrate versus didMigrate in MigrationStage.custom, along with a “bridge version” strategy for handling complex refactors, such as splitting entities.

Why MVVM-C with Coordinators does Scale -> A real-world SwiftUI perspective

Despite the title referencing “MVVM-C,” this is not simply an article defending a specific architectural pattern. Bruno Valente Pimentel redefines what “scalability” really means—arguing that it should not be measured by the number of screens or files, but by how well an architecture supports efficient collaboration and independent feature evolution. As the author puts it, “architecture is not about patterns, but about reducing fear”—the fear of changing code, collaborating with others, and evolving features.

No matter which architecture you prefer, when building SwiftUI apps you should seriously ask yourself: are we leveraging SwiftUI’s strengths, or trying to bend SwiftUI into the shape of UIKit as we know it?

TCA (Composable Architecture): The Honest Review

Following Bruno’s reevaluation of MVVM-C, Chandra Welim offers an objective assessment of another highly debated architecture: TCA. The article summarizes five key strengths of TCA (predictable state management, excellent testability, time-travel debugging, composability, and strong type safety) alongside five major challenges (learning curve, boilerplate, team adoption, overengineering for simple apps, and third-party dependencies). It also provides pragmatic guidance: TCA is a powerful tool, but it is not suitable for every scenario. For simple MVPs or teams without a functional programming background, traditional MVVM may be a more practical choice; for large-scale projects with complex state and a need for time-travel debugging, TCA can offer unmatched control. The core takeaway: TCA is worth it when you truly need it—but most apps don’t.

There is no silver bullet in architecture—only trade-offs in a specific context.

Improving the usability of C libraries in Swift

Although Swift is designed to interoperate with C, calling C APIs directly often results in a poor developer experience—exposing raw pointers, requiring manual memory management, and using naming conventions that feel foreign to Swift. To achieve a more “native” experience, developers often have to write and maintain cumbersome wrapper layers. In this article, Doug Gregor explains how API Notes and Clang Attributes can be used to “guide” the Swift compiler into generating Swift-friendly interfaces without modifying the underlying C library implementation.

The significance of this improvement lies in shifting the cost of “wrapping C libraries” from the logic layer (writing Swift glue code) to the declaration layer (authoring API Notes or adding annotations to headers). This is particularly important for the adoption of Embedded Swift, where existing C libraries are fundamental to the ecosystem. As the toolchain matures, developers may eventually need only a few annotations to use C libraries in Swift as if they were native. The article also provides regex-based automation scripts for generating API Notes in bulk from structured C headers.

Introduction to Building Swift for Yocto

For most iOS developers, Yocto may be unfamiliar, but it is the de facto standard in the embedded Linux world—offering precise control over every component included in a system. As Embedded Swift advances, integrating Swift into the Yocto ecosystem becomes a key challenge. Jesse L. Zamora demonstrates how to build a Swift runtime for Yocto using the recently revived meta-swift layer. Using a Raspberry Pi Zero 2 as an example, the article walks through the entire workflow, from setting up a Docker environment and building Yocto, to flashing the image and running Swift code on the device.

It is worth noting that a full build can take several hours and requires some familiarity with Yocto’s build system. However, the provided meta-swift-examples repository includes a Dockerized environment and one-click scripts that significantly lower the barrier to entry.

meta-swift is the Yocto layer for Swift. It had long been stalled at Swift 5.7, but thanks to community efforts, it now supports Swift 6.1.3.

TIL how to auto-move Xcode DEBUG builds to Applications

When developing apps that include App Intents, you may run into this issue: App Intents only appear in Shortcuts.app when the app is located in the /Applications directory. Since DEBUG builds are placed in DerivedData by default, this makes testing Shortcuts integration difficult. Carlo Zottmann previously relied on complex post-build scripts to move apps around, but in this article he shares a more “native” solution—using just three lines of .xcconfig to have Xcode automatically deploy build artifacts to a specified directory and clean them up properly when builds are removed.

This trick is useful not only for testing App Intents, but for any scenario where DEBUG builds need to live in a specific location.

Visualise anything with SwiftUI Charts

If you needed to build a custom, animated, and interactive circular stress indicator in SwiftUI, how would you approach it—using Shape, or Canvas? In this article, Kyryl Horbushko presents a creative solution by leveraging Swift Charts’ SectorMark to implement the component elegantly and efficiently.

Kyryl’s approach challenges the common assumption that Swift Charts are only suitable for traditional data visualization. For developers building complex dashboards in health or finance apps, this represents a highly instructive “dimensionality reduction” strategy—solving custom UI problems with a data visualization framework, while benefiting from built-in animations and interaction support.

Tools

Commander: A Focused Yet Flexible AI Coding Experience

I enjoy using CLI tools on macOS (such as Claude Code and Codex), but the visual experience of native terminal apps leaves much to be desired, so I usually rely on VS Code extensions to improve the workflow. However, one design choice in VS Code has consistently bothered me: even when the Claude Code panel is maximized, any file modifications made by the AI will still open new editor tabs or windows, disrupting the existing interaction flow.

Marcin Krzyżanowski’s macOS-native app Commander offers a compelling alternative. It provides a more polished interface than the terminal while preserving my “flow”—files are opened only when needed, and system-default apps can be used for viewing. Commander currently supports Claude Code and Codex, includes Git worktrees and code diff features, and is completely free. It occupies a sweet spot between the “focus” of the terminal and the “flexibility” of VS Code.

Oh My Agents: Centrally Managing Configuration for All AI Coding Assistants

With the rise of AI coding assistants like Claude Code, Cursor, Codex, and Windsurf, developers are facing a new challenge: managing scattered prompts, skills, and rules across multiple projects. Each agent has its own configuration format (CLAUDE.md, CURSOR.md, etc.), and manual copying is both inefficient and error-prone. Oh My Agents, created by Wei Wang (onevcat), addresses this problem directly.

Core features:

• Centralized management of all AI agent configurations

• Rule-based distribution with one-click syncing across projects

• Bidirectional sync, allowing project-level improvements to flow back into the central repository

• Change previews to prevent accidental overwrites

Note: Currently macOS-only (Windows/Linux support in progress). Free during the beta period.

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

Share

Skip 开源：从“卖工具”到“卖信任”的豪赌

网页版

在宣布 Fuse 版本对独立开发者免费 仅两个月后，Skip Tools 再次做出惊人之举——全面免费并开源核心引擎 skipstone。这意味着 Skip 彻底改变了经营方式：从“卖产品”转向“卖服务+社区赞助”。这次变化，既有对之前商业模式执行不佳而被迫调整的无奈，也体现了 Skip 团队的果敢——在当前 AI 盛行、开发工具格局固化的背景下，主动求变，力求突破。

很多优秀且有特点的产品没能获得应有的使用量，最大的阻碍往往不是技术，而是“信任”。正如 Skip 官方所言，企业最担心的是“rug pull”——万一公司倒闭或被收购，押注在这个工具上的产品和技术栈将面临推倒重来的风险。Skip 希望通过开源消除这种信任危机，让自己和其他跨平台工具站在同一起跑线上，同时激活社区力量，加速生态建设。

尽管社区对 Skip 的开源决定给予了充分肯定，但也有不少人担心：在放弃了 license key 这一稳定收入来源后，仅靠赞助模式能否支撑持续开发成本？毕竟，成功的开源商业案例虽有，但失败的也不少。这种担忧并非杞人忧天。在我撰写本期周报时（宣布开源数天后），尽管开源消息在社交媒体上引发了热议，但在 GitHub 上，Skip 的个人赞助者仅有十几位。从“热闹的讨论”到“真金白银的支持”，中间的鸿沟似乎比想象中还要深。这或许也解释了为什么 Skip 最终选择了开源——在无法说服开发者”付费使用”时，至少要争取到他们”免费使用”的机会。

一个有趣的现象是，在肯定与忧虑并存的情绪中，讨论的焦点悄然发生了变化：从“为什么要花钱买 Skip 而不是用免费的 KMP?”变成了“你是更喜欢写 Swift 还是 Kotlin?”。这个转变意义重大——它意味着 Skip 已经成功将竞争维度从“商业模式”转移到了“语言生态”，而参与竞争的主体也从“一家小公司”扩展为“整个 Swift 社区”。在这场语言之争中，Skip 聪明地（或许是无意间）将自己的角色从“主角”变成了“基础设施”。

Skip 最早的出发点是看到了一个商业机会，认为有足够的商业回报。如果不是有这样的预期，仅靠官方或社区的力量，Swift 可能无法快速推进在其他平台上的进展。这一路径与 The Browser Company 为了打造 Arc 浏览器而大力推动 Swift 在 Windows 平台上的适配如出一辙。

作为一个 Swift 开发者，我由衷希望 Skip 的这次调整能够取得预期效果。开源是一场信任的实验，也是一次生态的投资。如果你也期待 Swift 能在 iOS 之外的平台上拥有更多可能，不妨从成为一个独立赞助者($10/月)做起——这不仅是对 Skip 的支持，更是对整个 Swift 跨平台生态的投票。开源的 Skip 能走多远，取决于有多少人愿意从旁观者变成参与者。

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

原创

isolated(any) 与 #isolation：让 Swift 闭包自动继承隔离域

Swift 6 为并发引入了许多新功能与关键字。虽然其中不少内容在日常开发中可能鲜少用到，但一旦遭遇特定场景，若对这些新概念缺乏了解，即便有 AI 辅助也可能陷入僵局。本文将通过一个在开发测试中遇到的实际并发问题，来介绍如何利用 @isolated(any) 以及 #isolation 宏，实现函数的隔离域继承，从而让编译器自动推断闭包的运行环境。

近期推荐

SwiftData 数据迁移全解析 (A Deep Dive into SwiftData migrations)

随着应用的发展，数据模型几乎无可避免地会出现变化，如何安全地进行数据迁移对很多开发者来说都是一个不小的挑战。在本文中，Donny Wals 全面讲解了 SwiftData 的数据迁移机制，从基础的版本控制到复杂的自定义迁移策略。其中，Donny 给出了几个特别有价值的建议：即使是 V1 版本也应该使用 VersionedSchema 进行封装，为未来的迁移打好基础；只在 App Store 发布周期之间引入新的 Schema 版本，而不是在开发过程中频繁修改；对于轻量迁移，即使 SwiftData 可以自动完成，也建议显式地写入 SchemaMigrationPlan 中，使意图更加明确且易于测试。

文章的一大亮点是详细解释了 MigrationStage.custom 中 willMigrate 与 didMigrate 的适用场景，并提出了应对复杂重构（例如拆分实体）的“桥接版本（Bridge Version）”策略。

为什么 MVVM-C 在 SwiftUI 项目中依然能扩展 (Why MVVM-C with Coordinators does Scale -> A real-world SwiftUI perspective)

尽管标题中包含“MVVM-C”，但这并非一篇单纯为某种架构模式辩护的文章。Bruno Valente Pimentel 在文中重新定义了“扩展性”的内涵——它不应仅以屏幕或文件的数量来衡量，而应看其是否支持高效的多人协作及功能的独立演进。正如作者所言：“架构无关乎模式，而关乎减少恐惧”——减少修改代码、团队协作以及功能演进时的恐惧。

无论你倾向于哪种架构模式，在用它构建 SwiftUI 项目时，都应该认真思考：我们到底是在利用 SwiftUI 的特性，还是在试图把 SwiftUI 改造成我们熟悉的 UIKit？

TCA 架构的真实评估 (TCA (Composable Architecture): The Honest Review)

继 Bruno 为 MVVM-C “正名”后，Chandra Welim 对另一个极具争议的架构——TCA 进行了客观评估。作者总结了 TCA 的五大优势（可预测的状态管理、优秀的可测试性、时间旅行调试、组合性、强类型安全）和五大挑战（学习曲线、样板代码、团队采纳、对简单应用过度设计、第三方依赖），同时给出了务实的建议：TCA 是一个强大的工具，但绝非适用于所有场景。对于简单的 MVP 或缺乏函数式编程背景的团队，传统的 MVVM 或许是更务实的选择；而对于状态错综复杂、需要“时间旅行”调试的大型项目，TCA 则能提供无与伦比的掌控力。核心结论：TCA 在你需要时很值得，但大多数应用并不需要它。

架构选择没有银弹，只有在特定上下文中的权衡。

让 C 库在 Swift 中“像原生 API 一样好用” (Improving the usability of C libraries in Swift)

Swift 虽然生来就兼容 C，但直接调用 C API 往往体验不佳——开发者通常需要面对裸指针、手动内存管理以及不符合 Swift 命名习惯的函数。为了获得“原生”体验，开发者不得不编写和维护繁琐的 Wrapper 层。在这篇文章中，Doug Gregor 详细介绍了如何利用 API Notes 和 Clang Attributes 机制，在不修改 C 库实现代码的前提下，“指导” Swift 编译器生成符合 Swift 风格的接口。

这项改进的意义在于，它将“封装 C 库”的成本从逻辑层（编写 Swift 胶水代码）转移到了声明层（编写 API Notes 或添加头文件注解）。这对于 Embedded Swift 的普及至关重要，因为嵌入式开发高度依赖现有的 C 库生态。随着工具链的完善，未来开发者可能只需要给 C 库加几个注解，就能直接在 Swift 中像使用原生库一样调用它。文章还提供了基于正则表达式的自动化脚本，可以为结构化的 C 头文件批量生成 API Notes。

在 Yocto 系统中构建 Swift (Introduction to Building Swift for Yocto)

对于大多数 iOS 开发者来说，Yocto 可能比较陌生，但它是嵌入式 Linux 领域的事实标准——它能够精确控制系统中包含的每一个组件。随着 Embedded Swift 的推进，如何在 Yocto 生态中集成 Swift 成为了一个关键问题。Jesse L. Zamora 详细演示了如何使用近期重获更新的 meta-swift 在 Yocto 系统中构建 Swift 运行环境。文章以 Raspberry Pi Zero 2 为例，从 Docker 环境搭建、Yocto 构建、镜像烧录到实际运行，演示了完整的工作流。

需要注意的是，完整构建过程需要数小时，且要求对 Yocto 构建系统有基本了解。不过，文章提供的 meta-swift-examples 仓库已经包含了 Docker 化的构建环境和一键脚本，大大降低了上手门槛。

meta-swift 是 Swift 语言的 Yocto 层，此前曾长期停滞于 Swift 5.7，但在社区的努力下，目前已支持到 Swift 6.1.3。

让 Xcode 的 DEBUG 构建自动部署到 /Applications (TIL how to auto-move Xcode DEBUG builds to Applications)

开发包含 App Intents 的应用时，你可能遇到过这个问题：App Intents 必须在 /Applications 目录下才能在 Shortcuts.app 中显示。这意味着 DEBUG 构建默认放在 DerivedData 中时，开发者无法测试 Shortcuts 集成。 Carlo Zottmann 曾长期使用复杂的 Post-build 脚本来搬运 App，但他在本文中分享了一个更“原生”的方案——通过三行 .xcconfig 配置让 Xcode 自动将构建产物部署到指定目录，并在清理构建时正确删除已部署的文件。

这个技巧不仅适用于 App Intents 测试，也适用于任何需要将 DEBUG 构建放到特定位置的场景。

用 Swift Charts 构建自定义可交互仪表盘 (Visualise anything with SwiftUI Charts)

如果你需要自定义一个可动画、可交互的环形压力仪表盘（Stress Indicator）的 SwiftUI 组件，你会如何进行？是使用 Shape，还是 Canvas？Kyryl Horbushko 在本文中展示了一个非常有创意的解法——利用 Swift Charts 的 SectorMark，优雅且高效地实现了需求。

Kyryl 的实现打破了我们对 Swift Charts 仅用于“数据可视化”的刻板印象。对于需要开发健康类、金融类复杂 Dashboard 的开发者来说，这是一种极具参考价值的”降维打击”式方案——用数据可视化框架解决自定义 UI 问题，既减少代码量，又获得内置的动画和交互支持。

工具

Commander：兼顾专注与灵活的 AI 变成体验

我喜欢在 macOS 上使用 CLI 工具(Claude Code、Codex)，但原生终端应用的视觉体验实在不敢恭维，因此多数情况下我都在 VSCode 中通过插件来改善体验。然而，VSCode 的一个设计始终让我困扰：即便将 Claude Code 的对话栏最大化，AI 修改文件时仍会自动打开新的文件栏或窗口，打断既有的交互节奏。

Marcin Krzyżanowski 开发的 macOS 原生应用 Commander 给了我一个新的选择。它提供了一个比终端更优的交互界面，同时保护了我的“心流”——文件只在需要时才开启，并能调用系统默认应用查看。Commander 目前支持 Claude Code 和 Codex，内置了 Git worktrees 和 Code diff 支持，且完全免费。它在终端的“专注”与 VSCode 的“灵活”之间，构建了一个绝佳的中间地带。

Oh My Agents: 统一管理所有 AI 编程助手的配置

随着 Claude Code、Cursor、Codex、Windsurf 等 AI 编程助手的涌现，开发者面临着一个新问题：如何管理散落在各个项目中的 prompts、skills 和 rules? 每个 Agent 都有自己的配置规范(CLAUDE.md、CURSOR.md...)，手动复制粘贴不仅低效，还容易导致版本混乱。王巍(onevcat) 开发的 Oh My Agents 提供了解决方案。

核心功能:

• 集中管理所有 AI Agent 配置

• 定义分发规则，一键同步到多个项目

• 双向同步，项目改进可拉回中央库并更新所有关联项目

• 预览变更，避免意外覆盖

注：目前仅支持 macOS (Windows/Linux 开发中)，Beta 期间免费。

Building AI Moats: Anthropic’s Crackdown and the Apple-Google Alliance

Read on web →

As 2026 begins, the AI world has already been hit with two blockbuster announcements.

First, Anthropic took drastic measures to ban third-party command-line interfaces (CLIs) and “wrapper” software from accessing personal Claude subscription accounts (Pro/Max). The official intent is clear: to plug the loophole where users were arbitraging low-cost subscriptions against high-value API usage, and to consolidate this efficient coding experience into an exclusive moat for their official tool, Claude Code.

Close on its heels, Apple officially confirmed a deep partnership with Google. Gemini serves as the cornerstone for Siri and Apple Intelligence, handling backend reasoning and logic. This signifies that in Apple’s AI landscape, Google has secured its status as “infrastructure”—thanks to its profound accumulation of cloud computing and TPU computing power—while OpenAI’s role has been repositioned as an optional “premium add-on.”

These two seemingly unrelated events reveal a significant trend for the AI industry in 2026: as the marginal returns on model capability diminish, raw “intelligence” is no longer the sole barrier to entry. Companies are now aggressively constructing their own differentiated moats.

Anthropic has chosen “vertical integration”, cementing model capabilities into an irreplaceable workflow experience by tightly bundling Claude Code with its subscription plans. Google, on the other hand, has won through “economies of scale”, leveraging the extreme cost control and stability of its TPU clusters to secure a ticket to Apple’s billion-user ecosystem.

In 2025, we were still frequently switching subscriptions based on “which model is smarter.” While each service had its merits, they were highly substitutable. Entering 2026, the window for this kind of “homogeneous competition” is rapidly closing.

In the cash-burning race of AI, time is running out for the “good but mediocre” middle ground. Whether you possess extreme cost advantages (like Google) or an exclusive, killer workflow (like Anthropic), you must possess a “trait” that competitors cannot easily replicate.

I currently subscribe to four different AI services. I believe that before the year is out, retaining just two will likely suffice for all my needs.

The main theme of 2026 will no longer be the numbers game of benchmark leaderboards. Instead, it will be about providing a compelling reason for existence that truly resonates with both business and consumer users—whether through price barriers or ultimate user experiences.

Previous Issue｜Newsletter Archive

This Week’s Sponsor

AI moves fast. So should your builds

With build caching, selective testing, and actionable insights, your builds, test runs, and CI workflows fly, so your agents get faster feedback and more reliable results.

See it in action →

Recent Recommendations

Surviving tvOS: An Engineering Log of an Atypical Media Player

Within Apple’s vast hardware ecosystem, Apple TV often occupies a somewhat awkward position: it possesses a stable and loyal user base in the living room context, yet it is rarely a priority target for most developers, with the uncertainty of investment versus return deterring many. Ronnie Wong uses an atypical media player as an entry point to review her real-world experiences during tvOS development—ranging from platform limitations and interaction differences to engineering trade-offs and compromises. This article does not attempt to glamorize tvOS, but rather honestly presents how a developer can make rational choices and “survive” under realistic conditions on this “niche but unique” platform.

@_exported import vs. public import

Swift 6 introduced an inconspicuous yet profound new feature: Access-level modifiers on import declarations. This proposal requires developers to explicitly declare access levels when using import to reduce accidental dependency leaks and avoid “silent pollution” of module interfaces. In this article, Alexander Weiß systematically explains the design intent and usage caveats of this mechanism, focusing on the practical differences between public import and @_exported import in terms of module interface exposure, dependency transitivity, and API design. He explains why the former often does not achieve the “re-export” effect that developers intuitively expect. This has strong practical significance for developers who are building SDKs, Swift Packages, or wishing to clarify module boundaries.

After reading this article, I enabled InternalImportsByDefault in my current project and some third-party libraries, and was immediately greeted by a batch of compilation errors, somewhat reliving the experience of first encountering strict concurrency. However, compared to concurrency-related issues, these errors are usually more intuitive and easier to fix. I suggest you turn this setting on as early as possible to avoid facing larger-scale migration costs when it becomes the official default in the future.

Universal Links At Scale: The Challenges Nobody Talks About

The principles and implementation of Universal Links are not complex in themselves, which often gives the illusion of them being “simple and elegant.” However, once introduced into real-world scenarios involving large-scale applications, multiple domains, complex routing, and long-term evolution, the complexity reveals itself rapidly. In this article, Alberto De Bortoli combines his practical experience in large projects to systematically outline the issues often overlooked when using Universal Links at scale: the maintenance cost of AASA files, the uncertainty of caching and activation timing, risks under multi-environment and multi-team collaboration, and the reality that there is almost no “safety net” for debugging and rollback. Alberto reminds developers that when designing deep link solutions, they must prepare for “scale effects” in advance.

Swift Modules and Code/Assets Duplication

As Swift modularization deepens, resource (CodeAssets) management has gradually become an area that is easily overlooked but can cause actual problems in large-scale projects. Paulo Andrade analyzes the problem of duplicate packaging and volume inflation caused by Swift modules and CodeAssets in multi-module dependency scenarios through specific examples. He explains the underlying build and linking mechanisms and discusses feasible avoidance strategies under the current toolchain. Paulo reminds developers: modularization is not just about the design of APIs and dependency relationships; the boundaries and ownership of resources need to be treated just as seriously.

Crafting document-based apps in SwiftUI

Document-Based Apps are a form of application that is both common yet whose complexity is often underestimated. Compared to ordinary applications, their file lifecycle management, permissions and security scopes, and synergy with the system document browsing experience are unfamiliar to many developers. In this article, Alfonso Tarallo uses SwiftUI as the core to systematically outline the key components required to build document-based apps, including the division of responsibilities between FileDocument and DocumentGroup, and how SwiftUI works in synergy with system file mechanisms.

State of Swift 2026

This is a deep observation and trend analysis surrounding the Swift ecosystem. The article defines 2025 as a “year of transformation” for Swift, detailing the evolutionary path of the concurrency model from “strict” to “approachable,” as well as substantial breakthroughs in server-side (such as the Apple Password Service migration case) and Android development. The author does not shy away from community controversies regarding the architecture of SwiftUI versus AppKit, but objectively analyzes the opportunities and challenges within. Rather than a simple technical list, this article serves more as a strategic report, helping developers see the macro picture of Swift’s metamorphosis from a single “App language” to an all-scenario safe language, beyond daily technical details.

Tools

Axiom: Claude Code Agents for iOS Development

Axiom is a knowledge system of Claude Code Agents and Skills for iOS developers maintained by Charles Wiltgen. It systematically organizes development tasks, troubleshooting processes, and best practices that recur in real-world projects into reusable Skills, Agents, and Commands. It covers multiple directions including Swift 6, SwiftUI, concurrency, data persistence, debugging, accessibility, and Apple Intelligence.

Axiom attempts to answer another question: How to systematically entrust experienced engineering judgment to AI assistants. The author also encourages users to exchange practical experiences and feedback in the axiomdev subreddit.

BibTeXKit: Type-Safe BibTeX Parsing Library

BibTeX files are a text-based bibliographic database format widely used in the LaTeX document system to manage references. By maintaining independent .bib files, users can centrally store and reuse citation metadata, with tools automatically handling citation and formatting during the typesetting stage.

BibTeXKit, developed by Ezequiel Santos, is a BibTeX parsing and modeling library written in Swift with a clear objective: to provide a set of type-safe, scalable BibTeX processing capabilities for Swift projects. It maps entries, fields, and citation relationships in BibTeX files to clear Swift data structures, avoiding the complexity of staying at the string level for repeated parsing and manual processing. It is well-suited as a foundational component for bibliography management tools or research-oriented applications.

MirageKit: High-Performance Streaming and Remote Control Framework for Apple Platforms

MirageKit is a streaming framework dedicated to Apple platforms developed by Ethan Lipnik, aimed at achieving low-latency screen casting and control from macOS to iOS, visionOS, or another Mac.

The framework fully utilizes Apple’s latest system features (requires iOS 26+ / macOS 26+), with a core built on ScreenCaptureKit and Metal. It uses UDP for video streaming and supports AWDL peer-to-peer connections, achieving extremely low latency while ensuring image quality (supports 1:1 virtual display pixel-perfect rendering). Beyond simple screen transmission, MirageKit also enables input reverse control, supporting the forwarding of client-side mouse, keyboard, gestures, and even native menu bar interactions back to the host. For developers looking to build high-performance remote desktops, secondary screen apps, or Vision Pro productivity tools, this is a solution with significant potential.

Please note that MirageKit is still in an early and active stage of development, and breaking changes to the API may occur. The video shown in the tweet is a demonstration of an application Ethan is building based on MirageKit, which is also still under development.

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

Share

从 Anthropic 封杀与苹果谷歌结盟，看 AI 护城河的构建

网页版

2026 年伊始，AI 界便迎来了两记重磅消息。

首先是 Anthropic 痛下杀手，禁止第三方命令行工具（CLI）和“套壳”软件调用 Claude 的个人订阅账号（Pro/Max）。官方意图非常明显：堵住利用低价订阅“薅”高价 API 羊毛的漏洞，并将这种高效的编码体验收归为官方工具 Claude Code 的专属护城河。

紧接着，苹果正式确认与谷歌达成深度合作。Gemini 将成为 Siri 及 Apple Intelligence 后端推理、逻辑处理的主力基石。这意味着，在苹果的 AI 版图中，谷歌凭借其在云计算和 TPU 算力上的深厚积累成为了“基础设施”，而 OpenAI 的角色则被重新定位为可选的“高级插件”。

这两个看似独立的新闻，揭示了 2026 年 AI 行业的一个显著趋势：随着大模型能力的边际效应递减，单纯的“智力”已不再是唯一的壁垒，各家公司正在疯狂构建属于自己的差异化护城河。

Anthropic 选择了“垂直整合”，通过强绑定 Claude Code 与订阅计划，将模型能力固化为不可替代的工作流体验；而谷歌则赢在了“规模效应”，凭借 TPU 集群带来的极致成本控制和稳定性，拿下了苹果这张通往十亿用户的船票。

2025 年，我们还在为“哪个模型更聪明”而频繁切换订阅，各家服务虽各有千秋，但可替代性强。进入 2026 年，这种“同质化竞争”的窗口期已临近关闭。

在烧钱如流水的 AI 赛道，留给“不错但平庸”的中间派的时间已经不多了。无论你是拥有极致的成本优势（如 Google），还是拥有独占的杀手级工作流（如 Anthropic），你必须具备一个竞争对手无法轻易复制的“特质”。

我目前仍有 4 个不同的 AI 服务订阅，我相信不用到年底，留 2 个订阅或许就能满足我的全部需求。

2026 年的主轴将不再是跑分榜上的数字游戏，而是通过价格壁垒或极致体验，提供切实打动 B 端与 C 端的生存理由。

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

本期赞助

AI 速度快，你的构建也应如此

通过构建缓存、选择性测试以及可操作的洞察，让你的构建、测试运行和 CI 工作流飞速运转，让你的 AI 代理获得更快的反馈和更可靠的结果。

立即体验 →

近期推荐

在 tvOS 上活下來：一個非典型播放器的工程實錄

在苹果庞大的硬件生态中，Apple TV 往往处于一个略显尴尬的位置：它在客厅场景中拥有稳定且忠实的用户群，却始终不是多数开发者的优先目标，投入与回报的不确定性也让不少人望而却步。Ronnie Wong 以一款非典型播放器为切入点，回顾了她在 tvOS 开发过程中的真实经历——从平台限制、交互差异，到工程取舍与妥协。这篇文章这篇文章没有试图粉饰 tvOS 开发的痛点，而是如实呈现了在这一“小众但独特”的平台上，开发者如何在现实条件中做出理性选择并“活下来”。

@_exported import vs. public import

Swift 6 引入了一个并不显眼、却影响深远的新特性：Access-level modifiers on import declarations。该提案要求开发者在使用 import 时显式声明访问级别，以减少依赖无意外泄、避免模块接口被“悄然污染”。在本文中，Alexander Weiß 系统讲解了这一机制的设计初衷与使用注意事项，并重点对比了 public import 与 @_exported import 在模块接口暴露、依赖传递以及 API 设计层面的实际差异，解释了为什么前者往往并不能实现开发者直觉中的“重导出”效果。这对于正在构建 SDK、Swift Package，或希望明确模块边界的开发者来说，具有很强的现实指导意义。

我在读完这篇文章后，已经在当前项目以及部分第三方库中启用了 InternalImportsByDefault，并立刻迎来了一批编译错误，多少重温了刚接触严格并发时的体验。不过，相比并发相关的问题，这类错误通常更直观、也更容易修复。建议你尽早开启这一设置，以避免在未来官方默认启用时，集中面对更大规模的迁移成本。

Universal Links at Scale：那些鲜有人提及的规模化挑战 (Universal Links At Scale: The Challenges Nobody Talks About)

Universal Links 的原理和实现本身并不复杂，也因此常常给人一种“简单而优雅”的错觉。但一旦进入大规模应用、多个域名、复杂路由和长期演进的真实场景，其复杂度会迅速显现。在本文中，Alberto De Bortoli 结合自身在大型项目中的实践经验，系统梳理了 Universal Links 在规模化使用时常被忽视的问题：AASA 文件的维护成本、缓存与生效时机的不确定性、多环境与多团队协作下的风险，以及调试与回滚几乎没有“安全网”的现实困境。Alberto 提醒开发者在设计深度链接方案时，必须提前为“规模效应”做好准备。

当模块化遇到资源复制问题 (Swift Modules and Code/Assets Duplication)

随着 Swift 模块化程度的不断加深，资源（CodeAssets）管理逐渐成为一个容易被忽视、却可能在规模化项目中引发实际问题的领域。Paulo Andrade 通过具体示例分析了 Swift 模块与 CodeAssets 在多模块依赖场景下产生重复打包与体积膨胀的问题，解释了其背后的构建与链接机制，并探讨了当前工具链下可行的规避策略。Paulo 提醒开发者：模块化并不仅仅是 API 与依赖关系的设计，资源的边界与归属同样需要被认真对待。

使用 SwiftUI 构建文档型应用 (Crafting document-based apps in SwiftUI)

文档型应用（Document-Based App）是一个既常见、却常被低估复杂度的应用形态。相比普通应用，其文件生命周期管理、权限与安全作用域，以及与系统文档浏览体验的协同方式，对不少开发者而言都较为陌生。 在本文中，Alfonso Tarallo 以 SwiftUI 为核心，系统梳理了构建文档型应用所需的关键组成部分，包括 FileDocument、DocumentGroup 的职责划分，以及 SwiftUI 如何与系统文件机制协同工作。

Swift 2026 生态现状 (State of Swift 2026)

这是一篇围绕 Swift 生态的深度观察与趋势研判。文章将 2025 年定义为 Swift 的“变革之年”，详细梳理了并发模型从“严格”向“平易近人（Approachable）”的演进路径，以及服务端（如 Apple 密码服务迁移案例）与 Android 开发的实质性突破。作者没有回避社区关于 SwiftUI 与 AppKit 的架构争议，而是客观分析了其中的机遇与挑战。相比于单纯的技术清单，本文更像是一份战略报告，帮助开发者在日常代码之外，看清 Swift 正从单一的“App 语言”向全场景安全语言蜕变的宏观图景。

和 ChaoCode 一起学 CS146S

CS146S 是斯坦福大学开设的一门前沿计算机科学课程，全名为 “CS146S: The Modern Software Developer”。该课程的核心理念在于教导学生利用最新的 AI 工具（如 LLMs、Cursor、Claude 等）将开发效率提升 10 倍，从单纯的“代码编写者”转变为“AI 智能体的指挥官”。

如果你对这门课程感兴趣，但面对大量的英文阅读材料和纯文本 Slides 感到枯燥或畏难，那么 ChaoCode (Jane) 刚刚开启的这个“伴读”系列可能正是你需要的。Jane 以“视觉学习者”的视角，通过视频形式记录并分享了这门课程的学习过程。她不仅将原始 Slides 整理成了繁体中文/英文双语版本，补充了原版缺失的讲者注释，还专门维护了一个 Notion 页面 来整合所有的学习资源与作业。这不是一个课程搬运，而是一个“Learning in Public”的最佳实践。

工具

Axiom：面向 iOS 开发的 Claude Code Agent 集合

Axiom 是由 Charles Wiltgen 维护的一套面向 iOS 开发者的 Claude Code Agents 与 Skills 知识体系。它将大量真实项目中反复出现的开发任务、排障流程与最佳实践，系统整理为可复用的 Skills、Agents 与 Commands，覆盖 Swift 6、SwiftUI、并发、数据持久化、调试、可访问性以及 Apple Intelligence 等多个方向。

Axiom 尝试回答另一个问题：如何把经验丰富的工程判断，系统化地交给 AI 助手执行。作者也鼓励使用者在 Reddit 的 axiomdev 板块 中交流实践经验与反馈。

BibTeXKit：类型安全的 BibTeX 解析库

BibTeX 文件是一种基于文本的文献数据库格式，广泛用于 LaTeX 文档体系中管理参考文献。通过维护独立的 .bib 文件，用户可以集中存储并复用文献的元数据，在排版阶段由工具自动完成引用与格式化。

由 Ezequiel Santos 开发的 BibTeXKit 是一个使用 Swift 编写的 BibTeX 解析与建模库，目标非常明确：为 Swift 项目提供一套类型安全、可扩展的 BibTeX 处理能力。它将 BibTeX 文件中的条目、字段与引用关系映射为清晰的 Swift 数据结构，避免了停留在字符串层面反复解析与手工处理所带来的复杂性，更适合作为文献管理类工具或研究型应用的底层组件。

MirageKit：Apple 平台高性能投屏与远程控制框架

MirageKit 是一个由 Ethan Lipnik 开发的 Apple 平台专用流媒体框架，旨在实现 macOS 画面向 iOS、visionOS 或另一台 Mac 的低延迟投屏与控制。

该框架充分利用了 Apple 最新的系统特性（需 iOS 26+ / macOS 26+），核心基于 ScreenCaptureKit 与 Metal 构建，利用 UDP 传输视频流并支持 AWDL 点对点连接，在保证画质（支持 1:1 虚拟显示器像素级渲染）的同时实现了极低的延迟。除了单纯的画面传输，MirageKit 还打通了输入反向控制，支持将客户端的键鼠、手势操作甚至原生菜单栏交互回传至主机。对于想要构建高性能远程桌面、副屏应用或 Vision Pro 生产力工具的开发者来说，这是一个非常有潜力的起步方案。

需要注意的是，MirageKit 目前仍处于 早期且活跃的开发阶段，API 可能会出现破坏性变更。推文 中展示的视频，是 Ethan 基于 MirageKit 构建、仍在开发中的应用演示。

An AT Life Isn’t Necessarily Better Than an MT One

Read on web →

When I learned to drive, I used a manual transmission (MT). At first, my lack of skill often left me flustered, so for my first car, I went straight for an automatic (AT). However, after driving for a few years, I began to crave that sense of total control, so I added a manual car to my collection. Regrettably, as traffic congestion grew worse, the joy of shifting gears was gradually canceled out by exhaustion, and that car eventually sat neglected. It has been nearly twenty years since I seriously drove a manual, but deep down, I still occasionally miss that time when “man and car were one.”

As AI integrates more deeply into my work and life, I feel my existence shifting from MT to AT. Undoubtedly, AI has helped me break through many bottlenecks and brought immense efficiency gains even in familiar fields. But strangely, my sense of wonder about it keeps fading. It seems to have saved me time, yet I haven’t gained the expected satisfaction from this “extra time.” Perhaps my threshold for expectations keeps rising, but the undeniable fact is: I haven’t experienced that simple joy in the process of learning and developing for quite a while.

Fortunately, I rediscovered this long-lost happiness a few days ago. While preparing my Keynote for iOS Conf SG, because the app still relies on relatively “primitive” construction methods for animation—and lacks AI features—I had a rare, uninterrupted block of time to manually experiment and tweak things. Even for a simple parallel animation, I tinkered with great delight, debating between transitions, standard animations, or “Magic Move.” Settings that an expert might finalize in two or three minutes took me half a day of tinkering. Although efficiency was non-existent, I enjoyed every moment. Looking at the final, slightly “crude” effect I’d built, I found myself genuinely moved by what I’d made.

For professionals, efficiency and completeness are certainly hard metrics. But being able to experience the tangible reality in the process is perhaps a fundamental human pursuit.

I probably won’t buy an MT vehicle again, but as long as I can still grip the steering wheel, I won’t let “smart driving” take over completely. The same goes for coding—I fell in love with it because it brought me pure joy. When all our tools push us to be faster and better, I think we should leave ourselves a bit of space to be slower and “dumber”—after all, an AT life isn’t necessarily better than an MT one.

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

Farewell to Portable Assembly: I’ve Been Running Swift on MCUs for Seven Years

Since 2024, Swift has officially provided support for embedded systems, but gaining significant market share in this field still has a long way to go. In fact, as early as 2018, before the official support, Andy Liu and his MadMachine team began exploring and practicing the application of Swift in the embedded field, launching related hardware products along the way. They firmly believe that in increasingly complex development scenarios, Swift’s modern language features will demonstrate tremendous advantages. In this article, Andy shares his journey of exploration in this field over the past few years. I sincerely hope that Swift can showcase its charm in more scenarios.

Building a Base DialSlider Component in SwiftUI

In today’s world where AI capabilities are increasingly powerful, getting AI to help you implement a visual effect has become easier than ever. However, whenever I see developers continuously exploring implementation approaches and refining effects through their own “creative ingenuity”, I still find myself genuinely impressed. In this article recreating a “vintage telephone dial”, codelaby cleverly utilizes SwiftUI’s .compositingGroup() and .blendMode(.destinationOut) to achieve a dynamic “cutout” effect, making static numbers beneath the rotating layer clearly visible—offering more flexibility and native feel compared to simply rotating an image. Additionally, the article provides a thoroughly clear explanation of circular gesture handling, angle calculations (atan2), and stopper logic.

CKSyncEngine Questions and Answers

Many developers have complained about Core Data’s NSPersistentCloudKitContainer, finding it opaque and lacking customizability. However, when they actually try to tackle CloudKit data synchronization themselves, they discover there are far more considerations than imagined, with difficulty far exceeding expectations. Apple’s CKSyncEngine, introduced several years ago, completely broke through this impasse by providing clearer state management and error handling, automatically handling numerous complex edge cases, allowing developers to focus on building data synchronization logic.

Christian Selig shares his experience using the CKSyncEngine API through a Q&A format, detailing how CKSyncEngine serves as a perfect middle layer that retains data storage flexibility (you can continue using SQLite, Realm, or JSON) while taking over the most troublesome synchronization state management.

My Beef with the iOS 26 Tab Bar

SwiftUI’s adjustments to the Tab Bar in iOS 18 have had an impact almost comparable to when NavigationStack/NavigationSplitView replaced NavigationView—not only changing the design language but also having a disruptive effect on application implementation and data flow. The “search tab” feature introduced for iOS 26’s Liquid Glass style further advances this transformation. In this article, Ryan Ashcraft candidly points out numerous issues with the new Tab Bar design: the default floating style appears jarring in certain interfaces and is difficult to coordinate with the overall visual style of applications; new margin and spacing rules break long-standing design conventions, requiring developers to readjust large amounts of existing interfaces; more importantly, these changes have not significantly improved user experience but instead increased adaptation costs.

My biggest impression of the new Tab is that it will significantly impact developers’ decisions regarding minimum system versions when developing applications. Is it worth maintaining two sets of code for Tab? If simplifying implementation forces raising the minimum version to iOS 18, this might be another design intention of the SwiftUI team.

Dia: A Technical Deep Dive into The Browser Company’s macOS Browser

Arc was the first major Windows platform application built using Swift, and The Browser Company has made outstanding contributions to the Swift community’s Windows toolchain. After transitioning from Arc to Dia, the development team has not abandoned Swift, so what development frameworks does Dia specifically use on macOS?

In this article, Everett reveals Dia’s unique technical architecture: this is a native macOS application based on AppKit + SwiftUI, but its core rendering engine is not WebKit—instead, it embeds a self-modified Chromium (ArcCore). Additionally, a large number of local AI-related libraries (such as Apple MLX and LoRA adapters) were discovered in Dia’s binary files, indicating that Dia is not just about “speed” but has already prepared the underlying engineering for on-device AI inference.

Myths about Logitech Developer ID certificate expiration

A few days ago, many macOS users discovered that their Logitech mouse custom buttons had stopped working. Due to control console logs being filled with code signing-related errors, many users and media outlets attributed this to “Apple revoking certificates.” Through analyzing system logs, Jeff Johnson vindicated Apple’s role in this incident: this was not an Apple certificate service failure, but rather a software engineering issue on Logitech’s end. After updating, the Logi Options+ background process failed to pass macOS taskgated code signature validity verification and was directly terminated by the system. This article is not only a failure analysis report but also reminds developers: under macOS’s strict security mechanisms, the signature verification process for application updates cannot tolerate any carelessness.

“If your certificate expires, users can still download, install, and run versions of your Mac applications that were signed with this certificate. However, you’ll need a new certificate to sign updates and new applications.” — Apple Official Documentation

Stop Getting Average Code from Your LLM

Undeniably, in the ocean of information accumulated by humanity over time, high-quality data and information constitute only a minority. For individuals, we can purposefully identify and learn from this quality content. However, due to mechanism limitations, LLMs default to the “average” of their training data, causing the content they generate to appear mediocre in various aspects. In the specific context of Swift development, this often means generating large amounts of outdated, unstructured code.

To obtain high-quality code that conforms to Swift 6 standards or even specific architectural styles, the key is to combat this “regression to the mean” instinct. Krzysztof Zabłocki provides detailed guidance on how to use Few-Shot Prompting and context injection techniques, forcing the LLM to “forget” mediocre default settings by providing specific code examples and architectural specifications, instead generating high-quality code that precisely matches project standards.

Tools

swift-effect: A Type-Driven Approach to Side Effects

Alex Ozun has long focused on type-driven design in Swift, and this library is his practice of “Algebraic Effects + Effect Handlers” in Swift.

swift-effect doesn’t turn side effects into “data structures to be interpreted,” but rather models side effects as interceptable global operations (@Effect), combining and replacing behaviors at runtime through handlers, allowing business code to maintain a linear/procedural style while providing fine-grained control over I/O, concurrency, and other behaviors.

Core highlights:

• Maintains Linear Code: Calling effects like Console.print works like regular functions, but behavior can be dynamically determined by handlers.

• Behavior Testing Without Mocks: Use withTestHandler to intercept/assert effect sequences step by step, testing processes like “interactive scripts.”

• Controllable Concurrency: Supports deterministic testing of Task/AsyncSequence, solving the problem of unstable concurrency ordering.

Codex Skill Manager: A macOS Tool for Multiple CLI Services

Many developers use multiple AI programming services simultaneously. Although they have similar concepts, configurations, and tool types, differences remain in specific settings and detailed descriptions, making it difficult for developers to manage all services uniformly. Thomas Ricouard‘s Codex Skill Manager consolidates skills from Codex, Claude Code (as well as OpenCode and Copilot) in a single UI for viewing, searching, deleting, and importing, avoiding manual searching through multiple hidden directories.

Core Features:

• Local Skills: Scans paths like ~/.codex/skills/public and ~/.claude/skills, displaying lists and details

• Detail Rendering: Markdown view + reference preview

• Remote Skills: Clawdhub search/latest lists, detail fetching and downloading

• Import/Delete/Custom Paths: Supports importing from zip or folders, sidebar deletion, adding custom paths

• Multi-platform Installation Status: Marks installation status for different platforms

Events

LET’S VISION 2026

Born to Create. Powered by AI.

• Speakers • Exhibitors • Partners — now open

• 📍 Shanghai | March 27–29, 2026

Apple ecosystem · AI · Spatial Computing See you in Shanghai.

Let’s shape the future together.

Swift Student Challenge 2026

The annual student challenge returns once again. The challenge provides thousands of student developers with the opportunity to showcase their creativity and programming abilities, allowing them to present their work through App Playground and learn practical skills that will serve them throughout their careers.

This year’s submission period will be open from February 6 to February 28, 2026.

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

Share

AT 的人生未必比 MT 更好

网页版

学车时我开的是手动挡，起初因为技术生疏，常搞得手忙脚乱，所以第一台车就直接选了自动挡。但开了几年，我开始追求那种完全掌控的驾驶感，于是又增购了一台手动挡。遗憾的是，随着交通日益拥堵，换挡的乐趣逐渐被疲惫抵消，最终这台车也被冷落。算起来，我已经快二十年没认真开过手动挡了，但内心深处，我仍会时不时地怀念那段“人车合一”的时光。

随着 AI 深度介入我的工作与生活，我感觉自己的人生正从 MT 转向 AT。毫无疑问，AI 助我突破了许多能力瓶颈，也在熟悉领域带来了巨大的效率提升。但奇怪的是，我对它的“惊叹”却在与日俱减。看似它节省了我的时间，但我并未从这些“多出来的时间”里获得预期的满足感。也许是我对它的期望阈值不断提高，但一个不争的事实是：我已经有一段时间没有在学习和开发过程中，体会到那种单纯的快乐了。

幸好，几天前我又找回了这种久违的开心。在准备 iOS Conf SG 的 Keynote 时，由于 Keynote 在动画构建上相对“原始”且缺乏 AI 辅助，我难得地拥有一段完整的时间，去纯手工地尝试和修改。哪怕只是一个简单的并行动画，究竟是用转场、普通动画还是“神奇移动”，我都玩得不亦乐乎。那些在专家手里可能两三分钟搞定的设置，我折腾了大半天。尽管毫无效率可言，但我乐在其中。看着最终那个略显“简陋”的效果，我竟被自己感动了。

对于职场中人，效率和完成度固然是硬指标；但能否体会到过程带来的“实感”，或许才是作为“人”最朴素的追求。

我大概率不会再买 MT 的车了，但在我还能握紧方向盘的时候，也不会轻易让“智能驾驶”代劳。写代码也是如此，当初爱上它，正是因为它能给我带来纯粹的快乐。当所有工具都在催促我们变得更快更好时，我想应该给自己留一点变慢、变“笨”的空间——毕竟，AT 的人生未必比 MT 更好。

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

近期推荐

告别“可移植汇编”：我已让 Swift 在 MCU 上运行七年

从 2024 年开始，Swift 官方正式提供了对嵌入式系统的支持，但要在这个领域获得显著份额，仍有很长的路要走。其实，早在官方下场之前的 2018 年，Andy Liu 和他的 MadMachine 团队就开始在探索和实践将 Swift 应用于嵌入式领域，并陆续推出了相关硬件。他们坚信，在功能日益复杂的开发场景中，Swift 的现代语言特性将展现出巨大的优势。在本文中，Andy 分享了过去几年中在该领域的探索历程。我真心希望，Swift 能够在更多的场景中，展现其魅力。

在 SwiftUI 中构建基础拨号滑块组件 (Building a Base DialSlider Component in SwiftUI)

在 AI 功能越来越强大的今天，看到一个动效，让 AI 帮你实现已经越来越容易了。但每当看到开发者凭借自己的”奇思妙想”不断探索实现方式并打磨效果时，我仍会由衷赞叹。codelaby 在这篇复刻”老式电话拨号盘”的文章中，巧妙运用 SwiftUI 的 .compositingGroup() 和 .blendMode(.destinationOut) 实现了动态”镂空”效果，使旋转层下的静态数字清晰显现，相比单纯旋转图片更具灵活性和原生质感。此外，文章对环形手势处理、角度计算（atan2）以及限位逻辑（Stopper）的阐述也十分透彻清晰。

CKSyncEngine 答疑与实战经验分享 (CKSyncEngine Questions and Answers)

不少开发者对 Core Data 的 NSPersistentCloudKitContainer 颇有诟病，认为其不透明且缺乏定制性。但真正想自己着手解决 CloudKit 的数据同步问题时，才发现需要考虑的地方实在太多，难度远超想象。苹果在几年前推出的 CKSyncEngine 彻底打破了这个困境，提供了更清晰的状态管理和错误处理，并自动处理了诸多复杂的边缘情况，让开发者可以专心构建数据同步逻辑。

Christian Selig 通过自问自答的方式，分享了他在使用 CKSyncEngine API 时的经验，详细拆解了 CKSyncEngine 如何作为一个完美的中间层，在保留数据存储灵活性（你可以继续用 SQLite、Realm 或 JSON）的同时，接管了最令人头疼的同步状态管理。

我对 iOS 26 Tab Bar 的吐槽 (My Beef with the iOS 26 Tab Bar)

SwiftUI 在 iOS 18 中对 Tab Bar 的调整，其影响几乎堪比当年 NavigationStack/NavigationSplitView 取代 NavigationView，不仅改变了设计语言，对应用的实现方式和数据流走向都产生了颠覆性影响。而为 iOS 26 Liquid Glass 风格引入的”搜索标签”功能进一步推进了这种变革。Ryan Ashcraft 在这篇文章中直言不讳地指出了新 Tab Bar 设计的诸多问题：默认的浮动样式在某些界面中显得突兀，与应用整体视觉风格难以协调；新的边距和间距规则打破了长期以来的设计惯例，让开发者需要重新调整大量现有界面；更重要的是，这些改动并未明显提升用户体验，反而增加了适配成本。

我个人对新 Tab 的最大感受是，它会显著影响开发者在开发应用时对最低系统版本的决策。为 Tab 维护两套代码是否值得？如果为了简化实现而不得不将最低版本提高到 iOS 18，这或许正是 SwiftUI 团队的另一个设计意图？

Dia：深度剖析 The Browser Company 的 macOS 浏览器架构 (Dia: A Technical Deep Dive into The Browser Company’s macOS Browser)

Arc 是第一个使用 Swift 构建的大型 Windows 平台应用，而且 The Browser Company 也因此为 Swift 社区的 Windows 工具链做出了突出贡献。在从 Arc 转型到 Dia 后，开发团队并没有放弃使用 Swift，那么 macOS 端的 Dia 具体使用了哪些开发框架呢？

Everett 在本文中揭示了 Dia 独特的技术架构：这是一个基于 AppKit + SwiftUI 的原生 macOS 应用，但其核心渲染引擎并非 WebKit，而是嵌入了自行修改的 Chromium（ArcCore）。此外，在 Dia 的二进制文件中发现了大量与本地 AI 相关的库（如 Apple MLX 和 LoRA 适配器），这预示着 Dia 并非只是为了”快”，而是已经为设备端 AI 推理做好了底层工程准备。

关于罗技开发者证书过期的迷思 (Myths about Logitech Developer ID certificate expiration)

几天前，不少 macOS 用户发现罗技鼠标的自定义按钮失效。由于控制台日志中充斥着代码签名（Code Signing）相关的报错，不少用户和媒体将其归咎于”苹果撤销了证书”。Jeff Johnson 通过分析系统日志为苹果在本次事件中的角色进行了平反：这并非苹果的证书服务故障，而是罗技自身软件工程问题导致的。Logi Options+ 的后台进程在更新后，未能通过 macOS taskgated 的代码签名有效性验证，从而被系统直接终止。这篇文章不仅是一份故障分析报告，更提醒开发者：在 macOS 严格的安全机制下，应用更新的签名验证流程容不得半点马虎。

“如果你的证书过期了，用户仍然可以下载、安装和运行用该证书签名的 Mac 应用程序版本。但是，你需要一个新的证书来签署更新和新申请。” —— 苹果官方文档

拒绝 LLM 生成的平庸代码 (Stop Getting Average Code from Your LLM)

不可否认，在人类长久以来累积的信息海洋中，高质量的数据与信息只占少数。对于个体来说，我们完全可以有目的地去甄别和学习这些优质内容。但是，受限于机制，LLM 默认倾向于训练数据的“平均值”，这就导致它生成的内容在各个方面都显得比较平庸。具体到 Swift 开发领域，这往往意味着它会生成大量旧版的、非结构化的代码。

要想获得高质量、符合 Swift 6 标准甚至特定架构风格的代码，关键在于对抗这种“回归均值”的本能。Krzysztof Zabłocki 详细介绍了如何利用 Few-Shot Prompting（少样本提示）和上下文注入技术，通过提供具体的代码范例和架构规范，强迫 LLM “忘记”平庸的默认设置，转而生成精准匹配项目标准的高质量代码。

工具

swift-effect: 一种基于类型驱动的副作用处理方案

Alex Ozun 长期关注 Swift 中的 类型驱动设计，这个库是他对“代数效应（Algebraic Effects）+ 处理器（Effect Handlers）”在 Swift 里的实践。
swift-effect 不是把副作用变成“数据结构再解释”，而是将副作用建模为可拦截的全局操作（@Effect），通过 handler 在运行时组合和替换行为，让业务代码保持线性/过程式风格，同时又能精细控制 I/O、并发等行为。

核心亮点：

• 保持代码线性：调用 Console.print 等 effect 就像普通函数，但行为可由 handler 动态决定。

• 无 Mock 的行为测试：用 withTestHandler 逐步拦截/断言 effect 序列，像“交互式脚本”一样测试流程。

• 并发可控：支持对 Task/AsyncSequence 的确定性测试，解决并发顺序不稳定的问题。

Codex Skill Manager: 一款面向众多 CLI 的 macOS 工具

很多开发者都会同时使用多种 AI 编程服务，尽管它们拥有类似的概念、设定和工具类型，但在具体设置和细节描述上仍有差异，这导致开发者很难对所有服务进行统一管理。Thomas Ricouard 开发的 Codex Skill Manager 将 Codex、Claude Code（以及 OpenCode、Copilot）的技能集中在一个 UI 里查看、搜索、删除和导入，避免在多个隐藏目录中手动寻找。

核心功能

• 本地技能：扫描 ~/.codex/skills/public、~/.claude/skills 等路径，展示列表与详情

• 详情渲染：Markdown 视图+引用预览

• 远程 Skill：Clawdhub 搜索/最新列表、详情拉取与下载

• 导入/删除/自定义路径：支持从 zip 或文件夹导入、侧边栏删除、添加自定义路径

• 多平台安装状态：为不同平台标记已安装状态

活动

LET’S VISION 2026｜邀请你与我们同行！

✨ 大会主题：Born to Create, Powered by AI

• 📍 地点：上海漕河泾会议中心

• ⏰ 时间：2026 年 3 月 27 日 - 3 月 29 日

• 🏁 重点：汇聚顶尖创作者与 AI 技术大咖，共同探索 AI 应用的未来边界

• 🌍 官网：letsvision.swiftgg.team

别走开！请关注官方账号和主理人 SwiftSIQI，我们将持续放送更多精彩内容！

Swift Student Challenge 2026

每年一度的学生挑战赛再次登场。挑战赛为数以千计的学生开发者提供了展现创造力和编程能力的机会，让他们可以通过 App Playground 呈现自己的作品，并从中学习在职业生涯中受用的实际技能。

今年作品提交通道将于 2026 年 2 月 6 日至 2 月 28 日开放。

2026: When AI Fades into the Workflow, Are You Ready?

Read on web →

Happy New Year, everyone! Over the past few years, AI has consistently occupied the center stage of the tech world. But looking back from the start of 2026, I’ve noticed a significant shift: since late 2025, the obsession with “trillion-parameter models” and “leaderboard benchmarks” has gradually cooled. In its place is a sober, hands-on focus on the meticulous cultivation of AI Workflows.

If the past two years were characterized by most people experimenting with chatbots, today, AI has shattered the constraints of the chat box. Through CLI tools, MCP (Model Context Protocol), and various Slash commands, Skills, and SubAgents, AI is no longer just an external utility for experienced developers. Instead, it has become like a plugin, permeating every capillary of our terminals, editors, and even the operating system itself.

In this regard, macOS has demonstrated a serendipitous, natural advantage. Leveraging mature automation tools like AppleScript and Shortcuts, even non-developers can grant AI access to their private data without complex API development. This “old tech finding new life” has provided Apple with a new moat in the AI era. If this capability is fully unleashed on iOS through system-level Agents, we may see a profound reshaping of hardware device form factors.

Meanwhile, some manufacturers are taking a more “radical” approach. ByteDance’s Doubao phone attempts to “brute-force” control over everything at the system level by reading the screen and simulating interactions. Huawei, on the other hand, employs an A2A strategy, attempting to build a unified agent scheduling mechanism in the background. Regardless of the path, 2026 marks a singularity for the average consumer: AI is no longer a tool for conversation; it is explicitly or implicitly taking over our digital lives.

As the old saying goes: When a technology is no longer constantly talked about, it means it has truly integrated into our lives, becoming as indispensable as the blood in our veins.

However, the more seamless it becomes, the more vigilant we must be. As AI sinks deep into every detail of our workflows, privacy will become the ultimate luxury. In our pursuit of extreme automation and efficiency, the core challenges of 2026 will be how we choose our service providers, how we balance local versus cloud-based models, and how we preserve that last bit of symbolic “privacy.”

2026 is here. Have you started integrating AI into your workflow?

Previous Issue｜Newsletter Archive

📢 Sponsor Fatbobman’s Swift Weekly

Promote your product to Swift & iOS developers across:

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

Perfect for developer tools, courses, and services.

📢 View Sponsorship Options

Enjoyed this issue? Buy me a coffee ☕️

Recent Recommendations

The Indie Developer’s Trial: Zipic’s Productization Journey from 0 to 1

Zipic is an image compression tool I’ve been using frequently. I’ve personally witnessed how this app evolved from a small workplace necessity into an efficient, refined, and focused successful product through the continuous refinement by its author Shili. Indie developers often operate as a “one-person army,” constantly switching between strategy, design, development, distribution, and promotion. To uncover the story behind this journey, I invited Shili to review Zipic’s entire process from 0 to 1. The complete series consists of three chapters: product design (this article), distribution and sales without relying on the Mac App Store, and technical details review: SwiftUI pain points and performance bottlenecks.

Swift vs. Rust: 5 Surprising Facts Learned from the Ultimate Memory Management Showdown

In the developer community, discussions about Swift and Rust performance never cease. The conventional wisdom is: Swift is relatively slow due to Automatic Reference Counting (ARC), while Rust is renowned for its extreme speed and memory efficiency. However, Snow argues that these simple labels of “fast” and “slow” often obscure the fundamental differences in their design philosophies: Swift prioritizes developer experience and ecosystem compatibility, while Rust pursues ultimate performance and compile-time safety.

Through real-world examples, the article reveals five truths: Rust’s ownership rules are essentially zero-cost compile-time tools; Swift’s real performance burden comes from Objective-C compatibility rather than ARC itself; ARC’s core issue is performance unpredictability; for concurrency safety, Swift relies on runtime protection while Rust achieves compile-time guarantees; and why Swift cannot “become” Rust.

StoreKit Subscriptions: A Practical Guide

Based on years of iOS development experience and real-world cases, Mohammad Azam has written a comprehensive StoreKit subscription practical tutorial. The series covers: choosing monetization models (one-time purchases, subscriptions, consumable purchases, and hybrid strategies), paywall strategy comparison (trade-offs between soft/hard paywalls and subscription trials), onboarding experience design (evolving from static screenshots to an 8-step interactive onboarding that lets users experience core features and build emotional investment before paying), and complete technical implementation (App Store Connect configuration, StoreKit integration, and code examples for product loading and purchase flows).

Skip 2025 Retrospective and 2026 Roadmap

In 2025, with the official release of Swift SDK for Android on swift.org, Skip provided native compilation support through Skip Fuse, unlocking thousands of native Swift packages for use on Android. New dual-platform frameworks were added for NFC, Stripe, PostHog, Auth0, Socket.IO, and more. iOS 26’s introduction of the Liquid Glass interface style became a litmus test for cross-platform frameworks. Skip, by adopting a “fully native” strategy (using native SwiftUI on iOS and mapping to Jetpack Compose on Android), automatically supported the new interface on day one without requiring rewrites or workarounds. In 2026, Skip plans to continue expanding integrated frameworks, optimizing the Skip Fuse toolchain, and improving performance and developer experience.

How to use Claude Code

This is a practical guide compiled by Khoa Pham after months of intensive Claude Code usage. Core tips include detailed application scenarios for various modes, especially how to use Extended Thinking mode judiciously to avoid wasting tokens. It also covers essential keyboard shortcuts, context management techniques, MCP integration, VS Code and Chrome extensions, GitHub Actions integration, Git Worktrees parallel workflows, plugin ecosystem, and prompt best practices. The content is detailed, specific, and targeted—not just a simple feature introduction manual.

App Store Connect API Webhook｜Automate CI/CD Workflows Seamlessly

Apple announced the App Store Connect API Webhook at WWDC 2025, supporting real-time push notifications for build status, app version status, TestFlight feedback, and other events. Zhong Cheng addresses the pain point of traditional polling methods requiring approximately 20 minutes of waiting after build uploads (wasting $1.24 per GitHub Runner instance), providing detailed instructions on applying this capability in CI/CD to achieve zero waiting costs; GitFlow merge-back timing can precisely align with actual app release time; developers can receive timely rejection notifications even with limited permissions.

Setting up Embedded Linux with WendyOS

WendyOS is a Linux distribution designed for embedded devices, written in Swift, aiming to bring the convenience of iOS development to the embedded domain. Joannis Orlandos provides a complete getting-started tutorial in this article: from installing Homebrew and Wendy tools, flashing WendyOS to devices like Raspberry Pi/Jetson Orin Nano, connecting devices via USB, configuring WiFi, creating Swift projects (including wendy.json permission configuration), to using VSCode extensions for remote debugging (supporting breakpoints and state inspection). Suitable as an introductory tutorial for developers wanting to apply Swift to embedded devices or IoT scenarios.

Tools

Fucking Approachable Swift Concurrency

This is a learning resource created by Pedro Piñera, based on Matt Massicotte‘s Swift concurrency concepts, explaining core concepts like async/await, Task, Actor, and Sendable in an approachable way. Pedro uses an “Office Building” scenario to build intuitive mental models: comparing MainActor to a reception desk, actors to department offices, and await to knocking and waiting. Additionally, it provides a Skill.md file suitable for AI tools, allowing developers to directly embed these concurrency practices into their development workflow’s rule engine.

Dimillian’s Skills - iOS/Swift Development AI Agent Skills Collection

A Skills repository for iOS/Swift development created by Thomas Ricouard, containing six AI Agent Skills focused on practical workflows. Covers App Store Changelog generation (automatically generating release notes from git history), iOS Debugger Agent (building/debugging iOS projects using XcodeBuildMCP), Swift Concurrency Expert (fixing Swift 6.2 concurrency issues), SwiftUI Liquid Glass (implementing iOS 26+ Liquid Glass API), SwiftUI View Refactor (refactoring view structure and dependency patterns), and SwiftUI Performance Audit (reviewing performance bottlenecks and providing optimization recommendations).

StoreKit Helper - SwiftUI In-App Purchase Wrapper Library

A lightweight StoreKit 2 wrapper library developed by jaywcjlove, designed specifically for SwiftUI, greatly simplifying in-app purchase implementation. Compared to using the StoreKit 2 API directly, StoreKitHelper reduces approximately 70% of boilerplate code, making it particularly suitable for SwiftUI developers who need to quickly integrate in-app purchases without dealing with underlying complexity.

Core features include: @ObservableObject-based state management, protocol-driven type-safe product definitions, real-time transaction monitoring and automatic state updates, and built-in StoreKitHelperView and StoreKitHelperSelectionView UI components. Interface display can be easily controlled through hasNotPurchased/hasPurchased properties, supporting fluent API configuration for various purchase popup callbacks.

Jobs

macOS Systems Engineer

Photon is building open-source SDKs that let developers bring AI agents to interfaces that 99% of the world already knows how to use - iMessage, WhatsApp, phone calls, Discord, Signal, and more. On top of that, we’re building open-source Agent SDKs focused on interaction - things like multi-part messages, threading, reactions (Tapbacks), etc - so developers and enterprises can ship agents that actually feel human.

We are hiring a macOS Engineer. The ideal profile includes:

• Deep understanding of macOS internals and how system components interact

• Experience with macOS system analysis and debugging

• Hands-on experience working with system-level APIs and low-level mechanisms

• Strong curiosity and passion for exploring the undocumented side of Apple services

• (Optional but a plus) Experience with iMessage, IMAgent, or related messaging infrastructure

We offer competitive compensation (US-based, remote-friendly). Photon is backed by top-tier investors.

Contact: ryan@photon.codes

This is a job posting from Photon, a friend’s startup team. They’re building infrastructure for AI Agents on platforms like iMessage/WhatsApp—it’s an early-stage project. If you’re interested in macOS low-level technologies and early startup opportunities, feel free to check it out.

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

Share

2026：当 AI 隐入工作流，你准备好了吗？

网页版

大家新年好！在过去的几年中，AI 始终占据着科技界最耀眼的 C 位。但站在 2026 年的起点回看，我发现一个显著的转折：从 2025 年末开始，人们对“万亿参数”或“榜单跑分”的狂热逐渐褪去，取而代之的是对 AI 工作流深耕细作的冷静与实战。

如果说过去两年大多数人还在尝试如何与 Chat 机器人聊天，那么现在，AI 已经通过 CLI、MCP 以及各种 Slash、Skill、SubAgent，彻底打破了对话框的限制。对于有经验的开发者来说，AI 已经不再是一个外部工具，而是像插件一样，渗透进终端、编辑器乃至整个操作系统的每一个毛细血管。

在这一点上，macOS 展示了某种“无心插柳”的天然优势。借助 AppleScript 和快捷指令这些成熟的自动化工具，即便不通过复杂的 API 开发，普通用户也能让 AI 访问自己的私有数据。这种“老树发新芽”的现象，让苹果在 AI 时代拥有了新的护城河。而如果这种能力在 iOS 上通过系统级 Agent 完全释放，硬件设备的形态或许将迎来新一轮重塑。

与此同时，某些厂商的策略则更加“激进”。字节跳动的豆包手机尝试从系统底层通过屏幕读取与模拟交互来“暴力”接管一切；华为则通过 A2A（Agent to Agent）策略，试图在后台构建一套统一的代理调度机制。无论路线如何，2026 年对于普通消费者来说都标志着一个奇点的到来：AI 不再是聊天工具，而是显式或隐式地接管了我们的数字生活。

正如那句老话：当一个技术不再被反复提及，才说明它已真正融入生活，如同血液般不可或缺。

然而，越是无感，越要警惕。当 AI 深入工作流的每一个细节，隐私将成为最昂贵的奢侈品。在追求极致自动化与效率的同时，如何选择服务商、如何平衡本地与云端模型、如何保留最后一点象征性的“隐私”，将是我们在 2026 年必须面对的命题。

2026 来了，你开始将 AI 集成到自己的工作流中了吗？

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

近期推荐

独立开发者的试炼：Zipic 从 0 到 1 的产品化之路

Zipic 是我一直在高频使用的图片压缩工具，我亲眼见证了这个应用如何从一个职场工作的小需求，逐渐在作者 十里 的不断打磨下成长为一个高效、精致、专注的成功产品。独立开发者往往意味着“一人成军”，时刻在策略、设计、开发、分发与推广之间来回切换。为了挖掘这背后的故事，我邀请了十里复盘了 Zipic 从 0 到 1 的全过程。全文共分三个篇章：产品设计（本文）、不依赖 Mac App Store 的分发与售卖 以及 技术细节复盘：SwiftUI 痛点与性能瓶颈。

Swift vs. Rust：从内存管理的终极对决中学到的 5 个惊人事实

在开发者社区中，关于 Swift 和 Rust 性能的讨论从未停止。通常的看法是：Swift 因为自动引用计数（ARC）而相对较慢，而 Rust 则以其极致的速度和内存效率著称。但 Snow 认为，这种“快”与“慢”的简单标签往往掩盖了两者在设计哲学上的根本差异：Swift 优先开发体验和生态兼容，Rust 追求极致性能和编译时安全。

结合实际案例，文章揭示了五个真相：Rust 的所有权规则本质上是零开销的编译时工具；Swift 的真正性能包袱来自 Objective-C 兼容性而非 ARC 本身；ARC 的核心问题是性能的不可预测性；并发安全上 Swift 依赖运行时保护而 Rust 实现编译时保证；以及为何 Swift 无法“变成”Rust。

StoreKit 订阅实战指南 (StoreKit Subscriptions: A Practical Guide)

Mohammad Azam 基于多年 iOS 开发经验和真实案例，撰写了完整的 StoreKit 订阅实践教程。系列涵盖：变现模型选择（一次性购买、订阅、消耗型购买及混合策略）、付费墙策略对比（软/硬付费墙及订阅试用的权衡）、引导体验设计（从静态截图演进到 8 步交互式引导，让用户在付费前完成核心功能体验并建立情感投入）、以及完整的技术实现（App Store Connect 配置、StoreKit 集成、产品加载和购买流程的代码示例）。

Skip 2025 回顾与 2026 路线图 (Skip 2025 Retrospective and 2026 Roadmap)

在 2025 年，随着 Swift SDK for Android 在 swift.org 正式发布，Skip 通过 Skip Fuse 提供原生编译支持，解锁了数千个原生 Swift 包在 Android 上的使用。同时新增 NFC、Stripe、PostHog、Auth0、Socket.IO 等双平台框架。iOS 26 推出的 Liquid Glass 界面风格成为跨平台框架的试金石。Skip 因采用“完全原生”策略（iOS 上使用原生 SwiftUI，Android 上映射到 Jetpack Compose）而在第一天就自动支持新界面，无需重写或变通。在 2026 年 Skip 计划继续扩展集成框架、优化 Skip Fuse 工具链、提升性能和开发体验。

如何使用 Claude Code (How to use Claude Code)

这是一份 Khoa Pham 在高强度使用 Claude Code 数月后整理的实战指南。核心技巧包括各种不同模式的详细应用场景，尤其是如何合理使用 Extended Thinking 模式以避免浪费 Token。另外还涵盖了关键快捷键、上下文管理技巧、MCP 集成、VS Code 和 Chrome 扩展、GitHub Actions 集成、Git Worktrees 并行工作流、插件生态以及提示词最佳实践等众多内容。内容详实、具体、有针对性，并非简单的功能介绍手册。

App Store Connect API Webhook 串接｜提升 iOS CI/CD 自动化效率与通知流程

苹果在 WWDC 2025 中发布了 App Store Connect API Webhook，支持构建状态、App 版本状态、TestFlight 反馈等事件的实时推送。Zhong Cheng 针对打包上传后传统 Polling 方式需等待约 20 分钟（GitHub Runner 浪费 $1.24/次）的痛点，详细介绍了如何在 CI/CD 中应用该能力，实现零等待成本；GitFlow 回 master 时机可精确对齐 App 实际发布时间；开发者权限受限时也能及时收到拒审通知。

使用 WendyOS 开发嵌入式 Linux 应用 (Setting up Embedded Linux with WendyOS)

WendyOS 是一个专为嵌入式设备设计的 Linux 发行版，用 Swift 编写，旨在将 iOS 开发的便捷性带到嵌入式领域。Joannis Orlandos 在本文中提供了完整上手教程：从安装 Homebrew 和 Wendy 工具、刷写 WendyOS 到树莓派/Jetson Orin Nano 等设备、通过 USB 连接设备、配置 WiFi、创建 Swift 项目（含 wendy.json 权限配置）到使用 VSCode 扩展进行远程调试（支持断点和状态检查）。适合想将 Swift 应用到嵌入式设备或 IoT 场景的开发者作为入门教程。

工具

Swift 并发：通俗易懂的学习指南 (Fucking Approachable Swift Concurrency)

这是一个由 Pedro Piñera 创建、基于 Matt Massicotte 的 Swift 并发理念整理的学习资源，用通俗易懂的方式解释 async/await、Task、Actor、Sendable 等核心概念。Pedro 通过 “Office Building（办公楼）” 这一场景，将 MainActor 比作前台、actor 比作部门办公室、await 比作敲门等待，帮助开发者建立直观的心智模型。 另外，还提供了一个适用于 AI 工具的 Skill.md 文件，方便开发者将上述并发实践直接嵌入到开发工作流的规则引擎中。

Dimillian’s Skills - iOS/Swift 开发 AI Agent Skills 集合

Thomas Ricouard 创建的用于 iOS/Swift 开发的 Skills 仓库，包含六个专注于实际工作流的 AI Agent Skills。涵盖 App Store Changelog 生成（从 git history 自动生成发布说明）、iOS Debugger Agent（使用 XcodeBuildMCP 构建/调试 iOS 项目）、Swift Concurrency Expert（修复 Swift 6.2 并发问题）、SwiftUI Liquid Glass（实现 iOS 26+ Liquid Glass API）、SwiftUI View Refactor（重构视图结构和依赖模式）、SwiftUI Performance Audit（审查性能瓶颈并提供优化建议）等。

StoreKit Helper - SwiftUI 应用内购买封装库

由jaywcjlove开发的轻量级 StoreKit 2 封装库，专为 SwiftUI 设计，大幅简化应用内购买实现。相比直接使用 StoreKit 2 API，StoreKitHelper 减少了约 70% 的样板代码，特别适合需要快速集成应用内购买且不想处理底层复杂性的 SwiftUI 开发者。

核心特性包括：基于 @ObservableObject 的状态管理、协议驱动的类型安全产品定义、实时交易监听和自动状态更新、内置的 StoreKitHelperView 和 StoreKitHelperSelectionView UI 组件。通过 hasNotPurchased/hasPurchased 属性可以轻松控制界面显示，支持链式 API 配置购买弹窗的各种回调。

求贤

Mac OS 工程师

Photon 正在构建开源基础设施，帮助开发者将 AI Agent 带到人类已经熟悉的交互界面中，例如 iMessage、WhatsApp、电话通话、Discord、Signal 等。在此之上，我们还在打造以交互为核心的开源 Agent SDK，覆盖多段消息处理、消息线程处理、表情/回应（Tapbacks）等能力，让开发者和企业能够开发真正”像人一样”交流的 Agent。

职位要求

我们正在招聘 macOS 工程师，理想的候选人应具备以下条件：

• 对 macOS 内部机制以及系统组件之间的交互有深入理解

• 具备 macOS 系统分析与调试经验

• 熟悉 macOS 系统级 API 及底层机制

• 对探索 Apple 服务中的未知部分有好奇心

• 加分项：有 iMessage、IMAgent 或相关消息基础设施的经验

薪资待遇

我们将提供具有竞争力的薪资（工作地点：美国，支持远程办公）。此外，Photon 获得多家知名投资机构的支持。

联系方式

ryan@photon.codes

这是朋友创业团队 Photon 的招聘。他们在做 AI Agent 在 iMessage/WhatsApp 等平台的基础设施，是个早期项目。如果你对 macOS 底层技术和早期创业机会感兴趣，可以了解一下。

Swift, SwiftUI & SwiftData: A Mature 2025

Read on web →

Over the past few days, I’ve been reflecting on the evolution of Swift, SwiftUI, and SwiftData throughout this year. My overall impression is that while there weren’t many “flashy” surprises, a palpable sense of maturity has quietly emerged.

Undoubtedly, the centerpiece of Swift this year was the continued refinement of the concurrency programming experience. Although the influx of new options and keywords caused its fair share of teething troubles for developers in the short term, after months of debate and practice, the community is finally beginning to consolidate best practices for this new paradigm. I don’t expect the full establishment and widespread adoption of this paradigm to be a simple or swift process. However, in a year or two, the community’s focus will likely shift from concurrency to cross-platform development, marking a brand-new phase for the language.

For SwiftUI, the focus this year was largely centered on adapting to Liquid Glass. Due to initial implementation hurdles at the system level, the visual results were somewhat underwhelming at first. However, since the release of iOS 26.2, both performance and stability have seen significant improvements. To be honest, I am actually quite pleased that SwiftUI didn’t introduce more “revolutionary” features this year. This has given both the framework team and the developers some much-needed breathing room to truly digest the existing framework. At this stage, resolving legacy issues and optimizing performance is far more meaningful than blindly piling on new features.

The trend of “subtle evolution” is most evident in SwiftData. That said, I believe SwiftData’s performance this year is highly commendable—particularly the fact that many improvements and new features were back-ported to earlier OS versions. I only wish it had been in this state when it was first released three years ago. While SwiftData still lacks some key functionalities, it is now more than capable of handling a significant proportion of projects. With this solid foundation, I look forward to its growth in performance and capability over the coming years.

Personally, I am satisfied with the “report card” delivered by the Swift trio in 2025. I wonder, how do you feel about it?

This is the final issue of the year. I want to express my heartfelt gratitude to all of you for your support and readership throughout the year.

Wishing you all a Happy New Year! Happy Coding!

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 ☕️

Event

iOS Conf SG 2026

Next month (January 21–23), iOS Conf SG will take place in Singapore. I’ll be there in person and will be speaking on the topic “Using SwiftUI as a Language”—a talk not just about code, but about a shift in mindset.

If you’ll be nearby or are planning to attend, feel free to come say hi! The organizers have also provided a special discount for my readers: Fatbobman reader-exclusive 10% off link

Recent Recommendations

My Eight Years with CloudKit: From Open Source IceCream to Commercial Apps

I’ve always believed that the so-called Apple ecosystem is shaped by a combination of hardware, software, services, culture, and overall sensibility. Within that ecosystem, CloudKit is undoubtedly a crucial piece. For developers, using CloudKit well not only leads to better user experiences, but also enables innovation at a relatively low cost.

Cai Yue, the creator of IceCream, shares his eight-year journey with CloudKit—from open-sourcing IceCream in 2017 and gaining official recognition from Apple, to applying CloudKit in real-world commercial products such as Music Mate and Setlists. The article takes a deep dive into CloudKit’s core strengths, key limitations, and more advanced usage patterns.

What’s new in Swift: December 2025 Edition

This is a year-end wrap-up article for the Swift community, written by Tim Sneath and Dave Lester. It systematically reviews the major developments across the Swift ecosystem in 2025, spanning language features, platform expansion, and community growth.

The article not only summarizes how Swift 6.2 lowers the barrier to entry for concurrency through more approachable defaults—while continuing to advance C++ interoperability and memory safety—but also highlights sustained investments across Android, WASM, Windows, BSD, embedded systems, and AWS. Together, these efforts reinforce a clear signal: Swift is no longer a language focused solely on Apple platforms.

You may not agree with every change, but in the first year after entering its second decade, Swift has undeniably delivered a solid and substantial body of work.

My PM insisted we switch to SwiftUI for a massive legacy app rewrite. The result is exactly what you’d expect

I came across this post on Reddit a few days ago. The author complains about their PM’s decision to adopt SwiftUI too casually, arguing that it is ill-suited for rewriting a seven-year-old app. I don’t fully agree or disagree with that take—but what really surprised me was the direction of the comments. The overwhelming majority firmly sided with SwiftUI.

Many developers argued that:

• SwiftUI itself is already mature enough; the real issues lie in how it’s implemented

• Migration should be incremental, not a big-bang rewrite

• SwiftUI’s weak spots can be avoided—for example, by keeping UIKit navigation and migrating only the view layer

• Multiple large-scale projects (with over 10 years of history) have already completed successful migrations

This discussion highlights a reality I didn’t quite expect: SwiftUI adoption in production environments is far more widespread than many assume, and developer confidence in SwiftUI is clearly established. By the end of 2025, the claim that “SwiftUI isn’t ready for serious work” may no longer hold up.

As a strong advocate of SwiftUI, I both enjoy working with the framework and remain fully aware that it still has a long road ahead. If you’re still unsure whether SwiftUI is worth investing in, you might want to check out an article I wrote last year, “Common Misconceptions About SwiftUI”. Many of the misconceptions discussed there were echoed—and challenged—in this Reddit discussion.

Non-Sendable First Design

With the arrival of the Swift 6 era, many developers have developed a habit: either make types conform to Sendable, or wrap them in @MainActor or an actor. In this article, Matt Massicotte proposes a highly thought-provoking philosophy: “Non-Sendable First Design.”

The key idea lies in rethinking “isolation.” Isolation is, at its core, a constraint. When a type is marked as @MainActor, it effectively loses the freedom to be accessed synchronously outside of UI contexts. By contrast, a non-isolated, non-Sendable plain type can be far more flexible—it can be owned by any actor and accessed synchronously within that context, while also conforming easily to basic protocols like Equatable, without the complexity of crossing isolation boundaries.

With the introduction of NonisolatedNonsendingByDefault in Swift, this “non-Sendable first” approach is no longer awkward or cumbersome. Instead, its advantages are becoming increasingly apparent: clearer semantics and lower architectural overhead achieved with less isolation. While it won’t fit every scenario, in Swift 6 and beyond it’s a “subtractive” design approach well worth serious consideration.

Resolving Swift Packages faster With Registry from Tuist

Traditional Swift Package Manager dependency resolution is based on Git URLs. Xcode needs to clone entire repositories to retrieve version information and source code, which can be extremely time-consuming for projects with many dependencies (such as Firebase). Registry, on the other hand, is an alternative specification defined by Apple: it downloads archived artifacts for specific versions directly via package identifiers (IDs), bypassing the heavy Git operations.

Tuist recently announced that its Swift Package Registry is now open to all developers. The biggest change is that you no longer need to log in or create a Tuist account to use it.

Lee Young-jun tested the feature and found that dependency resolution (installation) time was reduced to about 35% of the original. However, project generation and build phases didn’t see the same gains, and in some cases even became slightly slower. In GitHub Actions, when combined with caching, dependency installation time for subsequent builds dropped from 53 seconds to 11 seconds—showing that the primary benefits are in CI environments.

Overall, Tuist Registry isn’t a “full pipeline accelerator,” but rather a targeted optimization focused on dependency resolution and cache friendliness. If your project has many dependencies and high CI costs, it’s well worth trying.

iOS Timer vs DispatchSourceTimer｜Safe Usage with Finite State Machine & Design Patterns

For many developers, the most frustrating aspect of working with DispatchSourceTimer is its “fragile” state model: even a slight mistake in call order can lead to crashes. In this article, ZhgChgLi proposes an engineering-focused solution to this highly sensitive state management problem. The article carefully outlines five common crash scenarios (such as calling resume repeatedly or releasing a timer while it’s suspended), and demonstrates how to use a finite state machine (FSM) to encapsulate operations, blocking illegal calls at the logic level while ensuring thread safety through a private serial queue.

This is a hands-on case study that guides readers from “writing code” to “designing systems.” It not only explains how to correctly use GCD timers, but also shows how design patterns can turn a “dangerous” low-level API into a clear, safe, and maintainable industrial-grade component. In an era where Swift Concurrency is becoming the norm, understanding—and elegantly wrapping—these low-level GCD tools remains a core skill for senior iOS developers.

Tools

ml-sharp: Turn Photos into 3D Scenes in Seconds

Apple open-sourced SHARP (Sharp Monocular View Synthesis) last week—an AI model capable of converting a single 2D photo into a 3D scene in under one second (model size: 2.8 GB). Compared to previous state-of-the-art models, it improves visual quality by 25–34% and achieves a 1000× speedup.

The community widely believes SHARP could power future spatial photo features. Today, Spatial Scenes in iOS 26 rely on the Neural Engine for depth reconstruction, whereas SHARP uses the more advanced 3D Gaussian Splatting technique, resulting in significantly higher quality.

The model supports CPU, CUDA, and MPS execution, and developers have already successfully run it on M1, M2, and M3 Macs. The output .ply files are compatible with various 3DGS viewers, and Vision Pro users can view the results directly via Metal Splatter (demo).

While Apple may not always stand out in general-purpose language models, its vertically focused AI models—deeply integrated with hardware and driven by clear application scenarios—continue to demonstrate strong competitiveness.

MaterialView: Breaking the Limits of NSVisualEffectView

Oskar Groth (creator of Sensei) has open-sourced MaterialView, a highly customizable material blur view that goes beyond the limitations of NSVisualEffectView. By reverse-engineering the implementation behind Control Center, Oskar achieved full control over blur radius, saturation, brightness, and tint, and documented the process in a detailed technical article.

Unlike system materials, which only allow you to “pick a type,” MaterialView fully parameterizes the blur effect. Developers can precisely control blur radius, saturation, brightness, tint color, and blend modes, while also supporting active / inactive / emphasized / accessibility states. This makes it an excellent fit for sidebars, floating panels, and utility windows where visual consistency is critical.

The library supports both SwiftUI and AppKit, and includes a demo app with real-time parameter tuning to quickly explore different material configurations.

Note: MaterialView relies on some undocumented Core Animation capabilities (such as CABackdropLayer and CAFilter). While these APIs have been stable for years, there is still a potential risk of change in future macOS releases.

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

Share

Swift、SwiftUI 与 SwiftData：走向成熟的 2025

网页版

在过去的几天里，我回顾了这一年来 Swift、SwiftUI 以及 SwiftData 的演进。总的感觉是：惊喜虽不算多，但“成熟感”却在不经意间扑面而来。

毋庸置疑，Swift 今年的重头戏在于改善并发编程的体验。尽管新增的选项和关键字在短期内又给开发者带来了不小的困扰，但经过这几个月的讨论与实践，社区已经显现出逐渐总结出新范式实践路径的趋势。我不认为新范式被确立且广泛接受会是一个简单、迅速的过程，但或许再过一两年，开发者对 Swift 的讨论重心将从并发转向跨平台，届时 Swift 也将迈入全新的发展阶段。

今年 SwiftUI 的更新重心大多集中在 Liquid Glass 的适配上。受限于系统初期的实现，显示效果起初并不尽如人意，但在 iOS 26.2 版本发布后，性能与稳定性都有了显著改善。坦率地说，对于今年 SwiftUI 没有引入更多革命性的新功能，我个人是挺高兴的。这让框架团队和开发者都能获得一点喘息之机，去进一步消化这个框架。在现阶段，解决遗留问题、优化性能与稳定性，远比一味堆砌新特性更有意义。

“变化较小”在 SwiftData 身上体现得尤为明显。但我认为 SwiftData 今年的表现尤为值得肯定，特别是许多改进与新功能都向下适配到了更早的系统版本。真希望它在三年前初次发布时，就能具备现在的状态。尽管 SwiftData 目前仍缺失一些关键功能，但对于相当比例的项目而言，它已经足以胜任。有了这个稳固的基础，其未来几年在性能与功能上的提高非常值得期待。

对于 2025 年 Swift 三件套的交出的答卷，我个人是满意的，不知你的感受如何？

这是本年度的最后一期周报，由衷感谢各位一年的陪伴与厚爱。

祝大家新年快乐，Happy Coding!

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

活动

iOS Conf SG 2026

下个月（1 月 21 日 - 23 日），iOS Conf SG 将在新加坡举行。我也将前往现场，并作为嘉宾进行主题为 “Using SwiftUI as a Language” 的演讲——不仅关于代码，更是关于思维方式的转换。

如果你也在附近，或者计划前往，欢迎来现场打招呼！组委会专门为我的读者提供了优惠：Fatbobman 读者专属九折优惠链接

近期推荐

我和 CloudKit 的这八年：从开源 IceCream 到商业应用实战

我一直认为，所谓的苹果生态是由很多的硬件、软件、服务、人文、气质等综合构建起来的。在这其中，CloudKit 无疑是非常重要的一环。而且对于开发者来说，用好 CloudKit 不仅可以给用户更好的体验，也能低成本的为自己的应用带来创新。

IceCream 作者 Cai Yue 分享他与 CloudKit 八年的开发历程：从 2017 年开源 IceCream 并获得 Apple 官方认可，到将 CloudKit 应用于 Music Mate 和 Setlists 等商业项目的实战经验。文章深入探讨了 CloudKit 的核心优势、关键局限以及进阶玩法。

Swift 2025 年度总结 (What’s new in Swift: December 2025 Edition)

这是一篇面向 Swift 社区的年度收官综述文章，由 Tim Sneath 和 Dave Lester 撰写，系统回顾了 2025 年 Swift 生态在语言特性、平台覆盖与社区建设方面的关键进展。

文章不仅总结了 Swift 6.2 在并发模型上通过更温和的默认策略降低使用门槛，同时继续推进 C++ 互操作与内存安全能力；更重要的是，从 Android、WASM、Windows、BSD、嵌入式到 AWS 等方向的持续投入，反复强化了一个清晰信号——Swift 已不再只是围绕 Apple 平台展开的语言。

或许你未必会认同其中的每一项变化，但在迈入第二个十年后的第一个年头里，Swift 依然交出了一份相当扎实的答卷。

关于 SwiftUI 的讨论 (My PM insisted we switch to SwiftUI for a massive legacy app rewrite. The result is exactly what you’d expect)

几天前无意间在 Reddit 上看到的帖子，作者对 PM 轻易选择 SwiftUI 有所抱怨，认为其无法胜任他们一个七年前开发的应用转换。对于这个观点我不置可否，但评论区的走向却出乎意料——绝大多数参与者都坚定地站在了 SwiftUI 的一边。

大量开发者认为：

• SwiftUI 本身已经足够成熟，问题出在实施方式上

• 应该渐进式迁移，而不是一次性重写

• 避开 SwiftUI 的弱项——比如可以保留 UIKit 导航，只迁移视图层

• 多个大型项目（10+ 年历史）已成功完成迁移

这个帖子展现了一个出乎我预料的现实：SwiftUI 在实际生产环境中的采用率比我们想象的高得多；开发者社区对 SwiftUI 的信心已经建立。在 2025 年底，“SwiftUI 难堪大任”的论调或许已经站不住脚了。

作为 SwiftUI 框架的推崇者，我既喜欢该框架，也很清楚它仍有很长的路要走。如果你仍在犹豫是否应该在 SwiftUI 上下功夫，或许可以看一下我在去年写的《几个常见的关于 SwiftUI 的误解》——这篇文章讨论的很多误解，恰好在这次 Reddit 讨论中得到了印证。

非 Sendable 优先设计 (Non-Sendable First Design)

随着 Swift 6 时代的到来，开发者逐渐养成了一种惯性：要么让类型符合 Sendable，要么给它套上 @MainActor 或 actor。在这篇文章中，Matt Massicotte 提出了一个极具启发性的哲学：“非 Sendable 优先设计”。

这一思路的关键在于对“隔离（Isolation）”的重新认识：隔离本身是一种约束。当一个类型被标记为 @MainActor，它实际上就失去了在非 UI 环境下进行同步调用的自由度。相比之下，一个非隔离、非 Sendable 的普通类型反而具有更高的通用性——它可以被任意 Actor 持有，并在其内部安全地进行同步访问，同时也更容易遵循 Equatable 等基础协议，而无需处理跨隔离域带来的复杂性。

随着 Swift 引入 NonisolatedNonsendingByDefault，这种“非 Sendable 优先”的设计路径不再像过去那样笨重或别扭，反而逐渐显现出其优势：以更少的隔离、换取更清晰的语义与更低的架构负担。这或许并非适用于所有场景，但在 Swift 6 之后，它已经成为一种值得认真考虑的、符合语言直觉的“减法”方案。

使用 Registry 加速依赖解析 (Resolving Swift Packages faster With Registry from Tuist)

传统的 SPM 依赖解析是基于 Git URL 的，Xcode 需要克隆整个 Git 仓库来获取版本信息和代码，这在依赖较多（如 Firebase）时非常耗时。而 Registry 是苹果定义的另一种规范：通过包的标识符（ID）直接下载特定版本的归档文件，跳过了繁重的 Git 操作。Tuist 最近宣布将其 Swift Package Registry 功能向所有开发者开放，最大的变化是现在无需登录或创建 Tuist 账号即可使用。

Lee Young-jun 实测发现，使用 Registry 后，依赖解析（Installation）时间缩短至原来的约 35%；但项目生成与构建阶段并未获得同等收益，甚至略有回退。在 GitHub Actions 中配合缓存使用时，二次构建的依赖安装时间则从 53s 降至 11s，优势主要体现在 CI 场景。

总体来看，Tuist Registry 并非“全流程加速器”，而是一个专注于依赖解析与缓存友好性的优化点。如果你的项目依赖数量庞大、CI 成本较高，它值得优先尝试。

iOS Timer 与 DispatchSourceTimer 选择与安全封装技巧｜有限状态机防止闪退

很多开发者在处理 DispatchSourceTimer 时，最头疼的就是它那“易碎”的状态：调用顺序稍有不对便会引发闪退。ZhgChgLi 在本文中针对这种极其敏感的状态管理提出了工程化的解决方案。文章详尽列举了导致崩溃的五大常见场景（如重复 resume、suspend 状态下直接释放等），并分享了如何利用有限状态机 (FSM) 封装操作，从逻辑层屏蔽非法调用，同时配合私有串行队列确保多线程环境下的调用安全。

这是一篇引导读者从“写代码”转向“做设计”的实战案例。它不仅讲清了 GCD 定时器的正确使用方式，更展示了如何借助设计模式，将一个“危险”的底层 API，封装为语义清晰、使用安全、可长期维护的工业级组件。在 Swift Concurrency 日益成为主流的今天，理解并优雅地封装这些底层 GCD 工具，依然是高级 iOS 开发者的重要基本功。

工具

ml-sharp：照片秒变 3D 场景

苹果在上周开源了 SHARP (Sharp Monocular View Synthesis)，一个能在不到 1 秒内将单张 2D 照片转换为 3D 场景的 AI 模型（模型大小 2.8 GB）。相比之前的最佳模型，视觉质量提升 25-34%，速度提升 1000 倍。

社区普遍认为 SHARP 可能用于未来版本的空间照片功能。目前 iOS 26 的 Spatial Scenes 使用 Neural Engine 进行深度重建，而 SHARP 采用更先进的 3D Gaussian Splatting 技术，质量显著提升。

模型支持 CPU/CUDA/MPS 运行，已有开发者在 M1/M2/M3 Mac 上成功运行。输出的 .ply 文件兼容各种 3DGS 查看器，Vision Pro 用户可通过 Metal Splatter 直接查看效果。

尽管苹果在通用语言大模型上不如竞争对手惊艳，但在垂直场景的 AI 模型上，凭借硬件深度整合与明确的应用导向，依然展现出强大的竞争力。

MaterialView: 突破 NSVisualEffectView 限制的毛玻璃视图

Oskar Groth (Sensei 作者)开源了 MaterialView，一个能够突破 NSVisualEffectView 限制的高度可定制毛玻璃视图库。通过逆向 Control Center 的实现，Oskar 实现了对模糊半径、饱和度、亮度和色调的完全控制，并撰写了详细的技术文章讲解实现原理。

与系统原生材质只能“选类型”不同，MaterialView 将模糊效果彻底参数化，允许开发者精确控制模糊半径、饱和度、亮度、tint 颜色与混合模式，并支持 active / inactive / emphasized / accessibility 等状态配置。这使得它非常适合用于侧边栏、浮层面板、工具窗口等对视觉一致性要求极高的场景。

该库同时支持 SwiftUI 与 AppKit，并提供了一个可实时调参的 Demo App，方便快速探索不同材质组合的效果。

需要注意的是，它依赖部分未公开的 Core Animation 能力（如 CABackdropLayer、CAFilter 等）。尽管这些 API 多年来相当稳定，但仍存在未来系统版本变动的潜在风险。

A Sunday Incident

Read on web →

Sunday afternoon, I was preparing Monday’s weekly newsletter as usual. The moment I stood up, my right pinky finger seemed to bump into something, and then it wouldn’t straighten.

Somewhat bizarre—no pain, no swelling, but just couldn’t extend. The ER doctor’s initial assessment was pinky extensor tendon injury. I scheduled further examination for Monday, and surgery will likely be needed for repair.

It was only then that I realized how important this usually low-profile pinky finger is. Now wearing a finger splint, typing has become significantly difficult. Fortunately, it shouldn’t be anything serious, just that I’ll be typing less for a while.

Life is unpredictable; face it with a smile.

Monday Update: After further examination today, they found no fracture requiring reduction, just a simple tendon rupture. This means no surgery needed—just wearing the finger splint for 6 weeks should restore it to normal.

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

From YaoYao to Tooboo: watchOS Development Pitfalls and Practical Tips

As the creator of popular watchOS apps YaoYao, Tooboo, and DunDun, Haozes shares high-quality practical experience in watchOS development, covering version compatibility, app wake-up communication, data synchronization, restart recovery, memory leaks, and battery optimization. This article encompasses a complete guide from HealthKit to WCSession, from HKWorkoutSession to TimelineSchedule, providing invaluable reference for developers who are building or planning to build Apple Watch applications.

As a long-time Apple Watch user and Swift blogger, I often marvel at the “mystique” of watchOS development—countless details beyond the documentation, with very few truly in-depth practical articles available online. For this reason, I specially invited Haozes, a leading independent developer in the watchOS space, to share his development insights.

My journey to Swift 6 and Strict Concurrency

A crash that “only appeared on real user devices” forced Irving Popovetsky to migrate an entire production iOS app to Swift 6 + Strict Concurrency. This article comprehensively documents the journey from the initial 76 errors and 238 warnings, through the gradual introduction of @preconcurrency, actor, @MainActor, Sendable, and nonisolated(unsafe), to verification with real devices and Thread Sanitizer. Irving points out that Swift 6’s runtime validates actor isolation the moment a closure is called—even if you use Task { @MainActor in } inside the closure, it may be too late. The article provides clear, reusable patterns for addressing this behavior.

Monitoring app performance with MetricKit

MetricKit is a system-level performance diagnostics framework introduced by Apple in iOS 13, designed to provide developers with app performance and stability data from real user devices. It only works in real device environments, with data sourced from long-term sampling and aggregation by the system in the background, thus more accurately reflecting app behavior in actual usage scenarios.

In this article, Majid Jabrayilov demonstrates how to subscribe to system-level performance data through MXMetricManager, progressively extracting and reporting key metrics from background abnormal exits, CPU/memory resource limits, to crash diagnostics, thereby building a more complete and traceable app performance monitoring dashboard. Majid also specifically reminds readers that MetricKit data is typically aggregated and delivered daily rather than in real-time callbacks, and actual analysis requires understanding the time range covered by each payload in combination with timestamps.

Rebuilding MistKit with Claude Code - From CloudKit Docs to Type-Safe Swift

When Leo Dion rebuilt MistKit, his long-dormant CloudKit server-side library, he discovered that swift-openapi-generator could significantly reduce refactoring complexity: by simply converting CloudKit’s REST documentation into OpenAPI specifications, he could automatically generate large-scale, type-safe Swift client code. To this end, he brought in Claude Code, specifically responsible for the translation work “from Apple documentation to OpenAPI YAML.”

The most valuable aspect of the article isn’t “how much code AI generated,” but rather how Leo uses AI. He didn’t let Claude directly implement MistKit, but positioned it as a “documentation translator and pattern amplifier,” while keeping the truly complex parts requiring engineering judgment and architectural trade-offs under his own control. Rather than having AI directly “write code,” it’s better to have it turn complex problems into generatable, verifiable problems—this is the most valuable lesson from this MistKit rebuilding process.

I Reverse Engineered ChatGPT’s Memory System, and Here’s What I Found!

Through extensive conversation experiments, Manthan Gupta reverse-engineered ChatGPT’s “memory” behavior and found its implementation far simpler than imagined: no vector database, no RAG across historical conversations, but rather composed of four layers of context—one-time injected Session Metadata, explicitly stored long-term user memories, lightweight summaries of recent conversations, and a sliding window of the current session. Manthan believes this design has obvious advantages in performance, latency, and token costs: trading pre-computed summaries and explicit fact injection for “good enough” continuity, rather than expensive full historical retrieval. Manthan also has another study on Claude’s memory system.

When using ChatGPT, I’m often surprised by how much it knows about me. Although I understand this “familiarity” comes from its memory and context mechanisms, this is also one of the important reasons why I’ve long preferred using the official client. Of course, if you’re particularly sensitive about privacy, this capability itself might be exactly the part you’re unwilling to accept.

Swift Configuration 1.0 released

Honza Dvorsky announced the official release of Swift Configuration 1.0 on the Swift official blog. This library provides a unified, type-safe configuration reading abstraction for Swift applications and libraries. The key isn’t about supporting how many configuration formats, but completely separating “how configuration is read” from “where configuration comes from.” This design is particularly important for library authors—libraries can accept configuration without binding to specific sources, thus maintaining good composability across different deployment environments. With the 1.0 release, Swift Configuration’s API has entered a stable phase and is being explored for integration by projects like Vapor and Hummingbird.

At first glance, introducing such an abstraction layer for configuration management seems somewhat “heavyweight,” but once configuration sources are no longer limited to a single file, or when code needs to be reused across different environments and projects, the advantages in structural clarity and extensibility quickly become apparent.

TCA Architecture: A Glorified Antipattern

This is an extremely opinionated long-form article. Lazar Otasevic systematically argues against TCA’s Action enum + Reducer core design from the perspective of functional programming and SwiftUI’s runtime model, considering it a classic antipattern of “encoding behavior as data” that unnecessarily takes away SwiftUI’s inherent state ownership. Unlike many “anti-TCA” discussions that remain at the emotional or preference level, this article provides a complete, runnable alternative approach: treating State as pure data, Logic as stateless implementation details, and exposing behavior through closures (capabilities), thereby maintaining testability and composability while better aligning with SwiftUI’s declarative data flow model.

Considering the period when TCA first emerged, many developers still struggled with ObservableObject‘s insufficient response granularity, lack of @MainActor and Task tools, and heavy reliance on Combine for asynchronous calls—TCA effectively solved a series of pain points at that time. However, as Swift and SwiftUI continue to evolve, some of TCA’s once-prominent advantages are no longer as obvious, and its composability model still has considerable learning and usage costs for many developers. Nevertheless, TCA remains a development paradigm that many developers and teams have adapted to and love—ultimately, what suits you is what’s best.

Tools

FluidAudio: Local Audio AI Toolkit for Apple Platforms

FluidAudio is a Swift audio AI SDK designed specifically for Apple platforms, providing fully local speech recognition, speaker diarization, voice activity detection, and other features, primarily developed by Brandon Weng and Alex Weng. All inference runs on the Apple Neural Engine (ANE), achieving low-latency, low-power audio processing capabilities.

Core Features:

• Fully Local: All models run on-device, no network connection required, fully protecting user privacy

• ANE Optimized: Leverages Apple Neural Engine, avoids GPU/MPS usage, reducing CPU usage and power consumption

• Open and Transparent: Based on MIT/Apache 2.0 licensed open-source models, available on Hugging Face

• Easy Integration: Install via Swift Package Manager, with clean and intuitive API design

• Production Ready: Adopted by well-known apps including Voice Ink, Spokenly, Slipbox, and BoltAI

FluidAudio supports automatic speech recognition (Parakeet TDT v3, 25 European languages), speaker diarization (offline/online dual modes), voice activity detection (Silero VAD), and text-to-speech (Beta). On M4 Pro, speech recognition achieves a real-time factor of approximately 190x, processing 1 hour of audio in just 19 seconds.

If you’re developing iOS/macOS applications involving speech processing, FluidAudio is definitely worth trying.

Navigable: Unified SwiftUI Navigation Management

A major pain point in SwiftUI is how to uniformly manage multi-level routing, sheets, full-screen covers, and alerts across different navigation and presentation mechanisms. Navigable, developed by Corey Davis, provides a more centralized and testable solution: it consolidates all navigation behavior into an observable NavigationState as the single source of truth.

Through this approach, Navigable maintains type-safety and modern Swift (@Observable, Swift 6) features while extracting navigation logic from views, supporting complex flows, deep linking, and unit testing. Additionally, it supports both declarative view construction and imperative APIs (like push / pop) for driving state changes, offering more controllability in complex scenarios similar to traditional routing systems.

The library is still in early development, but its implementation approach is worth continued attention.

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

Share

周日小插曲

网页版

周日下午，我正准备周一的周报。起身的瞬间，右手小指似乎碰到了什么，然后它就伸不直了。

有些诡异——不痛、不肿，但就是无法伸直。急诊医生初步判断是小指伸肌腱损伤，约了周一做进一步检查，很可能需要手术修复。

这才意识到，平时存在感不强的小指，原来如此重要。现在戴着固定指套，打字变得比较困难。好在应该不是什么大问题，只是接下来一段时间会减少打字量。

人生无常，微笑对待。

周一更新：今天进一步检查后，发现没有需要复位的骨折，只是单纯的肌腱断裂。这样就不用手术了，只需要戴指套固定 6 周就基本能恢复了。

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

近期推荐

从 YaoYao 到 Tooboo：watchOS 开发避坑与实战

作为知名 watchOS 应用 YaoYao、Tooboo、DunDun 的作者，Haozes 分享了 watchOS 开发中关于版本兼容、App 唤起通信、数据同步、重启恢复、内存泄露和电量优化等高质量实战经验。这篇文章涵盖了从 HealthKit 到 WCSession、从 HKWorkoutSession 到 TimelineSchedule 的完整开发避坑与性能调优指南，对于正在开发或计划开发 Apple Watch 应用的开发者具有极高参考价值。

作为一个长期的 Apple Watch 用户和 Swift 博主，我常感叹 watchOS 开发的“神秘”——文档之外细节繁多，且网络上真正有深度的实战文章寥寥无几。为此，我特别邀请了 watchOS 领域的头部独立开发者 Haozes，来分享他的开发体会。

Swift 6 严格并发迁移实战 (My journey to Swift 6 and Strict Concurrency)

一次“只在真实用户设备上才会出现”的崩溃，迫使 Irving Popovetsky 将一整个已上线的 iOS 应用迁移到 Swift 6 + Strict Concurrency。这篇文章完整记录了从迁移之初的 76 个 error、238 个 warning 开始，到逐步引入 @preconcurrency、actor、@MainActor、Sendable、nonisolated(unsafe)，再到真机 + Thread Sanitizer 验证的全过程。Irving 指出，Swift 6 的运行时会在闭包被调用的瞬间验证 actor 隔离，哪怕你在闭包内部再 Task { @MainActor in } 也可能为时已晚。文章中对这一行为给出了清晰、可复用的修复模式。

用 MetricKit 监控应用性能 (Monitoring app performance with MetricKit)

MetricKit 是 Apple 在 iOS 13 引入的系统级性能诊断框架，用于向开发者提供来自真实用户设备的应用性能与稳定性数据。它只在真机环境中工作，数据来源于系统在后台长期采样并聚合的结果，因此能够更真实地反映应用在实际使用场景下的行为。

Majid Jabrayilov 在本文中展示了如何通过 MXMetricManager 订阅系统级性能数据，从后台异常退出、CPU / 内存资源限制，到崩溃诊断信息，逐步提取关键指标并上报，从而构建一个更完整、可追溯的应用性能监控面板。Majid 也特别提醒，MetricKit 的数据通常按天聚合下发，而非实时回调，实际分析时需要结合时间戳理解其所覆盖的时间区间。

用 Claude Code 重构 MistKit (Rebuilding MistKit with Claude Code - From CloudKit Docs to Type-Safe Swift)

Leo Dion 在重建自己停更多年的 CloudKit 服务端库 MistKit 时，发现 swift-openapi-generator 能显著降低重构复杂度：只要将 CloudKit 的 REST 文档转化为 OpenAPI 规范，就可以自动生成大规模、类型安全的 Swift 客户端代码。为此，他引入 Claude Code，专门负责完成“从 Apple 文档到 OpenAPI YAML”的翻译工作。

文章最有价值的地方，并不在于“AI 生成了多少代码”，而在于 Leo 如何使用 AI。他并没有让 Claude 直接实现 MistKit，而是将其定位为“文档翻译与模式放大器”，而真正复杂、需要工程判断与架构取舍的部分，始终由作者亲自把控。与其让 AI 直接“写代码”，不如让它把复杂问题变成可生成、可校验的问题——这正是这次 MistKit 重建过程中最值得借鉴的地方。

ChatGPT 记忆系统逆向分析 (I Reverse Engineered ChatGPT’s Memory System, and Here’s What I Found!)

Manthan Gupta 通过大量对话实验，对 ChatGPT 的“记忆”行为进行了逆向分析，发现其实现方式远比想象中简单：没有向量数据库、没有跨历史对话的 RAG，而是由四层上下文共同构成——一次性注入的 Session Metadata、显式存储的长期用户记忆、近期对话的轻量摘要，以及当前会话的滑动窗口。Manthan 认为，这种设计在性能、延迟和 token 成本上的优势非常明显：通过预计算摘要和显式事实注入，换取“足够好”的连续性，而不是昂贵的全量历史检索。Manthan 还有另一篇针对 Claude 记忆系统的研究。

在使用 ChatGPT 的过程中，我时常会对它对我的了解程度感到惊讶。尽管我清楚，这种“熟悉感”来自其记忆与上下文机制，但这也正是我长期偏向使用官方客户端的重要原因之一。当然，如果你对隐私问题格外敏感，那么这种能力本身，可能正是你不愿接受的那一部分。

Swift Configuration 1.0 released

Honza Dvorsky 在 Swift 官方博客中宣布 Swift Configuration 1.0 正式发布。该库为 Swift 应用与库提供了一套统一、类型安全的配置读取抽象，其关键并不在于支持多少配置格式，而是彻底分离「配置如何读取」与「配置来自哪里」。这一设计对库作者尤为重要——库可以接受配置而不绑定具体来源，从而在不同部署环境中保持良好的可组合性。随着 1.0 发布，Swift Configuration 的 API 已进入稳定阶段，并开始被 Vapor、Hummingbird 等项目探索集成。

乍看之下，为配置管理引入这样一个抽象层似乎显得有些“重量级”，但一旦配置来源不再局限于单一文件，或者代码需要在不同环境与项目中复用，其带来的结构清晰度与扩展性优势就会迅速显现。

TCA 架构：一个被美化的反模式？ (TCA Architecture: A Glorified Antipattern)

这是一篇立场极其鲜明的长文。Lazar Otasevic 从函数式编程与 SwiftUI 的运行模型出发，系统性地反对了 TCA 以 Action enum + Reducer 为核心的设计，认为这是一种“将行为编码为数据”的经典反模式，并且不必要地夺走了 SwiftUI 原本应当拥有的状态所有权。与许多停留在情绪或偏好层面的“反 TCA”讨论不同，本文给出了一套完整、可运行的替代思路：将 State 视为纯数据、Logic 视为无状态的实现细节，并通过闭包（capabilities）暴露行为，从而在保持可测试性与可组合性的同时，更贴合 SwiftUI 的声明式数据流模型。

考虑到 TCA 刚出现的时期，很多开发者仍难以应对 ObservableObject 响应颗粒度不足、缺乏 @MainActor、Task 等工具、异步调用高度依赖 Combine 的现实处境，TCA 确实有效解决了当时的一系列痛点。但随着 Swift 与 SwiftUI 的不断演进，TCA 中一些曾经突出的优势已不再明显，而其可组合性模型对不少开发者而言，使用与理解成本也依然不低。即便如此，TCA 仍然是许多开发者和团队已经适应并喜爱的开发范式——归根结底，适合自己的，才是最好的。

工具

FluidAudio: 为 Apple 平台打造的本地化音频 AI 工具包

FluidAudio 是一个专为 Apple 平台设计的 Swift 音频 AI SDK，提供完全本地化的语音识别、说话人分离、语音活动检测等功能，由 Brandon Weng 和 Alex Weng 主导开发。所有推理都在 Apple Neural Engine (ANE) 上运行，实现了低延迟、低功耗的音频处理能力。

核心特性：

• 完全本地化：所有模型在设备端运行，无需网络连接，充分保护用户隐私

• ANE 优化：充分利用 Apple Neural Engine，避免使用 GPU/MPS，降低 CPU 使用率和功耗

• 开源透明：基于 MIT/Apache 2.0 许可的开源模型，可在 Hugging Face 获取

• 易于集成：通过 Swift Package Manager 安装，API 设计简洁直观

• 生产就绪：已被 Voice Ink、Spokenly、Slipbox、BoltAI 等知名应用采用

FluidAudio 支持自动语音识别（Parakeet TDT v3，25 种欧洲语言）、说话人分离（离线/在线双模式）、语音活动检测（Silero VAD）以及文字转语音（Beta）。在 M4 Pro 上，语音识别的实时系数可达约 190x，处理 1 小时音频仅需 19 秒。

如果你正在开发涉及语音处理的 iOS/macOS 应用，FluidAudio 绝对值得尝试。

Navigable: 统一 SwiftUI 导航管理

SwiftUI 中的一大痛点，在于如何将多级路由、sheet、full-screen cover 以及 alert 等不同导航与展示机制统一管理。由 Corey Davis 开发的 Navigable 提供了一种更集中、可测试的解决方案：它将所有导航行为统一收敛到一个可观察的 NavigationState 中，作为唯一的状态来源。

通过这种方式，Navigable 能够在保持 type-safe 与现代 Swift（@Observable、Swift 6） 特性的同时，将导航逻辑从视图中剥离出来，支持复杂流程、深链以及单元测试。同时，它既支持声明式的视图构建，也允许通过命令式 API（如 push / pop）驱动状态变化，在复杂场景下更接近传统路由系统的可控性。

该库仍处在开发早期，但其实现思路值得持续关注。

Unearthing “Silent Experts”

Read on web →

Regular readers of my blog may have noticed that I haven’t published many personal pieces lately. Instead, over the past few weeks, I’ve shared a series of guest posts from developers across different domains. This is part of a special initiative I recently launched—inviting practitioners who have deep experience and meaningful accomplishments in their respective fields to share their hands-on insights, hard-won lessons, unique perspectives, and personal journeys.

As a blogger, I’ve inadvertently written hundreds of articles over the years. While I still believe my content holds value, I must admit that, like many writers who publish regularly, I have gradually fallen into a kind of “formulaic” rhythm. My articles tend to focus on API usage and internal mechanisms, but they are often constructed with a “demo mindset.” Even when discussing bug fixes or pitfalls, they typically address isolated “points” rather than connected “lines,” let alone full “planes.”

As a newsletter editor, I’ve also noticed another pattern: although the internet produces an endless stream of high-quality technical articles every week, truly deep, domain-specific, and frontline-driven content remains surprisingly rare. Over time, I realized the root cause: developers working on the front lines simply lack the time or energy to write such pieces. So, a few months ago, I began planning this initiative—reaching out to these developers, hoping to unearth these “silent experts” and make their tacit knowledge explicit.

During conversations with these authors, one scenario appears again and again: they don’t know what to write about. Even though they tackle complex engineering problems every day, long-term immersion makes these challenges feel ordinary or unremarkable to them. Many wonder, “Isn’t this just common knowledge? Would anyone really care about this?” At moments like this, I switch to the perspective of both a developer and a reader, and I tell them—yes, these are exactly the stories and insights we want to learn about. These are the “industry secrets” that rarely make it into writing.

In the era of AI, large models may well master vast amounts of API usage and coding patterns. But for humans, genuine emotion, real-world constraints, the friction of working with imperfect systems, and the lessons forged through countless failures—these remain our most precious and irreplaceable assets.

I am deeply grateful to the authors who generously carved out time from their busy schedules to share their knowledge. Many of the insights in their writing could only come from long-term engineering practice and the experience of being repeatedly “battered” by challenges.

This effort to unearth “silent experts” is still ongoing, with more articles already lined up. If the response continues to be positive, I will keep inviting more of these practitioners to share their stories.

We do this for ourselves, for the community, and perhaps to preserve a few distinct voices forged through lived experience in a world increasingly homogenized by AI.

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

A Deep Dive into SwiftUI Rich Text Layout: Beyond AttributedString — Inside MarkdownView and RichText

Although AttributedString has been around for years, SwiftUI still lacks official support for full Markdown rendering, text–image mixed layout, selectable text, and fine-grained interactions. As the author of both MarkdownView and RichText, LiYanan walks through the technical journey behind solving these challenges—from early attempts with the Layout protocol, to hitting the limits of TextRenderer, and finally building an interactive, high-performance Markdown renderer on top of TextKit. This piece is both a record of persistence and growth, and one of the rare, in-depth resources available today on SwiftUI text rendering.

What Setting Should I Use?

Ten-year-old Swift has never been more powerful—nor more complex. Beyond added language features, developers now face an ever-growing list of compiler settings whose combinations effectively define different eras, philosophies, and semantics of Swift.

In this article, Matt Massicotte provides a grounded, highly practical answer to a real question: Which compiler settings should I actually enable in the Swift 6.2 / Xcode 26 era?
If you’re debating whether to adopt Swift 6 language mode, or can’t decide whether StrictConcurrency should be set to minimal, targeted, or complete, this article serves as a decision-making guide to help you migrate in a more controlled and incremental way.

Swift Enum Hidden Magic Tricks

Enums are one of Swift’s most distinctive language features, far beyond “switch cases with associated values.” For many experienced Swift/iOS developers, enums function as a modeling tool that shapes architectural boundaries, especially when managing complex state. In this article, Bruno Valente Pimentel systematically explains how enums help us make invalid states unrepresentable, illustrating how this principle evolves from a “syntax trick” into a genuine “design methodology” through real project examples.

“Make invalid states unrepresentable” is one of the core principles emphasized in type-driven design. If you’d like to dive deeper into the underlying concepts, the Type-Driven Design with Swift series by Alex Ozun is highly recommended.

Make Your App Visible with Alternative App Names

You may have noticed that some iOS apps can be found via Spotlight using multiple names—an incredibly convenient user experience. Behind this behavior is a SiriKit capability that allows developers to define up to three alternative app names in the app’s Info.plist, making the app easier to discover through different keywords. In this article, Wesley de Groot explains how to implement this feature.

With macOS 26 removing Launchpad, more users are turning to Spotlight to open apps. It wouldn’t be surprising if a similar alternative-names mechanism eventually comes to macOS as well.

Organizing SwiftUI Views with TabContent and @TabContentBuilder

In the last two SwiftUI releases, Apple significantly expanded the capabilities of tab-based navigation—extending it from classic bottom tab bars to more flexible, structured navigation patterns (such as sidebar-like behavior on larger screens). As a result, many real projects now have increasingly bloated TabView declarations: role-based screens, conditional branches, navigation stacks, label configurations, and team conventions often end up intertwined inside a single block.

Artem Mirzabekian suggests a cleaner approach: extracting tab definitions into a dedicated, composable configuration using a custom @TabContentBuilder. This greatly improves readability and scalability, making tab navigation easier to maintain in large SwiftUI projects.

Beyond @ViewBuilder, SwiftUI provides many domain-specific result builders—such as TableColumnBuilder, CommandsBuilder, SceneBuilder, ToolbarContentBuilder, and ChartContentBuilder. Using the right builder not only clarifies structure but can significantly reduce type-inference load in complex layouts (e.g., combining Charts and Table), helping avoid the infamous SwiftUI “type-checking explosion”.

LLDB Power User Guide: Essential Commands & SwiftUI Debugging

Debugging SwiftUI has never been easy. While many developers rely on sprinkling print statements throughout their code, the far more powerful capabilities of LLDB often go overlooked. In this article, Jai Krishna demonstrates—using extensive SwiftUI examples—how to inspect and modify the internal state of @State, @Binding, and @Published at runtime, trace redraw triggers with Self._printChanges(), and use targeted breakpoint strategies to pinpoint layout and interaction issues.

Identifying Hangs in iOS Apps

Many developers encounter UI hangs caused by main-thread blocking, yet identifying the exact source is often difficult. Tiago Henriques walks through a purposefully laggy demo app to show how to use Instruments’ Time Profiler to determine the nature and scope of the issue. Reproduction and identification are only the first steps—Tiago also notes that deeper performance-analysis content may follow if readers show interest.

Tools

SwiftUI Ratings

If you need to build an in-app rating/review interface or guide users more naturally toward leaving an App Store review, SwiftUI-Ratings, developed by James Sedlacek, offers a plug-and-play solution. It provides a highly customizable UI modeled after the App Store’s ratings and reviews page and allows developers to integrate any data source through the AppRatingProviding protocol (with mock and Supabase / App Store Connect examples included). A lightweight, modern, and extensible choice for implementing an in-app rating prompt.

Swift Hugging Face

Hugging Face is the world’s leading open-source AI community and model hub, offering a vast ecosystem of models, datasets, tools, and collaboration spaces—serving as essential infrastructure for building and deploying modern AI applications.

As Hugging Face’s official Swift client, Swift Hugging Face provides two major capabilities:
First, it fully wraps the Hugging Face Hub API, giving Swift developers native access to models, datasets, Spaces, and more. Second, it integrates the Inference API, enabling tasks such as chat completion, embeddings, text-to-image/video generation, and speech-to-text to run directly on iOS, macOS, visionOS, as well as Linux and Windows.

In the article Introducing swift-huggingface: The Complete Swift Client for Hugging Face, Mattt explains the library’s design and usage in depth, opening the door for Swift developers to fully leverage the Hugging Face AI ecosystem.

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

Share

挖掘“沉默的专家”

网页版

关注我博客的读者可能留意到，最近一段时间我较少发表个人的作品，取而代之的是，我陆续发布了多篇来自不同开发者的客座文章。没错，这是我近期发起的一项特别企划——邀请那些在各自领域深耕且卓有建树的开发者，分享他们的实战经历、独家秘籍、独特视角以及心路历程。

作为一名博主，不知不觉间我已经写了几百篇文章。虽然我相信这些内容仍具价值，但不得不承认，和许多定期输出的作者一样，我逐渐陷入了一种“程式化”的写作惯性中。我的文章往往侧重于探讨 API 的用法、剖析内部细节，但更多是基于“Demo”思维来构建的。即便涉及 Bug 修复或避坑指南，往往也只是处理一个个孤立的“点”，而非连贯的“线”或“面”。

作为周报编辑，我也观察到：尽管互联网上每周都有大量优秀技术文章涌现，但针对特定领域、能展开深度讨论且贴近一线实战的内容却显得稀缺。逐渐我意识到，主要原因是那些奋战在一线的开发者往往缺乏时间或精力来撰写这类长文。为此，几个月前我开始策划这项活动，主动向这类开发者约稿，试图挖掘这些“沉默的专家”，将他们脑海中的“隐性知识”显性化。

在与作者们的沟通中，我常遇到这样的场景：对方不知道该写什么。尽管他们每天都在解决棘手的难题，但因长期浸淫其中，往往“身在庐山不知真面目”，逐渐忽略了这些经验的普适价值。许多人认为自己的工作稀松平常——“难道这些不是常识吗？真的会有人想了解这些？”每当此时，我便会切换回开发者和读者的视角，向他们表达我对该领域的好奇，以及我渴望探究的那些“行业秘密”。

在 AI 时代，大模型或许已经掌握了海量的 API 用法和代码范式。但对于人类而言，那些真挚的情感、与物理世界的真实碰撞、以及从无数次失败实践中提炼出的教训，仍是我们最宝贵且独特的财富。

非常感谢这些作者，能在繁忙的工作中抽调时间与精力，无私地分享他们的知识宝藏。文中的许多内容，若非经过长期的工程实践和被困难反复地“折磨”，是绝不可能产生如此深刻的体悟的。

这项挖掘“沉默专家”的计划仍在继续。这不仅是为了丰富博客的内容，更是为了我们自己，为了社区。在这个信息逐渐被 AI 同质化的今天，我希望能为大家保留并呈现更多由鲜活经验铸就的、不一样的声音。

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

近期推荐

SwiftUI 图文混排深度剖析：超越 AttributedString —— MarkdownView 与 RichText 的实现

虽然 AttributedString 已经推出多年，但 SwiftUI 仍然缺乏「完整 Markdown 渲染 + 图文混排 + 可选中文本 + 精细交互」的官方支持。作为 MarkdownView 和 RichText 的作者，LiYanan 在本文中系统回顾了他为解决这些问题所进行的技术探索——从最初尝试 Layout 协议，到踩过 TextRenderer 的种种限制，再到最终基于 TextKit 打造可交互、高性能的 Markdown 渲染组件。这既是一份关于坚持与成长的技术复盘，也是目前 SwiftUI 文本渲染领域难得的资料。

我该开启哪些 Swift 编译器设置？ (What Setting Should I Use?)

十岁的 Swift 从未像今天这样强大，但随之而来的复杂度也显而易见。除了更多的语言特性，你还要面对不断扩张的编译器设置——它们彼此组合，足以构建出“不同年代、不同哲学、不同语义”的 Swift。

在这篇文章中，Matt Massicotte 用非常接地气的方式回答了一个现实问题：**在 Swift 6.2 / Xcode 26 时代，我究竟应该打开哪些编译器设置？如果你正犹豫是否切换到 6 语言模式，或迟迟拿不定主意 StrictConcurrency 应设为 minimal、targeted 或 complete，这篇文章可以视作一份决策辅助清单，帮助你按更可控、渐进的方式完成迁移。

枚举背后的力量 (Swift Enum Hidden Magic Tricks)

枚举是 Swift 中极具辨识度的语言特性，其能力远超“带点关联值的分支语句”。在许多资深 Swift/iOS 开发者眼中，枚举更像是一种用于塑造架构边界的建模工具，尤其在管理复杂状态时格外突出。Bruno Valente Pimentel在本文中系统阐述了枚举如何帮助我们让无效状态不可表示（Make Invalid States Unrepresentable），并通过多个真实项目的演化过程展示这一思想如何从“语法技巧”升级为“设计方法论”。

“让无效状态不可表示”是类型驱动设计推崇的关键思想之一。如果你想进一步理解这一理念的底层思想，非常建议一并阅读 Alex Ozun 的 Type-Driven Design with Swift 系列文章。

为应用设置替代名 (Make Your App Visible with Alternative App Names)

在日常使用中，你可能注意到某些 iOS 应用可以通过多个名称在 Spotlight 中被搜索到，这在实际使用场景中非常便利。其背后正是 SiriKit 提供的能力：开发者可以在应用的 Info.plist 中配置最多 3 个替代名称，使用户能够通过不同的关键词更轻松地找到你的应用。Wesley de Groot 在本文中介绍了这一功能的具体实现方式。

随着 macOS 26 移除了“启动台”（Launchpad），越来越多的用户开始依赖 Spotlight 启动应用。或许未来，类似的替代名称机制也会被引入到 macOS 平台。

用 @TabContentBuilder 组织你的 Tab 声明 (Organizing SwiftUI Views with TabContent and @TabContentBuilder)

在最近的两个版本中，SwiftUI 对 Tab 支持进行了大幅扩展：从传统的底部分页导航，延伸到更灵活的结构化场景，例如在大屏设备上表现类似侧边栏的导航模式。因此，许多项目的 Tab 声明开始变得越来越庞大：角色控制、条件分支、导航栈、标签配置与团队约定往往混杂在同一个 TabView 中。Artem Mirzabekian 在文中建议将与 Tab 相关的配置从主布局中抽离，借助自定义的 @TabContentBuilder 搭建一个专属的、可组合的 tab 定义区域。这种组织方式能够显著提升可读性与可扩展性，让 Tab 导航的维护不再成为 SwiftUI 项目的难点。

除了 @ViewBuilder 外，SwiftUI 还提供了大量领域专用的 result builder，如 TableColumnBuilder、CommandsBuilder、SceneBuilder、ToolbarContentBuilder、ChartContentBuilder 等。更精确地选用这些 builder，不仅能让视图结构更清晰，也能在复杂场景（例如并用 Charts 与 Table）减少类型推断负担，避免触发 SwiftUI 常见的 “type-checking explosion”。

用 LLDB 调试 SwiftUI 应用 (LLDB Power User Guide: Essential Commands & SwiftUI Debugging)

调试 SwiftUI 向来不轻松。相比在代码里不断插入 print，尽管 LLDB 的能力更强大，但却往往被忽略。在这篇文章中，Jai Krishna 通过大量 SwiftUI 示例演示了如何在 LLDB 中实时查看和修改 @State、@Binding、@Published 的内部状态，使用 Self._printChanges() 追踪视图的重绘来源，并借助精细化的断点策略定位布局与交互问题。

如何查找应用的挂起原因 (Identifying Hangs in iOS Apps)

许多开发者都会遇到主线程阻塞导致的 UI 挂起，但具体卡在什么位置、由何引起，并不是每个人都能准确调试。Tiago Henriques 通过一个刻意制造卡顿的示例 App，演示了如何利用 Instruments 的 Time Profiler 来初步判断问题的性质和范围。复现与识别只是解决问题的第一步，作者也表示如果读者感兴趣，未来还会继续推出这一主题的深入内容。

工具

SwiftUI Ratings

如果你正在为 App 构建评分/评论界面，或希望在应用内更自然地引导用户前往 App Store 留下评价，由 James Sedlacek 开发的 SwiftUI-Ratings 提供了一套即插即用的解决方案。它实现了一个高度可定制的评分界面，风格上与 App Store 的评分与评论页相近，允许开发者通过 AppRatingProviding 协议灵活接入任意数据源（项目中提供了 mock 实现与 Supabase / App Store Connect API 示例）。对于需要快速搭建“应用内评分请求”功能的开发者来说，这是一个轻量、现代、且易于扩展的选择。

Swift Hugging Face

Hugging Face 是全球领先的开源 AI 社区与模型平台，提供海量模型、数据集、工具链及协作空间，作为关键的 AI 基础设施，赋能研究者、工程师与企业高效构建并部署 AI 应用。

作为 Hugging Face 官方出品的 Swift 客户端，Swift Hugging Face 提供了两大核心能力：一方面，它完整封装了 Hugging Face Hub API，使开发者能够以原生 Swift 方式管理模型、数据集、Spaces 等资源；另一方面，它无缝集成 Inference API，让文本生成（Chat Completion）、文本向量化、文生图/视频（Text-to-Image/Video）、语音转写等任务能够直接在 iOS、macOS、visionOS 乃至 Linux 与 Windows 上运行。

在文章 Introducing swift-huggingface: The Complete Swift Client for Hugging Face 中，Mattt 详细阐述了该库的设计理念与核心使用方式，为 Swift 开发者打开了接入 Hugging Face AI 生态的完整路径。

When Android Phones “Force-Compat” with AirDrop

Read on web →

AirDrop has long enabled fast, lossless, cable-free transfers across Apple devices, forming a signature and tightly guarded advantage within the Apple ecosystem. But this long-standing situation has taken an unexpected turn. A few days ago, Google announced that the Pixel 10 can now interoperate with AirDrop without Apple’s involvement, bringing AirDrop-compatible wireless sharing to Android through Quick Share.

Shortly after, Qualcomm stated that Snapdragon-powered Android devices will “soon” support the same capability. In other words, this is no longer a Pixel-only experiment—it may spread quickly across the broader Android landscape.

Beyond Google’s technical effort, the decisive catalyst behind this breakthrough is likely the EU’s Digital Markets Act (DMA). AirDrop is built on AWDL (Apple Wireless Direct Link), a protocol that remains entirely private. However, under DMA’s interoperability requirements, Apple added support for Wi-Fi Aware starting in iOS 26. This dramatically lowered the barrier for this “forced compatibility”: Android phones can now broadcast standard Wi-Fi Aware signals to discover iPhones. And because this relies on an official industry standard, discovery is fast, connections are stable, and Apple has very limited grounds—legally or technically—to block it.

Over the years, the Android ecosystem has repeatedly initiated “pro-Apple compatibility”: from cross-platform file-transfer apps, to manufacturers adding support for Apple’s Live Photo format, and now to system-level near-field sharing. On one hand, this reflects the fact that many of Apple’s user experiences are genuinely superior; on the other hand, it shows how far Android manufacturers are willing to go to attract users embedded in the Apple ecosystem—actively aligning their experience with Apple’s. DMA, often criticized as overly strict, has in this case served as a perfectly timed catalyst, nudging Apple toward greater “openness” and enabling more seamless cross-platform experiences for consumers.

For Apple, however, the real challenge goes beyond regulatory battles. To maintain its ecosystem advantage, it must continue delivering new, compelling experiences. If one day such “forced compatibility” is no longer needed—because Apple’s distinctiveness has faded—that would be the scenario Apple fears far more than today’s developments.

Previous Issue｜Newsletter Archive

This Week’s Sponsor

Native macOS AI Client: GPT, Claude, Gemini & Local Models

Stop Context Switching · Truly Native · Ultra-Low Memory Usage

Tired of browser tabs eating up your RAM? Try BoltAI.

It seamlessly integrates GPT, Claude, Gemini, and Ollama local models directly into your development workflow. Access the latest AI capabilities in a unified, native interface.

With features like screen context awareness and instant code explanation, it’s the ultimate native AI tool built for developers.

🎉 Special Offer for Fatbobman Readers:
Use code BFCM25 for 51% OFF

🚀 Try BoltAI Today

Recent Recommendations

From iOS to Android: A Candid Look at My Real-World Journey into Dual-Platform Development

For many developers in the Apple ecosystem, Android feels both familiar and distant: massive user base yet fragmented ecosystem; significant revenue potential yet uncertain investment returns. This ambivalence keeps many hesitating over whether to develop an Android version. Senior iOS developer Shudao Wang has pursued a “dual-platform parallel” strategy for years. In this article, he shares real-world experiences from dual-platform development: how to align features across platforms, trade-offs when facing system differences, variations in operational performance, and changes in revenue structure.

Skip Framework: A Cross-Platform Journey for Native iOS Developer

Maxim Ermolaev shares his practical experience migrating a SwiftUI app to Android, revealing Skip’s real-world capabilities and boundaries. For SwiftUI features Skip already supports, the migration process is relatively smooth. For advanced features not yet covered, the author uses ComposeView to embed Jetpack Compose code directly within the same Swift file, providing customized implementations for the Android side. Maxim’s conclusion is pragmatic: Skip is sufficient for iOS-first teams to quickly obtain a “functional and consistent” Android client. However, achieving pixel-perfect visual and interaction parity across both platforms requires more platform-specific work on the Android side, or using Skip Lite to share business logic while keeping the UI fully native.

As the Swift Android SDK matures and tools like Skip continue to improve, Swift’s possibilities in the Android world are rapidly transitioning from “experimental” to “production-ready.” These two authors present the current real-world path from different perspectives, providing valuable reference for Swift developers considering “crossing to the other side.”

Building Mac Farm: Running 2000+ iOS Pipelines Daily

In this article, Yusuf Özgül details how the Trendyol team built a macOS Farm consisting of 130 devices from scratch to comfortably support over 2000 iOS pipelines daily. The entire system uses a self-developed VM management system based on Apple Virtualization Framework, solves secure auto-login for batch devices through Authorization Plug-ins, identifies and fixes performance bottlenecks in VM’s P/E Core recognition, and builds a Grafana monitoring and alerting system to achieve a self-healing Runner cluster. For pipelines, performance is further enhanced through Tuist Cache (approximately 70% faster builds) and selective testing (approximately 80% faster tests).

A rare comprehensive case study of macOS Farm implementation: from virtualization architecture to performance tuning, from logging and monitoring to pipeline design, covering nearly all key aspects needed for enterprise-level iOS CI/CD.

Building iOS and Mac apps in Zed: SwiftUI Previews

While developers can now develop and debug iOS apps in Zed, they still cannot access Xcode’s killer feature: Preview. The typical workaround is to keep an Xcode preview window open alongside Zed, but Xcode doesn’t automatically jump to the corresponding Preview when switching between SwiftUI files. Adrian Ross shares a clever trick: using a script combined with Zed Task to synchronize Xcode with Zed’s editing view, automatically displaying the corresponding Preview in an external preview window, essentially replicating the “using Preview in Zed” experience.

This approach isn’t limited to Zed—any macOS editor can use similar methods to work seamlessly with Xcode’s Preview functionality.

Enabling Selection, Double-Click and Context Menus in SwiftUI List Rows on macOS

macOS’s SwiftUI List differs significantly from iOS in desktop-specific interactions like row selection, double-click, and context menus. Developers need to use a List initializer with a selection parameter to enable selection functionality, and use the contextMenu(forSelectionType:menu:primaryAction:) modifier to implement both double-click operations and context menus. Compared to iOS, macOS’s List is closer to AppKit’s table-style interaction model. In this article, Gabriel Theodoropoulos demonstrates with concise examples how to properly combine these APIs to implement standard desktop interactions in macOS SwiftUI lists.

Using Associated Domains Alternate Mode during Development

When developing features involving Associated Domains (such as Universal Links, Shared Web Credentials, or App Clips), iOS by default fetches the apple-app-site-association (AASA) file through Apple’s CDN rather than directly from the server. While this works well in production, it causes inconvenience during development: file changes require waiting for CDN propagation, and local or staging servers may not be publicly accessible at all. Natascha Fadeeva introduces Apple’s Alternate Mode: by adding suffixes like ?mode=developer to Associated Domains entries, iOS bypasses the CDN and fetches the AASA file directly from the server. With this mechanism, developers can make configurations take effect immediately and debug in local environments without waiting for CDN cache refresh, significantly improving development efficiency.

Understanding Data Races: A Visual Guide for Swift Developers

Data races are a core concept in concurrent programming that’s difficult to understand. Krishna uses a series of illustrations—several ToddlerBots (toddler robots) coloring the same coloring page together—to visually demonstrate how shared mutable state causes chaos in concurrent environments: from minor result inconsistencies to logic failures and even crashes caused by interleaved reads and writes.

The article’s greatest strength is being “richly illustrated.” The ToddlerBot visual narrative successfully transforms a traditionally dry and serious technical topic into something vivid and easy to understand. Krishna indicates that future articles will continue using the ToddlerBot character to build a coherent mental model for Swift concurrency.

Teaching AI to Read Xcode Builds

While today’s AI may not consistently outperform seasoned developers at writing code, it is almost always superior at reading data and breaking down complex problems—especially when the information it receives is rich and well-structured. With Apple open-sourcing swift-build, the Tuist team gained access to detailed build-event data directly from the build service, storing it in SQLite so AI agents can genuinely understand a build rather than merely scrape xcodebuild’s text output.

In this article, Pedro Piñera walks through this approach and demonstrates, with real-world cases such as Wikipedia iOS and Tuist, how AI can leverage structured build data to provide diagnostics and optimization insights far beyond traditional log parsing. The result is a clear technical path toward real-time build observability and AI assistants that truly “understand” the build system.

Tools

SwiftUI-Popover: A Popover Library Supporting watchOS

While SwiftUI provides the .popover modifier, its behavior varies across platforms: on iPhone it degrades to a sheet, and watchOS doesn’t support it at all. Quirin Schweigert‘s SwiftUI-Popover is a lightweight, pure SwiftUI popover library that provides consistent popover functionality across platforms, supporting all SwiftUI platforms including watchOS. The library’s distinctive feature is that arrows automatically follow the attachment point position and can be flexibly embedded into any view hierarchy.

// 1. Attach popover
  Image(systemName: “globe”)
      .swiftUIPopover(
          isPresented: $showPopover,
          isDismissible: true,        // Tap background to dismiss
          isExclusive: true,           // Exclusive display
          preferredAttachmentEdge: .top // Prefer attaching at top
      ) {
          Text(”Popover content”)
      }
​
  // 2. Enable popover rendering on container view
  .presentPopovers()

SwiftIR: Modern ML Compiler Infrastructure for Swift

Currently available ML paths in Swift mainly include Foundation’s _Differentiation, handwritten Accelerate/Metal, and the now-discontinued Swift for TensorFlow. However, they face performance bottlenecks, high development costs, or lack of maintenance respectively. SwiftIR, developed by Pedro N. Rodriguez, emerged as a solution to these challenges.

SwiftIR intercepts Swift’s native automatic differentiation (@differentiable) operations through DifferentiableTracer, automatically builds complete computation graphs, and compiles to the same runtime (XLA/PJRT) as JAX/TensorFlow for execution on CPU/GPU/TPU. The project’s biggest breakthrough: While loop compilation time remains constant (~43ms, compared to tens of minutes for traditional unrolling), gradient overhead is only ~1.0x (compared to 2.5-4.3x for standard Swift), with performance significantly superior to standard Swift at scale. This brings truly modern ML compiler infrastructure to Swift.

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

Share

当 Android 手机『强行兼容』AirDrop

网页版

AirDrop 让使用者可以在各种不同类型的苹果设备上高效、无损的数据传输，它一直是苹果生态的专属且核心功能。但，这种情况现在出现了“奇怪”的变化。几天前，谷歌宣布在 Pixel 10 中，在没有苹果的参与下，为 Quick Share 提供了 AirDrop 的兼容机制，实现了安卓手机与苹果手机基于 AirDrop 的无线互通。

随后，高通也宣布其搭载 Snapdragon 的 Android 设备“很快就会”支持这一路线，也就是说这不再是 Pixel 的专属功能，而有望扩展到更广泛的 Android 手机阵营。

除了谷歌的技术能力外，本次互通的最大推手或许正是 DMA(欧盟《数字市场法案》)。AirDrop 依赖的技术是 AWDL (Apple Wireless Direct Link)，即便到现在也是私有的。但是 DMA 的要求下，苹果从 iOS 26 开始引入了对 Wi-Fi Aware 支持，这大幅降低了本次“强行兼容”的难度。安卓手机可以直接发出标准的 Wi-Fi Aware 信号去寻找 iPhone，并且由于走的是官方标准协议，连接极其稳定，发现速度极快，而且苹果很难有理由去封杀。

从厂商提供跨端应用实现无线互联，到部分厂商主动适配苹果的 livePhoto，这些年从安卓阵营发起的对苹果的主动兼容屡见不鲜。这一方面表现出了苹果的很多实现和体验确有过人之处，另一方面也展现出安卓厂商更愿意为了获取苹果生态的用户而主动出击，在体验上对齐。DMA 这种在某些方面看起来过分苛刻的法规，又恰如其分的促使了苹果的“开放”，从而创造出更多的跨平台无缝体验，满足了相当一部分消费者的需求。

对于苹果来说，在法律攻防战外，只有不断地推出更具吸引力的新功能才能保持苹果生态的“优势”。一旦某一天，这种“强行兼容”不再有需求，那么就意味着苹果的“独特性”衰落了。相比起现在的情况来说，我想苹果更不想看到这样的场景出现。

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

本期赞助

Mac 原生 AI 客户端：聚合 GPT、Claude、Gemini 及本地最新模型

受够了浏览器吃光内存？试试 BoltAI。

它将 GPT、Claude、Gemini 以及 Ollama 本地模型无缝集成到你的开发工作流中。无论模型如何迭代，你都能第一时间在原生界面中调用最强能力。

支持屏幕上下文感知、代码解释与重构，是真正属于开发者的 Mac 原生 AI 神器。

🎉 周报读者限时福利：
凭代码 BFCM25 可享 51% OFF

🚀 立即试用 BoltAI!

近期推荐

当我决定同时做 iOS 和 Android：独立开发者的真实双平台之路

在不少苹果生态开发者眼中，Android 既熟悉又遥远：用户规模巨大，但生态碎片化；潜在回报可观，但投入成本不确定。许多人因此对“要不要做 Android 版本”始终犹豫不决。资深 iOS 开发者道哥采用“双平台并进”策略多年。在本文中，他分享了双平台开发的实战经验：双端功能如何对齐、遇到系统差异时的权衡、两边的运营表现差异、收入结构的变化等。

Skip 框架的跨平台实践 (Skip Framework: A Cross-Platform Journey for Native iOS Developer)

Maxim Ermolaev 分享了他将 SwiftUI 应用迁移到 Android 的实践经验，呈现了 Skip 在真实项目中的表现与边界。对 Skip 已支持的 SwiftUI 功能，迁移过程相对顺畅；而对于尚未覆盖的高级特性，作者则通过 ComposeView 在同一 Swift 文件中直接嵌入 Jetpack Compose 代码，为 Android 侧提供定制实现。Maxim 的结论相当务实：Skip 足以让 iOS-first 团队快速获得一个“可用且一致”的 Android 客户端。但如果目标是两端达到完全一致的视觉与交互体验，则仍需在 Android 侧做更多平台特化，或采用 Skip Lite 共享业务逻辑、将 UI 保持为原生实现。

随着 Swift Android SDK 的成熟与 Skip 等工具的不断完善，Swift 在 Android 世界的可能性正迅速从“实验性”迈向“可落地”。两位作者从不同角度呈现了当前的真实路径，也为正在考虑“跨到另一边”的 Swift 开发者提供了难得的参考。

打造每天跑 2000+ 条流水线的 Mac 机器农场 (Building Mac Farm: Running 2000+ iOS Pipelines Daily)

在本文中，Yusuf Özgül 详述了 Trendyol 团队如何从零搭建一套由 130 台设备组成的 macOS Farm，以从容支撑每天 2000+ 条 iOS 流水线的实战经验。整套系统采用基于 Apple Virtualization Framework 自研的 VM 管理体系、通过 Authorization Plug-ins 解决批量设备的安全自动登录、定位并修复 VM 在 P/E Core 识别上的性能瓶颈，并构建 Grafana 监控与告警系统，实现自愈式 Runner 集群。在流水线上，通过配合 Tuist Cache（构建提速约 70%）与选择性测试（测试提速约 80%）进一步提高了性能。

少见的 macOS Farm 落地全景案例：从虚拟化架构到性能调优，从日志与监控到流水线设计，几乎覆盖了企业级 iOS CI/CD 所需的全部关键环节。

在 Zed 中实现 SwiftUI 预览的小技巧 (Building iOS and Mac apps in Zed: SwiftUI Previews)

尽管目前开发者已经可以在 Zed 中开发调试 iOS 应用了，但仍无法实现 Xcode 中的杀手级功能：Preview。通常的替代方案是在 Zed 旁边再开一个 Xcode 预览窗口，但切换编辑的 SwiftUI 页面后，Xcode 并不会自动跳转到对应的 Preview。Adrian Ross 分享了一个小技巧：通过一个脚本配合 Zed Task，实现 Xcode 与 Zed 的编辑页面同步，从而在外部预览窗口中自动同步展示对应的 Preview，基本复刻了“在 Zed 中使用 Preview”的体验。

这一思路不仅适用于 Zed，任何在 macOS 上的编辑器都可以用类似方式与 Xcode 的 Preview 功能协同工作。

在 macOS 的 SwiftUI 列表中启用选择、双击和右键菜单 (Enabling Selection, Double-Click and Context Menus in SwiftUI List Rows on macOS)

macOS 的 SwiftUI List 在行选择、双击和右键菜单等桌面端特有交互上，与 iOS 存在显著差异。开发者需要使用带 selection 参数的 List 初始化器来启用选择功能，并通过 contextMenu(forSelectionType:menu:primaryAction:) 修饰器同时实现双击操作和右键菜单。相比 iOS，macOS 版的 List 更接近 AppKit 的表格式交互模型。在本文中，Gabriel Theodoropoulos 以一套简洁的示例展示了如何在 macOS 的 SwiftUI 列表中正确组合这些 API 以实现桌面端标准交互。

开发阶段使用 Associated Domains 的替代模式 (Using Associated Domains Alternate Mode during Development)

在开发涉及 Associated Domains 的功能（如 Universal Links、Shared Web Credentials 或 App Clips）时，iOS 默认通过 Apple CDN 获取 apple-app-site-association (AASA) 文件，而非直接从服务器获取。这在生产环境中运行良好，但在开发阶段会带来不便：文件更改需要等待 CDN 传播，本地或测试服务器可能根本无法公开访问。Natascha Fadeeva 介绍了苹果提供的 Alternate Mode（替代模式）：通过在 Associated Domains 条目中添加 ?mode=developer 等后缀，让 iOS 绕过 CDN，直接从服务器拉取对应的 AASA 文件。借助此机制，开发者可以让配置即时生效、在本地环境调试，而不必等待 CDN 缓存刷新，大幅提升开发效率。

用可视化方式理解 Swift 中的数据竞争 (Understanding Data Races: A Visual Guide for Swift Developers)

数据竞争是并发编程中难以理解的核心概念。Krishna 通过一系列图片：几个 ToddlerBot（幼儿机器人）一起给同一张涂色页上色，以直观方式展示了共享可变状态在并发环境中如何引发混乱：从轻微的结果错乱，到读写交错导致的逻辑失效甚至崩溃。

本文最大的特色在于“图文并茂”。ToddlerBot 的视觉化叙事成功把传统上枯燥严肃的技术主题变得生动易懂。Krishna 表示后续文章将继续沿用 ToddlerBot 这一角色，构建一套连贯的 Swift 并发心智模型。

教 AI 读懂 Xcode 构建 (Teaching AI to Read Xcode Builds)

如果说当下 AI 在“写代码”这件事上未必优于经验丰富的开发者，那么在“看数据、拆问题”上，它几乎一定强过大多数人类，而且输入的信息越多、越结构化，优势越明显。苹果开源 swift-build 之后，Tuist 团队得以直接从构建服务中获取详尽的构建事件数据，并将其以结构化的方式写入 SQLite，让 AI 代理能够真正“理解”一次构建，而不只是被动解析 xcodebuild 的文本输出。在本文中，Pedro Piñera 详细介绍了这一尝试的实现路径，并通过在 Wikipedia iOS、Tuist 等真实项目上的实测，展示了 AI 如何基于这些结构化数据做出远超“读日志”的诊断和优化建议，为未来的实时构建可观测性以及真正“懂构建”的 AI 助手描绘出一条相当清晰的技术路线。

工具

SwiftUI-Popover: 支持 watchOS 的气泡提示库

尽管 SwiftUI 提供了 .popover 修饰器，但它在不同平台上的表现并不一致：iPhone 上会降级为 sheet，watchOS 则完全不支持。Quirin Schweigert 开发的 SwiftUI-Popover 是一个轻量级、纯 SwiftUI 实现的 Popover 库，提供跨平台一致的气泡提示功能，支持包括 watchOS 在内的所有 SwiftUI 平台。该库的特色在于箭头会自动跟随附着点位置，且可以灵活嵌入到任何视图层级中。

// 1. 附加 popover
  Image(systemName: “globe”)
      .swiftUIPopover(
          isPresented: $showPopover,
          isDismissible: true,        // 可点击背景关闭
          isExclusive: true,           // 独占显示
          preferredAttachmentEdge: .top // 优先附着在顶部
      ) {
          Text(”气泡内容”)
      }
​
  // 2. 在容器视图上启用 popover 渲染
  .presentPopovers()

SwiftIR: Swift 的现代 ML 编译基础设施

目前 Swift 中可用的 ML 路径主要包括 Foundation 的 _Differentiation、手写 Accelerate/Metal，以及已经停更的 Swift for TensorFlow。但它们分别面临性能瓶颈、开发成本高或缺乏维护等问题。由 Pedro N. Rodriguez 开发的 SwiftIR，正是在这种背景下出现的解决方案。

SwiftIR 通过 DifferentiableTracer 拦截 Swift 原生自动微分（@differentiable）的运算过程，自动构建完整计算图，并编译到与 JAX/TensorFlow 相同的运行时（XLA/PJRT），最终在 CPU/GPU/TPU 上执行。项目最大的突破在于：While 循环编译时间保持常数（~43ms，传统展开需要数十分钟），梯度开销仅 ~1.0x（标准 Swift 为 2.5-4.3x），在大规模计算时性能显著优于标准 Swift。为 Swift 带来了真正现代化的 ML 编译基础设施。

When AI Makes “Seeing Is Believing” Impossible

Read on web →

Nearly thirty years have passed since I graduated from college. Most of my classmates are now fully absorbed in their careers and families, so our alumni chat stays quiet for long stretches of time. But last Thursday night, an unexpected burst of activity suddenly broke the silence.

A classmate who hadn’t appeared in over a decade rejoined the conversation, saying his family was going through a difficult situation and asking if anyone could help. Almost immediately, doubts were raised—was it really him? Many of my former classmates work in legal professions, and their instincts tend to be finely tuned to anything that feels off.

We went through the usual steps: voice calls, video chats, back-and-forth questions. Still, some remained unconvinced. “AI makes impersonation way too easy now. Video and voice aren’t enough anymore.”
It wasn’t until more personal details surfaced—shared memories, old nicknames, inside jokes known only to our class—that everyone finally felt reassured. Once his identity was confirmed, help arrived quickly, and the immediate crisis was resolved.

Strictly speaking, it’s hard to blame anyone for being suspicious. When a single smartphone can “swap faces” or “alter voices,” seeing is believing no longer holds up. Social media is flooded with AI-generated oddities, and our tolerance for the absurd has quietly risen. Whose pet doesn’t talk or cook online these days? And if a UFO actually landed one afternoon, people might not be surprised at all—our threshold for the unknown has been reshaped.

This shift has brought a new kind of anxiety:

We once worried about not getting information fast enough or broadly enough; now we worry about whether the information is even real. “Trusted sources” have become a scarce commodity.

And no, AI shouldn’t shoulder the blame alone. It remains a tool. The ones exploiting it for deception are still people—the tactics have simply evolved, and the cost of lying has dropped dramatically.

Against this backdrop, rebuilding truth and trust becomes increasingly difficult.
Perhaps we’ll need to “fight fire with fire”: digital signatures, trusted timestamps, blockchain-based verification. None of these are perfect solutions, but they may be meaningful paths forward.

My mother used to tell me when I was young: “Doing good is like climbing uphill; doing harm is like falling off a cliff.”

The same is true of trust—infinitely harder to rebuild than to destroy, which is precisely what makes it precious.

Previous Issue｜Newsletter Archive

This Week’s Sponsor

Need to debug HTTPS on your iPhone?

Try Proxyman! The best-in-class macOS that helps you capture/debug HTTP(s) with a few clicks. Support iOS devices and Simulator.

🎉 Black Friday Offer – 30% OFF this week only! Get Started Now →

Recent Recommendations

Deep Dive into iMessage: Behind the Making of an Agent

As Apple ecosystem developers, we often face a subtle paradox: the system possesses powerful capabilities, but these aren’t necessarily exposed to developers through public APIs. iMessage is a prime example—deeply integrated into iOS and macOS as a core communication tool for users, yet it has never provided automation interfaces for developers. LingJueYa, the author of imessage-kit, shares his exploration journey in building this tool. The core challenges almost all stem from the Apple platform itself: parsing timestamps with a 2001 epoch, recovering NSAttributedString content from binary plists, safely accessing resources within macOS’s sandbox system, and working with AppleScript—a venerable automation mechanism.

2025: The Year SwiftUI Died

Jacob Bartlett‘s provocatively titled article presents a discussion-worthy perspective: 2025 might mark a turning point for SwiftUI, rather than its peak. His core argument centers on Apple introducing the @Observable macro and updateProperties() method to UIKit, giving it modern state management capabilities, while the maturation of AI-assisted programming tools has dramatically reduced the cost of writing UIKit code (whereas AI’s understanding of SwiftUI’s declarative paradigm remains insufficient).

Apple’s long-term commitment to SwiftUI isn’t going anywhere — especially given its natural advantages in multi-platform adaptation. Meanwhile, the rise of AI has made it easier for many developers who started with SwiftUI to lean on UIKit when they need to fill performance or capability gaps. In practice, the choice for most adults isn’t either-or, but using both together in the most effective way.

Automatic Property Observation in UIKit with @Observable

UIKit officially introduced native support for Swift Observation in iOS 26. When you read properties of an @Observable object in updateProperties(), UIKit automatically tracks these dependencies and refreshes the corresponding views on-demand when data changes. Natalia Panferova demonstrates the convenience of this feature for cross-framework data sharing through a practical case mixing UIKit and SwiftUI. The article also introduces the iOS 18 backward compatibility solution: add the UIObservationTrackingEnabled key to Info.plist and place the update logic in viewWillLayoutSubviews() to achieve the same effect.

How SwiftData Represents AttributedString in Core Data Storage

Although AttributedString itself conforms to Codable, developers previously couldn’t use it directly as a property in SwiftData models. This restriction was finally lifted in iOS 26—Apple clearly opened a “special channel” for it, and now it can be stored directly like basic types such as Int and String. Oleksii Oliinyk, author of DataScout for SwiftData (a SwiftData database analysis app), encountered related crashes while maintaining the tool and took the opportunity to deeply analyze the implementation mechanism behind it.

SwiftData’s ability to allow developers to use Codable-conforming types as model properties is itself a powerful feature. However, its underlying handling may differ from what many people expect. In “Considerations for Using Codable and Enums in SwiftData Models,” I provide a more systematic introduction to SwiftData’s Codable conversion logic and potential pitfalls. Additionally, if you need to save AttributedString before iOS 26, you can refer to this thread on Apple’s developer forums.

Introducing AnyLanguageModel: One API for Local and Remote LLMs on Apple Platforms

AnyLanguageModel is a unified Swift LLM interface library developed by Mattt. We introduced its core concept in Issue 109. Building on Foundation Models’ API design, the library maintains a familiar developer experience while uniformly supporting multiple model providers, including local models (Core ML, MLX, llama.cpp, Ollama) and cloud models (OpenAI, Anthropic, Google Gemini, etc.), significantly reducing the integration burden across different APIs and execution methods, and making it easier to explore open-source models.

In this article, Mattt further introduces AnyLanguageModel’s design philosophy, cross-backend capability abstraction, and how Swift 6.1 package traits help control dependency size. Notably, while Apple currently doesn’t provide image input capability in Foundation Models, AnyLanguageModel has already added this functionality for models like Claude, enabling vision-language scenarios to work smoothly on Apple platforms.

Approachable Concurrency and MainActor by Default

Regardless of how things ultimately unfold, Approachable Concurrency introduced in Swift 6.2 is destined to leave a significant mark in Swift’s history. It significantly reduces the mental burden of concurrent programming in certain scenarios, but has also left many developers feeling “more confused the more it’s explained.”

• In Approachable Concurrency in Swift 6.2: A Clear Guide, Antoine van der Lee provides a systematic overview of the relevant proposals and new behaviors.

• After conducting extensive research and sharing about these features, Matt Massicotte emphasizes in his latest article MainActor by Default: at least for now, he won’t enable Default actor isolation = MainActor in his projects, because “understanding why MainActor is needed is far simpler than understanding why or how to remove it.”

• However, one thing is crystal clear: MainActor by Default aligns perfectly with embedded platforms. In Embedded Swift Improvements Coming in Swift 6.3, Doug Gregor and Rauhul Varma further demonstrate the improvement direction and motivation for Swift 6.3 on embedded platforms.

How to Build Scalable White-Label iOS Apps: From Multi-Target to Modular Architecture

A White-Label product refers to a flexible, reusable app framework that can be deployed across different clients, with customizable branding and feature configurations (such as a universal restaurant ordering app template). Pawel Kozielecki systematically outlines the evolution of iOS White-Label applications in this comprehensive article, dividing it into three stages: basic branding customization, custom UI/UX, and full modularization. Building on this foundation, he compares three common implementation strategies—multi-target, resource replication, and modular architecture—and points out that as the number of clients and differentiation requirements grow, only modular architecture can truly scale long-term and avoid maintenance chaos. The article also discusses key challenges in scaling white-label projects, including App Store review, code signing, resource and configuration layering, testing, and CI, all with abundant practical details.

Tools

QuickLayout: Declarative UIKit Layout Library

Since UIKit can now seamlessly integrate Observation, it’s no surprise that writing layout code in SwiftUI style is also possible. QuickLayout, developed by Constantine Fry, provides exactly this capability and has been used by Meta in Instagram’s core features. You can lay out views directly like this:

import QuickLayout
​
@QuickLayout
class MyCellView: UIView {
​
  let titleLabel = UILabel()
  let subtitleLabel = UILabel()
​
  var body: Layout {
    HStack {
      VStack(alignment: .leading) {
        titleLabel
        Spacer(4)
        subtitleLabel
      }
      Spacer()
    }
    .padding(.horizontal, 16)
    .padding(.vertical, 8)
  }
}

UIKit and SwiftUI were never opposites, but rather two UI thinking models that can learn from each other. Currently, SwiftUI’s advantages lie in abstraction and consistency, while high performance, fine-grained control, and toolchain support remain UIKit’s strengths.

SettingsKit

Nearly all apps need a settings interface. While not difficult to write, maintenance costs rise as options multiply. SettingsKit, developed by Aether, was created to address this. It enables SwiftUI developers to quickly build scalable, consistently styled settings interfaces with built-in search capabilities, featuring multiple styles including grouped, card, and sidebar layouts—ideal for medium to large settings modules.

KurrentDB-Swift

Kurrent (formerly EventStoreDB) is a database specifically designed for event storage. It not only saves the current state of a system but also maintains a complete record of every change in its history, making it ideal for scenarios requiring strong traceability such as finance, logistics, retail, e-commerce, and SaaS. As a Swift client library for KurrentDB, KurrentDB-Swift developed by Grady Zhuo supports Swift 6, async/await streaming subscriptions, and event reading, filling a long-standing gap in the Swift ecosystem for mature Event Sourcing tools.

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

Share

毕业 30 年同学群：一场 AI 引发的“真假难辨”危机

网页版

大学毕业快三十年了，同学们大多忙于事业与生活，群里常年冷清。但上周四晚上，一阵久违的热闹突然打破了沉寂。

一位十几年未露面的同学重新加入群聊，说家里遭遇了变故，向大家求助。很快就有人提出质疑——这真的是本人吗？毕竟群里多数人从事法律相关工作，职业敏感度让他们对任何异常格外警觉。

语音通话、视频聊天，一轮轮验证下来，仍有人不放心：“现在 AI 造假太容易了，光凭这些可不够。”直到更多细节被摆上桌面——共同经历、内部昵称、只有我们知道的旧梗——大家才最终确认身份，随即伸出援手，帮助他度过暂时的难关。

严格来说，并不能怪大家变得多疑。在如今一部手机就能“换头”“变声”的时代，“眼见为实”早已不再成立。社交媒体上布满了由 AI 生成的各种离奇情景，人们对“离谱视频”的耐受度不断被拉高：谁家的宠物不会说话、做饭呢？也许哪天真看到 UFO 降落，都不会再令人惊讶——我们对未知的恐惧阈值，正在被悄悄重塑。

随之而来的，是一种新的信息焦虑：过去担心的是获取不及时、不全面；如今担心的是获取的内容是否真实。“可信来源”，正在变成一件稀缺品。

当然，这一切不能算在 AI 头上。AI 本质上只是工具，真正利用它造假、行骗的仍然是人，只是欺骗的方式变了、成本更低了。

在这种背景下，重拾真实与信任，只会变得愈发困难。
或许，最终仍需“魔法打败魔法”：数字签名、可信时间戳、区块链验证……它们未必是完美解法，但至少是值得探索的方向。

从小我母亲就常说：“从善如登，从恶如崩”。

信任亦如此——重建远比摧毁艰难，却也正因如此才显得格外珍贵。

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

本期赞助

需要在 iPhone 上调试 HTTPS？

试试 Proxyman！这是一款顶级的 macOS 应用，只需点击几下，即可轻松捕获和调试 HTTP(s) 流量。支持 iOS设备和模拟器。

🎉 黑五特惠 — 本周限时 7 折！ 立即试用 →

近期推荐

深入 iMessage 底层：一个 Agent 是如何诞生的

作为 Apple 生态的开发者，我们常常会面对一个微妙的悖论：系统本身具备强大的能力，但这些能力并不一定以公开 API 的形式向开发者开放。iMessage 正是其中的典型 —— 它深度融入 iOS 与 macOS，是用户日常沟通的核心载体，却始终没有提供可供开发者使用的自动化接口。imessage-kit 的作者 LingJueYa，分享他在构建这一工具时的探索路径。但其核心挑战几乎都来自 Apple 平台本身：解析以 2001 为纪元的时间戳、从二进制 plist 中恢复 NSAttributedString 内容、在 macOS 的沙盒体系下安全地读取资源、以及与 AppleScript 这种历史悠久的自动化机制打交道。

SwiftUI 已死? UIKit 的回归之路 (2025: The Year SwiftUI Died)

Jacob Bartlett 的这篇文章标题颇具挑衅意味，他提出了一个值得讨论的观点：2025 年也许是 SwiftUI 的拐点，而不是它的巅峰。核心论点在于，苹果将 @Observable 宏和 updateProperties() 方法引入 UIKit，使其具备了现代化的状态管理能力；同时，AI 辅助编程工具的成熟极大降低了编写 UIKit 代码的成本（而 AI 对 SwiftUI 这种声明式范式的理解仍显不足）。

苹果对 SwiftUI 的长期投入不会动摇，尤其考虑到它在多端适配上的天然优势。与此同时，AI 的普及也让许多以 SwiftUI 入门的开发者更容易使用 UIKit 来补齐性能或能力上的不足。选择不一定要非此即彼，可以将两者结合起来用得更好。 这样更好吧

UIKit 中的视图自动刷新 (Automatic property observation in UIKit with @Observable)

UIKit 在 iOS 26 中正式引入了对 Swift Observation 的原生支持。当你在 updateProperties()中读取 @Observable 对象的属性时，UIKit 会自动追踪这些依赖关系，并在数据变化时按需刷新对应视图。Natalia Panferova 通过一个混合 UIKit + SwiftUI 的实际案例展示了这一特性在跨框架数据共享时的便利性。文章还介绍了 iOS 18 的向下兼容方案：在 Info.plist 中添加 UIObservationTrackingEnabled 键，并将更新逻辑放在 viewWillLayoutSubviews() 中即可实现相同效果。

SwiftData 对 AttributedString 的原生支持 (How SwiftData Represents AttributedString in Core Data Storage)

尽管 AttributedString 本身符合 Codable，但过去开发者并不能直接在 SwiftData 模型中将其作为属性使用。这一限制终于在 iOS 26 中被解除 —— 苹果显然为它开了一条“特别通道”，如今它已经可以像 Int、String 这样的基础类型一样直接存储了。DataScout for SwiftData（SwiftData 数据库分析应用）的作者 Oleksii Oliinyk 在维护工具时遭遇了相关的崩溃问题，并顺势深入分析了其背后的实现机制。

SwiftData 允许开发者将符合 Codable 协议的类型作为模型属性，这本身是一项十分强大的能力。但它的底层处理方式可能与许多人预想的并不相同。我在《在 SwiftData 模型中使用 Codable 和枚举的注意事项》中对 SwiftData 的 Codable 转换逻辑与潜在陷阱做了更系统的介绍。此外，如果你需要在 iOS 26 之前保存 AttributedString，可以参考苹果开发者论坛上的这个帖子。

AnyLanguageModel:统一 Apple 平台的 LLM 接口 (Introducing AnyLanguageModel: One API for Local and Remote LLMs on Apple Platforms)

AnyLanguageModel 是由 Mattt 开发的统一 Swift 大模型接口库，我们已在第 109 期周报中介绍过其核心理念。该库以 Foundation Models 的 API 设计为基础，在保持开发者熟悉的使用方式的同时，统一支持多种模型提供方，包括本地模型（Core ML、MLX、llama.cpp、Ollama）以及云端模型（OpenAI、Anthropic、Google Gemini 等），大幅降低了跨 API、跨运行方式所带来的集成负担，也让探索开源模型变得更容易。

在这篇文章中，Mattt 进一步介绍了 AnyLanguageModel 的设计思路、跨后端的能力抽象及 Swift 6.1 package traits 在控制依赖体积中的作用。值得一提的是，尽管苹果当前尚未在 Foundation Models 中提供图像输入能力，AnyLanguageModel 已为 Claude 等模型补上这一功能，使视觉-语言场景也能在 Apple 平台上顺利落地。

Approachable Concurrency 与 MainActor by Default

无论最终走向如何，Swift 6.2 中引入的 Approachable Concurrency 注定会在 Swift 发展史上留下浓重的一笔。它在某些场景下显著降低了并发编程的心智负担，但也让不少开发者感到“越解释越困惑”。

• 在 Approachable Concurrency in Swift 6.2: A Clear Guide 一文中，Antoine van der Lee 中对相关提案和新行为进行了系统梳理。

• Matt Massicotte 在对这些功能进行了详尽研究和分享后，他在最新文章 MainActor by Default 中强调：至少在现阶段，他不会在项目中启用 Default actor isolation = MainActor，因为“理解为何需要 MainActor，要比理解为何删除它更容易”。

• 不过有一点已经十分明确：MainActor by Default 与嵌入式平台非常契合。在 Embedded Swift Improvements Coming in Swift 6.3 一文中，Doug Gregor 和 Rauhul Varma 则进一步展示了 Swift 6.3 在嵌入式平台上的改进方向与动机。

构建可扩展的白标 iOS 应用 (How to Build Scalable White-Label iOS Apps: From Multi-Target to Modular Architecture)

白标产品（White-Label）指的是一个架构灵活、可在不同客户之间复用的通用 App 框架，能够按需更换品牌皮肤与功能配置（例如通用的订餐 App 模板）。Pawel Kozielecki 在这篇长文中系统梳理了 iOS White-Label 应用的演进路线，将其划分为三个阶段：基础品牌定制、自定义 UI/UX，以及完全模块化。在此基础上，他对比了三种常见实现策略——多 Target、资源复制、模块化架构，并指出随着客户数量与差异化需求增长，真正能够长期扩展、避免维护失控的方案只有模块化（Modular Architecture）。文章还结合大量实战细节，讨论了审核、签名、资源与配置分层、测试与 CI 等白标项目在规模化过程中的关键挑战。

工具

QuickLayout: 声明式 UIKit 布局库

既然 UIKit 已经可以无缝集成 Observation 了，那么以 SwiftUI 风格编写布局代码也就不足为奇了。由 Constantine Fry 开发的 QuickLayout 便提供了这样的能力，其已被 Meta 在 Instagram 的核心功能中使用。你可以直接以如下的方式进行布局:

import QuickLayout
​
@QuickLayout
class MyCellView: UIView {
​
  let titleLabel = UILabel()
  let subtitleLabel = UILabel()
​
  var body: Layout {
    HStack {
      VStack(alignment: .leading) {
        titleLabel
        Spacer(4)
        subtitleLabel
      }
      Spacer()
    }
    .padding(.horizontal, 16)
    .padding(.vertical, 8)
  }
}

UIKit 和 SwiftUI 从来不是对立面，而是两套可互相借鉴的 UI 思维模型。现阶段 SwiftUI 的优势在于抽象与一致性，而高性能、精细控制、工具链支持等仍是 UIKit 的特长。

SettingsKit

几乎所有应用都需要设置界面，虽然编写难度不高，但当选项不断增加时，维护成本也会随之上升。Aether 开发的 SettingsKit 正是为此而生。它让 SwiftUI 开发者可以快速构建一个可扩展、样式统一、并带有搜索能力的设置界面，并内置分组、卡片、侧栏等多种风格，适用于中大型设置模块的搭建。

KurrentDB-Swift

Kurrent（原 EventStoreDB）是一款专门用于事件存储的数据库，它不仅保存系统的最新状态，还能完整记录每一次变化的历史，非常适用于金融、物流、零售、电商、SaaS 等需要强可追溯性的场景。作为 KurrentDB 的 Swift 客户端库，由 Grady Zhuo 开发的 KurrentDB-Swift 支持 Swift 6、async/await 流式订阅与事件读取，补上了 Swift 生态在 Event Sourcing 领域长期缺乏成熟工具的空白。