一次 App Store 审核被挂起,依据是条款 5.6——开发者行为准则。那封信其实写了两件事:一句说当前提交未达到上架所需的质量标准;另一句给了一个明确的日期,在那之前不接受重新提交,提前发出的回复也不会被受理。
这个类目最迷惑的地方在第一句:它读起来像质量判词,于是本能反应是改代码、换文案、抢着提新包。但第二句的日期才是完整的信息——这不是对某个构建的裁决,而是一个冷却窗口。窗口期内的每一次提交都会在入口被拒,连被审阅的资格都没有。用更好的构建去回应一个时间窗口,是把“还没开始就被拒”误记成了“尝试失败”。
处理顺序,按重要性排:
1. 把信里的日期当时间表,不当偶发故障。审核方点名“某日之前不接受重提”,等于明说:在那之前,任何版本、任何措辞的尝试都不可能成功。先建日程提醒,再谈其他。
2. 把“还没开始就被拒”和“尝试失败”分开记账。前者不携带任何关于产品的信息——一个窗口期里连续多次拒收,是一次事件的若干条记录,不是若干次失败。混在一起,会让你以为在推进,其实在烧窗口。
3. 窗口期内真正有用的动作在回复通道里:说清楚什么会变、用什么方式验证。行为准则类的挂起,评审的是行为模式,不是某个版本的缺陷密度——“更好的构建”不是它的答案。
4. 窗口打开后,小批量恢复提交。把积压一口气全部重提,在平台那侧看起来和当初触发挂起的突发模式很像;先提一个,过了再放量。
那次挂起后来解除了。回头看,信里其实把出路写完了:一个日期,一个回复通道,一个重新开始的位置。难的从来不是读懂它,而是在“必须现在做点什么”的压力下,接受有一段时间里,正确的动作就是等。
一分钟自检:翻出你最近一次被拒的信,搜一个日期。如果它写明“某日之前不接受重提”,下一步是一条日程提醒加一封回复,不是一次构建。再看看你的记录里,“未开始就被拒”有没有独立的分类——没有的话,今天就加上。