App Tracking Transparency is the iOS feature behind the "Allow [App] to track your activity?" prompt, and it changed how mobile advertising and analytics work. Since iOS 14.5, your app must ask permission before it tracks a user across other companies' apps and websites or accesses the advertising identifier. The part that catches developers off guard is that a third-party SDK, an ad network or analytics library, can trigger the tracking obligation even if your own code does nothing. Here is what ATT is, when you actually need the prompt, and how to handle it.
Short answer
App Tracking Transparency (ATT) requires your iOS app to get the user's permission, through the system prompt, before it tracks them across other companies' apps and websites or accesses the device's advertising identifier (IDFA). Per Apple's user privacy guidance, you need ATT if your app or any SDK in it links user or device data with data from other companies for targeted advertising or shares it with data brokers. You add an NSUserTrackingUsageDescription string and call the request API, and if the user declines, you must not track and the IDFA is unavailable. Apple requires this under Guideline 5.1.2, and it applies regardless of whether the tracking comes from your code or a dependency.
What you should know
- ATT gates tracking: permission is required before tracking across apps and sites.
- It controls the IDFA: the advertising identifier needs ATT permission.
- SDKs can trigger it: an ad or analytics library counts as tracking.
- Declined means no tracking: you must honor the user's choice.
- It is required by Apple: Guideline 5.1.2 mandates the permission to track.
What is App Tracking Transparency?
It is the iOS framework and prompt that put cross-app tracking under user control. Before ATT, apps could access the device's advertising identifier and link user data across apps and sites for advertising fairly freely. Since iOS 14.5, an app must request authorization, showing the standard ATT prompt, before it does that, and only if the user allows it can the app track them or read the IDFA. "Tracking" here has a specific meaning: linking data collected in your app to data from other companies for targeted advertising or measurement, or sharing user or device data with data brokers. ATT does not gate everything an app does with data, only that cross-company tracking, which is why understanding what counts as tracking is the key to knowing whether you need it.
When do you need the ATT prompt?
When your app or its SDKs track users across apps and sites. The table clarifies.
| Behavior | ATT prompt needed? |
|---|---|
| Showing personalized ads using the IDFA | Yes |
| Sending user or device data to a data broker | Yes |
| An ad or analytics SDK that tracks across apps | Yes |
| Sharing data to link with other companies' data | Yes |
| First-party analytics with no cross-company linking | No |
| No tracking and no IDFA access | No |
The line is cross-company linking. If your app, or a third-party SDK you include, combines your data with other companies' data for advertising or shares it with data brokers, you need ATT permission. Purely first-party use of data, analytics about your own app that you do not link to other companies, generally does not require the prompt. The trap is that an ad network or attribution SDK often performs tracking by default, so you can owe an ATT prompt because of a dependency.
How do you implement it, and what counts as tracking?
Declare the purpose, request authorization, and honor the result. Add an NSUserTrackingUsageDescription string to your Info.plist explaining why you want to track, since the system shows part of this context and the app is rejected without it when you use the tracking APIs. Call the tracking authorization request at an appropriate moment, and only track or access the IDFA if the user grants permission; if they decline, do not track, and expect the advertising identifier to be unavailable. Crucially, audit your SDKs, because an ad, attribution, or analytics library may track across apps on your behalf, which means you must present the ATT prompt and configure the SDK to respect the result. Keep your App Privacy label and any tracking disclosure consistent with this, since what you declare must match what the app and its SDKs actually do.
What to watch out for
The first trap is assuming you do not need ATT because your own code does not track, when a bundled ad or analytics SDK does; audit your dependencies. The second is using the tracking APIs without the NSUserTrackingUsageDescription string, which causes a rejection. The third is ignoring the user's choice, continuing to track after a decline, which violates the rule and your privacy commitments. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and surfaces the SDKs and network endpoints in your build, which helps you see which tracking or advertising libraries are present so you know whether ATT applies. The prompt and SDK configuration you implement in the app.
What to take away
- App Tracking Transparency requires user permission before your app tracks them across other companies' apps and sites or accesses the IDFA.
- You need it if your app or any SDK links user data with other companies' data for advertising or shares it with data brokers; first-party use generally does not.
- Add the NSUserTrackingUsageDescription string, request authorization, and honor a decline by not tracking, since Apple requires this under Guideline 5.1.2.
- Audit your SDKs, since a dependency can trigger the obligation, and use a pre-submission scan such as PTKD.com to see which tracking libraries are in your build.
