背景
很多开发者遇到 Guideline 2.5.4‑Performance‑Software Requirements 拒审，代码运行正常，没有崩溃 Bug，却反复被打回。 绝大多数情况，根源不是业务逻辑出错，而是Info.plist 权限配置、权限描述文案和 App 真实功能对不上。尤其 Expo / React‑Native 开发者，很容易在eas.json配置环节踩坑。
一、什么是 2.5.4 审核条款
Guideline 2.5.4 - Performance‑Software Requirements
苹果这条规则的核心逻辑：
App 在配置文件里声明了某一项系统能力、权限、后台模式，就必须真实使用该能力。 不能声明权限却完全不用；也不能权限用途描述和实际业务行为互相矛盾。
两类典型触发场景：
- Info.plist 里面写了权限 Key，代码全程没有调用对应能力；
- 权限描述文案写错，实际用途和文案说明不一致。
举个典型反面例子：
NSPhotoLibraryUsageDescription（相册读取权限），文案写：“保存图片需要访问您的相册”。 实际 App 只做相册读取，不做保存，用途描述冲突，直接触发 2.5.4 拒审。
二、高频踩坑权限清单（开发必核对）
表格
| Plist 权限 Key | 对应权限含义 |
|---|---|
NSCameraUsageDescription | 摄像头权限 |
NSMicrophoneUsageDescription | 麦克风权限 |
NSPhotoLibraryUsageDescription | 相册‑读取权限 |
NSPhotoLibraryAddUsageDescription | 相册‑写入 / 保存图片权限 |
NSLocationWhenInUseUsageDescription | App 使用期间定位 |
NSLocationAlwaysUsageDescription | 后台持续定位 |
💡注意：定位后台模式
UIBackgroundModes‑location，如果开启但业务不需要持续后台定位，同样会触发 2.5.4 驳回。
三、分场景修复方案
场景 1：声明了权限，但业务完全没有用到
现象：原生库、第三方 SDK 引入，打包自动注入权限 Key，业务代码并未调用。
✅ 修复步骤：
- 梳理项目全部权限，把业务完全用不到的权限全部移除；
- Expo/EAS 构建项目，一定要修改
eas.json/app.json 配置，清除多余权限声明，仅仅修改 Xcode 工程是无效的，重新打包会被配置覆盖； - 清理完成后重新打包 IPA，再提交审核。
场景 2：确实要使用权限，但是用途描述文案错误
现象：有权限调用，但是描述写的和真实行为不一致，误导用户。
✅ 修复要点：
- 权限描述直白客观，告诉用户App 拿这个权限用来干什么；
- 读相册就写读取用途，保存图片就写保存用途，不要混用；
- 避免模糊话术：例如 “需要访问相册” 这种笼统表述，尽量写清业务场景。
✅正确示例（相册读取）：
访问相册，用于选择图片上传❌错误示例（相册读取）：保存图片到您的相册
场景 3：后台模式 UIBackgroundModes 触发 2.5.4
如果开启后台音频、后台定位，业务必须真的在后台使用该能力；如果不需要，直接删除对应配置项。
四、提审自查清单（提交版本前逐项检查）
✅ 所有 Info.plist 权限 Key，业务代码中确实有对应调用；
✅ 没有第三方 SDK 残留的、未使用的权限配置；
✅ Expo 项目确认在eas.json/app.json 完成权限清理，防止构建复现；
✅ 每一条权限描述和真实用途一一对应，不存在张冠李戴；
✅ 后台模式UIBackgroundModes只保留业务真实需要的项。
提示：2.5.4 属于二进制包问题，修改元数据没用，必须重新打包 IPA 上传新版本。这点和 3.1.2 只改后台元数据不一样，很多开发者在这里踩坑。
写在最后
2.5.4 拒审，属于配置类问题，不是业务 Bug。 很多项目因为引入第三方原生 SDK，打包自动注入一堆权限，开发者没有感知，提审直接翻车。 上架前把权限清单过一遍，就能规避大部分该条款驳回，节省反复审核的等待时间。
遵守规则，方得长治久安，最后祝大家大吉大利，今晚过审！
🌟附加服务：
1️⃣支持国内外苹果🍎开发者账号，个人公司均有
2️⃣支持AppStore，好评业务！覆盖差评提高产品星级
