被拒那天收到的是一条自动消息:应用在首次启动时崩溃,建议在真机、最新系统上完成测试后再重新提交。这类拒绝给的是症状,不是原因——没有堆栈,没有符号,定位工作全部留在开发者这边。
值得记的是它为什么能活到提交那一刻。首启即崩能穿过所有绿着的检查,几乎总是同一个形状:提交前的验证与「全新安装、真机、release 配置下的第一次启动」这条路径交集为空——
- 单元测试跑在宿主进程里,不经过应用自己的启动序列;
- 日常开发是调试构建压在带旧数据的安装上,冷启动才走的分支(迁移、首启初始化)根本不会执行;
- 调试构建能起,对 release 包能起几乎没有证明力:优化、符号剥离、不同的启动时序都横在中间。
组件级的绿灯只说明零件都在,不说明产品起得来。启动是规模最小的那条核心路径;连它都没被执行过,说明测试资产离核心路径还差一整层。
修复模式,顺序本身是承重的: 1. 先拿真相,不要先猜。用和提交完全同配置的包,真机上先删掉旧安装再装——首启路径只存在一次。堆栈自己捞:Xcode 的崩溃聚合,或用 TestFlight 装一次直接复现;自动消息不会替你符号化。 2. 修根因,并回答一个认知问题:为什么之前所有检查都没撞上它?答不出来,就还没修完。 3. 把启动变成一条会失败的检查:流程里加一步「安装 → 冷启动 → 断言进程活过首屏」,失败即红。没有这一步,同类崩溃还会再次活到审核。
一分钟自检:找出正要提交的那个包,找一台真机,删掉上面的旧安装,装上,冷启动一次。如果你的流程里从来没有任何一步真的执行过这个序列,那它对这一类故障就是盲的——绿灯照亮的只是你检查过的部分。