让 AI 看见 SwiftUI:Xcode Preview MCP 的实践、陷阱与期待
Xcode 26.3 是苹果第一次通过 MCP 把自身能力开放给外部 Agent。其中不少能力此前借助 CLI 也能获得,但 Preview 渲染是头一回出现。到了 Xcode 27,苹果又提供了 headless MCP server,调用起来更加顺手,于是我把 Preview 渲染大量嵌进了自己的 AI 工作流。一路用下来,踩了一些坑,也多了一些感悟和期待。
Xcode 26.3 是苹果第一次通过 MCP 把自身能力开放给外部 Agent。其中不少能力此前借助 CLI 也能获得,但 Preview 渲染是头一回出现。到了 Xcode 27,苹果又提供了 headless MCP server,调用起来更加顺手,于是我把 Preview 渲染大量嵌进了自己的 AI 工作流。一路用下来,踩了一些坑,也多了一些感悟和期待。
在 第一次看到 `ArrangementView` 的 API 时,我有一种说不出的别扭感。直到在 Xcode 27.1 beta 中实际使用后,这种感觉才逐渐清晰。查阅更多的苹果资料,再把它放回 iPhone Duo 的使用场景,我发现这份别扭其实来自两个方面:一部分源于我对它的定位不够清楚,理解之后便释然了;另一部分则来自 API 本身,即便想明白了,依然存在。
苹果新发布了 27.2 beta。尽管 iPhone Duo 模拟器依然缺席,但新增的 `project.xcproj` 令人眼前一亮。它替代的是 `.xcodeproj` 包里的那份构建图 `project.pbxproj`,而不是整个工程包。它有哪些亮点,解决了什么问题,又有哪些事情没有改变,本文将对此进行探讨。
数据集一大,SwiftData 的列表就开始卡。这是这几年里我听到最多的性能抱怨。SwiftUI 确实有责任,但并非最主要的问题。真正花时间之后会发现,慢的不只是一开始加载时间长,巨大的内存占用同样会把性能拖垮。本文将聊聊在 SwiftData 中为什么会出现这些问题,以及该从哪里下手改善。
AI 工作流的核心其实很简单——人定好验收标准,AI 执行并且按标准验收。说得没错,但实现起来并不容易。“标准”如何而来?如何得到尊重?随着上下文的增长或换一个新上下文,标准难免偏移甚至会被篡改。我需要一种可被信任的 AI 使用方式,简单来说就是“可委托”
从问答、代码生成,到让 Agent 接手更完整的工作,不知不觉间,我已经使用 AI 好几年了。这些年里,变化的不只是模型能力,人与 AI 的协作方式也一直在变。我也在一边使用,一边调整自己的方法。我关心的已经不只是“AI 能不能完成这项工作”,而是另外几个问题:执行范围是否稳定,结果能否被信任,投入是否可以预期,以及什么时候需要人介入。
在 WWDC 2026 中,苹果工程师介绍了 SwiftUI 的一个新特性——ContentBuilder。从使用方式看,它似乎只是一个覆盖范围更广的 ViewBuilder。苹果同时宣称,这项调整能够显著改善类型检查性能。本文将解析 ContentBuilder 的本质,探索性能提升背后的奥妙。
SwiftUI 的 Text 有一项默认行为:当段落末行只剩一个孤词或孤字时,它会主动把上一行的完整词组一并推到末行,避免“落单”。这份体贴多数时候是对的,但代价是上一行可能留下一大片空白——在窄容器或中英混排的场景中,反而破坏了段落的均衡。本文将挖掘 SwiftUI 中一个早已存在、却始终未曾公开的 API —— `avoidsOrphans`,让开发者重新拿回这项控制权。