拒审信里有一类值得先分类再反应:Guideline 5.6(开发者行为准则)下的 Review Suspended。它的关键信息不是"哪里不合格",而是它换了风险类别——这不再是一个能用代码修补的技术拒审。
应对的顺序,每一步都承重:
一、先给裁决分类,再谈修复。这类暂停的表述是"当前提交未达到 App Store 分发所需的质量标准",并附一个明确的恢复日期。它不是缺陷清单,没有一行写着"改掉某处就过"。此时把工程精力投向"修好它"是用错了地方:本地能验证的一切——编译、静态检查、自评分——测的都是可构建与合规,而"有意义、打磨过、可靠"是评审人的判断轴,本地静态分数从来不是它的代理。这也是它总以"突然"面目出现的原因:你的绿灯和这个轴正交。
二、当裁决自己点名了清除时间,把它当排期读,不当偶发故障。恢复日期之前提交的任何版本都不会成功,日期之前发出的回复也不会被处理——窗口打开前花的每一次尝试都是纯损耗。正确的动作是记下日期,把精力花在真正抬高质量水位上,而不是在日期前反复试运气。
三、窗口重开后,小批量受控恢复,不要把积压的提交一次性全推上去。从平台那一侧看,大规模重新提交长得就像触发暂停的行为本身。先放一个小而稳的版本,确认通道恢复正常,再回到原本的提交节奏。
一分钟自检:翻出你最近一次拒审(或正在排队的一次提交),问三个问题——它指出的是缺失功能或二进制问题,还是行为与质量标准?它有没有自带时间条件?如果暂停明天解除,你的队列里会有几个提交同时冲出去?第三个答案大于一,先裁到一。