添加NSLocationAlwaysUsageDescription至info.plist的影响及合规咨询

嘿，我来帮你理清楚这个问题的来龙去脉和应对方向：

首先你遇到的情况很典型——苹果的自动审核会扫描App二进制里的API符号，只要检测到requestAlwaysAuthorization这类特殊权限API的引用，不管你实际有没有调用，都会要求你在Info.plist里配上对应的权限描述，否则直接拒审。

先说说添加这个描述会带来的影响： #

• 审核层面：最直接的结果是能通过苹果的自动检测，顺利拿到审核结果，解决当前被拒的问题。
• 用户体验层面：如果你的App本身不需要始终定位权限，用户在系统设置的「隐私-定位服务」里会看到你的App有「始终允许」的选项，但因为没实际调用接口，用户不会看到权限请求弹窗。这种“有选项却没用到”的情况，可能会让敏感用户质疑App的隐私合理性，甚至降低对App的信任度。
• 后续合规风险：如果未来第三方库更新后实际触发了requestAlwaysAuthorization调用，你提前加的描述能避免再次被拒，但此时用户会看到权限弹窗，你必须确保描述内容和实际用途一致，不然可能会因为“描述与实际使用不符”再次触发审核问题。

如果你不想添加不必要的权限描述，还有这些替代方案： #

• 移除无用的API引用：用静态代码分析工具（比如Clang静态分析）或者开启App Thinning的「剥离未使用代码」功能，把二进制里没被实际调用的requestAlwaysAuthorization符号删掉。不过这个方法需要一定技术能力，得确保不会破坏第三方库的正常功能。
• 更换第三方库：找功能相同但不包含该权限API引用的替代库，从根源上解决符号扫描的问题。
• 联系第三方库开发者：给开发者反馈这个情况，要求他们移除不必要的权限API引用，或者提供不含该API的轻量化版本。

补充一句：苹果的这种检测逻辑是基于符号匹配，不是代码执行路径分析，所以哪怕代码没跑起来，只要二进制里有这个符号，就会触发审核要求。

内容的提问来源于stack exchange，提问作者Jonas Stawski