有时提审被一封自动消息停住，而不是一条带编号的指南判定。我们有两次是这样：自动分析认为应用含有 VPN 功能，要求在 App Store Connect 里回答两个问题：收集了哪些用户信息，出于什么目的？ 其中一次是 1.0 版本，而且那个应用几乎不联网。
下面来自我们自己的送审记录。
它是问卷，不是拒审
它靠补信息解除，不靠改代码，补信息的最佳时机是提审之前。它总在提交后才出现，是因为预审分析读的是信号，不是意图：链接的框架、entitlements、二进制里的字符串。只要二进制携带网络扩展相关的能力，它就是一台“含 VPN 功能”的机器，哪怕 VPN 只是边缘特性。本地的构建、测试、静态检查全绿，因为没有任何本地门会问“这组符号会不会触发审核的 VPN 问卷”。
处理顺序
- 逐字答问题。 它问“收集什么、为什么”，答案就按这两条组织。“我们非常重视隐私”这类立场声明，一条也没答上。
- 先扫产物，再写答案。
otool -L看链接了哪些网络相关框架；codesign -d --entitlements看有没有 network-extension、personal-vpn；grep本地化字符串里那个关键词。能写“未链接该框架、无该 entitlement”，这是可核查的事实；“我们不做这个”的保证只是感觉。 - 把答案放进消息点名的地方。 既在回复里答，也写进 App Review Information。只回消息，下一轮读 notes 的人看不到。
- 删掉可移除的触发点。 链进来却没用到的框架、过期的 entitlement、遗留文案，直接删，别靠解释绕过。带着触发点过审，下个版本会收到同一道题。盘点二进制携带的网络能力、逐项问它是否承重，是不被这份问卷点名的最便宜办法。
- 与隐私声明对齐。 这条通道能看到什么、用途是什么、是否留存、流向哪里。问卷答案和隐私标签互相矛盾，比坦白承认收集更糟。
一分钟自检
上传前，在工程里搜 NEVPNManager、NETunnelProvider 和任何 VPN entitlement，并对将要上传的构建跑一遍第 2 步。每一个你说不清来由的网络能力，都是一封还没寄到的审查问题。
以上来自 Obelisk Club 自己的送审记录。Apple 的流程会变，请以你收到的消息和当前 App Review 指南为准。