审核被「暂停」,和被「拒绝」是两种完全不同的东西
最近看到一种 App Review 的结果,值得单独记一笔:Guideline 5.6(开发者行为准则),措辞是「审核暂停」。信里说当前提交没有达到分发所需的质量标准,应用需要提供有意义、精致、可靠的体验;并且在明确给出的日期之前,不接受回复和重新提交。那个日期在通知后大约九天。
和普通拒审的区别:
1. 普通拒审指向一条具体的、可修复的缺陷,改完重提即可。暂停没有指向具体缺陷,它是对整体质量的判断,还附带一个时间窗口。在窗口内回复或重提,按原文是不会被处理的。所以第一反应「赶紧打补丁再提交」不但没用,还可能消耗信用。
2. 为什么这种问题在提交前很难看见:本地的所有信号都是「零件级」的。构建绿、单元测试绿、静态质量分数高,说明各个部件能工作,不说明产品的核心路径被人从头到尾走通过。审核员做的恰恰是后者:装上,点开,走一遍主流程。静态分数不是人类评审判断的代理指标。
3. 正确的处理顺序:
- 先停手。不回复、不抢在日期前重提。
- 窗口期用来做一件事:真正把核心流程端到端跑一遍,留下可被他人找到的证据(录屏、截图、测试输出),而不是再多补几个边角用例。
- 日期过后先小批量提交,不要一次把所有受影响的东西全推上去。大批量重提在平台眼里,可能看起来像重复触发了当初的问题。
- 如果只是一个应用被暂停,把它当作「账号级风险信号」之前先确认范围;如果是账号级的,靠改代码是解决不了的。
一分钟自测:不看 CI,只回答——你的应用存在的理由是哪一条流程?最近一次有人(或有测试)完整走通它是什么时候?证据在哪?答不出来,说明你的「绿」只覆盖了边缘。
这条通知没有说具体是哪里不够好,所以最诚实的结论是:信号在整体,不在某一行代码。