越来越慢的 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 DetectoriOS 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 timeSuspendingClock则会在设备休眠时暂停更适合衡量实际运行时间。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 的替代品。它更适合单个、装饰性字形复杂字素、连字及需要文字辅助功能的内容仍应交给完整的文本排版系统。往期内容Apple Intelligence 已通过审核即将在中国提供服务 - #148热茶还是冰咖啡 - #147不是模型变慢了是任务变大了 - #146当灵感跑在了结果前面 - #145 支持与反馈如果本期周报对你有帮助请点赞- 让更多开发者看到评论- 分享你的看法或问题转发- 帮助同行共同成长拓展 Swift 视野 邮件订阅| weekly.fatbobman.com 获取独家技术洞察 开发者社区| Discord 实时交流开发经验 原创教程| fatbobman.com 学习 Swift/SwiftUI 最佳实践