一封自动化的预审消息能把提审整个停住:预审分析判定应用含 VPN 功能,要求在 App Store Connect 里逐条回答——这条 VPN 收集哪些用户信息、收集来做什么。这类停摆是问卷,不是否决;它的解除从来不是靠改代码,而是靠补信息,而补信息的最佳时机是提审之前。
为什么它到那一刻才显形:自动分析读的是 entitlement 和链接的框架,不是你对应用的自我定位。只要二进制携带网络扩展相关的能力,它就是一台“含 VPN 功能”的机器——哪怕 VPN 只是产品的边缘特性。本地的构建、测试、静态检查全绿,因为没有任何本地门会问“这组符号会不会触发审核的 VPN 问卷”:本地门验证你造了什么,审核屏核对声明了什么,缝隙就长在中间。
通用修复模式,顺序本身是承重的:
1. 先盘点再决定:列出二进制实际携带的网络能力(entitlement、链接的框架),逐项问它是否承重。不用的就删——一个闲置的 entitlement,是永远不被这份问卷点名的最便宜办法。 2. 把答案写到能交给隐私监管的水准:这条通道能看到什么数据、用途是什么、是否留存、流向哪里。含糊的回答只会换来下一轮追问。 3. 提审前就把答案放进 App Review Information 一栏,并与隐私声明逐条对齐。问卷答案和隐私标签互相矛盾,比坦白承认收集更糟。
一分钟自检:在工程里搜 VPN 相关符号(NEVPNManager、NETunnelProvider、vpn entitlement)。只要命中一条,而你没法各用一句话说清“收集什么、为了什么、流向哪里”,今天就写这三句——不要等到提审被拦的那天。