一次 2.4.5(vii) 拒审,值得整段记下来,因为它的机制和大多数拒审相反:命中的不是 bug,是一个功能。
条款本身(Mac App Store 公开规则):应用不应自带额外的更新检查或更新——商店自己会通知用户。信里标题的措辞是"包含可能被用于在商店之外更新应用的 framework 或 API",读起来像二进制扫描的误报,会让人一头扎进第三方 SDK 里翻符号;而"具体来说"那句点名的,往往是自家的一等公民功能:应用里的"检查更新"。
为什么本地看不见:
- 自带更新检查在非商店分发里是基本功,甚至是"负责任"的标志。同一段代码,换一个分发渠道,从 quality 变成 violation,没有任何本地检查编码这条边界。
- 绿灯度量的都是行为:能编译、能跑、测试通过。商店合同不在代码库里,没有任何本地信号长得像"违反分发政策"。
- 它藏在好功能的形状里:没有崩溃、没有报错,连日志都干净。
修的顺序,顺序本身是承重的: 1. 读原文点名的具体行为,不是分类标签。标签说 frameworks、正文说更新检查时,以正文为准,不然会去修一个不存在的问题。 2. 把"更新"映射到所有入口:菜单项、设置开关、启动时的后台检查、新版本红点、"去官网下载新版"的链接——它很少只活在一个地方。 3. 从包里拿掉,而不是运行时关掉。条款审的是成分:默认关闭、藏在设置深处的更新器,API 仍然在二进制里。商店变体应该在构建期就排除更新器,直发变体才带;运行时开关糊不住静态检查。 4. 在商店渠道上,更新属于商店。别留一条绕过商店的下载路径——那同样是"在商店外更新"。
一分钟自检:把准备提审的 Mac 应用的菜单、关于、设置全过一遍,搜"检查更新";grep Info.plist 里的更新源 URL;看一眼 Contents/Frameworks 里有没有更新框架。然后问自己:商店替你发新版时,谁负责告诉用户?如果答案里还有"应用自己",这条拒审已经在路上了。
更一般的教训:绿灯证明的是各部分能工作,证明不了产物合规——合规的判据在另一份文档里,而没有任何本地工具读它。读拒审信也是同一个纪律:从"具体来说"那句读起,别从标签读起。