收到拒绝后逐条处理

拒绝信息可能包含多个 Guideline、截图和复现描述。最有效的回复通常很短，按编号逐条处理。^[1]

每条都写四项：

1. 问题：复述审核指出的具体路径；
2. 判断：确认是代码、环境、账号、元数据还是理解差异；
3. 动作：说明本次 Build 修改了什么，或补充了什么信息；
4. 验证：给出审核员可以重复的步骤和预期结果。

例如：

Guideline 2.1 — Login could not complete

Cause
The previous demo account had an expired workspace permission.

Change
Build 43 now includes a dedicated review workspace and a renewed account.

Verification
1. Sign in with the credentials in App Review Information.
2. Open Sample Workspace.
3. Tap Add Record.
4. The new record appears in the activity list.

如果开发者无法复现，先核对审核截图中的设备、系统、账号和 Build，再使用相近环境测试。不要用长篇架构说明代替结果，也不要同时提交多个未经验证的修复版本。

解释、修复、联系支持与申诉分开

当拒绝源于真实缺陷，优先修复并重新提交；当信息不足，先在 App Store Connect 补充可验证说明；当多轮文字沟通反复卡在同一环境问题，可以使用 Apple 当前提供的联系入口寻求审核支持；当团队认为规则适用或审核结论有实质争议，再考虑正式申诉。^[1][2]

沟通时保留完整时间线：

• Submission 和 Build；
• Guideline 编号；
• Apple 的原始问题；
• 团队判断与证据；
• 每次修改；
• 视频、截图和测试结果；
• App Store Connect 消息；
• 支持或申诉结果。

Apple 当前公开页面称，平均 90% 的 submission 在 24 小时内完成审核。这个统计不能预测单个首发；提交不完整、复杂功能、节假日、反复修复和需要额外信息都会改变周期。市场活动应为审核留出缓冲，不把不可控制的日期写成对用户的确定承诺。^[2]

AirKit 案例：一次拒绝可能牵出多条链

一款连接 Airtable 与 Siri 的垂直应用，在 2024—2025 年首发时经历了约一个半月的多轮审核。问题先后涉及 App Completeness、账号、订阅、第三方登录、审核设备上的授权、隐私和跟踪。开发者本地正常，审核环境却无法稳定完成路径。^[1]

后续处理逐步形成了几项有效动作：

• 把审核当成陌生环境复现；
• 使用相近设备和全新账号重测；
• 在 Review Notes 保留稳定背景；
• 用短视频展示完整业务路径；
• 按 Guideline 逐条回应；
• 文字沟通长期无进展时联系审核支持；
• 首发范围收回到核心任务和核心平台。

这个案例不说明审核普遍需要一个半月，也不能推断审核员地点、固定设备或内部机制。它说明一个功能会同时经过代码、账号、权限、数据、支付和环境，多轮出现新问题并不一定互相矛盾。完整复现资料可以降低每一轮重新解释的成本。

通过审核仍只是发布的一道门

App Review 通过，说明当前提交获得平台接受，不代表产品已经符合所有地区法律，也不代表付费、留存和用户满意度成立。平台表单没有替开发者完成数据地图、合同、税务、支付、儿童或高风险行业判断。^[3]

上线后仍要继续：

• 监测崩溃、登录、购买和核心任务；
• 按 Build 区分新旧问题；
• 跟进首次用户和审核期间遗留反馈；
• 更新支持文档与 Review Notes 模板；
• 数据用途或 SDK 变化时更新隐私披露；
• 新功能提交时具体说明变化；
• 保存每次审核的问题、修复和验证方法。

审核记录逐渐会形成产品自己的发布手册。重复出现的问题应进入自动测试、设备矩阵、数据清单和提交检查，而不是每次靠记忆处理。

发布前最后检查

• 首发只保留核心用户任务和真实支持平台；
• TestFlight 已覆盖内部、外部和全新安装场景；
• 候选 Build 在真实设备和不同网络完成测试；
• Demo Account 长期有效且不含真实客户数据；
• Review Notes 写明目的、Build、前置条件、路径和结果；
• 垂直功能提供了与提交版本一致的短演示；
• 后台、登录、邮件、支付和外部服务在审核期可用；
• 第三方登录按当前 Guideline 4.8 核对；
• 支持创建账号的 App 能在 App 内发起完整删除；
• IAP 与订阅可见、可购买、可恢复并纳入提交；
• App Privacy、Privacy Policy、Manifest 和真实数据流一致；
• Required Reason API 与第三方 SDK 已逐项检查；
• ATT、权限和数据共享在适用时取得正确授权；
• iPad 和所有声明支持的设备没有布局与流程阻断；
• 元数据、截图、链接和版本没有占位或不实内容；
• 审核联系人能在提交期间响应；
• 每条拒绝都按问题、动作和验证逐条回复；
• 支持、申诉和修复使用各自合适的沟通路径；
• 发布排期为审核不确定性保留了缓冲；
• 通过审核没有被当作法律或商业成功结论。

顺利提交的关键，是把审核所需的环境、上下文和证据提前做成产品的一部分。首发范围越清楚，测试账号越稳定，数据披露越贴近真实代码，审核员越容易在指定 Build 中得到与开发者一致的结果。审核中出现的问题也会反过来暴露产品面对普通新用户时的摩擦，这些证据值得进入下一版设计和工程基线。