Guideline 2.1（Performance – App Completeness） 的拒审信很短。2.1(a) 说发现了一个或多个 bug，附上设备型号和版本号；2.1(b) 说审核无法完成。1.0 首次提审撞上它，第一反应多半是「我这里复现不了」，而这个反应本身就是答案。
下面来自我们一批小应用的送审记录。三种情形占了大多数。
1. 冷启动才是审核环境
你的每一次测试都是热路径：数据是全的，权限早就授过，主流程走过上百遍，设备是自己最顺手的那台。一个 1.0 在上线前真正意义上的冷启动只有一次，并且必然落在审核员手里：空数据、每个弹窗都还没回答、一台你没挑的设备（我们有一次信里写的是 iPad Air），入口还是你从来不会点的那个。
构建和测试通过，证明零件都好，不证明产品在陌生人的前五分钟里是好的。
按他们的方式复现：
- 先读信。设备型号标出这次检验的是哪个形态；如果有复现步骤，照着走，别按自己习惯的路径走。
- 抹掉一台模拟器（Erase All Content and Settings），装上提审的那个构建，拒掉每个权限弹窗，从最不显眼的入口开始点：空列表、设置页、次要 tab、旋转、前后台切换。
- 把「陌生人的前五分钟」固化成每次提审前的固定动作。它抓的是你自己永远不会自然走到的路径，所以「再多测几遍」替代不了它。
2.1(b) 还意味着审核会在手机和平板两种形态上跑，核心流程要在两边都能走完。
2. 检查全绿，购买按钮却冻结
付钱那一下，是全 App 里唯一一条编译通过、单元测试通过、付费页正常渲染、购买接口也被调用过，而订阅按钮在真正被点下去时仍然冻结或报错的路径。我们有过两次这样的 2.1(a)，一次按钮冻结，一次点击报错，送审的包检查全是绿的。这些信号都是中间信号，故障发生在它们所在层级之下。
- 成功信号只有一个：完整购买流程走到权益到账。产品加载成功、页面渲染、接口被调用，都不算。
- 用 UI 测试真点那个按钮：点击、等待、断言已解锁，重启后也要在。
- 间歇性失败不是 flaky 测试，是缺陷本身按自己的失败率被采样。找到卡住的阶段：产品加载了吗？交易开始了吗？确认页弹出又关掉了吗？一次变绿的重跑只是又一个样本，不是关闭。
3. 没有送审的内购
我们的一款 tvOS 应用吃了 2.1(b)：应用引用了付费内容，但对应的内购项目没有提交审核。构建有效，本地检查全过；「内购是否随这个版本送审」只存在于 App Store Connect 里。几个平台事实叠成盲区：产品停在 Ready to Submit，不等于已随本版本送审；上传新构建不会自动带上待提交的内购；把内购挂进版本只能在网页端操作；内购缺审核截图会停在 Missing Metadata，连版本页的选择列表里都不出现。
修的顺序：先让产品可提交（本地化元数据加不透明、无 alpha 的审核截图），逐个提交内购审核，再逐个挂到要送审的版本上。然后加一道检查：列出应用引用的每个 product id，和版本页已挂的做差集，「引用了但没挂上」就拦住提交。
一分钟自检
抹掉模拟器，装当前构建，拒掉所有权限，空数据下点主流程之外的第一条路径；再在全新安装里打开付费墙，记下它展示的每个内购，去 App Store Connect 的版本页逐个确认已列出且已送审。第一步出现空白、卡死或崩溃，或第二步少了某个 product id，就是审核员会先找到的东西。
以上是 Obelisk Club 自己的送审记录。Apple 的措辞和工具会变化，具体行为请以当前的 App Review Guidelines 和 App Store Connect 为准。