你四天前给外部测试员传了一个 TestFlight build。内部测试员立刻能装，外部测试员却看到 “This build is not yet available.” 在 App Store Connect 里，外部 group 下的这个 build 状态是 Waiting for Review。前几次审核都不到一天就过；这次到了 96 小时。审核员没消息、没拒、没邮件——一片寂静。你在纠结：重传、找 Apple、还是接着等。
最快的思路：TestFlight App Review 没有加急通道，所以先排除任何在悄悄卡你的东西（检查 Resolution Center，确认 build 没卡在 Missing Compliance），再用内部测试员（不需要审核）解锁紧急测试，让外部审核自己走完。只有在确实过了下面表里的预期窗口后，才去联系 Apple。
截至 2026 年 6 月，“Waiting for Review” 的中位时间大约 9 小时，真正 “In Beta Review” 大约 1 小时（见 Runway 的实时审核耗时追踪）。但长尾很长：高峰窗口里同一个队列会拖到好几天，2026 年 3 月那波积压时，有开发者等了 7 到 30 天。所以等 4 天算慢，但还没到”一定出问题了”的程度。
一个容易绊倒人的命名点：Apple 现在文档里叫它 TestFlight App Review（以前叫 “Beta App Review”，build 状态里你还会看到 “In Beta Review”）。同一个审核、同一个队列。
先判断你属于哪一类
动手前先过一遍这张表。靠前的几行是成本低、命中率高的检查。
| 现象 | 大概率原因 | 在哪看 | 怎么做 |
|---|---|---|---|
| build 状态是黄色 Missing Compliance / Waiting for Export Compliance Review | 出口合规问题没答，审核根本没开始 | TestFlight 标签，build 那一行 | 回答加密问题（见 Step 1） |
| Resolution Center 里有未回的 thread | Apple 在等你，时钟实际暂停 | App Store Connect → Resolution Center | 回复那个 thread |
| 全新 App 的第一个外部 build | 首发审核更严（开发者历史、业务、内容） | 无 | 预期 2-4 天，见原因 1 |
| 自上个 build 起加了 entitlement / 新 IAP / 新登录方式 | build 被标记人工细看 | 和上个快速通过的 build diff capabilities | 预期更慢，见原因 3 |
| WWDC 周、11 月底-12 月、或新 iOS major 发布刚过 | 系统性高峰积压 | r/iOSProgramming、Apple Developer Forums | 等，见原因 2 |
| 状态已经是 Ready to Test 但测试员装不上 | UI / 同步滞后 | 硬刷新、看 Activity | 见原因 5 |
| 以上都不对，且已经好几天 | 可能是系统事故或队列真的慢 | Apple System Status | 见原因 6，再走 Step 5 |
常见原因
按命中率排序。
1. 新 App 第一次外部审核
全新 App 的第一个外部 build 要走额外环节：开发者历史、业务核验、内容审查。v1.0 预期 2-4 天，而成熟 App 的中位数不到一天。注意 Apple 真正的规则是：每个新版本的第一个 build 都要走一次完整审核；同一版本之后的 build 通常能跳过。所以一个新版本号（不只是新 App）就可能重新触发慢通道。
如何判断：看这是不是这个版本的第一个 build（或这个 App 历史上第一次提交）。任意一种都会把你打回慢车道。
2. Apple 高峰窗口
WWDC 周（6 月上中旬）、11 月底到 12 月（节日封板前的爬坡）、新 iOS major 发布后几天，审核延迟都集中。TestFlight App Review 用的是和完整 App Store Review 同一批审核员，这些窗口里人手被占满。2026 年 3 月那波积压把部分外部审核推到了 7 天以上。
如何判断：查社区（r/iOSProgramming、Apple Developer Forums）和 Runway 追踪。同窗口其他开发者也报告多天审核，就是系统性问题，等是唯一真正有用的杠杆。
3. Build 触发了审核启发式
加 entitlement（HealthKit、Contacts、push、后台模式）、新登录/auth 方式、新 IAP、敏感数据类目，都会拉长审核。系统会把 build 标记给人工更细地看。
如何判断：把你的 entitlement、IAP 配置、capabilities 和上一个快速通过的 build diff。新增任意一项就预期更慢。
4. 审核员需要你没提供的信息
What to Test（在 Test Information 下）是你告诉审核员怎么跑这个 build 的地方。如果 build 有非显然或带门控的功能，而你没解释怎么进去，审核员可能卡住找指引，或者把它打回 Resolution Center。
如何判断：读你的 What to Test。如果写的是 “Bug fixes and improvements”，而你实际上了一个新的门控功能，那就是缺口。补上 demo 凭证和一句到达该功能的路径。
5. Build 已通过但 UI 没跟上
部分审核在后端已经完成，TestFlight 标签才慢慢刷新。Build 已经是 Ready to Test，你的 group 视图却还显示一阵子 Waiting for Review。
如何判断：硬刷新 App Store Connect（Cmd+Shift+R / Ctrl+Shift+R）。看这个 build 的 Activity 里的状态切换时间戳，并留意审批邮件（Admin 会收到）。
6. Apple 系统状态事故
少见但真实：TestFlight 或 App Store Connect 事故会静默卡住审核。Apple 的系统状态页有时会滞后 30 分钟以上才标记事故。
如何判断：查 Apple 系统状态页 + 开发者 forums / 社交平台，看过去 48 小时有没有 “TestFlight” 或 “App Review” 的提及。
动手前先收集的信息
- App Store Connect → Activity → All Builds 里精确的上传时间戳。
- Build 当前的状态字符串，以及它在这个状态多久了。
- 你的 What to Test 文本。
- 这是不是这个版本的第一个 build（或该 App 历史上第一次提交）。
- 自上次快速通过的 build 起，新增的 entitlement、IAP、capabilities。
最短修复路径
Step 1：先确认 build 没卡在合规上
打开 App Store Connect → TestFlight → External Testing → 你的 group，看 build 那一行。
- 黄色 Missing Compliance 或 Waiting for Export Compliance Review 表示审核还没开始。先回答出口合规 / 加密问题。（可以在
Info.plist里加ITSAppUsesNonExemptEncryption，给以后的 build 提前答好。） - 绿色 Ready to Submit 而你从没提交，说明它根本没进队列——把它提交审核。
- Waiting for Review（黄）→ 已排队；In Beta Review（黄）→ 审核员正在看；Ready to Test（绿）→ 完成。
Step 2：检查 Resolution Center
App Store Connect → Resolution Center → 打开你 App 的 thread。Apple 有时会在这里发一个审核问题，不触发邮件，而审核时钟实际上会暂停到你回复为止。一个没回的 thread，是真正”卡几天”里最常见、且确实是你这边责任的原因。有未回的问题就回。
Step 3：用内部测试解锁紧急需求
内部测试员不需要 TestFlight App Review，处理完成后立刻可装。你可以有最多 100 名内部测试员，每人最多在 30 台设备上测试。把任何等不了的人加进内部 group，外部审核就不是硬阻塞了。
App Store Connect → TestFlight → Internal Testing → Add Testers。每个内部测试员必须是你 Apple Developer Program 团队成员，角色为 Account Holder、Admin、App Manager、Developer 或 Marketing。
Step 4：按窗口等待
记下提交时间，等到越过对应的”联系 Apple”门槛再动。（中位数取自 2026 年 6 月的 Runway 追踪；门槛取保守值。）
| 提交时机 | 通常清掉 | 联系 Apple 前等多久 |
|---|---|---|
| 周一-周三，成熟 App | 当天到 24h | 3 个工作日 |
| 周四-周五，成熟 App | 24-48h | 下周二 |
| 高峰周（WWDC、12 月、新 iOS 后） | 3-7 天 | 7 个工作日 |
| 新 App 第一个 build | 2-4 天 | 5 个工作日 |
重交一个一模一样的 build 通常是重新排队，不是插队。注意 Apple 的上限：每 24 小时最多提交 6 个 build 审核，且同一个版本同时只能有一个 build 在审。
Step 5：等够窗口后联系 Apple
用 Contact App Review，选 TestFlight 的状态更新主题。写得就事论事、具体：
Subject: TestFlight build awaiting review — status update request
App: Acme Studio
Build: 2.7 (47)
Submitted: 2026-05-15 14:32 PT
Current status: Waiting for Review (5 business days)
Could you confirm whether this TestFlight submission has been routed?
This is an external test cycle that other deadlines depend on.
Thank you.TestFlight App Review 没有加急通道——不要从这个队列申请加急（加急只针对完整的 App Store Review）。
Step 6：为下次改进 What to Test
你的 What to Test 备注应该对标好的 App Review notes：demo 凭证、每个新功能或门控功能的一句走查、地区相关说明、一个联系方式。审核员能从你的备注里自己回答问题，而不用停下来问，就过得更快。
怎么确认已经修好
- Build 状态从 Waiting for Review（或 In Beta Review）切到 Ready to Test——可能在联系 Apple 后几小时内，或自然落在预期窗口里。
- 外部测试员能从 TestFlight App 装上 build，不再看到 “This build is not yet available.”
- App Store Connect → Activity 显示状态切换时间戳。
- 收到审批邮件（发给 Admin）。
如果还是过不了
- 回复你已有的 Contact App Review thread，附上原工单号——别新开一个，那等于排到队尾。
- 通过 Apple Developer System Status 页确认没有正在进行的 TestFlight 或 App Store Connect 事故。
- 传一个真的新 build（真实的 bug 修复或小功能）——Apple 有时会优先新提交，而不是同一个 build 的一模一样重传，而且稍有不同的 build 可能避开卡住上一个的那个启发式。
- 重新评估 build 的风险画像（新 entitlement、新 IAP、敏感类目）。如果某一个改动一直是长尾，把它单独拆成一次发版，单次审核就更快。
预防建议
- 新 App 的第一个 build、或任何新版本，都要提早提交，给依赖它的外部测试窗口留足时间；首次审核按最多 5 个工作日估。
- 仓库里维护一份 What to Test 模板，每次外部提交都从这里抄。
- 把风险改动（新 entitlement、IAP、auth）按发版拆开，单次审核更快。
- 在
Info.plist里用ITSAppUsesNonExemptEncryption提前答好出口合规，让 build 永远不卡在 Missing Compliance。 - 把关键测试员留在 Internal Testing group 做后备——内部测试不用审核。
- 别让时间紧的外部提交撞上已知高峰期（WWDC 周、12 月节日、新 iOS major 发布后那周）。