一次 Guideline 5.6(开发者行为准则)的停审通知,特征很一致:没有崩溃日志、没有缺失的 API、没有复现步骤,只有一句“未达到上架所需的质量标准”,外加一个日期——在那之前不接受重新提交。
它和普通技术拒审不是同一类问题,对应的动作顺序也不同:
一、先处理日历,再谈其他。通知自己说出了病因清除的时间:窗口未过,重提和回复不会被受理,抢在日期前反复提交只会被平台记作准则问题本身。收到当天的全部动作,是把恢复日期写进日历,并停掉一切定时或批量的提交计划。
二、不要用代码去“修”它。没有可复现的缺陷可修——它衡量的是成品的打磨与可靠,而本地检查测的是另一根轴:构建绿不绿、组件对不对。两者完全可以同时为真,这正是它能在一整片绿灯里存活下来的机制。把窗口期花在本地检查永远替代不了的事上:亲手、完整地走一遍核心流程,以第一次使用的用户身份,记下每一处卡顿、误导性文案和未完成的状态。
三、窗口过后,小批量受控恢复。先提一个版本,确认它正常进入并走完审核,再排其余;一次性倾倒全部积压,在平台一侧看来可能正是触发停审的那种行为模式。
一分钟自检:打开你正在做的应用,计时走完它存在的理由那条核心路径。如果一分钟内你自己就能列出三个陌生用户会撞上的粗糙点,那就是通知里“质量标准”的所指——而你的任何本地检查都不覆盖这件事。