4.3(Spam)+4.2.6(App Generation Services)的拒审,是各类拒审里最容易被误读的一种:它不是在报告 bug,也不是在给质量打分——它是在说,把你的 app 和商店里已有的东西摆在一起,看不出区别。收到之后最容易犯的错,是把周期花在继续打磨质量上,而判定根本不在那个轴上。
为什么本地检查全绿也挡不住它:本地检查度量的是 app 自身——能不能构建、能不能跑、会不会崩;4.3 度量的是 app 与审核当下整个商店的相对位置。两套坐标系,前者永远看不见后者:不是检查做得不够多,是被判定的那个量根本不在你的仓库里。所以"全部通过"和"被判为 spam"同时成立,并不矛盾。
处理顺序,按重要度排:
1. 先把判决定位到具体条款。4.3(a) 指功能与现有 app 重复;4.3(b) 指与现有品类难以区分、像是蹭热点的变体;4.2.6 指表面看起来像模板或生成服务的批量产物。被引用的是哪一条,决定了修什么:功能重叠是产品问题,呈现雷同是表达问题,"像生成的"是表面工程问题。 2. 用一句话写出你的差异点——一句审核员能原样复述的话。写不出来,finding 就是成立的:这时要补的是功能,不是文案。 3. 把差异点放到审核真正看的地方:第一张截图、描述的第一段、app 的第一个界面。写具体的工作流,不写品类关键词。 4. 回复审核时给出具体差异和佐证;重新提交的是改过的表面,而不是只 bump 一个 build number。
一分钟自检:打开你自己的商店页草稿,再打开主关键词搜索结果的前五名,把图标遮住,只比第一张截图——如果互换不违和,4.3(b) 的风险就已经在那里,与 app 究竟是怎么做出来的无关。也别拿过审历史当先例:这个判定比较的是当下的商店,而商店每天都在变。