App Store审核积压：垃圾应用照样上架，合规开发者苦等12天
缓慢的申请审核流程实际上正在停止谁？
App Store评价变慢，越来越多的开发者能明显感受到。在氛围编码时代，开发和迭代应用的成本大幅下降，因此不难理解为何审核系统面临更大压力。
问题在于，较长的审核时间似乎不过是系统被不断增长的投稿量压垮，而阻止诈骗应用进入商店的门槛却没有相应增加。
最近，Jeff Johnson 在 Mac App Store 发现了一个极其可疑的 Safari 扩展：它的截图似乎是 AI 生成的，宣传的“4.9 分（满分 5 分）”并不存在，而且一些五星好评甚至在应用正式发布前就已经过时了。
进一步调查，他发现该扩展开发者在App Store上有41款应用，过去一年累计至少提交了368条审核——平均每天近一则。与此同时，知名开发者Marco Arment的新应用已经在评测队列中搁置了12天。
这造成了一个相当尴尬的局面。一方面，可疑且潜在的欺诈应用可以通过审核并攀升排行榜。另一方面，人工智能使快速开发和频繁迭代变得前所未有的容易，大量合法和高风险的投稿都通过同一审核系统，消耗了有限的资源。
一个紧急问题变得难以避免：申请审核是否应继续单独对待每一份提交？
约翰逊建议引入类似信任系统的机制，让那些长期遵守规则并保持良好评价记录的开发者能更快收到评论，同时将更多资源投入到那些提交量异常高、批量发布应用或表现出其他可疑模式的账户。
批评者担心，这种系统最终可能会变成对知名开发者或愿意付费者的优待，进一步提高新用户进入App Store的门槛。
如今，随着人工智能大幅降低了应用开发成本，将每条提交都视为孤立案例的审核模型变得越来越难以维持。我认为将开发者的历史、提交频率、应用间相似性以及元数据异常等因素纳入风险评估中，没有任何不合理之处。
良好的业绩记录不应意味着免于审查，而是减少重复且低价值的检查;可疑账号不应被禁止提交，但应受到更严格的审查。
也许App Review真正需要的，不仅仅是更高的效率，而是从单独审查单个提交，转向评估开发者行为模式。
📢赞助商：Fatbobman's Swift Weekly
向Swift和iOS开发者推广你的产品：
- 博客：50,000+ 月访客
- 通讯：4,000+ 订阅者，53开启率
非常适合开发者工具、课程和服务。
原版
ContentBuilder 解析：SwiftUI 类型检测加速背后的秘密
在 2026 年 WWDC 关于 SwiftUI 新动态的会议中，苹果工程师推出了一项新的 SwiftUI 功能：ContentBuilder.从你用它的方式来看，它看起来不过是ViewBuilder覆盖范围更广——之前接受的 APIViewBuilder,ToolbarContentBuilder，或者CommandsBuilder现在可以单独共用一个建造商。
苹果还声称，这一变化显著提升了类型校验性能。本文将深入探讨ContentBuilder确实如此，以及这种表现的来源。
近期建议
无头Xcode：从提示到MCP模拟器
Xcode 27 beta 5 介绍xcrun mcp-server允许Xcode的MCP功能作为后台服务暴露给外部编码代理，而无需启动Xcode UI。阿尔捷姆·诺维奇科夫使用 Claude Code 演示完整的 Headless Xcode 工作流程：创建 Xcode 项目，生成 SwiftUI 代码，构建项目并渲染预览，启动模拟器，读取无障碍层级，执行交互，最后通过截图和 OSLog 验证应用状态。
这意味着一个完整的开发循环——从提示到代码，再到执行和验证——开始成形，不再依赖Xcode界面。
iOS 26：数据检测器
iOS 26 引入了新的DataDetector，为长期存在的 Swift 提供了更现代、原生的替代方案NSDataDetector.安东·古巴连科通过大量示例介绍新API：开发者可以获得AsyncSequence直接通过StringProtocol.dataDetectorMatches然后使用原生Swift范围和强烈输入的语义结果来识别电子邮件地址、电话号码、日期、地址、金额、尺寸、航班号、发货追踪号码等信息。
新的API不仅使用起来更自然，还能识别更丰富的语义对象。
使用连续时钟测量Swift的经过时间
许多开发者仍然习惯性地使用Date()记录开始和结束时间，但Date难道不是回答“这次手术花了多长时间？”的最佳工具吗？凯尔·布朗宁探索ClockSwift 5.7引入的系统，并解释了两种更可靠的时间测量方法：ContinuousClock以及SuspendingClock.
ContinuousClock单调增加，并在设备休眠时持续计数，因此适合测量真实世界的经过时间。SuspendingClock相比之下，设备休眠时会暂停，使其更适合测量实际执行时间。
凯尔给出了一个简单的经验法则：如果Date()你的代码被用来“测量时间”而不是“记录某个时间点”，你应该考虑用ContinuousClock.
从XCUITest到宣传视频
每一次应用界面的变动都可能意味着要重新制作App Store的截图、宣传视频和不同语言的资源。诺姆·埃弗根提出了一个有趣的解决方案：将营销资产视为可重复的构建工件。
利用启动参数和固定测试数据，他让真实应用按需进入确定性界面状态，然后利用XCUITest自动截取不同地区的截图，再将结果传递给Remotion生成推广视频。
整个工作流程不再维护一个独立的模拟界面用于营销，而是将实际运行的SwiftUI界面作为其源素材。它还展示了测试之外的另一个可测试性价值：当应用能够可靠且精确地复现给定状态时，同样的能力可以支持调试、演示、本地化和自动化营销内容制作。
软件工程基础比以往任何时候都更重要
随着编码代理能够快速生成代码、完成测试，甚至独立实现相当复杂的功能，“它能被构建出来吗？”正逐渐成为软件开发中较容易的问题之一。
约瑟夫·赫克他认为真正困难的部分并未消失：设计清晰的边界和抽象，使软件可调试、可维护和可组合，并在竞争约束之间做出合理权衡。
人工智能可以显著降低实施成本，但它无法取代基于经验、判断和长期视野的软件工程技能。从某种意义上说，随着“写出可行代码”变得越来越容易，软件工程的基础比以往任何时候都更重要。
为什么在人工智能时代，软技能比技术技能更重要
如果说上一篇文章讨论的是“如何在人工智能时代更好地构建软件”，穆罕默德·阿扎姆问题更进一步：首先，我们需要决定“应该建造什么”。
随着AI持续降低实施成本，理解业务、明确需求、提出正确问题、沟通协作以及权衡权衡变得更加重要。人工智能可以在几秒钟内生成十种实施方法，但它不知道公司内部为何存在某个特定业务规则，也无法代表开发者对最终产品负责。
技术技能的价值并未减退——它们依然是判断AI生成结果是否可靠的基础。未来可能变得更稀缺的不是“写更多代码”的能力，而是理解问题、做出明智判断并最终解决正确问题的能力。
工具
GlyphKit：SwiftUI 中的精确字形布局，带矢量轮廓
在SwiftUI中显示角色很简单，但要让字形精确占据指定区域就不行了。Text主要为文本布局设计，基线、字体指标和动态字体都会影响最终结果。
GlyphKit 采取了不同的方法，将字形视为图形：它提取矢量轮廓（CGPath通过核心文本对单个角色进行渲染，并用 SwiftUI Canvas 渲染，从而更直接地控制大小和位置。GlyphKit 不能替代Text.它更适合单个装饰性字形，而复杂的字形、连字和需要文本可访问的内容仍应由全文布局系统处理。
感谢阅读Fatbobman的《Swift Weekly》！这篇帖子是公开的，欢迎大家分享。
越来越慢的 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。 阿尔捷姆·诺维奇科夫 以 Claude Code 为例，完整展示了一条 Headless Xcode 工作流：从创建 Xcode 工程、生成 SwiftUI 代码、构建项目和渲染 Preview，到启动 Simulator、读取 accessibility hierarchy、执行交互，并最终结合截图与 OSLog 验证应用状态。 这意味着，从 Prompt 到代码，再到运行和验证，一个不依赖 Xcode UI 的完整开发闭环已经初具雏形。
iOS 26：数据检测器
iOS 26引入了全新的方法 DataDetector，为已经服役多年的 NSDataDetector 提供了一套更符合现代 Swift 风格的替代方案。 安东·古巴连科 通过大量示例介绍了新 API 的使用方式：开发者可以直接通过 StringProtocol.dataDetectorMatches 获得 AsyncSequence，并使用 Swift 原生 Range 和强类型的语义结果识别文本中的邮箱、电话号码、日期、地址、金额、度量值、航班号、物流单号等内容。 新 API 不仅使用起来更加自然，能够识别的语义对象也更加丰富。
用 ContinuousClock 替代 Date（） 测量持续时间（用 ContinuousClock 测量 Swift 的经过时间）
很多开发者仍习惯使用 Date() 记录开始和结束时间，但 Date 并不是回答“这段操作持续了多久”的理想工具。 凯尔·布朗宁 围绕 Swift 5.7 引入的 Clock 体系，介绍了两种更加可靠的时间测量方式：ContinuousClock 和 SuspendingClock。
ContinuousClock 单调递增，并包含设备休眠期间经过的时间，适合衡量真实世界中的 elapsed time；SuspendingClock 则会在设备休眠时暂停，更适合衡量实际运行时间。 Kyle 给出了一个简单的建议：如果代码中的 Date() 是用来“计时”而不是“记录时间点”，通常就应该考虑换成 ContinuousClock。
用 XCUITest 自动生成 App 宣传视频（从 XCUITest 到 Promo 视频）
每次修改 App 界面，都可能意味着 App Store 截图、宣传视频以及不同语言版本的素材需要重新制作。 诺姆·埃弗根 提出了一个很有意思的解决思路：将营销素材也视为可以重复生成的 build artifacts。 他通过 launch arguments 和固定的测试数据，让真实 App 可以随时进入确定的 UI 状态，再使用 XCUITest 自动完成不同 locale 下的截图，并将结果交给 Remotion 生成宣传视频。 整个流程并没有为了营销重新制作一套 mock UI，而是始终以实际运行的 SwiftUI 界面作为素材来源。 这也展示了 testability 在测试之外的另一层价值：当应用能够稳定、准确地重现某个状态时，同一套能力也可以服务于调试、演示、本地化以及营销内容的自动化生产。
AI 时代，软件工程基本功比以往任何时候都更重要（软件工程基础比以往任何时候都更重要）
当 Coding Agent 已经能够快速生成代码、完成测试，甚至独立实现相当复杂的功能后，“能不能做出来”正在逐渐成为软件开发中更容易解决的问题。约瑟夫·赫克 认为，真正困难的部分依然没有消失：如何设计清晰的边界与抽象，如何让软件具备可调试性、可维护性和可组合性，以及如何在各种约束之间做出合理的取舍。 AI 可以显著降低实现成本，却无法替代这些建立在经验、判断和长期视角之上的软件工程能力。 某种意义上，当“写出能工作的代码”越来越容易，Software Engineering fundamentals 反而变得更加重要。
为什么说在 AI 时代，“定义问题”比“写出代码”更重要？ (Why Soft Skills Matter More Than Technical Skills in the Age of AI)
如果上一篇讨论的是 AI 时代“怎样把软件做好”，穆罕默德·阿扎姆 则把问题向前推进了一步：我们首先需要判断“应该做什么”。 当 AI 不断降低代码实现的成本，理解业务、澄清需求、提出正确的问题、沟通协作以及评估取舍的重要性反而更加突出。 AI 可以在几秒钟内给出十种实现方案，却不知道公司的某条业务规则为何存在，也无法替开发者承担最终交付的责任。 技术能力并没有因此失去价值——它仍然是判断 AI 生成结果是否合理的基础； 只是未来更加稀缺的，或许不再是“能够写出多少代码”，而是理解问题、做出判断，并最终解决正确问题的能力。
工具
GlyphKit：在 SwiftUI 中用矢量轮廓精准控制字形排版
在 SwiftUI 中显示一个字符很简单，但要让字形精确地占据指定区域，却并不容易。 Text 的首要目标是文本排版，基线、字体度量以及 Dynamic Type 都可能参与最终布局。
GlyphKit 选择把字形当作图形处理：通过 Core Text 提取单个字符的矢量轮廓（CGPath），再使用 SwiftUI Canvas 绘制，从而获得更直接的尺寸与位置控制。 GlyphKit 并非 Text 的替代品。 它更适合单个、装饰性字形； 复杂字素、连字及需要文字辅助功能的内容，仍应交给完整的文本排版系统。
求贤
[深圳 / 上海 / 北京] 抖音研发 - 客户端渲染引擎研发工程师（iOS / 跨端渲染）
团队介绍
团队介绍：抖音研发部门负责多款大型产品的研发，包括但不限于抖音、西瓜视频、汽水音乐。 加入我们，你将有机会参与亿级用户场景的开发与架构工作，使用前沿的技术助力业务一起不断成长。
岗位描述
- 负责客户端跨端渲染基础框架的功能迭代与性能优化，持续提升复杂界面的流畅度与稳定性；
- 参与声明式 UI 框架在 iOS 上的能力建设，包括核心渲染能力、系统特性适配与配套研发设施；
- 深入渲染链路开展性能分析与调优，定位并解决卡顿、掉帧、内存与启动等关键问题；
- 参与渲染性能监控体系建设，结合监控数据推动问题的自动化分析、归因与治理；
- 沉淀通用优化方案与技术体系，对外进行技术输出，提升公司客户端整体研发效率与技术影响力。
岗位要求
- 本科及以上学历，计算机及相关专业；
- 3年以上 iOS/Mac 客户端开发经验，熟悉 Apple SDK，熟练掌握 Swift/C++；
- 熟悉 SwiftUI/Compose 等声明式UI框架的渲染机制，或有跨端UI框架的开发、落地经验；
- 具备扎实的性能优化能力，熟练使用 Instruments、Time Profiler、Allocations、System Trace 等工具进行分析与调优；
- 具有良好的代码驾驭能力与技术设计能力，能独立完成模块设计与复杂问题攻坚；
- 良好的沟通协作能力与服务意识，责任心强、自驱力强、追求卓越。
联系方式
内推联系：邮箱 yexulei.swift@bytedance.com
联系时请备注「客户端渲染引擎 + 姓名 + 工作年限」
点赞
收藏
点踩
分享