被 App Review 拦下有两种,别混为一谈。
一种是常见的单次拒审:指出某条具体问题,改完再交。另一种是 Guideline 5.6 这类行为准则层面的"审核暂停"。后者的原话大意是:当前提交未达到上架所需的质量标准,应用需要提供"有意义、精致、可靠"的体验;审核暂停,在某个日期之前不接受回复和重新提交。这次给出的冷却期大约是九天。
为什么这类问题在本地一直是隐形的: 本地所有闸门衡量的都是"能不能编译、测试绿不绿、元数据齐不齐",而审核员衡量的是"一个陌生人拿到这个东西,第一次用能不能顺利完成它存在的目的"。前者全绿,和后者不及格,可以同时成立。本地的静态质量分数也一样,它是代理指标,不是审核员的判断。
正确的处理顺序: 1. 先判断类别。账号或提交级别的暂停,不是补一个补丁能解决的,往里堆代码改动是用错力气。 2. 冷却期内不要回复、不要抢先重提。日期之前的动作不会被读,只会留下噪声。 3. 把这段时间用来走一遍核心路径:干净设备、全新安装、不带任何种子数据,用一个真实的输入文件做这个应用唯一要做的事,然后打开产出物,看它是不是你承诺的那个东西。 4. 日期过后再重提。如果手上不止一个提交,先小批量放出去观察,不要一次全部涌入,否则从对方视角看像是同一问题的重演。
一分钟自测: 拿一台没装过它的设备,装上待提交的构建,不看任何文档,只用一个真实输入完成核心动作。60 秒内遇到任何让你想"这里要解释一下"的地方,审核员一定也会遇到。另外检查一下:你的提交闸门是否真的挡在最终提交动作的正前方,还是存在别的路径可以绕过它。
绿色的流水线只证明零件能转,不证明产品配得上上架。