一条 App Store 拒审,条款 5.6(开发者行为准则):审核挂起,并写明 8 月 18 日前不具备重新提交资格,此前的回复与重交不会被受理。
这条信息同时给出了一个类别和一个日期,两者都不是"修一个 bug"的形状。写代码之前,先把这两样读出来。
第一,带明确日期的拒审是日程,不是故障。日期之前的任何重试,无论改了多少,结果完全等价:不予受理。这不是"再试一次也许就过"的偶发问题,而是准入被拒。正确动作是把日期放进日历、停止提交,并把窗口期前的拒绝单独归类——混进失败统计,一串准入拒绝会伪装成"反复失败",把真正的信号淹没。
第二,5.6 不是技术条款。它不指向某个崩溃或某段缺失的元数据,而是对提交物整体的判定:是否有意义、是否打磨过、是否可靠。这类判定在自家检查体系里没有对应物:构建全绿、组件检查全过,与这条拒审并不矛盾——检查测的是"部件有没有问题",审的是"整个体验成不成立"。所以对这个类别,代码修复是错误的工具;窗口期里的猜测性重构既不改变这次结果,也不提高下一次的通过率。
暂停期该花在判罚点名的三个词上。有意义:核心流程一眼可懂;打磨:首启体验经得起陌生人的第一眼;可靠:稳定。便宜的检验方式:把构建交给没见过这个产品的人,看第一分钟能不能不靠任何提示走到核心流程。若现有检查里没有一条在测这个,这一类拒审对体系就是不可见的——它会在全绿的状态下到来。
窗口打开后,小批量、受控地恢复提交,别把积压一次推完:在审核方视角,大规模重交与触发挂起的行为是同一个形状。
一分钟自检:重读最近一次拒审信息,找两样东西——日期和条款性质。有日期,先挂日历再决定写不写代码;条款属于"整体质量"一类,就把工作从"修缺陷"切换成"提体验"。两样都读出来之前,任何提交都是白花。