[iOS] 4. Working with ATT (App Tracking Transparency / iOS)
All ATT handlig needs to be managed on the mobile app itself, and not through our SDK, as our SDK is not aware of the lifecycle of the mobile app integrating it. ATT request needs to be displayed and completely handled before our SDK, and the ATT dialog should not be loaded at the same time or on top of our consent layer. Make sure you only load our consent layer via checkAndOpen() or forceOpen() methods after handling the ATT request and making sure the user's choice regarding ATT was updated on the device already. Do not load our consent layer before that.
Overview
All new apps submitted to the App Store must comply with Apple's App Tracking Transparency (ATT) guidelines for iOS 14.0+. These guidelines enhance user privacy by requiring explicit consent before tracking. This document outlines the necessary steps to implement ATT when using our CMP SDK.
What ATT is (in one paragraph)
ATT is Apple’s rule that you must ask for permission before you “track” a person across other companies’ apps/websites or access the device’s IDFA. Apple defines tracking as linking data from your app with third-party data for targeted ads or ad measurement, or sharing data with data brokers. If you track, you must use the AppTrackingTransparency framework to show Apple’s system prompt; without permission, IDFA returns zeros and you may not track. Apple Developer
When you must use ATT
Use ATT before you (or your SDKs) do any of the following:
-
Targeted ads or cross-app measurement that combine your app’s data with data from other companies (e.g., AdMob/Meta SDK retargeting, probabilistic matching across apps)
-
Share identifiers or lists (IDFA, device IDs, emails / hashed emails, etc.) with an ad network or data broker for retargeting, lookalikes, or cross-app audience building
-
Use third-party SDKs that themselves combine data across apps (even if you don’t directly use that feature)
-
Deferred deep-linking / third-party linking that passes unique identifiers to create a shared identity across different companies’ apps for ads or measurement. (Apple’s own FAQ calls this out explicitly.)
Apple’s App Review Guidelines also make this a hard requirement: “You must receive explicit permission … via the App Tracking Transparency APIs to track their activity.”
When you don’t need ATT
-
First-party analytics only, or using IDFV to analyze usage across your own apps only (no combining with third parties).
-
On-device linkage only (data stays on the device and cannot identify the user/device off-device).
-
Fraud detection / security uses with a data broker solely for that purpose (not ads).
-
Credit reporting use cases with a consumer reporting agency.
-
Apple’s privacy-preserving attribution frameworks (AdAttributionKit, SKAdNetwork) — these don’t require ATT and can be used regardless of tracking authorization status.
You must not “coax” or “gate” the ATT prompt
-
You can’t gate access to content or features on agreeing to track, and you can’t incentivize people to tap “Allow”. Apple’s guideline 5.1.2(i) is explicit: “Your app may not require users to enable … tracking in order to access functionality, content, use the app, or receive monetary or other compensation.”
-
You may show an educational screen (pre-prompt) to explain why you’re asking, but it mustn’t manipulate or mimic the system alert and must respect the user’s choice. (Apple’s “User privacy and data use” page clarifies this.)
Implementation notes (what to actually ship)
-
Info.plist: add NSUserTrackingUsageDescription with a clear purpose string — this is required in the system prompt. (Apple announced enforcement from April 26, 2021.)
-
Requesting authorization: call
ATTrackingManager.requestTrackingAuthorization(...)at a contextual moment (after an explanatory screen, not on first launch splash). The system won’t re-prompt unless the app is reinstalled; handle authorized/denied/restricted gracefully. -
System-level setting: if the user has “Allow Apps to Request to Track” off, you won’t be able to prompt; treat as Denied and offer a route to Settings if appropriate.
-
Kids / restricted contexts: tracking may be restricted (e.g., certain age/account configurations). Code for
restrictedstatus and avoid prompting loops. -
Privacy manifests & Required Reason APIs: from 2024-2025 Apple requires manifests (for you and third-party SDKs) and declarations for “required reason APIs” — many of which are the fingerprinting-sensitive ones. Expect App Store validation to enforce this.
According to Apple's official documentation:
Calls to the API only prompt when the application state is UIApplication
1. Add the ATT Framework in Xcode
To integrate AppTrackingTransparency.framework, navigate to:
<PROJECT_NAME>.xcproject / <PROJECT_NAME>.xcworkspace -> General -> Frameworks, Libraries, and Embedded Content.
Ensure the framework is correctly embedded to enable ATT functionality.
2. Add NSUserTrackingUsageDescription
Include the following key in your Info.plist file:
<key>NSUserTrackingUsageDescription</key>
<string>Your app description explaining why tracking permission is requested.</string>
This message will be displayed to users in the ATT consent prompt.
3. Request Tracking Authorization
To ensure proper consent handling, request ATT permission on the first app launch. This should only occur if the user's consent status is unknown.
Example Implementation:
import AppTrackingTransparency
class AppDelegate: UIApplicationDelegate {
// IMPORTANT: this is the proper lifecycle event where the request needs to be done
func applicationDidBecomeActive(_ application: UIApplication) {
if #available(iOS 14, *) {
ATTrackingManager.requestTrackingAuthorization { status in
switch status {
case .authorized:
print("Tracking enabled")
case .denied, .notDetermined, .restricted:
print("Tracking disabled")
}
}
}
}
}
Note: Ensure UI-related logic is executed on the DispatchQueue.main queue, as the completion handler runs on a concurrent queue by default.
4. Monitor Tracking Authorization Status
Use ATTrackingManager.trackingAuthorizationStatus to track consent status changes. The following states are possible:
For consistency, treat restricted as denied unless explicit vendor consent is provided.
5. Handle Consent in Analytics & Third-Party SDKs
If your app uses third-party analytics, update their configuration based on the user’s ATT status:
- Disable analytics tracking for users who deny or restrict tracking.
- Use anonymized tracking if the analytics provider offers an opt-out setting (e.g., mParticle’s optOut mode).
- Review SDK policies regularly to stay compliant with Apple's privacy requirements.
Example for Firebase:
- If no ad frameworks are linked, Firebase Analytics will not access the advertising identifier.
- If using analytics with ads, ensure compliance with ATT guidelines before submission.
For apps that do not require advanced analytics, App Store Analytics (accessible via App Store Connect) may provide sufficient insights while ensuring compliance.
6. Additional Considerations
-
Wrap ATT calls in an iOS version check to avoid crashes on older versions:
if #available(iOS 14.0, *) { ATTrackingManager.requestTrackingAuthorization { _ in } } -
Track consent for older iOS versions using backend flags or local storage.
-
Comply with ATT promptly, as non-compliance may block app updates, even in cases of critical bug fixes.
For more information on managing user consent within the app, refer to Apple’s ATT documentation.
