同样是每年 99 美元的开发者账号。

有人的新 Mac App 在审核队列里等了 12 天，有人却已经上架了 41 个 App，累计完成至少 327 次更新。

当 AI 可以一天做出一个 App，苹果的审核机制还跟得上吗？

最近，独立开发者圈里又开始讨论 App Store 审核变慢的问题。

知名开发者 Marco Arment 表示，他尚未发布的一款 Mac App，已经等待苹果审核 12 天。

与此同时，另一名开发者被发现拥有 41 个 App，其中大部分同时提供 iOS 和 macOS 版本。统计这些 App 的版本记录，可以找到至少 327 次更新。

加上 41 次首次上架，这意味着一个开发者至少产生了 368 次已经通过的审核提交。

还不包括那些被拒绝、重新提交，却不会公开出现在版本记录里的次数。

一个认真打磨许久的 App 在队列里等待十几天；另一边，大量结构相似的应用和更新不断进入同一条队伍。

这很容易让人得出一个结论：

苹果的审核队列，正在被批量生产的 App 塞满。

但这个结论目前还不能直接成立。

审核变慢是真实的开发者体验，AI 推动提交量增长也是苹果亲口承认的趋势；可某个 App 等了 12 天，是否就是 AI 应用造成的，外界没有苹果内部数据可以证明。

真正值得讨论的，不是找一个简单的替罪羊，而是当 App 的生产方式彻底改变后，苹果沿用多年的审核机制是不是也应该改变。

01｜苹果每天要处理多少次提交？

苹果公布过一组很夸张的数据。

2025 年，App Review 团队一共评估了超过 910 万次 App 提交。

平均下来，每天接近 2.5 万次。

其中超过 200 万次被拒绝，包括约 120 万个新 App 和接近 80 万次 App 更新。

苹果还识别出：

• 超过 37.1 万次抄袭、垃圾或误导性提交；
• 超过 44.3 万次隐私违规提交；
• 超过 2.2 万次包含隐藏或未说明功能的提交；
• 接近 5.9 万个上架后“变脸”的 App。

这说明审核团队面对的远不只是“页面能不能打开”。

它需要检查功能、支付、隐私、内容、元数据、账号、地区法律和潜在欺诈，还要判断一次普通更新有没有暗藏另一套逻辑。

苹果在自己的报告里也明确提到：强大的 AI 开发工具，正在推动 App 提交量激增。

不过，苹果紧接着又表示，审核系统已经顺利扩容，能够应对这些增长。

这就与最近不少开发者的体感形成了明显冲突。

如果系统确实已经顺利扩容，为什么一个正常的 Mac App 还会等待 12 天？

02｜AI 降低的不只是开发成本，还有提交成本

过去，一个人一年发布两三个 App，已经算相当高产。

从想法到上架，中间要经历产品设计、界面、编码、测试、截图、文案和审核。即使只是一个小工具，也可能需要数周甚至数月。

现在，Codex、Claude Code 以及各种 App Builder 可以把大量工作压缩到几天，甚至几个小时。

这让更多普通人有机会把想法做出来，本身是一件好事。

问题在于，当开发成本快速下降，提交一次 App Store 审核的边际成本也跟着下降了。

一个 App 没有下载量，可以再做十个；一个关键词有流量，可以快速复制出多个相似版本；审核被拒，也可以让 AI 按照回复立即修改，再次提交。

开发者付出的时间越来越少，但每一次提交仍然会消耗苹果的审核资源。

而目前所有人支付的开发者年费基本相同。

维护一个 App 十年的独立开发者，与一年提交几百次的批量开发者，都交 99 美元，也可能进入同一套审核体系。

真正的不对称就在这里：

App 的生产能力已经被 AI 放大，审核资源却仍然是有限的。

03｜41 个 App，不等于 41 个垃圾 App

看到“一个开发者拥有 41 个 App”，很容易直接给他贴上垃圾应用的标签。

但数量本身不能证明质量，更不能证明这些 App 都由 AI 生成。

大型公司拥有几十个 App 很正常，专注 Safari 扩展、教育工具或企业定制的独立开发者，也可能维护多个细分产品。

同样，一个开发者频繁更新，可能是在修复问题、适配系统，也可能是在认真维护用户。

所以，不能简单规定“每个开发者最多只能有几个 App”，也不能看到更新频繁就自动处罚。

这个案例真正暴露的是：App Store 几乎没有向外界展示一套与审核资源消耗相关的约束机制。

一个账号每月可以提交多少次？

大量相似 App 会不会触发更严格检查？

长期无违规的开发者能否获得更稳定的审核时间？

紧急 Bug 修复与普通营销更新，是否应该永远排在同一条队伍？

这些问题，苹果都没有给开发者足够透明的答案。

04｜那就提高开发者年费？

有开发者提出，可以重新引入不同等级的 Apple Developer Program。

愿意支付更高费用的专业开发者，可以获得独立审核队列、更快响应，甚至让信誉良好的 App 更新先发布、后检查。

这个方案听起来很现实。

提高批量提交成本，确实可能挡住一部分只想快速复制 App 的人；依赖 App 收入生活的开发者，也可能愿意为稳定的审核时间付费。

但它同时会制造另一个问题：

审核速度从质量和信誉问题，变成了付费能力问题。

大公司可以轻松购买快速通道，个人开发者、学生和第一次尝试做 App 的新人，只能留在更慢的队伍里。

一个维护十年、从未违规的免费 App，难道应该因为没有收入，就比一家刚注册的公司审得更慢？

如果只靠涨价解决，最后被挡在门外的未必是垃圾应用，也可能是下一个真正有创造力的小开发者。

钱可以证明支付能力，却不能证明 App 的质量。

05｜更合理的不是付费插队，而是“审核信誉”

相比单纯提高年费，我更倾向于让审核资源与开发者的历史行为关联。

第一，建立可以积累的开发者信誉

长期没有欺诈、隐私和重大审核问题，提交内容与审核说明始终一致，线上崩溃率稳定的开发者，应该逐步获得更确定的审核体验。

这不是给老开发者永久特权，而是让每个新人都有一条能够通过良好记录进入快速通道的路径。

第二，对异常提交频率进行分级处理

频繁更新不应该自动判定违规，但一个账号突然连续提交大量高度相似的 App，理应触发额外检查。

限制的不是正常创新，而是对公共审核资源的异常占用。

第三，把机械问题拦在提交之前

无效演示账号、缺失隐私字段、未提交的内购项目、错误权限说明、截图尺寸和元数据问题，很多都可以在进入人工审核前自动发现。

与其让审核员花时间写一封模板拒绝信，不如让 App Store Connect 在开发者点击提交时就明确阻止。

第四，为严重线上问题保留真正的紧急通道

支付故障、崩溃、安全漏洞与数据风险，不应该和换一张商店截图、修改几个关键词排在同一个优先级。

紧急审核也需要防止滥用，但不能只依赖一张没有明确处理时限的申请表。

第五，让审核进度更透明

开发者最难受的往往不是等待，而是不知道为什么等待。

“正在排队”“需要额外技术审核”“账号合规检查”“等待地区法律确认”，哪怕只提供大致阶段，也比十几天停留在同一个状态更可控。

06｜在苹果改变之前，开发者只能先改变自己的节奏

审核机制不是个人开发者能够控制的，但有几件事可以减少不必要的等待：

• 不要把提交时间卡在发布日期前一两天；
• 需要登录时，提供真实可用的演示账号和验证码说明；
• 把非显而易见的功能、权限用途和内购路径写进审核备注；
• 确保审核期间后端服务、测试账号和订阅商品都可用；
• 不要因为等待焦虑就频繁撤回并重新提交；
• 真正影响现有用户的严重问题，再申请加急审核。

这些动作不能保证快速通过，却至少不会因为一个可以提前发现的问题重新排队。

AI 让更多人能够开发 App，也让成熟开发者的发布速度大幅提高。

问题不在于谁有资格做 App，更不在于一个人应该拥有几个 App。

真正的问题是：当提交量可以被机器无限放大时，苹果是否还应该让所有提交以几乎相同的方式消耗人工审核资源。

涨价是最简单的答案，却未必是最公平的答案。

比付费快速通道更值得建立的，是一套可以积累、可以失去，也对新人开放的审核信誉体系。

App Store 需要拦住的不是新开发者，而是低成本、无节制地消耗审核资源的人。