App Store 元数据被拒：解决 2.3.x、2.3.7、4.3 和 5.2.1
你刚收到邮件，状态变成了元数据被拒，解决中心的说明引用了一个你还得查一下才知道是什么意思的指南编号。好消息是，元数据被拒是比较容易解决的一种：你不需要重新上传构建包，只需编辑版本记录并重新提交。
首先要检查的是解决中心消息里的指南编号，它能准确告诉你该修改哪个字段。这篇文章会介绍在列表被拒时最可能遇到的四条指南。指南编号会随时间重新编排，本文所引用的编号以当前的 App Store 审核指南为准。
首先说清机制：「元数据被拒」到底是什么意思
元数据被拒状态指向的是你的商店列表——应用名称、副标题、关键词、描述、截图、预览视频、URL——而不是编译后的应用本身。因为标记的是元数据，你不需要新的构建包。只需在 App Store Connect 中编辑被指出的字段，保留该版本已关联的构建包，然后重新提交。
有两点值得说清楚。第一，重新提交仍然会把你重新排进审核队列，所以它不需要新构建包，但不是免审核——仍会有人工或自动审核再看一遍。第二，修好 Apple 指出的那一个字段并不能让列表的其他部分免疫。审核人员在下一轮可能标记出另一条指南。既然已经在改了，不如把整个列表都清理一遍，而不只是被引用出来的那句话。
指南 2.3.3——截图必须展示应用的实际使用场景
触发原因。你的截图没有展示应用实际做的事情。典型情况是第一张图是启动画面、登录页面，或者只有标语和艺术字、没有真实界面的封面图。展示应用不具备的功能，或引用了其他平台的设备或界面，也会触发这条。
修改前：第一张图是你的 logo 居中放在渐变背景上，写着「规划一周的最聪明方式」，画面里没有任何应用界面。
修改后：第一张图是核心流程中的真实界面——一个填好了实际条目的周视图——设备上方配一句简短的文案说明卖点。审核人员（以及用户）从缩略图就能看出应用是做什么的。可以保留营销文案和设备边框，但底下的应用界面必须是真实且当前版本的。
这是一次元数据修改：替换版本记录里的图片，重新提交，不需要新构建包。
指南 2.3.7——关键词必须描述你的应用，而不是蹭游戏搜索
触发原因。这是关于关键词滥用的指南。当你的元数据里塞满了不描述你应用的词——你不拥有的商标词、更大或更受欢迎的应用名称、放错字段的价格文案、为了蹭流量塞进去的名人或公众人物名字，或者纯粹为了蹭搜索堆砌的通用短语——就会触发这条。通常是 100 个字符的关键词字段出问题，但副标题和名称也会被标记。应用名称上限是 30 个字符，价格或促销语言不应出现在名称、副标题或截图中。
修改前（关键词字段）：列表里包含同类别中三个更大的应用的名字、一个知名创作者的名字，以及几个不相关的热门词，没有一个描述你实际做出的功能。
修改后：关键词对应用户为了找到你的功能真正会搜索的内容——它完成的任务、它解决的问题、你自己界面里出现的名词。每个词都应该指向应用真实具备的东西。
修改前（副标题）：一句把自己和某个具名竞品对比定位的文案。
修改后：用平实的语言说明你的应用带来的结果，不出现任何其他品牌名字。副标题是用来说明你的应用是什么的，而不是用来借用别人流量的地方。
指南 4.3——垃圾应用和高度雷同的应用
触发原因。4.3 关注的是「雷同」。当你用不同的 Bundle ID 发布多个几乎一模一样的应用（每个城市、每个团队、每个客户分别做一个构建包，而不是一个应用内含这些变体），或者一个提交与已经广泛存在的东西难以区分时，就会触发这条。这通常是产品概念层面的问题，但让重复变得显眼的往往是列表本身——你自己账号下多个应用的描述和截图完全一致，就是一个明显信号。
修改前：你账号下有五个应用，布局相同、功能列表相同，文案只是把城市或团队名字换了一下。
修改后：一个应用把这些变体做成应用内选项或内购项目，列表描述它真正独特的功能。如果你确实有多个不同产品，那就让每个列表的截图和描述展示出它真正不同的地方，而不只是把一个专有名词做查找替换。
如果底层应用真的只是一个套皮产品，4.3 可能需要的不只是修改元数据。但如果问题只是你的多个列表看起来像彼此的克隆体，把文案和截图区分开来就是一次元数据修复。
指南 5.2.1——元数据中出现他人的知识产权
触发原因。在你的 Bundle、开发者名称或元数据的任何位置，使用了你没有权利使用的受保护第三方素材——商标、受版权保护的作品、仿冒名称。一个常见变体是列表中的应用或品牌与实际提交者身份不一致，这会让 Apple 询问这个名字究竟归谁所有。
修改前：把一个你不拥有的品牌或平台名称放在应用标题、副标题或关键词字段里，借以蹭它的搜索流量。
修改后：标题、副标题和关键词里使用你自己的产品名称。如果你确实与某个第三方平台有集成、需要说明这一点，把这条事实性的兼容说明保留在描述里（这是被允许的位置），而不要放进名称和副标题。如果你是为拥有该商标的客户开发这个应用，就用商标所有方的账号提交，或者被加入他们的团队，让卖家名称和品牌保持一致。
再强调一次：不需要改构建包的部分
以上四条，只要修复内容在版本记录里——文字和图片——你就可以直接在 App Store Connect 里改好，重新提交同一个构建包，不需要提升构建版本号，也不用等待处理。这就是元数据被拒给你的快车道。代价是你要重新走一遍审核，所以在点击重新提交之前，把整个列表对照这四条完整检查一遍，比一次只解决一个被拒问题要更划算。
Mokbi 能帮上什么忙（以及帮不上什么忙）
大多数 2.3.7 的问题从写文案阶段就开始了，当时关键词字段或副标题被塞进各种词来蹭流量。Mokbi 的 AI 会根据你的应用实际做的事情，起草你的列表文案——名称、副标题、关键词、描述——从源头上避免那些堆砌关键词、蹭品牌的习惯，而这些正是导致关键词被拒的根源。之后它会把这份文案本地化成 50 种语言，这样你就不用为每个市场手写一遍关键词字段，也就不会在每个市场重蹈同样的覆辙。
但也要清楚它的边界。这能降低文案层面触发 2.3.x 或 5.2.1 标记的概率，不能保证一定通过审核，也不会决定你构建包里的内容。审核结果由 Apple 决定。符合规范、准确反映应用内容的文案，能消除那些容易避免、纯属自找的被拒理由。Mokbi 不会自动发布到你的列表——它只生成文案和截图，你审核后自行提交。