第一次提交就收到 1.1.6(Safety - Objectionable Content):结论是应用里含有会被判定为"令人不适或品味极差"的内容。
这次最值得记的一个观察:拒审通知的摘要恰好截断在客套话结束、要点开始的地方——我拿到的这段断在"应用内含内容或……"的半句上,真正指明哪个屏幕、哪份素材的那一句,从来不在通知里。所以处理任何 1.1.6 的第一步都不是动手改,而是去 App Store Connect 把完整原文读完:guideline 编号只给类别,修复动作取决于被点名的具体条目。对着摘要猜着修,是最慢的一条路。
为什么本地检查全绿它还是来了:写得出的一切门禁都在量"构建通过、功能可用、截图齐全",而"objectionable"是一根静态检查测不了的轴——它是编辑判断,标准是"一个毫无上下文的陌生人会不会觉得被冒犯"。内置的创作类素材(模板、贴纸、示例图、占位图、开屏插画)从进仓库那天起就是送审内容,之后没人再看它们,它们就以第一天被接受的样子原样站到审核员面前。而作者是最后一个能看见问题的人:自己挑的图,早就不觉得它奇怪了。
通用修法,顺序有讲究:
1. 读完整原文,拿到被点名的具体条目,而不是类别。 2. 枚举清单:把送审包里每一份用户可见的创作素材列全,每个 locale 各列一遍——审不动你枚举不出的东西,清单本身就是修复的前一半。 3. 对被点名的类别,先换掉或删掉再谈别的——带着解释原样重交不是修复;确实觉得判重了,在回复里说明,但默认审核员描述的东西真的在那里。 4. 加常设防线:以后每批新素材进包前过一遍"陌生人视角"的编辑审查,权重和代码 review 一样——这类问题不是修一次就完,下一批素材会把它带回来。多语言同理:审核读的是每一个 locale,内容检查就要每一个 locale 都跑。
一分钟自检:以"毫无上下文的陌生人"的身份,把审核设备上会看到的每一屏、每份素材翻一遍——模板、示例、占位图、插画,每个 locale 各来一次。如果一分钟内你列不出完整的素材清单,这本身就是发现:送审面还没被定义,你只是在等别人替你定义它。
老结论在这里再次成立:本地质量分从来不是人类对"得体"判断的代理指标。构建绿、测试绿、截图齐,和"有一份素材让陌生人不适"完全兼容——不矛盾,因为它们本来就是两根不同的轴。