拒审读起来像判决，其实只是一条消息。它会写明条款编号，通常描述审核员看到了什么，有时还会写出用的是哪台设备。接下来做什么，全看你有没有把它读明白。下面是一个在我们的经验里行之有效的顺序。
1. 先看条款编号
打开 Xcode 之前，先找到条款编号，以及它指向的是哪一块：
- 元数据（名称、副标题、关键词、截图、描述）：在 App Store Connect 里改。Apple 帮助文档写道："If your app was rejected for a metadata issue, you can resubmit the same build after resolving the issue."（因元数据被拒的，改好后可以用同一个构建重新提交。）不要动代码。
- 二进制本身（崩溃、按钮没反应、功能缺失）：需要新构建。
- App 内购买（缺失、无法审核）：多半是提交时的问题，不是代码问题。
- 没有任何缺陷，只有一个日期： 看下面的 5.6。
然后把消息剩下的部分再读两遍。记下设备、复现步骤，以及审核员附上的截图。先按他们的方式复现出他们看到的东西，再判断它意味着什么。
2. 三选一：回复、修复、申诉
回复，适用于审核员缺信息的情况。Apple 帮助文档说，你可以和 App Review 来回沟通并附上文件，"until you resubmit"（直到你重新提交为止）。适合回复的情况：功能藏在某个设置里他们没找到；需要登录却没给演示账号；应用看起来像它其实不是的东西。只回答对方问的问题，指明具体在哪个界面，附一张截图或一段简短录屏。
修复后重提，适用于消息里说的问题确实存在。大部分拒审属于这一类。修根因，而不是修审核员碰巧踩到的那一个点：一个权限路径崩了，就亲手把所有权限路径都测一遍。
申诉，只在 Apple 描述的情形下使用。Apple 的 App Review 页面说，如果你认为 "we misunderstood your app's concept and functionality, or that you were treated unfairly"（误解了应用的概念和功能，或在审核中受到不公平对待），可以向 App Review Board（审核委员会） 申诉，并要求：
- 具体说明为什么应用符合指南；
- 每个被拒的提交只申诉一次；
- 申诉前先答复对方要求补充的信息。
申诉不是把同一套说法再大声讲一遍。还没回复过的，先回复。
如果应用已经上架，这次只是修 bug，指南写明 bug 修复 "will not be delayed over guideline violations except for those related to legal or safety issues"（除法律或安全问题外，不会因其他违规而被拖延）。Apple 可能会给你一个 bug 修复提交的选项：在 App Store Connect 里回复接受，然后在下个版本里解决另一个问题。
3. 用同一个版本重提
版本处于被拒状态时，你没法开新版本。Apple 帮助文档写明，当前版本必须是“可供分发”（Ready for Distribution）才能创建新版本。所以修复只能放进被拒的这个版本：
- 上传一个构建号更高的新构建，在同一个版本页上选中它。
- 元数据也在同一个版本页上改。
- 如果要换版本号，就在被拒的版本上直接改；按我们的经验，这个字段在被拒版本上仍然可以编辑。
- 从 App 审核（App Review）区域重新提交。
如果提交显示 Unresolved Issues（问题未解决），Apple 的规则很具体：被拒的项目要么编辑后重提，要么移除；每个项目在重提前只能编辑一次；这个提交里不能再加新项目；移除的项目不能再加回同一个提交。
4. 确认内购跟着你回来了
版本被拒时，随它一起提交的内购通常也会被标成“被拒”，哪怕它们本身没问题。它们被拒，只是因为版本被拒了。
重新提交之前，逐个打开内购和订阅，确认它们和版本一起回到了提交里。每种类型的第一个内购必须随 App 版本提交；Apple 帮助文档也写了，版本和所有要一起审的内购，必须在提交前放进同一个草稿提交。漏了这一步，修好的应用会因为缺内购再收一封 2.1(b) 拒审。
5. 5.6「审核暂停」给的日期是什么意思
5.6 的消息可能不指出任何缺陷，只给一个质量标准和一个日期。按我们的经验，在那个日期之前发的回复和重提都不会被处理。把日期当作排期，而不是 bug：不要提前重提，不要靠猜去打补丁，把这段时间用来在干净设备上以陌生人的视角把应用用一遍。日期过了，先做一次小而稳的重提。详见 5.6：审核暂停。
不要做的事
- 不要原样重提。 指南写明，如果应用 "is repeatedly rejected for the same guideline violation"（因同一条款反复被拒），审核 "will take longer to complete"（会花更长时间）。
- 元数据的问题不要去改代码， 代码的问题也不要去改元数据。点名哪里，就修哪里。
- 不要加一句免责声明就指望过审。 我们收到过的一封消息原话是："adding a disclaimer to the app description is not sufficient if the rest of the metadata and the app are misleading"（如果其余元数据和应用本身有误导，只在描述里加免责声明是不够的）。功能本身有问题，就要出新构建。
- 不要藏问题。 指南 2.5.19 禁止隐藏或未说明的功能。让审核员看到的和用户拿到的不一样，比原来的拒审严重得多。
- 不要新建一个应用记录重来。 Apple 把“重复提交相似应用”归在 4.3 之下，见 4.3：Spam。
- 回复时不要争吵。 具体、简短。5.6 开发者行为准则要求你在每条发给 Apple 的消息里保持尊重。
按条款找指南
- 2.1，bug 和缺内购：App 完整性
- 2.3.2：描述里的付费功能
- 2.3.3：截图
- 2.3.7：“Free”等价格词
- 2.3.8：商店名和主屏名对不上
- 2.4.5，Mac：沙盒存文件与自带更新检查
- 2.5.4：后台模式
- 4，Mac：关掉主窗口后没法再打开
- 4.1(c) 和 5.2.5：元数据里的他人品牌
- 4.3：Spam
- 5.6：审核暂停
- VPN 问卷：先查构建，再作答
一分钟自检
点“重新提交”之前：条款编号已经记下；改动针对的是消息点名的那一块；每个内购都回到了提交里；回复用两三句话说清楚改了什么、在哪里能看到。然后把 提审前检查清单 再过一遍，换了构建，构建那几项就要重查。各步骤用得上的浏览器工具都在 工具箱页面。
以上来自 Obelisk Club 自己的送审记录。Apple 的流程和措辞会变，请以当前 App Review 指南、App Store Connect 帮助文档和你收到的消息为准。