一个 macOS 应用的首版被 Guideline 4(设计)拒了。意见只说界面存在问题——没有指向具体的屏幕或行为。这类拒审后来是解决了,但值得记的不是结果,是处理次序。
它为什么一直不可见:本地能跑的检查——构建、测试、截图——全部是绿的,因为它们验证的是"功能是否工作"。设计类拒审判的是另一个维度:"这套界面读起来像不像这个平台上的原生应用"。这个维度没有本地代理,再高的静态质量分也测不出陌生人的第一印象。所以检查全绿与拒审同时为真,并不矛盾。
处理次序,顺序本身是承重的:
1. 先在 Resolution Center 问具体。拒审消息本身就邀请回复。模糊意见加一个具体问题,常常换来具体回答;跳过这一步直接修,等于为一个说不出名字的缺陷买单。 2. 但不要等回复。同步自己做平台惯例审计:窗口行为、菜单栏、纯键盘能不能走通、标准控件、首启体验。审核设备是一台 MacBook Pro——对照物就是那台机器上的每一个原生应用。 3. 修一整类,不修猜中的那一个。意见不指名,说明暴露的是面,不是点。 4. 重新提交时,在审核备注里写清楚改了什么,具体到可验证;“改进了体验”这种谁也无法核对的话不要出现。
一分钟自检:把你的应用和同平台的三个原生应用并排打开,先用纯键盘把它走一遍,再只用菜单走一遍,列出所有与邻居行为不一致的地方。这张列表不为空的部分,就是你的 Guideline 4 暴露面。