先记住顺序：先在 App Store Connect 正式提交审核，再为已提交项目申请加急。App Store expedited review 是请求尽快审核，不是一套更宽松的通过标准。你要用真实、可核验的事实解释紧迫性，Apple 则根据可用资源和申请需求决定是否受理。
哪些情况适合申请加急？
Apple 的 App Review 官方说明列举了需要特殊处理的情形，例如修复严重故障，或 App 与即将举行的活动直接相关。团队内部排期延误，并不等于存在影响用户的紧急情况。
严重故障：重点是当前线上版本。 说明 App Store 正在分发的版本出了什么问题。Apple 明确要求提供该线上版本的复现步骤。写清受影响的操作流程、对用户的影响，以及哪个已提交更新包含修复。不要把仅存在于未发布构建中的问题描述成线上事故。
活动相关：重点是真实活动和直接关系。 写清活动是什么、何时举行，以及 App 如何服务参与者。说明他们需要哪项功能，为什么这个时间点重要。Apple 建议尽可能提前安排发布；活动日期不能代替正常的发布准备。
如果无法如实说明紧迫性，就继续正常审核流程。不要编造活动，也不要把轻微缺陷夸大成严重故障。
App Store 加急审核的正确申请顺序
按照 Apple 的加急审核帮助文档准备：
- 先让提交内容具备可审核条件。 在 App Store Connect 选择正确构建并补全必填信息。在 App Review Information 的 Notes 中写好必要说明。涉及账户功能时，提供可用的演示账号或功能完整的演示模式，让审核员能够实际访问。
- 正式提交审核。 上传构建、准备资料都不等于提交完成。确认项目已真正提交；只有已提交项目才能申请加急。不熟悉流程可先看 App Store Connect 新手指南。
- 打开 Apple 官方申请表。 登录 Request an Expedited App Review，选择对应的 App 和平台。这是 Apple 的申请入口，不是 AirBuild 可以替你开启的特殊优先按钮。
- 简洁说明紧迫性。 标明已提交版本号和构建号，说明严重故障或活动事实，并补充下方清单中的相关证据。让对方一眼看懂为什么需要加急。
- 持续关注审核沟通。 留意 App Store Connect 和申请相关邮箱，安排能及时答复的联系人，并保持演示环境可用。
不要把生产环境密码、客户数据或私密凭据放进可复用的申请模板。审核所需的演示访问资料应填写在相应的 App Review Information 字段中，而不是公开文档里。
提交前的证据清单
下面是方便团队整理材料的清单，并不表示每一项都是申请表的必填字段：
- 定位本次提交： App 名称、Apple ID、平台、已提交版本号、构建号和当前提交状态。
- 一个清晰理由： 严重线上故障或具体活动，直接陈述事实，不写营销口号。
- 故障证据： App Store 线上版本号、设备和系统环境、逐步复现路径、预期与实际结果，以及已知用户影响。估算范围必须注明是估算。
- 修复验证： 本次构建改了什么，以及如何验证受影响流程已恢复。
- 活动证据： 真实活动名称、日期和时区、可核验的参考信息，以及 App 在活动中的直接作用。
- 审核准备： 必要 Notes、经过测试的演示访问或演示模式、可访问的服务，以及能够及时回复的联系人。
把观察到的事实和推测分开。相比没有依据的“所有人都无法使用”，明确写出“线上版本在结账流程第三步失败”更有帮助。影响范围尚未确认时，就如实说明。
假设申请模板：不是成功案例
以下仅用于帮助组织语言，不是 AirBuild 客户案例，也不代表申请曾获批准。请把每个占位符替换为真实信息，无法证明的内容就删去。模板中不应填写凭据。
严重故障修复
App：[名称 / Apple ID]；平台：[平台]
已提交更新：[版本号 / 构建号]；状态：[当前状态]
申请加急审核，原因是当前 App Store 线上版本 [版本号]
的 [操作流程] 存在严重故障。
用户影响：[已确认影响，以及证据范围和局限]。
当前线上版本的复现步骤：
1. [起始条件、设备 / 系统版本]
2. [具体操作]
3. [实际结果，以及预期应出现的结果]
已提交构建 [构建号] 修复了 [原因或行为]。
验证：[执行的测试及结果]。
审核访问与说明：[在 App Review Information 中的位置]。
联系人：[负责回复的团队联系人]。
活动相关提交
App：[名称 / Apple ID]；平台：[平台]
已提交版本 / 构建：[版本号 / 构建号]
活动：[真实名称]
日期与时区：[日期 / 时间 / 时区]
参考信息：[可核验的活动信息，如有]
直接关系：[App 如何服务参与者]。
时效需求：[活动期间必须使用的具体功能]。
为该已提交项目申请加急，原因是：
[说明时间为何重要的事实]。
审核说明：[在 App Review Information 中的位置]。
联系人：[负责回复的团队联系人]。
向 Apple 提交时，使用你能准确表达事实的语言。模板的价值在于信息结构，不在于某种“必过措辞”。
审核被拒后：回复、修复还是申诉？
加急解决的是时间紧迫性，不会推翻拒绝结论，也不会免除 App Review Guidelines 的要求。先根据具体问题选择路径：
- 缺少信息或审核员有疑问： 在 App Store Connect 中直接回复，补充解释或访问步骤。申诉前先答复尚未解决的审核请求。
- 产品或商店资料确实存在问题： 修复、验证，再按实际情况重新提交。新提交如果仍有真实紧急理由，再单独解释加急需求。
- 认为合规 App 被误解： 可考虑向 App Review Board 申诉。针对审核指出的问题，具体说明 App 为什么符合要求。Apple 要求每次被拒的提交只申请一次申诉。
不要把加急申请写成申诉信。即使处理速度变快，无法登录的演示账号或尚未修复的合规问题也不会自动消失。
发布计划要留余量，不要押注承诺时限
Apple 会根据可用资源和申请需求评估加急请求。提交申请、甚至理由成立，都不代表一定受理，更不代表按指定时间完成或一定通过。一般性的审核耗时数据也不是你这款 App 的服务时限承诺。
及时向相关人员同步状态，为活动或受影响用户准备替代方案，并单独核对发布设置。审核通过和更新实际可供用户下载，是不同步骤。
如果你正准备把 Web 项目带到 iOS，可以了解 AirBuild 的项目迁移选项。这属于开发工作流，不是获得 Apple 审核优先权的渠道。使用 AirBuild 或 SwiftUI 都不会自动满足审核要求。你能控制的是充分测试、完整审核资料，以及诚实且有证据支持的申请。