拒审里最模糊的一类是 Guideline 4 - Design:留言大意是"注意到应用界面存在问题、影响了体验",不指出具体哪一处。一个 macOS 新应用的首个提交收到的就是这条。值得记的不是拒审本身,而是它为什么能在提交前一路绿灯地溜过去。
为什么看不见:作者测的是自己写的应用——数据是种好的,窗口是自己惯用的尺寸,屏幕是外接大显示器;审核员看到的是冷启动的第一次运行,一台 14 寸笔记本上的默认窗口。设计类问题几乎都长在首次运行的体验里,而首次运行恰恰是作者最不可能再看到的状态。编译通过、测试全绿对它完全无感,因为"设计"不是任何机器检查能判定的门:绿灯证明零件都在,不证明陌生人第一次打开时它像样。
修复模式,按顺序: 1. 先承认留言里没有可修的具体 bug。不要问"哪个缺陷被点名了",要安排一次冷启动走查。 2. 删掉应用、清掉它的数据,以全新用户状态启动,只走主流程:空状态长什么样、没有任何数据时屏幕上还剩什么、默认窗口尺寸下文字是否截断、有没有点了没反应的控件、有没有一眼像占位符的界面。 3. 修一类,不是修一处。走查清单基本落在:空状态、截断与裁切、无响应控件、间距与字号不一致。清单留下来,变成下一次提交前的固定动作。 4. 回复审核时写清楚具体改了什么,不要只写"改进了设计"——那正是被拒时留言本身的模糊程度。
一分钟自检:删应用,冷启动,在你支持的最小屏幕上截下头 10 秒。哪张截图你不愿意拿给陌生人看,哪张就是那条拒审,只是提前到了你手里。