App Tracking Transparency Explained for App Founders
Here’s how to decide whether your app needs ATT, plan the permission flow, and write a clear prompt that follows Apple’s rules.
App Tracking Transparency is one small pop-up with the project-management skills of an octopus: it pulls product, privacy, ads, engineering, and App Review into the same meeting. This guide explains App Tracking Transparency for app founders, including when you need it, what your team must build, and how to ask for permission without confusing people.
What App Tracking Transparency means
App Tracking Transparency, usually shortened to ATT, is Apple’s permission system for tracking people across apps, websites, or offline data owned by different companies. Apple requires this permission on iOS 14.5, iPadOS 14.5, and tvOS 14.5 or later before an app tracks someone or accesses the device’s advertising identifier.
The key word is tracking. Under Apple’s definition, tracking includes:
- Linking data from your app with data from another company for targeted ads or ad measurement
- Sharing user or device data with a data broker, a company that collects and sells or shares personal data about people it does not directly serve
- Adding a third-party software development kit (SDK) that combines your users’ data with data from other companies for those purposes
This can involve an Identifier for Advertisers (IDFA), an email address, a session ID, or another identifier. Hashing an email address does not turn tracking into nontracking. The label changes, but the connection still exists.
ATT does not cover every bit of analytics in your app. If you measure how people use your app without linking that data to another company’s data for tracking, ATT may not apply. Apple also says the Identifier for Vendor can support analytics across apps from the same content provider, as long as it is not combined with other data to track people across companies.
ATT is about what happens between your app’s data and other companies’ data, not every piece of analytics inside your app.
When someone chooses Ask App Not to Track, the IDFA returns as all zeros and the app may not track that person as Apple defines tracking. The answer is not a suggestion in a tasteful gray font. Your app and every SDK inside it must honor the choice.
Even with ATT permission, fingerprinting, which uses device signals to identify a person or device, is never allowed.
Does your app need ATT?
Do not start with the prompt copy. Start with a data map, because a charming sentence cannot rescue a tracking flow nobody has checked.
1. List every place data goes
Include your app, servers, analytics tools, ad networks, attribution services, customer support tools, single sign-on providers, and webviews. Ask each vendor what data its SDK collects, where it sends that data, and what the vendor does with it.
Apple makes the developer responsible for all code included in the app, including third-party SDKs and sign-in tools. “The vendor did it” is not an escape hatch, even if it would make bug reports much more exciting.
2. Check why data is linked or shared
You need ATT permission if data from your app is linked with data from another company’s app, website, or offline property for targeted advertising or advertising measurement. You also need it when you share user or device data with a data broker.
Common examples include:
- Retargeting someone in another company’s app
- Measuring ads by matching your app users with another company’s ad-view data
- Sending email addresses, advertising IDs, or locations to an ad network that builds cross-company profiles
- Using an analytics SDK that repurposes your app data for targeted ads elsewhere
- Tracking inside an app webview, unless the person is simply browsing the open web
Tracking can happen on your server too. Sending app data to your own server before passing it to an ad partner does not move it outside ATT’s scope. That would be a very convenient tunnel, and Apple has already closed it.
3. Check whether an exception fits
Apple lists a few cases that do not count as tracking. These include linking data only on the person’s device without sending identifying data off the device, and sharing data with a data broker only for fraud prevention, security, or certain consumer-credit purposes.
First-party ads can also avoid ATT when they use only data from your company’s own apps and websites. Contextual ads based on the current screen or content may be another nontracking option. Your exact data flow decides the answer, not the label your ad dashboard uses.
4. Make a clear yes-or-no decision
If your app tracks, implement ATT and wait for permission before tracking begins. If it does not track, do not show the prompt merely because another app does. Instead, remove tracking code you do not need and make your App Store Connect answers match the app’s real behavior.
What ATT changes for an app founder
ATT is not only an engineering ticket. It affects what the product can do, how the business measures ads, and what App Review expects to see.
First, your app must still work when someone refuses tracking. App Review Guideline 5.1.2(i) says an app cannot require tracking permission for access to features, content, use of the app, or rewards. Plan a full denial path before anyone opens Xcode.
Second, user-level attribution, retargeting, and ad personalization may be limited without permission. Founders should decide which reports are truly needed and which can use aggregate or contextual methods. Apple points developers to AdAttributionKit for privacy-preserving ad attribution.
Third, ATT adds a consistency check. Your code, SDK behavior, permission message, App Privacy answers, privacy policy, and Review Notes all describe the same data flow from different angles. If one says “no tracking” while another sends identifiers to an ad network, the paperwork and the app are telling different stories.
Set up the ATT permission flow in five steps
1. Audit the app before writing the message
Confirm which data is collected, where it goes, and whether tracking starts at launch or after a later action. Remove SDK features that collect more than you need. This also gives your writer something more useful than “please make the privacy words sound friendly.”
2. Add a purpose string
Add NSUserTrackingUsageDescription to the app’s Info.plist configuration file. Its value becomes the custom sentence inside Apple’s system alert. The AppTrackingTransparency framework documentation requires this key before the app requests authorization.
The purpose string should be brief, specific, and written in active voice. Apple’s Human Interface Guidelines for privacy recommend a complete sentence that explains how the app uses the requested data.
3. Choose a moment with context
Ask before your app or its partners start tracking. If tracking does not need to begin at launch, wait until the person understands the related part of the app. A useful moment might be after the first task, before an ad-supported feature, or when the app explains personalized ads.
Permission-alert bingo gets noisy fast, so avoid stacking ATT beside location, notification, camera, and contact requests.
4. Request authorization once the app is active
Call ATTrackingManager.requestTrackingAuthorization only while the app is active. Apple says the prompt will not appear if another permission request is waiting, and concurrent requests are not saved. Check that trackingAuthorizationStatus is notDetermined before making the call.
The standard request is generally shown once per installation. The system remembers the answer unless the app is uninstalled and reinstalled. Test the states authorized, denied, restricted, and notDetermined rather than testing only the happy path.
5. Honor the answer
Start tracking only when the status is authorized. Check the status each time the app launches because people can later change permission under Settings > Privacy & Security > Tracking.
Consent is not a boss battle. If someone declines, keep the app useful and switch to the nontracking path. You may offer a neutral shortcut to Settings when the choice matters later, but do not keep nagging.
The clearest ATT flow starts with an honest data map, not a clever prompt.
ATT permission prompt practices and examples
Your team controls when the prompt appears and the purpose string inside it. Apple controls the rest of the system alert, including the buttons. That leaves less room for creative copy, which is probably a gift.
Write a purpose string that names the real use
Adapt these examples only if they match what your app and partners actually do:
- Ad measurement: “We use your activity across other companies’ apps and websites to measure which ads lead to installs and purchases.”
- Relevant ads and measurement: “We use your activity to show more relevant ads and measure ad performance.”
- Cross-company personalization: “We link your activity with partner data to personalize ads and measure their results.”
“Your data helps us improve your experience” is too vague. It does not say that data is used for tracking, ads, or measurement. A purpose string should help someone understand the choice, not make them solve a tiny riddle.
Use a pre-prompt only when it adds honest context
Apple allows a custom screen before ATT when it clearly explains why the app wants permission. If you use one, connect the request to a real feature or business model and use one neutral button such as Continue or Next to open the system alert.
Do not mimic Apple’s alert, label the custom button Allow, point toward Apple’s Allow button, or claim the app will stop working. App Review Guidelines 5.1.1(iv) and 5.1.2(i) prohibit manipulation, gating features, and rewards for permission.
A simple pre-prompt could say:
Help us measure our ads
We use activity from this app and our advertising partners to learn which ads lead to installs and purchases. You can keep using every feature if you choose not to allow tracking.
Continue
That message explains the use and the denial path without pretending tracking is required. Keep it consistent with the purpose string that follows.
Watch the announced EU prompt change
Apple says that, beginning with iOS 27.2 and iPadOS 27.2, developers can use an alternative ATT prompt for apps distributed in the European Union. For apps distributed in Germany, France, Italy, Poland, and Romania, only the alternative version is available. The alternative can include an Additional Information button for more detail and local consent controls.
Apple also says EU users can be shown the system prompt again one year after their previous choice, unless they turned off the device-wide setting that allows apps to ask. Treat this as a regional flow. Do not build global prompt logic from an EU-only rule, and check Apple’s current documentation before release because these details are time-sensitive.
Keep the build and App Store submission aligned
ATT permission is one part of the privacy work. Your team still needs to complete the app’s App Privacy details in App Store Connect. Apple explains that App Privacy disclosure and ATT permission are separate requirements.
Privacy manifests are separate too. They describe data practices in third-party code and help Xcode produce a combined report, but they do not replace your App Privacy answers, privacy policy, or ATT flow.
Before submission, compare these six items:
- The app’s real network and SDK behavior
- The
NSUserTrackingUsageDescriptionpurpose string - The pre-prompt, if the app has one
- App Store Connect App Privacy answers
- The app’s privacy policy
- Review Notes that say where and when the ATT prompt appears
Use the App Store Connect checklist to check the rest of the listing, and compare your policy with the app privacy policy checklist. For the review rules behind these checks, see the App Review Guidelines guide.
Your prompt, App Privacy answers, SDK behavior, and Review Notes should tell the same story.
Check ATT before release
- We documented every SDK and server that receives user or device data.
- We confirmed whether each data flow meets Apple’s definition of tracking.
- Tracking waits until
trackingAuthorizationStatusisauthorized. - The app works when permission is denied or restricted.
- The purpose string names the real use in plain language.
- The pre-prompt does not imitate, pressure, reward, or mislead.
- App Privacy answers and the privacy policy match the released build.
- We tested first launch, denial, approval, restriction, reinstall, and a later Settings change.
- Review Notes explain where App Review can find the prompt.
FAQ
Does every iOS app need an ATT prompt?
No. An app needs ATT when it tracks people as Apple defines tracking or accesses the IDFA. An app that does neither should not show the prompt.
Can I show the ATT prompt again after someone says no?
The standard prompt is a one-time request per installation. You can provide a neutral shortcut to the app’s tracking setting, but you must respect the current status. Apple has announced a separate one-year re-prompt option for EU users beginning with iOS 27.2 and iPadOS 27.2.
Can I reward someone for allowing tracking?
No. Apple does not allow apps to gate features, content, use, or rewards on tracking permission.
Does ATT apply to analytics SDKs?
It can. ATT applies when the SDK links your app’s user or device data with other companies’ data for targeted ads or ad measurement, or shares it with a data broker. Ask the SDK provider how it uses data rather than assuming “analytics” means nontracking.
Is ATT the same as a privacy policy or App Privacy disclosure?
No. ATT records permission for Apple-defined tracking. Your privacy policy explains wider data practices, while App Privacy in App Store Connect describes collection and use on the product page. You may need all three.
Is there an Android version of ATT?
No direct Android feature uses the ATT framework or Apple’s prompt. Android has its own advertising ID, privacy tools, and Google Play disclosure rules, so plan and document that platform separately.
Conclusion
Decide whether your app tracks before designing the prompt. Map every data flow, include third-party code, ask before tracking begins, and keep a complete denial path. Then make the purpose string, App Privacy answers, policy, and Review Notes match the same facts.
Further reading: Turn Apple’s App Review Guidelines into a release checklist
Keep Reading

App Privacy Policy Checklist: What to Include Before Launch
Use this app privacy policy checklist to cover data collection, ads, analytics, payments, account deletion, and Apple and Google store disclosures.

App Privacy Policy Generator Comparison: What Tools Cover
Compare app privacy policy generators by SDK prompts, hosting, editing, Apple App Privacy, Google Data safety, and account deletion support.