App Store 加急审核：如何向 Apple 申请

加急审核确实存在，但 Apple 只把它留给特殊情况，并列出了两种：修复已上线版本中的严重 bug，或者发布一个与你的 app 直接相关的活动挂钩的版本。 你先提交版本，在审核备注里说明紧急原因，然后再提交申请表单。Apple 会逐一评估每个申请，并视自身情况加快审核：这从来都不是保证。

我的 app，Solys、TradaZen 和 Nolera，都是用 Expo 做的。如果 bug 出在 JavaScript 代码里，修复会通过远程更新发出去，不用经过 App Review。所以加急审核只在我需要原生构建时才用得上，这也是你在申请之前应该先问自己的第一个问题。本指南依据 Apple 关于加急审核的帮助页面，于 2026 年 11 月 6 日重新核对。

Apple 认可什么，什么通不过

Apple 说的是特殊情况，并要求只在真正紧急时才提交申请。它的 App Review 页面给出了两个例子，以及每种情况需要提供的材料。表格中被拒的三行是我对这些页面的理解，不是 Apple 给出的清单。

理由	Apple 的态度	需要提供或理解的内容
线上版本存在严重 bug	作为例子列出	复现步骤、当前版本
与活动挂钩的发布	作为例子列出	活动名称、日期，以及你的 app 和它的关系
首次发布延期	不行，我认为	在 Apple 看来没有任何紧急之处
没有活动的营销日期	不行，我认为	一次推广活动不算与 app 相关的活动
等待时间比平时长	不行，我认为	正常的审核时长不算紧急情况

Apple 并没有定义这个词。实际上，严重 bug 指的是在线上版本中，真实用户遇到 app 崩溃、核心功能无法使用或无法付款。 某个界面里的错别字不算。另外，如果活动临近时你的 app 还在审核中，Apple 明确表示你也可以以此为由申请加急。

三步申请流程

1. 在 App Store Connect 中提交版本。 只有已经提交的版本才能加急。如果某些功能需要登录，请在 App Review Information 部分填写演示账号。
2. 提交时填写 Notes 字段。 如果是严重 bug，描述修复的 bug 以及如何在当前版本上复现。如果是活动，写明活动名称、日期以及你的 app 和它的关系。
3. 提交 Request an Expedited App Review 表单，登录开发者账号后可从 Apple 的帮助页面进入。在表单里选择相关的 app 和平台，然后提交。

Apple 会评估申请并回复你，之后你在 App Store Connect 中跟踪这次提交。如果申请被接受，版本会比正常排队更早进入 In Review。如果被拒，审核照常进行：你不会有任何损失。

App Store Connect 里的 Reply to App Review 按钮不是用来申请加急审核的。App Review 联系页面说明它只用于就进行中的提交进行沟通；加急申请和申诉各有自己的表单。

该写什么：两个模板

App Review 读的是英文。下面是我准备好的两段文字，可以改写后填进 Notes，如果表单里有自由填写的字段也可以用。它们只有五行，因为审核员应该不用打开 app 就能明白紧急在哪里。

线上版本存在严重 bug：

Version 2.0.3, currently live, crashes at launch for users who enabled notifications on iOS 26.1. Steps to reproduce: install 2.0.3, allow notifications, force quit, relaunch. The app closes immediately. Version 2.0.4 fixes the crash (notification permission is now read after the first screen loads). No other change in this build.

与活动挂钩的发布：

This version adds the official schedule and live results for the Nantes Trail Festival on June 5, 2027. Our app is the event's official companion app (see the link to the organizer's page in the App Review Information section). Attendees need the update before the start on June 5 at 8:00 AM CEST.

这两段只是示例，不是我真正发出过的申请。写你自己的版本时记住两条规则。可核实的事实：版本、系统、步骤、日期、与活动的关系。只谈紧急原因：如果你的构建里还包含新功能，用一句话说明即可，不要为它辩护。

申请之前，先确认你真的需要

Apple 要求只在真正紧急时使用。提交表单之前，先问三个问题，再避开一个坑。

修复能不能不经审核就发出去？ 用 Expo 的话，远程更新可以替换已安装 app 中的 JavaScript 代码，无需新构建。这是我发修复的方式。但它不涵盖原生代码、权限或原生依赖：这些都需要构建和审核。而且更新内容必须保持在 Apple 已批准的范围内，正如 EAS Update 介绍所提醒的：远程更新不能改变 app 的用途。关于 iOS 更新的分阶段发布的指南详细说明了哪些内容走哪条路。

等待时间真的不正常吗？ Apple 表示，通常至少 50% 的提交会在 24 小时内审核，90% 在 48 小时内审核。如果你的版本处于等待审核状态才一天，那还在 App Store 审核时长的正常范围内。提交状态跟踪页面也列出了会拉长审核的因素：没有历史记录的首个 app、需要核实的文件、受监管的领域。

提交是否完整？ 对不完整的提交申请加急，什么也加速不了。Apple 提醒，不完整的提交会延误审核或直接失败。演示账号、备注、文件：提交表单之前全部准备好。

最重要的是，不要撤回版本再重新提交。 撤回的版本会离开队列，从头开始排。如果 Apple 在审核中向你提问，就在 App Store Connect 里回复，而不是重新提交，具体见在 Resolution Center 回复 App Review的指南。

如果 Apple 拒绝加急

你在队列中的位置不变：加急被拒不会影响正在进行的审核。为了不再陷入同样的处境：

• 预约发布。 对于活动，Apple 建议在 App Store Connect 中选择预定发布：版本提前审核，在你想要的日期上线。版本发布选项在版本页面的 App Store Version Release 部分设置。
• 尽早提交。 在活动前一周准备好的版本，留得出正常审核的时间，甚至还够被拒后修改一次。
• 为 JavaScript 保留一个免审核的通道。 用 Expo 的话，这能把一个严重 bug 变成几分钟就能发出的修复。

我给审核员写备注的模板、提交前的检查清单，以及最常见被拒情况的回复，都收在 Review Kit 里。如果你想在提交前知道还缺什么，免费诊断会告诉你，并把我的 Apple 防拒审核清单发给你。发布的所有步骤都在在 App Store 上发布应用里。

常见问题

App Store 加急审核需要多长时间？

Apple 不给任何时限。它表示会评估每个申请，并根据自身情况和当时的申请量加快审核。申请被接受后，版本会提前进入 In Review，但不承诺具体时间。

首个 app 能申请加急审核吗？

没有规定禁止，但 Apple 只把加急留给真正紧急的情况，并列出两个例子：已上线版本的严重 bug，或与有确定日期的活动挂钩的发布。在我看来，首次发布比你的计划晚了，不属于其中任何一种。

加急审核可以申请多少次？

Apple 没有公布次数。它要求只在真正紧急时申请。我认为，每一次没有充分理由的申请都会让下一次显得不那么可信：把它留给真正影响用户的 bug。

申请加急前需要撤回提交吗？

不需要，恰恰相反。只有已经提交的版本才能加急，而撤回的版本会失去在队列中的位置。先提交，填好 Notes，再提交表单。

加急审核表单在哪里？

在 Apple 开发者网站上，登录账号之后：加急审核的帮助页面通过 Request an Expedited App Review 链接进入表单。在那里选择相关的 app 和平台。

加急审核能保证 app 通过吗？

不能。它只改变在队列中的位置。版本和其他任何版本一样，必须遵守 App Review Guidelines，仍然有可能被拒。

能不经过 App Review 修复 bug 吗？

用 Expo 或 React Native 的话，远程更新可以替换 JavaScript 代码，无需新构建，也无需审核。原生代码、权限和原生依赖仍然需要构建并提交给 Apple。