# App 提审卡在 Waiting for Review，跟开发者账号入驻慢是同一条线吗？ **URL:** \ **Category:** 问题求助\ **Tags:** iOS, 移动开发, App-Store\ **Created:** [2026 年11 月 2 日 02:55 UTC](https://www.shiqidu.com/t/topic/1890 "2026-11-02T02:55:24Z")\ **Posts on this page:** 1\ **Page:** 1
作者： ![shiqidu\_editor](https://www.shiqidu.com/user_avatar/www.shiqidu.com/shiqidu_editor/32/528_2.png) [@shiqidu\_editor](https://www.shiqidu.com/u/shiqidu_editor)\ 发布日期： [2026 年11 月 2 日 02:55 UTC](https://www.shiqidu.com/t/topic/1890/1 "2026-11-02T02:55:24Z")
App Store Connect 上的状态会长时间停在审核中：第一次上架的 App 会碰上，Safari 扩展拒过一次、补了演示录屏再提也会碰上。旁边常有人把这件事跟「个人开发者账号还在审」混成一句「Apple 审核慢」。两条线入口不一样，能催的条件也不一样。 ## App Review 自己写的时间目标 Apple 的 [App Review](https://developer.apple.com/distribute/app-review/) 页写着：App Review 全天运转，通常至少 50% 的提交在 24 小时内审完，90% 在 48 小时内审完。状态变化会发邮件，也能在 App Store Connect 的 Apps，或手机上的 App Store Connect App 里查。同一页还提醒：提交不完整时，审核可能被拖慢，也可能直接不过。 常见拖慢点，官方把一大部分归到指南 2.1 App Completeness：崩溃、占位内容、信息不全。需要登录的功能要在 App Review Information 里准备演示账号。难复现的环境或特殊硬件，可能要准备演示视频。首次扩展、新 App 被要录屏或演示账号，按官方说法属于把材料补齐，不是另开一条灰色加急通道。 提交侧还有几条容易忽略。[Overview of submitting for review](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/overview-of-submitting-for-review/) 写明：每个平台同一时间只能有一个 app version submission 在审。还可以另有一份不含 app version、只带活动页或自定义产品页一类条目的 submission。多平台的版本要分开提。提交顺序也不保证按你点按钮的先后审。App Review Information 应写在该平台最新已通过版本那一侧，给审核员可操作的说明，而不是只在邮件里抱怨「已经等了很久」。 ## 跟开发者账号入驻慢分开 国区个人账号注册、协议、付款方式那一截卡住，走的是开发者计划入驻，不是某一版 binary 的 App Review 队列。站里[这篇](https://www.shiqidu.com/t/topic/1848)专门谈账号入驻等待。账号还没真正能用 App Store Connect 提版本之前，谈「催审」没有对象。已经能提版本、状态停在 Waiting for Review / In Review，才轮到下面说的 Expedited。 把两件事搅在一起的典型表现是：还在等账号邮件，却去搜「如何加急 App Review」。或者账号已可用，却把「演示账号没填」造成的反复拒审，说成「审核队列本身坏了」。前者要回去走入驻，后者先把 App Review Information 和构建完整性补齐。 ## 官方 Expedited 怎么走 [Request an expedited review](https://developer.apple.com/help/app-review/after-submitting-for-review/request-expedited-review/) 写得很清楚：必须先在 App Store Connect 把 App 提交给 App Review，只有已经送审的 submission 才能申请加急。适用情形举例是修复严重 bug，或发布时间要跟自己直接相关的活动对齐。Notes 里要写复现步骤（修 bug），或写活动名称、日期、App 和活动的关联。需要登录的功能，同样要准备好演示账号或 demo mode。官方注明：expedite 应留给真正紧急的情况，加不加快还取决于当时的容量和需求。 App Review 页对 Expedited 的概述与帮助页一致：严重 bug 修复，或与活动时间绑定。没有写「首次上架等不及」或「扩展被要了一次录屏」这一条。别把「材料被要补」理解成加急失败。缺 Notes、缺演示账号，本身就会拖慢普通队列。也没有任何官方页授权第三方「代催」「插队」渠道，那些说法直接忽略。 状态自己先对一下时间线：提交时刻、有没有收到过「信息不完整」类回信、构建能不能安装、演示账号能不能在干净设备上登录。目标里的 50% / 90% 是整体统计，不是你这一单的承诺。超时本身也不等于一定能 Expedited。和活动相关的加急，最好在 Connect 里提前排好发布日期，帮助页也建议能排期就先排期，而不是把加急当成日常节奏。 卡在 Waiting for Review 超过两天的，最后是补齐了 2.1 材料过的，还是走了官方 Expedited？