今天的「肘子的 Swift 周报」第 149 期，放了两个让 iOS 开发者心里一沉的数字。开发者 Jeff Johnson 追查一款可疑的 Safari 扩展后发现，对方名下有 41 款 App，过去一年至少产生了 368 次获批的审核提交，平均几乎每天一次。而同一时间，著名开发者 Marco Arment 的新 App，已经在审核队列中等待了 12 天。知乎
同一个队列，有人几乎天天过审，有人等 12 天还没排上。App Store 的审核到底慢成了什么样，慢住的又是谁？
先说慢到什么程度。今年 3 月底就有媒体报道，正常应用审核时间从原本的 24-48 小时，增至最长 45 天。知乎到了 8 月，独立开发者王大力记录了自己提审新 App 的经历：等了一周，才有 review 结果，结果是没过。知乎需要说明的是，苹果官方从未承认审核积压，以上是社区感受和具体案例。但从 3 月到 8 月、横跨多个平台的不同开发者都在说同一件事，这已经不是单个账号运气差能解释的了。
队列是被谁挤长的？周报里点了一句：在 Vibe Coding 时代，App 的开发和迭代成本大幅降低。前面那个一年过审 368 次的账号就是极端样本——批量注册、模板化生产、高频提交。基础设施也在往这个方向走：Xcode 27 beta 5 新增了 xcrun mcp-server，让外部 Coding Agent 不用打开 Xcode 界面，就能以后台服务方式调用构建、预览、模拟器验证等能力。知乎从 AI 生成代码到打包提审的最后一公里，正在被铺平。被 AI 挤到的还不止审核队列：苹果的漏洞赏金计划也被 AI 生成的报告淹没，8 月 2 日苹果在内部安全门户上对漏洞提交设置了数量上限和 30 天冷静期。36氪当审核资源被批量提交大量消耗，认真做产品的开发者只能排更久。
但有一个事实容易被误读：慢，不等于严。8 月中旬，一款仿冒福建政务 App「闽政通」的山寨应用「闽证通」出现在 App Store，仅仅一字之差，图标、介绍高度模仿正版，由个人开发者上架，却通过了审核。知乎事件曝光后，苹果下架了该应用，已有人被骗，公安正在处理。微博
对老实做开发的个人开发者，这其实是双重消耗：排队的时间成本涨了，看门的水平却没见涨——45 天的队伍，并没有拦住一个山寨政务 App。
那审核资源到底该怎么分？社区已经有方案在讨论。Jeff Johnson 建议引入类似信用体系的机制：让长期遵守规则、保持良好审核记录的开发者获得更快的审核，把更多资源投入高频、批量和存在异常行为的账号。知乎反对者担心，这会变成对知名或付费开发者的优待，抬高新人门槛；3 月时开发者社群还提出过分级审核优先权、每次提交收取 50 至 100 美元费用等建议。知乎这些方案苹果目前都没有回应。
争议归争议，如果你是打算赶 iOS 27 正式版窗口的独立开发者，眼下的队列速度意味着提审节奏必须调整。iOS 27 Beta 6 今天已经推送，按苹果的惯例节奏，正式版大概率在 9 月落地，留给开发者的窗口只有 4 周左右。
这 5 件事，建议现在就做：
提审时间往前挪 1-2 周。过去按 24-48 小时的审核速度留缓冲就够了，现在要按队列实际情况把缓冲拉长，想赶 iOS 27 新版流量，建议本周就提交，别等 9 月。
避开 4.3(a) 的高风险模式。高频提交相似 App、模板换皮、误导性 metadata 都容易触发这条垃圾应用条款，而且从 2026 年起，被拒 4.3(a) 的应用会直接录入数据库，后续提审新包都会拿来对比，被拒记录越多，后面越麻烦。知乎
加急审核通道省着用。现在连加急申请也难以快速通过，没有真正的紧急情况别动用，用在真正卡发布节点的场合。
被拒之后别盲目重提。像王大力那次被拒，原因是没有挂上订阅商品，以及 Description、EULA 等元数据问题，这类问题补齐配置再提，并在回复里说清楚改了什么，比改代码有用。知乎
等待期先用 TestFlight 跑真机验证。队列越长，每次被打回的成本越高，把崩溃、权限、隐私说明这类低级问题在提审前消化掉，少浪费一次排队。
后面值得盯的信号有三个：苹果会不会落地某种信用或分级审核机制；iOS 27 正式版发布后，队列时长是否回落；以及苹果是否对审核积压给出官方口径。有变化，再来看。
