把审核看成一次无陪同用户测试

App Store 首发多了一位关键参与者：一名不了解产品背景的审核员，需要在指定 Build、陌生设备、陌生账号和不同网络环境中独立完成检查。开发者本地能够运行，只能证明开发环境成立；审核员能否理解产品、进入账号、找到购买项目并完成核心任务，决定了提交能否顺利推进。

因此，App Review 可以按异步复现流程来准备。团队先收窄首发范围，在 TestFlight 和全新设备上走完主流程，再把测试账号、前置条件、Review Notes、演示材料、数据用途和兼容范围交给审核。遇到问题后，按 Guideline 逐条回复「问题、修改、验证方法」，并保留每个版本的证据。

本文所述平台规则查阅至 2026 年 8 月。Apple 会持续更新 App Review Guidelines、App Store Connect、隐私清单、Required Reason API 和各地区商业条款；正式提交前仍应重新检查与产品功能和分发地区直接相关的官方页面。^[1][2]

审核员拥有平台规则和审核工具，不会天然理解垂直业务。一个与 Airtable、企业账号、医疗设备或专用硬件连接的应用，若没有上下文，审核员可能连从哪里开始都无法判断。

提交材料要让对方回答五个问题：

1. 这个应用服务什么用户；
2. 审核需要从哪个入口开始；
3. 需要什么账号、权限、数据、设备或网络前提；
4. 核心功能怎样一步一步完成；
5. 成功结果应该是什么。

Apple 当前 App Review Guidelines 要求提交版本包含完整元数据、可用链接和已经在设备上测试的稳定 App。若应用有账号功能，要提供有效 Demo Account 或经过 Apple 预先同意、能够展示完整功能的 Demo Mode；后台服务也要在审核期间保持可访问。非显而易见的功能、应用内购买和商业模式应在 Review Notes 中解释。^[1]

这条要求可以转成一个简单标准：交给一位从未见过产品的人，只给提交材料，不进行口头陪同，看他能否走完审核路径。不能完成时，问题可能出在产品、环境或说明中的任意一层。

首发先减少变量

首次上架通常同时暴露功能、账号、支付、隐私、设备、平台和元数据问题。把所有愿望放入第一个版本，会让每轮拒绝都难以定位原因。^[3]

首发范围可以用三张清单收窄：

必须完成

• 用户最核心的任务；
• 完成任务所需的注册或登录；
• 必要的权限、输入和结果；
• 与核心价值直接相关的付费能力；
• 错误、空状态和恢复路径；
• 支持、隐私与账号管理入口。

可以延后

• 不影响主任务的 Widget；
• 额外主题和复杂个性化；
• 次要平台和设备优化；
• 多套 Onboarding 路径；
• 尚未形成完整验证方式的实验功能；
• 只为首发显得丰富而加入的页面。

必须删除或修正

• 占位文案和空链接；
• 无法使用的购买项目；
• 隐藏但仍可触发的未完成功能；
• 与真实能力不一致的截图和描述；
• 已废弃的 SDK、权限和账号；
• 不真实的平台支持声明。

收窄首发并不代表隐瞒残缺。核心承诺、账号、支付和主流程仍要完整，暂不支持的能力要从产品和元数据中一致移除。

从 TestFlight 建立可复现基线

TestFlight 适合在正式提交前验证安装、升级、账号、购买沙盒、通知、权限和真实设备行为。内部测试先覆盖团队控制的账号与设备，外部测试再观察不了解产品的人能否独立开始。^[3][1]

Apple 当前说明，TestFlight 可以邀请最多 100 位具备指定 App Store Connect 角色的内部测试者，也可以邀请最多 10,000 位外部测试者。外部测试组需要 Beta App Description、Beta App Review Information 和联系邮箱，某个版本的第一个外部 Build 需要先经过 TestFlight App Review；后续 Build 可能不再需要完整审核。这些容量和流程属于动态平台能力，采用时应以 App Store Connect 为准。^[1]

测试不应只记录「能打开」。每个 Build 至少覆盖：

• 全新安装与升级安装；
• 新账号、已有账号和被限制账号；
• 登录、退出、密码恢复和第三方登录；
• 权限首次拒绝、后来允许和永久关闭；
• Wi‑Fi、蜂窝网络、慢网和无网；
• 试用、购买、恢复购买和订阅状态；
• 后台服务为空、超时或返回错误；
• 最小和最大支持系统版本；
• iPhone 与实际声明支持的其他设备；
• 深色模式、文字放大和关键可访问性路径。

测试记录应包含设备、系统、Build、账号类型、步骤、预期、实际结果和附件。只有 Build 编号与 App Store Connect 提交完全对应，测试证据才能在审核往返中继续使用。

使用全新环境，而不只依赖开发机

开发者设备往往已经保存登录状态、Cookie、权限、调试配置和历史数据。审核设备没有这些条件，环境差异很容易暴露死循环。

提交前可以安排一轮「干净房间」测试：

1. 删除应用和相关本地数据；
2. 使用从未登录过的测试账号；
3. 关闭开发环境专用代理和白名单；
4. 从公开可访问的后端开始；
5. 按 Review Notes 中的步骤操作；
6. 在没有开发日志提示的情况下处理失败；
7. 核对所有成功和错误文案；
8. 再让一位不了解业务的人独立复现。

若应用依赖特定硬件、样本二维码、企业租户、地理位置或预置内容，审核材料需要提供可用资源或清楚替代方式。测试账号不能依赖一次性验证码落到无人查看的邮箱，也不能要求审核员联系团队后才临时开通权限。

App Review Information 要能独立使用

App Store Connect 当前要求提供审核联系人姓名、电话和邮箱，并根据应用情况提供 Demo Account、密码和 Notes；还可以上传审核附件。这些信息不会显示在商店页面，用于让审核团队完成检查。^[1]

审核信息可以按以下顺序组织：

联系人

• 使用审核期间能够响应的姓名、邮箱和电话；
• 确保联系人理解产品和本次 Build；
• 若跨时区，内部安排接收通知和交接；
• 不在公开文档复用审核专用联系方式。

测试账号

• 提供长期有效、权限完整的专用审核账号；
• 明确用户名、密码和对应角色；
• 预置完成核心任务所需的安全样本数据；
• 禁止二次验证阻断审核，或说明可行测试方式；
• 不放真实客户、员工或生产敏感数据；
• 审核结束后按既定安全流程管理，而非把凭证公开。

前置条件

• 指定设备、系统、地区或语言条件；
• 说明需要开启的系统权限；
• 提供外部服务、样本二维码或硬件替代；
• 说明购买项目和沙盒状态；
• 写清后台服务在审核期间可用。

Build

• 写明版本号和 Build 编号；
• 说明本次新增或修改的具体功能；
• 不使用「Bug fixes and improvements」代替真实变化；
• 核对附件展示的就是提交版本。

Apple 当前 Guidelines 要求在 Notes for Review 中具体说明新增功能、产品变化和可审核入口，泛化描述可能被拒绝。^[1]

Review Notes 使用短而完整的结构

Review Notes 的任务是压缩上下文，方便当前和下一位审核员快速理解。它不适合复制整段历史聊天，也不需要证明开发者在技术上正确。^[3]

一份可扫描模板如下：

App purpose
一句话说明目标用户和核心任务。

Build under review
Version 1.0, Build 42。

Demo account
Username / Password / Role。

Prerequisites
需要的权限、样本、设备、地区或外部服务。

Core review path
1. 打开应用并登录；
2. 进入某页面；
3. 完成某操作；
4. 查看预期结果。

In-App Purchases
商品位置、测试入口、适用状态和结果。

Changes for previous issue
按 Guideline 编号说明问题、修改和验证方法。

Attachment
演示视频或截图说明。

每次重新提交时，只保留仍然有用的背景，更新 Build、修改内容和验证路径。容易反复误解的业务规则可以继续放在 Notes 中，过期说明要删除。