iOS17 隐私协议适配详解距离 iOS 17 正式推送已经过去几个月了我陆续处理了几个项目的隐私协议适配工作也看了不少群里开发者的吐槽。说实话很多团队对“隐私协议适配”这件事的理解还停留在“在 Info.plist 里加几段权限描述文案”的阶段结果等到提审被拒、或者上线后收到用户投诉“为什么总是弹窗”才反应过来。这篇文章我想从实际踩坑的角度把 iOS 17 里涉及到隐私协议适配的几块核心改动讲清楚包括系统级的权限交互变化、图片选择器、位置授权、后台联网通知以及 2024 年之后所有上架应用都需要提供的隐私清单文件。内容会尽量贴合真实开发场景代码和配置文件都是可以直接拿回去用的。先说明一下这篇文章适合谁看如果你正在维护一个已经上线多年的老 App还没做过 iOS 17 适配那你会遇到的大部分问题都在这里如果你是刚接触 iOS 开发的新人想搞明白权限弹窗背后到底发生了什么这篇文章也能帮你建立一个完整的认知框架。我会尽量把“为什么系统要这么做”“为什么适配要这么写”讲明白而不是只丢一堆 API 文档。1. iOS 17 隐私体系改了什么先看清全局再动手1.1 这次不是单纯的“加权限文案”而是完整闭环很多开发者第一次感知到 iOS 17 隐私变化是在 Xcode 15 升级后第一次跑项目时发现系统弹窗变多了或者提交 App Store 审核时收到一条关于“隐私清单”的警告。但如果你仔细看苹果在 WWDC 2023 上的内容就会发现这次改动是一个完整的闭环从权限申请、权限使用、权限透明度到权限管理系统都介入了。具体来说iOS 17 里跟开发者直接相关的隐私改动包括这么几个方向第一照片权限的交互逻辑改变了。iOS 17 之前用户第一次访问系统相册时弹窗会直接给出“允许访问所有照片”的选项。iOS 17 里系统更倾向于引导用户使用“选择照片”或者“只允许部分访问”在一些场景下甚至不会弹窗而是弹出系统级的“图片选择器”。很多老项目还在用 UIImagePickerController 或者直接请求照片权限这部分必须改。第二位置服务新增了“减量授权”模式。用户在授权弹窗里除了可以选“使用 App 期间”“使用 App 期间精确”“不允许”之外还可以选择关闭“精确位置”。注意位置权限弹窗在默认展示时精确位置开关是一个可选项很多用户会下意识地关掉它。如果你的 App 对定位精度有强依赖比如地图导航类这部分适配不好会直接影响核心功能。第三后台联网权限通知。iOS 17 在部分场景下会对 App 在后台发起网络请求的行为进行弹窗提示系统会告诉用户“某某 App 可能正在后台连接互联网”并让用户选择是否继续允许。这个弹窗的出现逻辑虽然不完全由开发者控制但与你的网络发起方式、BGTask 使用方式都有关系。第四隐私清单Privacy Manifest。这是最需要重视的一项苹果要求从 2024 年春季开始新提交的应用和更新版本如果包含用户隐私数据的收集行为或者使用了“必需原因 API”Required Reason API就必须在项目里包含一份名为 PrivacyInfo.xcprivacy 的清单文件。这个不是可选项而是上架要求。1.2 适配策略先静态后动态先自查后整改我的经验是iOS 17 隐私适配这项工作不能零散地做最好按照“静态自查 - 动态适配 - 联调验证”的顺序推进。静态自查指的是梳理项目里所有涉及权限的代码。建议直接全文搜索几个关键词UIImagePickerController、PHPhotoLibrary、CLLocationManager、UIApplication backgroundTasks、NSURLSession还有 Info.plist 里的所有 UsageDescription。先搞清楚项目里到底用了哪些权限才能知道后面要改什么。动态适配指的是针对上面梳理出来的每一项逐一选择合适的 iOS 17 方案。比如图片选择器改 PHPicker定位流程加精确位置检测后台联网逻辑加用户提示等。这里要说的一点是适配不是简单的把 API 换掉而是要结合产品形态来做决策。同样是获取照片如果你的 App 只是让用户上传一张头像那完全不需要请求相册权限用 PHPicker 就够了但如果你要做的是一个相册管理工具那 PHPicker 就不够用还是要走相册权限但要适配 limited 授权状态。联调验证这一步最容易忽略但恰恰是最重要的。苹果的权限弹窗、授权状态变化在模拟器和真机上的表现是有差异的尤其是位置服务里的减量授权只有真机才能完整测出来。我建议适配完成后准备一台 iOS 17 的真机把授权状态的各种组合都走一遍未授权、拒绝、仅精确、仅模糊、后台定位等等。把这些状态下的界面表现、功能表现都截图留档既能作为开发自测依据将来提审被问到时也有证据可以回复。2. 相册权限与图片选择器最普遍的适配场景2.1 为什么 iOS 17 强烈推荐 PHPicker在 iOS 17 之前很多 App 获取照片的路径是这样的先请求 NSPhotoLibraryUsageDescription 权限用户点击允许后再调起系统相册界面或者自己写一个相册列表页面用 PHAsset 去读取图片数据。这套流程有一个天然的体验问题用户一旦拒绝授权App 就什么都干不了。而且从数据隐私的角度讲App 其实拿到了整个相册的访问权即使你只想要一张头像。PHPickerPHPickerViewControlleriOS 14 引入从根本上改变了这个逻辑。它运行在独立的进程里App 无法直接访问用户的完整相册只能拿到用户明确选中的图片资源。最重要的是PHPicker 不需要申请相册权限也就不会触发权限弹窗。用户在 PHPicker 里选择完图片后App 得到一个临时访问凭证只能读取选中的内容。这种“按需授权”的模式正是苹果想推的iOS 17 在系统设置里也对相册权限做了更细的分类目的就是让开发者少拿权限、用户少弹窗。我当时接手的一个项目就是活生生的例子。那个 App 是一款二手交易应用用户需要上传商品图片。老版本里开发者在 App 启动后的新手引导页就要求用户授权相册因为后面要上传图片。iOS 17 用户对这个弹窗的反感度明显提升很多用户直接拒绝导致后面连“选择图片”这个功能都进不去。后来我们换成了 PHPickerApp 启动时的权限弹窗直接移除了用户在需要上传图片时才调起选择器整个流程的转化率反而提高了。2.2 PHPicker 的完整接入流程与关键参数PHPicker 的接入不算复杂但有几个细节容易踩坑我把关键代码贴出来然后逐个讲解。第一步在需要调起选择器的地方创建配置并弹出import PhotosUI var config PHPickerConfiguration() config.selectionLimit 9 config.filter .images config.preferredAssetRepresentationMode .current let picker PHPickerViewController(configuration: config) picker.delegate self present(picker, animated: true)这里有几个参数需要注意。selectionLimit 是选择数量的上限如果业务上只需要一张图就设为 1。很多人忽略的是这个参数在 PHPicker 里是支持用户多选的如果你不想让用户选多张必须显式设置。filter 用来限定内容类型.images 表示只看图片.videos 表示只看视频也可以传 nil 表示全部内容。如果你同时还要支持 Live Photo这里需要用 .images 配合 PHPickerResult 里的资源类型判断因为 Live Photo 本质上是图片和视频的复合体。preferredAssetRepresentationMode 是 iOS 15 才新增的参数它决定了你希望拿到的资源格式是原始的、兼容的还是当前的。如果你的业务需要高质量原图建议设置为 .current 或者 .original避免拿到被转码后的图。上传头像之类的场景用 .current 比较稳定。第二步实现代理方法extension ViewController: PHPickerViewControllerDelegate { func picker(_ picker: PHPickerViewController, didFinishPicking results: [PHPickerResult]) { dismiss(animated: true) let identifiers results.compactMap { $0.assetIdentifier } let fetchResult PHAsset.fetchAssets(withLocalIdentifiers: identifiers, options: nil) // 处理 fetchResult 中的 PHAsset } }注意 PHPickerResult 里有一个 assetIdentifier这个字段在你需要做后续处理比如保存到相册、上传原图时非常有用。拿到 identifier 之后通过 PHAsset.fetchAssets 可以获取对应的 PHAsset 对象进而读取更多元数据。需要注意的一个坑是PHPicker 返回的结果只在当前这次选择有效你不能把 assetIdentifier 存起来下次再用因为用户可能已经撤销了对 App 的访问授权。很多开发者在实现“选择图片后先保存草稿下次再上传”这类功能时直接存了 identifier结果下次运行发现读不到图片就是因为这一层原因。正确的做法是把选中的图片数据先临时拷贝到 App 自己的沙盒目录再存草稿。2.3 必须保留系统相册权限的场景怎么处理虽然苹果推荐使用 PHPicker但总有一些场景绕不开相册权限。比如你做的是一个图片编辑工具需要读取用户在相册里创建的所有相簿或者你需要在 App 内实现“保存到相册”的功能那就要用到 PHPhotoLibrary 的 add 方法这同样需要用户授权。iOS 17 对相册权限做了更进一步的细化系统设置里现在会把访问级别分成“无”“仅添加”“选择照片”“完整访问”几种。对应到开发侧PHPhotoLibrary.requestAuthorization(for: .readWrite) 和 .addOnly 的区别要搞清楚。如果你的产品只是想让用户“保存图片到相册”建议使用 addOnly 权限不要请求 readWrite。这样用户在设置里看到的是“仅添加照片”而不是“访问所有照片”用户的信任感会强很多。之前有一个反馈数据很能说明问题我们一个工具类 App 从 readWrite 改为 addOnly 之后权限通过率提升了将近 20 个百分点。如果你确实需要读取相册内容那就必须做好 limited 授权状态下的适配。iOS 14 之后用户可以选择“允许访问部分照片”这时你的相册列表界面要提供一个入口引导用户去系统设置里把权限改为“全部”。系统的 PHPhotoLibrary.shared().libraryUpgradeRequired 方法可以帮你判断是否需要展示升级提示。我见过不少 App 在这个状态下直接把相册列表渲染为空用户完全不知道发生了什么体验很差。这里再补充一个细节在 iOS 17 的新交互里即使用户选择了“选择照片”在第一次触发 PHPicker 时系统也可能出现一个类似“访问受限”的说明提示。这个是系统控制的开发者不需要做额外处理但如果你同时监听 PHPhotoLibraryChangeObserver可能会收到一次资源变化的回调代码逻辑上要做好幂等处理。3. 位置权限适配最容易被忽视的“减量授权”模式3.1 减量授权到底改了什么iOS 17 在位置权限弹窗里加入了一个“精确位置”开关。用户可以选择保持“约略位置”而不是精确位置。这里需要理解的是这个开关不是简单的“精度下降”而是系统层面给 App 返回的定位结果完全变成了“模糊”数据。在开发层面你需要同时关注两个维度一个是授权状态authorizationStatus决定 App 能否获得地理位置另一个是精确度授权accuracyAuthorization决定 App 拿到的是精确位置还是模糊位置。如果用户关闭了精确位置CLLocationManager 的 locationManagerDidChangeAuthorization 代理方法会首先被触发你可以通过 locationManager.accuracyAuthorization 属性拿到一个 CLAccuracyAuthorization 枚举值它只有两种情况.fullAccuracy 和 .reducedAccuracy。同时当你开始定位时系统返回的 CLLocation 对象的 horizontalAccuracy 值会变得很大通常是 5000 米左右。也就是说即使 you 所在的城市没有变返回的经纬度也会偏差很多。这对地图类、打车类、外卖类应用的影响是致命的因为这些场景下你根本没法做精确导航和派单。3.2 适配代码与降级策略适配的第一步是在请求权限之前做好判断别一上来就闷头请求。import CoreLocation class LocationManager: NSObject, CLLocationManagerDelegate { let manager CLLocationManager() override init() { super.init() manager.delegate self manager.desiredAccuracy kCLLocationAccuracyBest } func requestLocationAuth() { // 先检查当前精确度状态 if manager.accuracyAuthorization .reducedAccuracy { // 提示用户去设置开启精确位置 } else { manager.requestWhenInUseAuthorization() } } func locationManagerDidChangeAuthorization(_ manager: CLLocationManager) { switch manager.accuracyAuthorization { case .fullAccuracy: break case .reducedAccuracy: // 业务降级处理并弹出引导 break unknown default: break } } }这个判断逻辑看着简单但实际项目中很容易漏掉。不少开发者只判断了 authorizationStatus忽略了 accuracyAuthorization结果用户明明点了允许定位但定位信息返回的是 5000 米的模糊范围功能却还在走精确流程最后的体验自然是一塌糊涂。系统在用户关闭精确位置后CLLocationManager 会返回 horizontalAccuracy 为负数的结果吗不会它返回的是一个大数值的 positive accuracy。这里有一个比较可靠的判断方式当 horizontalAccuracy 大于 1000 米时就可以认为当前是减量授权状态UI 上要给出明显的提示。如果你的 App 在“减量授权”状态下依然可以运行那就要考虑业务上的降级策略。比如一个天气 App精确位置能定位到你所在的小区模糊位置只能定位到所在商圈那也可以接受只需要在页面上提示一下“已开启省电定位天气信息可能不太精确”。但如果是叫车类 App模糊定位会导致司机找不到你那最好直接弹窗引导用户去系统设置开启精确位置。苹果是允许这种引导的只要不诱导用户做违反隐私政策的事就没问题。3.3 关于“临时精确位置”的新 APIiOS 17 还新增了一个临时精确位置授权的 APICLLocationManager 的 requestTemporaryFullAccuracyAuthorization(withPurposeKey:completion:)。这个 API 可以让你在业务关键时刻临时申请一次性的精确位置访问权限。举个例子用户之前关闭了精确位置但这次他要用 App 的“导航到停车场”功能。这时你可以通过 requestTemporaryFullAccuracyAuthorization 让系统弹出一个说明弹窗用户点了允许之后App 可以在短时间内获得精确位置。用完即止不会改变用户在系统设置里的默认选择。这个 API 在 iOS 17 的适配中非常实用。它既尊重了用户的默认选择又满足了特定场景下的高精度需求。使用时要记得在 Info.plist 里配置 NSLocationTemporaryUsageDescriptionDictionary 这个键里面的每个 purpose key 都要有对应的描述文案否则调用 API 后系统不会弹窗回调会直接返回失败。踩坑提醒这个临时授权弹窗是有使用频率限制的连续多次调起会失败。我遇到过在测试机上调试时连续点了七八次后面直接不弹了重启手机才恢复。所以在产品交互上不要设计成“用户每进一次页面就申请一次”而是要把这个能力留给真正需要精确位置的场景。4. 后台联网权限通知与隐私清单上架审核的必考项4.1 后台联网权限是怎么触发的iOS 17 里部分用户在安装 App 后第一次收到系统弹窗“某某 App 正在后台连接互联网”的时候第一反应是卸载。开发商第一反应是“我明明没写后台联网代码为什么系统会弹”这个弹窗背后的机制其实是系统在监控 App 在“非前台活跃状态”下的网络连接行为。具体来说当 App 处于后台、锁屏、或者处于非活跃状态时如果通过 NSURLSession 发起了网络请求系统就会记录并在后续弹出提示。这不一定是开发者显式写的后台任务才触发很多 SDK 在后台做统计上报、推送相关请求、或者及时通讯长连接都会触发这个机制。要搞清楚自己的 App 是否会被弹窗最直接的办法是在 iOS 17 真机上跑一次完整流程打开 App、切后台、等待若干秒观察日志和弹窗。但更根本的做法是在设计和开发阶段就明确你的 App 里有哪些网络请求可能在后台发起如果确实存在这些请求那么适配的重点有两条。第一确认这些请求是必要且合规的比如推送服务的 ack 请求、后台下载任务第二在 App 内的隐私设置页面里给用户一个明确的说明和可能的关闭入口。苹果并不是禁止后台联网而是要求开发者对后台联网行为负责给用户知情权。4.2 怎么合理规避无意义的弹窗弹窗的核心触发条件是“用户在非预期情况下感知到了 App 在后台联网”。所以规避思路不是去欺骗系统而是尽可能减少不必要的后台网络行为。一种常见的做法是把所有非关键性上报都合并到 App 进入前台后的第一时间统一发送而不是像以前那样每隔几秒就发一个埋点。对很多 App 来说统计上报和日志上报完全可以在进入前台时批量做根本没必要在后台实时发送。如果你们的业务有强实时性需求比如即时通信或实时定位上报那这些行为应该走系统提供的后台任务或推送机制而不是自己无限循环地在后台跑 NSURLSession。还要注意一个细节如果你的 App 使用了 BGTaskScheduler 进行后台任务刷新BGAppRefreshTask 或 BGProcessingTaskiOS 17 对这些任务的审批和运行限制更严格了。系统可能不会按你要求的时间点执行更不会因为任务没跑完就让你继续在后台联网。适配时要做好任务失败后的状态同步避免出现“后台任务没执行但 UI 状态已经改了”的问题。4.3 隐私清单从“建议”变成“上架要求”重点说一下隐私清单。这个文件本质上是一份声明你需要把 App 内收集了哪些用户数据、使用了哪些 API 的原因写清楚然后放进你的 App 包内。苹果官方提供了一份需要声明的“必需原因 API”清单涉及到文件时间戳、系统启动信息、用户默认设置、磁盘空间等 API。如果项目里使用了一些容易触发隐私声明的第三方 SDK比如崩溃统计、用户行为分析、广告聚合这些 SDK 都可能在你的二进制文件里引入需要声明的 API。你需要在项目里搜索并生成一份综合的隐私清单。实际操作中很多第三方 SDK 的最新版本已经自带 PrivacyInfo.xcprivacy你只需要确认集成的版本是不是最新的。老版本 SDK 大概率没有这个文件上架时会被警告。创建一个隐私清单的步骤很简单在 Xcode 15 的文件菜单里选择 New File搜索 PrivacyInfo.xcprivacy然后打开编辑填入 App 收集的数据类型、使用的 API 类型和对应的原因。关键点在于你要知道你到底用了哪些 API。这一点比较麻烦因为第三方 SDK 内部的调用不会直接暴露给你。我的建议是分三步走第一步先把你自己写的代码里涉及必需原因 API 的地方找出来。搜 UserDefaults、FileManager、mach_absolute_time、systemUptime 这些关键词逐一记录使用场景。第二步把项目里所有第三方 SDK 列个清单去官网查看是否有新版本支持隐私清单并确认升级后是否还需要在你的主工程里额外声明。第三步用一个私有静态扫描工具或者找一台安装了 Xcode 15.3 的机器用官方提供的命令对编译产物进行扫描。你可以通过 Xcode 的 Product Archive 导出 .xcarchive然后在终端里使用 grep 搜索相关 key也能在 build 日志里看到警告。实际扫出来的问题往往比你预期的多不要慌逐个处理即可。下面是一个隐私清单文件的基本结构示例?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keyNSPrivacyTracking/key false/ keyNSPrivacyCollectedDataTypes/key array dict keyNSPrivacyCollectedDataType/key stringNSPrivacyCollectedDataTypeUserID/string keyNSPrivacyCollectedDataTypeLinked/key true/ keyNSPrivacyCollectedDataTypeTracking/key false/ keyNSPrivacyCollectedDataTypePurposes/key array stringNSPrivacyCollectedDataTypePurposeAppFunctionality/string /array /dict /array keyNSPrivacyAccessedAPITypes/key array dict keyNSPrivacyAccessedAPIType/key stringNSPrivacyAccessedAPICategoryUserDefaults/string keyNSPrivacyAccessedAPITypeReasons/key array stringCA92.1/string /array /dict /array /dict /plist注意 NSPrivacyAccessedAPITypeReasons 里的代码是不能乱填的它必须和你的实际调用场景匹配。比如访问 UserDefaults如果你的 App 需要用 UserDefaults 存登录密钥或用户偏好可以用 CA92.1如果只是用来检测 App 是否第一次启动可能就对应不上这个 reason。填错了苹果在审核时是有可能发起质询的。关于审核被拒的应对策略我的经验是如果你的隐私清单描述和你实际上传的二进制行为不一致苹果的审核系统会通过静态扫描发现并发出 ITMS-91053 警告。这个警告在 2024 年春季之后会直接变成硬性拒绝。处理办法是不要试图在文案上蒙混过关把代码里实际调用的 API 和用途一条条捋清楚然后用客观的语言描述。5. 常见问题与排查技巧实录5.1 高频问题速查表这段时间我前前后后处理了几十个适配咨询把大家遇到最多的问题整理成一个表字段包括现象、原因、解决思路方便你在适配的时候对照着查。现象根本原因解决方案用户明明选了图片但回调里拿不到图片数据PHPicker 的临时授权在后台被系统回收在回调中立即复制图片到沙盒而不是只保存 identifier相册列表是空的用户说“我相册里明明有照片”limited 授权状态下未做增量检测使用 PHPhotoLibraryChangeObserver 监听变化并及时刷新定位信息返回经纬度偏差 5 公里用户关闭了精确位置accuracyAuthorization 为 reduced判断精确度状态提示引导开启或使用临时精确授权 API用户拒绝定位权限后点击“重新授权”无效使用了旧版 requestAlwaysAuthorization系统机制限制引导用户到系统设置页修改代码无法直接弹第二次系统弹窗进入后台后再回前台发现网络请求全部失败被系统后台联网限制请求未完成统一网络层进入前台后重新发起并给用户显示重试状态崩溃日志里有 UserDefaults 相关的隐私警告使用了必需原因 API 但未在隐私清单里声明补充 NSPrivacyAccessedAPITypes 配置隐私清单加了 UserDefaults 声明但审核被拒Reason Code 与实际调用场景不匹配检查实际用途选择正确的 code必要时移除相关调用第三方 SDK 更新后 App 启动变慢新版本 SDK 增加了隐私数据的采集和同步评估 SDK 功能关闭不必要的采集项或者更换 SDK5.2 审核被拒后的排查顺序隐私问题导致的审核被拒最容易让人慌因为苹果邮件里通常只给了一个笼统的描述比如“App 访问了用户敏感数据但未提供准确的使用说明”。我的排查顺序是这样的。先看邮件里的具体附件。苹果在处理隐私类问题时会附带一份报告或者截图看清楚它是指向了你的主工程代码还是第三方 SDK。如果是指向主工程代码直接看代码里对应的 API 位置检查是否在隐私清单声明里遗漏了。如果是指向第三方 SDK则去官网找新版 SDK看 Release Notes 里关于隐私清单的说明。再看 Unity 或者其他跨平台引擎生成的工程。如果你用的是跨平台方案编译产物里可能包含了不止一份隐私清单而且是在你自己看不见的地方生成的。这种情况下要同时检查原生工程和引擎导出的工程里的 Info.plist把两份配置对齐。最后看审核报告里的时间戳。有时候审核被拒不是因为你现在的版本有问题而是你之前测试时留下的旧包被扫描到了。如果你确认当前包没问题可以在回复审核中附上最新的测试报告和导出日志把自查结果发过去。5.3 调试权限状态的小技巧权限状态在模拟器里测试是不完整的尤其是位置授权的减量模式和后台联网弹窗模拟器基本不会触发。所以我强烈建议适配期准备一台 iOS 17 真机专门用来做权限状态切换。有几个调试技巧值得分享。第一在真机上修改权限状态时不需要每次都卸载重装。可以在系统设置里找到对应 App进入权限管理页把各个权限关闭后再打开实测下来系统状态更新的及时性没问题App 侧可以通过设置里的“重置隐私权限”或者在 App 内用 UIApplication.openSettingsURLString 引导用户跳转。第二测试精确位置开关时要观察的核心指标是 CLLocation 的 horizontalAccuracy不要只看模拟器地图上的蓝色圆圈那个不准确。第三后台联网弹窗的复现要先把 App 切到后台然后立刻在日志里看是否有网络请求日志如果没有日志但弹窗出现了那么大概率是某个 SDK 发的请求可以通过关掉各 SDK 的收集开关来逐一定位。6. 写在最后按这份清单去做能少走 90% 的弯路这篇文章的最后我不打算做什么总结性的升华就想分享一点实际经验。如果你现在才开始做 iOS 17 隐私适配我建议你给自己留出至少三个工作日不要想着一天搞定。第一天做静态自查把项目里所有权限相关代码、第三方 SDK 版本、隐私清单缺失情况全部梳理出来第二天做动态适配按照我这篇文章里提到的照片、位置、网络、清单四条线逐项改第三天用真机做组合场景测试把各种拒绝、模糊授权、取消授权的状态都过一遍同时把界面截图留档。另外一个小小的建议是适配过程中遇到某一行代码不确定时优先查看苹果官方文档的“Required Reason API”页面以那个名单为准。网上很多转载的清单已经过时了比如有的文章还在用 iOS 16 时代的 description 文案列表那对 iOS 17 是不适用的。最后说一点我的真实感受隐私适配这项工作看起来繁琐但其实是 iOS 生态回归用户体验本质的一个信号。做得好用户的信任感会提升对产品的长期留存是有很大帮助的。希望这篇内容能帮你扫清适配路上的障碍也欢迎你在评论区分享你遇到的具体问题我会尽可能给出有针对性的建议。