越来越慢的 App Review，拦住了谁？
App Store 审核变慢，已经是越来越多开发者能够明显感受到的变化。在 Vibe Coding 时代，App 的开发和迭代成本大幅降低，审核压力随之增加并不难理解。但问题在于，更慢的审核似乎只是被不断增长的提交数量拖垮，却没有相应提高诈骗 App 进入商店的门槛。
最近，Jeff Johnson 在 Mac App Store 中发现了一款颇为可疑的 Safari 扩展：截图疑似 AI 生成，展示着并不存在的"4.9 分"评分，部分五星评论甚至早于 App 的上架时间。继续调查后，他发现该扩展的开发者在 App Store 中拥有 41 款 App，过去一年至少产生了 368 次获批的审核提交，平均几乎每天一次。而在同一时间，著名开发者 Marco Arment 的新 App 却已经在审核队列中等待了 12 天。
这形成了一种颇为尴尬的局面：一方面，可疑甚至涉嫌诈骗的 App 能够通过审核并在排行榜上高歌猛进；另一方面，AI 又让快速开发、频繁迭代变得前所未有地容易，大量正常提交与高风险提交共同涌入同一套审核机制，持续消耗有限的审核资源。
一个紧迫的问题摆在眼前：App Review 是否还应该孤立地对待每一次提交？
Johnson 建议引入类似信用体系的机制，让长期遵守规则、保持良好审核记录的开发者获得更快的审核，将更多资源投入高频、批量和存在异常行为的账号。反对者则担心，这最终可能演变成对知名开发者或付费开发者的优待，进一步抬高新人进入 App Store 的门槛。
在 AI 大幅降低 App 生产成本之后，仅仅把每一次 submission 当作彼此孤立的对象进行审核，这种模式已经越来越难以为继。将开发者历史、提交频率、App 之间的相似度、metadata 异常等纳入风险评估，我认为并无不妥。信用良好不意味着免审，而是减少重复、低价值的检查；异常账号也不是禁止提交，而是接受更深入的审查。
或许 App Review 真正需要升级的，不只是审核效率，而是从单点"审核"迈向"行为判断"。
原创
ContentBuilder 解析：SwiftUI 类型检查性能提升的秘密
在 WWDC 2026 的 SwiftUI 新功能 Session 中，苹果工程师介绍了 SwiftUI 的一个新特性------ContentBuilder。从使用方式看，它似乎只是一个覆盖范围更广的 ViewBuilder：过去分别接受 ViewBuilder、ToolbarContentBuilder、CommandsBuilder 的 API，如今可以共享同一个 builder。苹果同时宣称，这项调整能够显著改善类型检查性能。本文将解析 ContentBuilder 的本质，探索性能提升背后的奥妙。
近期推荐
无界面 Xcode：利用 MCP 建立 AI 辅助开发的全自动流程 (Headless Xcode: From Prompt to Simulator with MCP)
Xcode 27 beta 5 新增了 xcrun mcp-server，让 Xcode 的 MCP 能力可以在不启动 Xcode UI 的情况下，以后台服务的形式提供给外部 Coding Agent。Artem Novichkov 以 Claude Code 为例，完整展示了一条 Headless Xcode 工作流：从创建 Xcode 工程、生成 SwiftUI 代码、构建项目和渲染 Preview，到启动 Simulator、读取 accessibility hierarchy、执行交互，并最终结合截图与 OSLog 验证应用状态。这意味着，从 Prompt 到代码，再到运行和验证，一个不依赖 Xcode UI 的完整开发闭环已经初具雏形。
iOS 26: Data Detector
iOS 26 引入了全新的 DataDetector，为已经服役多年的 NSDataDetector 提供了一套更符合现代 Swift 风格的替代方案。Anton Gubarenko 通过大量示例介绍了新 API 的使用方式：开发者可以直接通过 StringProtocol.dataDetectorMatches 获得 AsyncSequence，并使用 Swift 原生 Range 和强类型的语义结果识别文本中的邮箱、电话号码、日期、地址、金额、度量值、航班号、物流单号等内容。新 API 不仅使用起来更加自然，能够识别的语义对象也更加丰富。
用 ContinuousClock 替代 Date() 测量持续时间 (Measuring Elapsed Time in Swift with ContinuousClock)
很多开发者仍习惯使用 Date() 记录开始和结束时间，但 Date 并不是回答"这段操作持续了多久"的理想工具。Kyle Browning 围绕 Swift 5.7 引入的 Clock 体系，介绍了两种更加可靠的时间测量方式：ContinuousClock 和 SuspendingClock。
ContinuousClock 单调递增，并包含设备休眠期间经过的时间，适合衡量真实世界中的 elapsed time；SuspendingClock 则会在设备休眠时暂停，更适合衡量实际运行时间。Kyle 给出了一个简单的建议：如果代码中的 Date() 是用来"计时"而不是"记录时间点"，通常就应该考虑换成 ContinuousClock。
用 XCUITest 自动生成 App 宣传视频 (From XCUITest to Promo Video)
每次修改 App 界面，都可能意味着 App Store 截图、宣传视频以及不同语言版本的素材需要重新制作。Noam Efergan 提出了一个很有意思的解决思路：将营销素材也视为可以重复生成的 build artifacts。他通过 launch arguments 和固定的测试数据，让真实 App 可以随时进入确定的 UI 状态，再使用 XCUITest 自动完成不同 locale 下的截图，并将结果交给 Remotion 生成宣传视频。整个流程并没有为了营销重新制作一套 mock UI，而是始终以实际运行的 SwiftUI 界面作为素材来源。这也展示了 testability 在测试之外的另一层价值：当应用能够稳定、准确地重现某个状态时，同一套能力也可以服务于调试、演示、本地化以及营销内容的自动化生产。
AI 时代，软件工程基本功比以往任何时候都更重要 (Software Engineering fundamentals matter more than ever)
当 Coding Agent 已经能够快速生成代码、完成测试，甚至独立实现相当复杂的功能后，"能不能做出来"正在逐渐成为软件开发中更容易解决的问题。Joseph Heck 认为，真正困难的部分依然没有消失：如何设计清晰的边界与抽象，如何让软件具备可调试性、可维护性和可组合性，以及如何在各种约束之间做出合理的取舍。AI 可以显著降低实现成本，却无法替代这些建立在经验、判断和长期视角之上的软件工程能力。某种意义上，当"写出能工作的代码"越来越容易，Software Engineering fundamentals 反而变得更加重要。
为什么说在 AI 时代，"定义问题"比"写出代码"更重要？(Why Soft Skills Matter More Than Technical Skills in the Age of AI)
如果上一篇讨论的是 AI 时代"怎样把软件做好"，Mohammad Azam 则把问题向前推进了一步：我们首先需要判断"应该做什么"。当 AI 不断降低代码实现的成本，理解业务、澄清需求、提出正确的问题、沟通协作以及评估取舍的重要性反而更加突出。AI 可以在几秒钟内给出十种实现方案，却不知道公司的某条业务规则为何存在，也无法替开发者承担最终交付的责任。技术能力并没有因此失去价值------它仍然是判断 AI 生成结果是否合理的基础；只是未来更加稀缺的，或许不再是"能够写出多少代码"，而是理解问题、做出判断，并最终解决正确问题的能力。
工具
GlyphKit：在 SwiftUI 中用矢量轮廓精准控制字形排版
在 SwiftUI 中显示一个字符很简单，但要让字形精确地占据指定区域，却并不容易。Text 的首要目标是文本排版，基线、字体度量以及 Dynamic Type 都可能参与最终布局。
GlyphKit 选择把字形当作图形处理：通过 Core Text 提取单个字符的矢量轮廓（CGPath），再使用 SwiftUI Canvas 绘制，从而获得更直接的尺寸与位置控制。GlyphKit 并非 Text 的替代品。它更适合单个、装饰性字形；复杂字素、连字及需要文字辅助功能的内容，仍应交给完整的文本排版系统。
往期内容
💝 支持与反馈
如果本期周报对你有帮助，请：
- 👍 点赞 - 让更多开发者看到
- 💬 评论 - 分享你的看法或问题
- 🔄 转发 - 帮助同行共同成长
🚀 拓展 Swift 视野
- 📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察
- 👥 开发者社区 | Discord 实时交流开发经验
- 📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践