夜雨聆风做 iOS 出海，最焦虑的不是被拒，而是版本一直停在 Waiting for Review 或 In Review。很多团队第一反应是：“能不能催一下？”
结论先说：催审有用，但只对真正紧急、材料清楚、审核障碍已排除的单子有用。它不是插队券，更不是绕过规则。
卡审先别玄学化。Apple 在 App Review Guidelines 里明确列过提交前检查项：测试崩溃和 bug，确保元数据完整准确，联系人可用，给审核提供完整访问权限；如果 App 需要账号，要准备可用的测试账号或完整演示模式；后端服务也要在审核期间保持可访问。
所以，很多“卡审”并不是审核员慢，而是审核员无法顺利判断：账号登不上、地区服务没开、某个功能需要白名单、内购或订阅路径没讲清楚、后台临时关闭、版本说明写得太省。催之前，先把这些坑排掉。
状态也要看懂。Waiting for Review 是 Apple 已收到提交，但还没开始审核；In Review 才是正在审核。前者时间波动更正常，后者如果停很久，更值得检查 App Review 消息、测试账号、服务器状态、地区可用性和版本信息。
不要一着急就撤回重提。除非你确实发现材料有错，否则撤回可能让排队重新开始，反而更慢。
那加急审核什么时候值得提？
我会按三类判断：
第一，线上严重事故。比如崩溃、安全漏洞、支付、登录、核心功能不可用，已经影响真实用户。
第二，明确的时间节点。比如和你的产品直接相关的活动、合规要求、合作上线窗口，而且日期可验证。
第三，用户权益受损。比如旧版本有严重问题，新版本已经修复，并且你能提供清楚证据。
如果理由只是“市场排期急”“老板在催”“等了两天不爽”，通常不够硬。
加急材料别写情绪，写事实：App 名称、Apple ID、版本号、Build 号、当前状态、提交时间、问题影响范围、必须在某个时间前上线的原因，以及你已经做过哪些自查。
同时，把 Review Notes 补完整：测试路径、账号密码、地区或设备要求、内购说明、后台开关、复现步骤。若涉及线上事故，可以写用户影响、崩溃率、修复内容，但不要夸大，更不要虚构安全、医疗、金融等高风险理由。
一个合格的加急说明可以这样写：
“我们提交的 2.3.1 版本修复了生产环境登录崩溃，影响部分 iOS 用户。当前线上版本在启动后可能进入循环崩溃，客服已收到集中反馈。新 Build 已通过 TestFlight 验证，测试账号和复现路径已写入 Review Notes。由于约定上线日前需要恢复现有用户访问，请协助加急审核。”
我的建议是：卡审 24-48 小时，先排雷；发现材料缺失，先补材料或回复审核消息；确实有重大用户影响，再申请加急。
真正有效的不是“催”，而是让紧急性可验证。
最后提醒一句：App Review 不是可对抗系统。不要买所谓内部通道，不要频繁换包试探，不要隐藏功能，不要诱导审核。合规、可复现、信息完整，才是 iOS 上架最稳定的捷径。
关于我们
