# 被 App Review 拒了之后：回复、修复还是申诉，按顺序来

> App Review 的拒审是一条带条款编号的消息，这个编号决定了你该回复、修复后重提，还是申诉。一个稳妥的处理顺序、同一版本怎么重提、内购会跟着发生什么、5.6 给的日期是什么意思，以及哪些事不要做。

- Canonical page: https://obelisk.club/blog/after-app-store-rejection-what-to-do-zh
- Author: Peter Zhang
- Published: 2026-10-30
- Tags: app-store, app-review, rejection, checklist, indie, 中文

App Store 拒审之后，先看条款编号：它告诉你要改的是 App Store Connect 里的元数据、要出新构建，还是提交里的内购。然后，审核员缺信息就回复；问题确实存在就修好后用同一个版本重提；只有认为应用被误解或受到不公平对待时，才向 App Review Board 申诉。

拒审读起来像判决，其实只是一条消息。它会写明条款编号，通常描述审核员看到了什么，有时还会写出用的是哪台设备。下面是一个在我们的经验里行之有效的顺序。

## 1. 先看条款编号

打开 Xcode 之前，先找到条款编号，以及它指向的是哪一块（把拒信粘贴到 [App 审核拒信解读](/tools/app-review-rejection-decoder)，能看到引用的每一条和它的意思）：

- **元数据**（名称、副标题、关键词、截图、描述）：在 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）才能创建新版本。所以修复只能放进被拒的这个版本：

1. 上传一个构建号更高的新构建，在同一个版本页上选中它。
2. 元数据也在同一个版本页上改。
3. 如果要换版本号，就在被拒的版本上直接改；按我们的经验，这个字段在被拒版本上仍然可以编辑。
4. 从 App 审核（App Review）区域重新提交。

如果提交显示 **Unresolved Issues（问题未解决）**，Apple 的规则很具体：被拒的项目要么编辑后重提，要么移除；每个项目在重提前只能编辑一次；这个提交里不能再加新项目；移除的项目不能再加回同一个提交。

## 4. 确认内购跟着你回来了

版本被拒时，随它一起提交的内购通常也会被标成“被拒”，哪怕它们本身没问题。它们被拒，只是因为版本被拒了。

重新提交之前，逐个打开内购和订阅，确认它们和版本一起回到了提交里。每种类型的第一个内购必须随 App 版本提交；Apple 帮助文档也写了，版本和所有要一起审的内购，必须在提交前放进同一个草稿提交。漏了这一步，修好的应用会因为缺内购再收一封 [2.1(b) 拒审](/blog/app-review-guideline-2-1-app-completeness-rejection-zh)。

## 5. 5.6「审核暂停」给的日期是什么意思

5.6 的消息可能不指出任何缺陷，只给一个质量标准和一个日期。按我们的经验，在那个日期之前发的回复和重提都不会被处理。把日期当作排期，而不是 bug：不要提前重提，不要靠猜去打补丁，把这段时间用来在干净设备上以陌生人的视角把应用用一遍。日期过了，先做一次小而稳的重提。详见 [5.6：审核暂停](/blog/app-review-guideline-5-6-review-suspended-zh)。

## 不要做的事

- **不要原样重提。** 指南写明，如果应用 "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](/blog/app-review-guideline-4-3-spam-rejection-zh)。
- **回复时不要争吵。** 具体、简短。5.6 开发者行为准则要求你在每条发给 Apple 的消息里保持尊重。

## 按条款找指南

- 2.1，bug 和缺内购：[App 完整性](/blog/app-review-guideline-2-1-app-completeness-rejection-zh)
- 2.3.2：[描述里的付费功能](/blog/app-review-guideline-2-3-2-paid-features-description-zh)
- 2.3.3：[截图](/blog/app-review-guideline-2-3-3-screenshots-rejection-zh)
- 2.3.7：[“Free”等价格词](/blog/app-review-guideline-2-3-7-free-price-words-zh)
- 2.3.8：[商店名和主屏名对不上](/blog/app-review-guideline-2-3-8-app-name-mismatch-zh)
- 2.4.5，Mac：[沙盒存文件与自带更新检查](/blog/app-review-guideline-2-4-5-mac-app-store-zh)
- 2.5.4：[后台模式](/blog/app-review-guideline-2-5-4-background-modes-rejection-zh)
- 4，Mac：[关掉主窗口后没法再打开](/blog/app-review-guideline-4-mac-window-reopen-zh)
- 4.1(c) 和 5.2.5：[元数据里的他人品牌](/blog/app-review-brand-names-in-metadata-4-1-5-2-5-zh)
- 4.3：[Spam](/blog/app-review-guideline-4-3-spam-rejection-zh)
- 5.6：[审核暂停](/blog/app-review-guideline-5-6-review-suspended-zh)
- VPN 问卷：[先查构建，再作答](/blog/app-review-vpn-questionnaire-before-submission-zh)

## 常见问题

### App Store 被拒之后第一步做什么？

先看条款编号，判断它指向哪一块：元数据、二进制还是内购。然后按审核员的方式复现他们看到的东西，再决定改什么。

### 元数据被拒，能用同一个构建重新提交吗？

能。Apple 帮助文档写明，因元数据被拒的，改好后可以用同一个构建重新提交。在 App Store Connect 里改，不要动代码。

### 被拒后该回复、修复还是申诉？

审核员缺信息就回复；消息里说的问题确实存在，就修好后重提；只有认为应用被误解或受到不公平对待，才向 App Review Board 申诉。还没回复过的，先回复。

### 被拒后内购要重新加进提交吗？

通常要。随被拒版本一起提交的内购通常也会被标成“被拒”，重新提交前逐个确认它们和版本一起回到了提交里。

### 重新提交后审核要多久？

Apple 说通常至少 50% 的提交在 24 小时内审完，90% 在 48 小时内。因同一条款反复被拒的应用，审核会花更长时间，所以不要原样重提。

## 一分钟自检

点“重新提交”之前：条款编号已经记下；改动针对的是消息点名的那一块；每个内购都回到了提交里；回复用两三句话说清楚改了什么、在哪里能看到。然后把 [提审前检查清单](/blog/app-store-submission-checklist-zh) 再过一遍，换了构建，构建那几项就要重查。各步骤用得上的浏览器工具都在 [工具箱页面](/toolkit)。

*以上来自 Obelisk Club 自己的送审记录。Apple 的流程和措辞会变，请以当前 App Review 指南、App Store Connect 帮助文档和你收到的消息为准。*