App Tracking Transparency is a rule about linking people to other companies, not about collecting data.
App Tracking Transparency is narrower than most teams assume. Apple does not ask for the prompt because your app collects data. It asks because your app links data about a person to data other companies collected about them, for advertising. Plenty of apps never do that, and never need the prompt. What you hold and how you hold it is a separate subject, covered in app security basics.
This page gives the Apple definition of tracking, the three cases Apple excludes from it, the App Review rule that requires the ATT prompt, what the IDFA returns after a refusal, and the five reasons the prompt sometimes never appears at all.
Check whether your app needs the promptThe short version
Tracking means linking your users to data collected by other companies, and that is the whole trigger.
Apple defines tracking as linking user or device data from your app with user or device data collected from other companies' apps, websites or offline properties, where the purpose is targeted advertising or advertising measurement. Sharing user or device data with a data broker is tracking as well.
Since iOS 14.5 you need the user's permission through the App Tracking Transparency framework before you do either of those, and before you read the device advertising identifier. Analytics that stays inside your own app and your own backend is not tracking by that definition. A third party SDK that pools your users with users of other developers' apps can be.
What Apple counts as tracking
The trigger is narrow and worth reading slowly. Tracking is linking user or device data collected in your app with user or device data collected from other companies' apps, websites or offline properties, for targeted advertising or advertising measurement. It is also sharing user or device data with a data broker, whatever the purpose of the sharing. The words doing the work are other companies. Data that stays with you is a different question.
Apple's own examples are more concrete than the definition. Showing ads in your app targeted using data gathered from apps and websites owned by other companies. Sending a list of emails, advertising IDs or other IDs to a third party ad network so it can retarget those people in other developers' apps or find people like them. Sharing device location data or an email list with a data broker. Embedding a third party SDK that combines your users' data with data from other developers' apps for ad targeting or ad measurement, even when you never use the SDK for that yourself.
Three situations are excluded. Data from your app linked to third party data only on the device, where nothing capable of identifying the user or device leaves it. A data broker that uses what you share solely for fraud detection, fraud prevention or security. And a consumer reporting agency receiving data for credit reporting or for a credit determination. One further rule closes the obvious workaround: under the Apple Developer Program License Agreement you may not derive data from a device in order to identify it uniquely, so fingerprinting is not a quiet alternative to asking.
The SDK question has a blunt answer. Apple treats the developer as responsible for all code included in the app, so an ad or analytics SDK that tracks makes your app an app that tracks. The privacy manifest each SDK ships is where its collection and tracking behaviour is declared, and reading those is part of answering the App Store questions honestly.
Apple, App Store user privacy and data use
Try it
Does this app need the prompt
Tick what the app actually does. The answer follows the Apple definition of tracking, not the amount of data you collect.
No prompt required
Nothing selected links a user to another company for advertising, so the rule does not bite.
The rule Apple enforces at review
The App Review Guidelines state it in one sentence, in section 5.1.2 on data use and sharing: you must receive explicit permission from users through the App Tracking Transparency APIs to track their activity. It sits beside the requirement to disclose sharing with third parties and to get permission for that too. This is the rule to cite when someone asks whether the prompt is optional.
The same section closes a popular growth idea. An app may not require users to enable a system function, tracking included, in order to reach functionality, content, the app itself, or any compensation, including gift cards and codes. A rewarded opt in is a rejection. A screen of your own that explains the ask before the system prompt is ordinary practice, but it cannot gate anything on the answer.
The purpose string is required, not decorative. The tracking usage description key has to be in your app configuration before the framework is used, and the app crashes if the framework is called without it. The guidelines ask that purpose strings describe your use of the data clearly and completely. The system already shows your app name in the prompt, so spend the sentence on the reason rather than the branding.
If the answer is no, or the prompt never appears, the advertising identifier reads as all zeros and you may not track that person. The iOS tracking permission is one answer for the whole app rather than a switch per feature, and a user who has turned off Allow Apps to Request to Track in Settings cannot be asked again.
Why the prompt sometimes never appears
Most teams meet this as a bug report: the prompt does not show and the completion handler returns something nobody expected. Apple's AppTrackingTransparency documentation lists the cases where the system runs your handler without prompting. Tracking is restricted on the device. The person has turned off Allow Apps to Request to Track under Settings, Privacy and Security, Tracking. A request is already pending. The call came from an app extension. Or the app was in a state other than active when you called.
That last one explains most reports. A request fired during launch, while the app is still becoming active, gets you nothing at all. Wait until the app is active and a real screen is in front of the user. If the system dismisses the prompt without a decision, the status stays not determined, which means your app has to ask again rather than treat it as a refusal.
Geography changes the behaviour as well. In the European Union the system records the date when someone answers and will not show your prompt again for a year, whether the answer was yes or no, and a user who disables tracking requests in Settings stays unasked. In France, Germany, Italy, Poland and Romania the request appears as a full page sheet instead of an alert, so a first run flow designed around a small dialog will look wrong in five markets.
Where the prompt lands in the first run sequence is a design decision rather than a technical one, and it belongs in the mobile app wireframe next to your other permission screens. Asking on the launch screen, before anyone knows what the app does, is how you convert a maybe into a permanent no.
What you can still measure after a no
A refusal removes the advertising identifier. It does not remove your ability to count what happens in your own app. Screen views, activation, retention, funnel drop off and revenue are first party measurements. They are not linked to another company's data and they do not go to a broker, which puts them outside the definition and outside the prompt.
Campaign attribution is where people get nervous. A link that carries a campaign parameter into your app, where the parameter stays in your own backend, is a different thing from matching one person across two companies. How that link resolves, and what survives an install, is the subject of mobile app deep linking. If a third party SDK handles it for you, read what that SDK sends home before you decide the prompt is unnecessary.
Apple also ships its own answer for ad measurement. SKAdNetwork and AdAttributionKit return signed postbacks about campaigns rather than user level records, with a tiered system meant to keep small conversion counts anonymous in a crowd. Neither depends on the advertising identifier. You get less detail than an identifier gives, and you get it without the opt in rate deciding your numbers.
Choosing what to count, and deciding what a number has to be worth before you instrument it, is a longer subject than one permission. Start with measuring without tracking rather than with a list of SDKs.
What each approach gives you after the prompt
| Approach | Tracking by the Apple definition | Prompt required | Still works after a no | Who holds the data |
|---|---|---|---|---|
| Analytics inside your own app and backend | No | No | Yes | you |
| Ad SDK that links your users across other apps | Yes | Yes | No | the ad network |
| Sending an email or device list to a data broker | Yes | Yes | No | the broker |
| Broker used only for fraud and security checks | No | No | Yes | the broker |
| Apple ad attribution postbacks | no user level data | No | Yes | Apple |
Putting the prompt into your own app
The work is small and the order is the whole job. Add the tracking usage description to the app configuration. Request authorization once, when the app is active and the person has seen enough of it to know what they are agreeing to. Read the status before anything touches the identifier, and handle not determined as a reason to ask later rather than as a no. In a React Native and Expo project the module is expo-tracking-transparency, installed with npx expo install, with the usage string set through its config plugin and requestTrackingPermissionsAsync making the request. On Android the same call reports granted, because Android has no equivalent prompt.
The harder half is knowing what your dependencies do. The App Store question about tracking is about the whole binary, not the code you wrote, so a platform that keeps the build and hands you a finished app leaves you answering for SDKs you cannot inspect. That is the point where an off the shelf builder stops fitting: not the prompt itself, which is a few lines, but the dependency list behind it.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and uploads iOS builds to TestFlight using your own Apple Developer account. It is $25 a month and there is no free plan. Because the output is an ordinary Expo project that you can pull down with the CLI, the tracking module and the dependency list are yours to read. We have not tested that module inside a generated project, so treat the Expo route above as the standard path and verify it in your own build.
Questions people ask about App Tracking Transparency
No. You need it only if your app tracks as Apple defines tracking, or if you want to read the device advertising identifier. An app that keeps its analytics in its own systems, shares nothing with a data broker and carries no cross company ad SDK never has to show the prompt.
Build the app, then decide what it is allowed to know
Describe the app you want and the measurement you actually need, and keep the permission prompt for the cases that genuinely require it.
Start building