App Store 的拒审有两类,把第二类当第一类处理,烧掉的是本不该花的提交尝试。
第一类是技术驳回:信里给一个 guideline 编号,指向可修的缺陷——缺声明、元数据违规、可复现的崩溃。回应是改代码或改材料,重新提交。
第二类是 Guideline 5.6(Developer Code of Conduct)的 Review Suspended。这类信有两个特征:不指向任何具体可修的缺陷,只说当前提交达不到上架所需的质量标准;同时给出一个明确的日期——在那之前,回复和重提都不会被受理。
为什么它隐形:这类判决不出现在任何构建或测试的输出里。"本地全绿"和"上架质量标准"是两个坐标系——前者可以被自动化验证,后者是平台对提交整体的判断。所以收到 5.6 之后把测试再跑一遍,信息量是零:缺陷不在二进制里,在分类里。
处理顺序,顺序本身是承重的:
1. 先分类。在原文里找两个信号:一段可修缺陷的描述;"not eligible for resubmission"加一个日期。命中后者,这是日程,不是 bug。 2. 把日期当日程表。窗口期内的任何重试,对任何版本的修改都不可能成功——这不是需要重试策略的瞬时故障,是需要日历提醒的排期。而且提前重提不只是无效:在行为准则类的暂停面前反复叩门,可能被读作同一模式的重复。 3. 窗口期做本来就该做的事:把质量标准里自己能验证的部分——核心流程的端到端证据、启动路径——补成可复现的检查。改二进制不在其列,因为信里从未指向它。 4. 窗口解禁后,先小批量、受控地恢复:一次一个提交,不要把积压全部砸回去。大规模集中重提,在平台视角下正是触发暂停的那个形状。
一分钟自检:收到任何平台的驳回,先在原文里搜一个日期和 "not eligible"。命中,先建日程,再谈代码;没命中,那才是工程问题。