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 个展位，欢迎前往官网和票务平台了解更多信息。