Fatbobman's Swift Weekly #125
OpenClaw Is Impressive — I Just Don’t Really Need It (Yet)
OpenClaw Is Impressive — I Just Don’t Really Need It (Yet)
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.
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
LineMarkinstances), performance bottlenecks become almost inevitable. In such cases, stepping back to lower-level drawing APIs likePathoften 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.
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 个展位，欢迎前往官网和票务平台了解更多信息。
Well, I'm with you, boss. The Claude outage this morning was a reminder that we're a long way from sufficient reliability to achieve ubiquity. For me, the autonomous agent bar requires complete operational independence. I don't want something like a Waymo or Tesla car that literally stops working because it can't phone home. I get that the "ai bros" haven't figured out how to monetize me running models on my own compute, and that's the real barrier to discovering the marginal utility of frontier models. Like the dotcom era tech, we're only going to figure out where the real value for consumers lies after this hype cycle crashes. Apple seems to have foreseen this and was putting ML cores on chip before "ai" took off and seems to have been holding cash to await the inevitable to buy what they want again (as they did in the last big hype cycle). I'mma go check the Claude status page again. 🙄