德国联邦卡特尔局在 2026 年 8 月 17 日宣布，苹果已经就 App Tracking Transparency（ATT）提出具有约束力的改进承诺。未来，苹果自有服务和第三方 App 使用的个性化广告授权提示需要更加接近，第三方开发者也将获得更大的空间来解释个性化广告，并把 Apple 要求的授权请求与数据保护法要求的同意流程清晰地衔接起来。
这不是一次简单的“允许或禁止追踪”的政策变化。它触及了 iOS 应用如何设计隐私说明、如何请求权限，以及平台规则如何影响广告商业模式。对开发者来说，眼下不应急着假设某个新 API 已经上线，而应该先把 ATT 的系统权限、应用自己的解释页面和广告数据链路拆开治理。
这次监管结论到底改变了什么
德国联邦卡特尔局并没有认定苹果不能保护用户隐私。它的关注点是：苹果为自有服务使用的授权请求，与它为第三方 App 预先规定的授权请求，在文案、设计和选择项上存在差异，可能让用户更容易同意苹果自有服务的个性化广告，却更容易拒绝第三方 App 的请求。
监管机构还指出，第三方 App 在某些情况下需要向用户请求多次同意，即使用户已经按照数据保护法给出了有效同意。苹果认为 ATT 规则符合竞争法，但仍然提出了承诺；德国联邦卡特尔局已经把这些承诺宣布为具有约束力，并结束了相关程序。
承诺主要包含三部分：
- 让苹果自有服务和第三方 App 的授权提示更加接近；
- 移除第三方预设请求中可能造成劝阻效果的符号和措辞，使内容、文案和布局更加中性；
- 允许 App 发布者和内容提供商更充分地解释个性化广告对其服务和商业模式的意义，并以用户容易理解的方式组合或衔接 Apple 请求与数据保护同意请求。
苹果需要在收到决定后的四个月内实施承诺，并在实施前与 App 发布者共同测试。承诺期限为七年，由独立的监测受托人监督。这里的时间表属于监管公告中的实施要求，并不等于开发者今天已经可以使用一个新的 ATT SDK 接口。
ATT 在技术上负责什么
Apple 的开发者文档把 App Tracking Transparency 的职责定义得很清楚：当 App 收集与终端用户有关的数据，并与其他公司共享，用于跨 App 或网站追踪时，应使用这个框架请求用户授权，并读取授权状态。
当前的工程入口主要有三个：
- 在
Info.plist中提供NSUserTrackingUsageDescription，作为系统授权提示所需的说明； - 调用
ATTrackingManager.requestTrackingAuthorization请求用户授权； - 读取
ATTrackingManager.trackingAuthorizationStatus，决定后续是否启用相应的追踪能力。
可以把一次完整的隐私流程拆成下面三层：
1 | 应用自己的说明页面 |
这三层不是同一个东西。应用自己的说明页面可以解释为什么需要相关数据；ATT 是操作系统提供的授权机制；广告 SDK 则负责在获得合适授权后执行测量、归因或个性化处理。监管机构此次要求调整的重点，正是 Apple 预定义提示与第三方应用说明、数据保护同意之间的关系。
开发者现在不要做的三件事
不要把媒体报道理解成 API 已经变化
监管公告说的是苹果作出的承诺和实施期限。除非 Apple 发布新的开发者文档、系统版本说明或 SDK 行为变更，否则现有 ATT 调用方式仍应按当前官方文档实现。
因此，不要因为新闻出现就删除 NSUserTrackingUsageDescription，也不要在没有验证的情况下修改权限判断。权限状态可能是 authorized、denied、restricted 或尚未决定，业务逻辑仍应对每种状态做明确处理。
不要用自定义弹窗冒充系统授权
自定义说明页可以帮助用户理解产品，但它不能替代 ATT 系统提示，也不能把用户在自定义页面上的点击直接当作系统授权。只有系统框架返回的授权状态，才能决定是否执行需要 ATT 授权的处理。
更稳妥的方式是把自定义页面当作解释和选择时机的一部分，并清楚说明数据用途、是否会与其他公司共享，以及拒绝后哪些功能会受到影响。具体文案仍需结合适用的数据保护法律和产品实际情况。
不要把“允许追踪”当成唯一业务指标
德国联邦卡特尔局明确表示，目标不是帮助任何一方尽可能提高个性化广告的同意率，而是让用户能够在充分知情的情况下自由决定是否同意。
如果团队只用授权率评价弹窗，就可能在无意中把产品设计成“劝用户点击允许”。更完整的指标还应包括说明页到系统提示的转化、拒绝后的核心功能可用性、广告收入变化、归因质量、投诉率和撤回授权后的数据处理行为。
对 iOS 工程架构的三个启示
1. 把权限决策从广告 SDK 中抽出来
不要让多个 SDK 在不同页面各自决定何时弹出 ATT。应用可以建立统一的 TrackingConsentCoordinator，集中管理：当前授权状态、隐私说明是否展示过、何时请求系统权限，以及授权变化后通知哪些模块。
这样做的好处是，未来 Apple 调整请求组合方式时，团队只需要修改权限编排层，而不用在广告、分析、推送和归因代码中逐处寻找弹窗逻辑。
2. 为拒绝授权设计可运行的降级路径
ATT 被拒绝不应让 App 的核心功能失效。广告系统可以切换到非个性化广告，分析系统可以减少跨公司标识的使用，归因系统可以采用适用的隐私保护方案。具体选择取决于业务和法律要求，但工程上都应提前定义“未决定”“已拒绝”和“受限制”三种状态的行为。
同时，撤回授权也需要被视为一个运行时事件，而不是只在首次启动时判断一次。已经缓存的标识、待发送的事件和本地归因数据，都需要有清晰的处理策略。
3. 记录同意链路，而不是只记录一个布尔值
在不保存不必要个人信息的前提下，系统可以记录隐私版本、说明文案版本、用户做出选择的时间、ATT 返回状态、数据处理目的和 SDK 版本。这样当政策、系统版本或文案发生变化时，团队能够回答“用户在什么信息基础上作出了选择”。
日志不应成为绕过拒绝状态的隐蔽通道。它的目的应该是帮助排查合规和产品问题，而不是重新建立一个未经授权的跨 App 用户画像。
这对广告支持的 App 意味着什么
第三方 App 的广告收入可能依赖个性化广告带来的更高价值，但隐私授权从来不是一个只由收入决定的开关。平台提示的措辞和用户对数据用途的理解，会直接影响授权选择；如果用户认为自己被引导或重复询问，长期信任和留存也会受到影响。
这次承诺可能给内容平台和广告支持的 App 带来更多解释空间，但不会自动提高授权率，也不会取消数据保护法下的其他义务。开发者依然需要区分：哪些数据用于 App 内部分析，哪些数据会与其他公司共享，哪些处理依赖用户同意，以及用户撤回同意之后如何停止或改变处理。
更值得关注的是，德国监管机构表示这套解决方案可能影响其他欧盟成员国。法国和意大利竞争主管机构此前也曾因 ATT 对苹果作出处罚。未来 Apple 如果统一调整欧洲地区的提示设计和请求流程，跨市场运营的 App 可能需要重新测试授权率、广告填充、归因和隐私说明的交互。
写在最后
ATT 的核心问题不是“弹窗应该放在哪个按钮旁边”，而是平台、开发者和用户之间如何分配对数据使用的控制权。德国联邦卡特尔局此次要求苹果调整授权提示，说明隐私界面已经不只是产品设计问题，也可能成为平台竞争秩序的一部分。
对开发者而言，最稳妥的准备方式是保持当前 API 实现符合 Apple 文档，同时把权限编排、说明文案、广告 SDK 和同意记录解耦。等 Apple 发布实施细节后，再针对系统版本和目标市场做验证。无论最终提示长什么样，一个值得长期维护的 App 都应该让用户知道数据被怎样使用，也应该在用户拒绝或撤回授权后继续提供基本功能。