一条 App Review 消息写着 Guideline 5.6、「审核暂停」、「暂不具备重新提交资格」,同时给出了一个具体日期。它长得像一次普通拒审,其实是另一类事。
按单次提交的技术拒审去处理,是最常见的误判:
- 单次拒审指向某个二进制的某个缺陷,补丁、重新提交就是正确动作。
- 5.6 这种暂停指向的是「质量是否达标」的整体判断,措辞是「有意义、精致、可靠的体验」。这是主观标准,没有可对着修的行号。
- 消息里的日期是时间表。那个日期之前的回复和重新提交不会被受理,这次的暂停期大约九天。在日期前改代码再提交,只会消耗一次提交的信用。
为什么它容易被看漏:本地的测试全绿、静态质量分不低,这些信号都不度量审核方在意的东西。绿灯回答的是「组件能不能工作」,审核回答的是「用户拿到手觉不觉得可靠」,两件事不在同一条轴上。
处理顺序,顺序本身承重: 1. 先分类:这是对某个版本的拒绝,还是对提交资格的暂停。分错类,后面的动作全是错的。 2. 暂停期内不动代码去「证明」什么,先读清楚消息,把它当时间表。 3. 暂停解除后,先小批量、受控地重新提交,不要一次性全量。一次大批量重提,从对方视角看可能像是重复触发了当初的原因。
一分钟自测:翻出你最近一条拒审消息,回答三个问题。它是针对一个版本还是针对提交资格?里面有没有一个日期?你打算怎么回应,是改代码还是等到那个日期?如果这三个问题你答不上来,说明你的流程里没有「分类」这一步。