AI-Friendly Framework:当抽象上移,验证如何跟上?
随着 AI Coding 的普及,不少人开始倾向一种观点:UIKit 这样的命令式框架,可能比 SwiftUI 更适合 Coding Agent。理由很直观——UIKit 的逻辑直接明确:创建对象、设置属性、加入层级、建立约束,每一步都有具体操作的实体;而 SwiftUI 把大量实现细节收束在声明式语法之后,状态、环境、身份、布局与渲染共同决定了最终结果。
随着 AI Coding 的普及,不少人开始倾向一种观点:UIKit 这样的命令式框架,可能比 SwiftUI 更适合 Coding Agent。理由很直观——UIKit 的逻辑直接明确:创建对象、设置属性、加入层级、建立约束,每一步都有具体操作的实体;而 SwiftUI 把大量实现细节收束在声明式语法之后,状态、环境、身份、布局与渲染共同决定了最终结果。
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 的本质,探索性能提升背后的奥妙。