首版 1.0 (1) 提审,吃到 2.1(a) Performance:应用在审核中崩溃。审核设备是 iPad Air 11-inch (M3) 和 iPhone 17 Pro Max。整份拒审里可用的诊断只有这一句——没有堆栈,没有界面,没有复现步骤。
这类拒审的价值不在它告诉了你什么,而在它逼你回答的问题:为什么一台全新设备能把应用弄崩,而你自己测不出来?
因为它测的是你回不去的状态。开发机是热的:装过、引导过、写过 defaults 和 keychain、迁移过数据。首启路径——引导页、第一次权限弹窗、空数据渲染、首次网络拉取——在你第二次运行之后就再也不执行,而它们恰恰是全应用里测试里程最短的代码;审核员却只走这一段。双端形态又把覆盖面翻倍:同一个 build 在 iPhone 和 iPad 上各有一套布局与导航分支,你每天盯着的那台,往往只测了其中一端。
处理顺序比修复本身更要紧:
1. 先复现,再动手。抹掉模拟器(Erase All Content and Settings),冷启动,从首启把核心流程的第一分钟完整走一遍,每个支持的形态各来一次。复现不了,沿状态维度加宽:首次拒绝权限、无网首启、换地区与语言——崩溃类拒审最常见的藏身处就在这些分支里。 2. 修一类,不是修一个 nil。首启崩溃几乎都是把上一次运行的假设带进了第一次运行:强解包只在数据存在时才安全的值、内容未到就取下标的数组、把首次异步拉取的结果当同步数据用的代码。让"第一次"成为显式状态——注册过的默认值、空态视图——而不是碰运气的解包。 3. 把冷启动做进提审前的检查。审核机只是一台你不拥有的测试环境;干净状态启动并走通核心流程,应该是每次提审前都跑的一条,而不是靠你记得。绿色构建证明的是组件都在,从来不是产品能从零启动。
重提时,在备注里写清楚:崩在哪、怎么修的、现在如何验证。这是你能主动交给审核的唯一上下文,而他们会读。
一分钟自检:你最常用的那台模拟器,上一次"抹掉所有内容与设置"是什么时候?答不上来,这条拒审要说的事你就已经全知道了。