App Tracking Transparency (ATT) is Apple's rule that an iOS app must ask permission, through a system prompt, before it tracks people across other companies' apps and websites or reads the device's advertising identifier.
The most reliable ways to get more people to say yes are a short, honest pre-prompt screen with one "Continue" button, and a moment when the user already sees value in the app.
The exact timing is worth A/B testing, because the published data points in different directions.
A caveat first. Our database has no A/B tests of ATT prompts yet.
What it has is a large set of tests on the screens around that moment: permission-style asks, onboarding order and paywall timing in subscription apps.
We use those below where they teach something about the ATT ask, and we say clearly when we are drawing a parallel.
What ATT is and why the opt-in rate matters
Apple's user privacy and data use page says that on iOS, iPadOS and tvOS 14.5 or later you need permission through the ATT framework to track users, to access the advertising identifier (IDFA), or to share user or device data with data brokers.
"Tracking" there means linking data from your app with data from other companies for targeted ads or ad measurement.
The same page rules out the workarounds. You can't fingerprint the device, and you can't use a hashed email or phone number as a stand-in identifier without ATT permission.
You also can't gate features on the answer or reward people for allowing tracking.
For a subscription app, the opt-in rate matters mostly for paid acquisition.
Users who allow tracking can be matched to the ad that brought them in, which gives ad networks better signal for targeting and gives you cleaner data on what a campaign returned.
If you don't run paid user acquisition or ad monetization, you may not need the prompt at all, and skipping it removes one interruption from your onboarding.
How the prompt works
Implementation is short. You add the NSUserTrackingUsageDescription key (the purpose string) to your app's target properties, then call requestTrackingAuthorization.
According to Apple's documentation for that method, the system returns one of four statuses: authorized, denied, not determined or restricted.
Four details from that documentation shape your design:
- The prompt only appears when the app's state is active. Calling it during launch, before the app is active, can return without showing anything.
- No prompt appears if the user has turned off "Allow Apps to Request to Track" in Settings. In that case you get a denial without ever asking.
- In France, Germany, Italy, Poland and Romania, the system shows a full-page sheet instead of an alert. That sheet can use a separate rich-text purpose string, NSUserTrackingMarkdownUsageDescription.
- In the European Union, once a user answers, the prompt can't show again until a year has passed. After that you can ask again, whatever the earlier answer was.
Outside that EU rule, treat the prompt as a one-shot request.
If you waste it at a bad moment, you can't take it back.
Pre-prompt designs that pass review
A pre-prompt is your own screen shown just before Apple's alert.
It's the same idea as a permission primer for notifications or location.
Apple allows it, but the rules are stricter for tracking than for other permissions.
Apple's Human Interface Guidelines on privacy set out what a pre-alert screen may contain:
- One button, and it opens the system alert. Label it "Continue" or "Next." Apple says a button titled "Allow" is a form of manipulation, because it primes people to tap the alert's Allow button without meaning to.
- No other actions. No close button and no cancel link. Apple says the screen shouldn't offer a way to leave without seeing the system alert, unless that's needed to collect a legal consent.
- Nothing that confuses or misleads. Apple lists designs that lead to rejection: offering incentives, a screen that looks like a request, an image of the alert, and annotations on the screen behind the alert (such as an arrow pointing at "Allow").
The "no close button" rule surprises people who know paywall testing, where removing the close button is a known dark pattern.
The difference is that the pre-prompt makes no choice for the user.
The real yes or no stays in Apple's alert.
What to put on the screen
Within those rules, the levers are copy and framing.
A pre-prompt that works usually does three things in a few lines:
- Says plainly what tracking means for this app (for example, "This helps us see which ads brought you here, so we spend less on ads that don't work").
- Says what the user gets or keeps (relevant ads, a free tier funded by ads, a better product).
- Reminds them they can change the choice later in Settings.
The purpose string inside Apple's alert matters too.
Apple's guidance is a brief, complete, specific sentence in sentence case, in the active voice, ending with a period.
Make it match the pre-prompt so the two screens read as one message.
Why honest framing tends to pay
Our closest evidence comes from paywalls, not ATT.
Blinkist tested a trial timeline paywall that told users exactly when they would be charged.
Marcus Burke, then at Blinkist, reported a significant rise in trial opt-in and 4% fewer trial cancellations.
Being upfront about what happens next did not cost conversions.
The reverse also shows up. BoldVoice removed the close button from its onboarding paywall, and trial starts went up, but refunds rose by more than the gain.
Apple's ATT rules are partly designed to block that kind of forced yes.
If you're tempted to write copy that pressures people, this test is a reminder that a coerced yes is worth less than it looks.
When to show the ATT prompt
Timing is where the advice conflicts, so it helps to see what each source says.
Apple's guidance pulls toward later. The HIG says to avoid requesting permission at launch unless the data is required for the app to work.
For tracking, it adds that if you want to track as soon as people launch the app, you must show the system alert before you collect any tracking data.
AppsFlyer's early data pulled toward first launch. In its analysis of prompt timing, consent was highest when users opened the app for the first time, with a 30% drop in opt-ins when the prompt was shown two hours later.
The same data showed that 30% of non-gaming apps had higher opt-in rates seven days after install.
AppsFlyer's related post dates the data to June 15, 2021, weeks after ATT launched, so it describes an early market.
Both can be true. A first-launch prompt catches everyone while they're paying attention, and a later prompt reaches fewer people who are more convinced.
Which one gives you more opted-in users depends on how many people survive to that later point.
The trade-off for subscription apps
Subscription apps have a second constraint: the ATT prompt competes with the paywall for the same first minutes.
Our tests show how much order matters in those minutes.
Rosie Hoggmascall ran a three-way test where trial opt-in was 2% with the paywall after the home screen, 8% with it before onboarding, and 15% with a short carousel added before that paywall.
Rootd saw revenue grow 5x after moving its paywall to the start of onboarding (a before-and-after comparison, not a controlled test).
If moving one screen shifts trial opt-in that much, inserting the ATT alert in front of your paywall is not a free choice.
Measure trial starts as well as opt-in when you test ATT placement.
Three placements are worth testing:
- Right after the first value screen or two of onboarding. Users know what the app does, and you still reach nearly everyone. The carousel result above suggests a short explanation of value before an ask can help.
- Right after the paywall decision. The trial or purchase decision is made first, then you ask. This protects paywall conversion, but people who drop off at the paywall are never asked.
- At a contextual moment later. For example, after the first completed workout or saved project. Wizz cut its monetization prompts by about half and showed them only at more receptive moments, and its primary offer flow converted 81% better, with LTV up about 20% (vendor-reported via a ContextSDK case study). That was an offer, not a permission ask, but the principle of asking when someone is receptive carries over.
Lose It! found that users tolerate more onboarding than teams expect: making onboarding longer with more questions lifted trial start rate by double digits.
One extra, well-explained screen before the ATT alert is unlikely to be the step that breaks your flow.
Still, check it in your own funnel. Our app onboarding checklist covers how to sequence the other permission asks around it, including push notifications.
ATT opt-in rate benchmarks
Benchmarks depend on who measures and what they count, so treat them as ranges.
We keep a fuller breakdown on the ATT opt-in rate benchmark page.
| Source | Figure | Period |
|---|---|---|
| Adjust | 35% industry average opt-in among users shown the prompt, up from 34.5% a year earlier | Q2 2025 |
| Adjust | Gaming subgenres led: sports 50%, hyper casual 43%, action 40% | Q2 2025 |
| AppsFlyer | 50% of users globally consent to tracking, about 10 points higher than at launch; France just under 51%, Germany 47% | April 2025 |
| AppsFlyer | 30% to 40% on the advertiser side | June 2021 |
The gap between Adjust's 35% and AppsFlyer's 50% is a definition and sample difference, not a contradiction.
If you compare your own rate, divide users who allowed tracking by users who saw the prompt, not by all installs.
Otherwise people who turned tracking off device-wide in Settings drag your number down without ever seeing your screen.
Measured results: what changes opt-in
Published, controlled tests of ATT pre-prompts are scarce.
Most claims you'll see online ("pre-prompts double opt-in") come without a sample, a control or a source. Here is what we could verify.
Wording and layout move the rate a lot. Researchers from Carnegie Mellon, USC and Meta ran a survey experiment with 11,000 adults in the US and UK, randomly showing either Apple's ATT prompt or the prompt Apple uses for its own personalized ads.
Opt-in was 13% with the ATT prompt and 25% with Apple's own prompt.
Two of the authors work at Meta, which has a stake in the result, and this was a survey rather than live app traffic.
Still, it shows that framing alone roughly doubled consent in a controlled setting.
You can't change Apple's alert, but your pre-prompt and purpose string are the framing you control.
Timing moves it too. AppsFlyer's 2021 data above showed a 30% drop when the prompt came two hours after first launch, and also showed that later prompts won for 30% of non-gaming apps.
The honest reading: the best moment is app-specific, so test it.
Context beats volume. Our database doesn't include an ATT test yet, but the pattern in permission-like asks is consistent.
JourneyStamp replaced one generic paywall with paywalls matched to where the user was in the app and lifted conversion 50%, to 7.3% overall (vendor-reported by Superwall, with several changes bundled).
Wizz's 81% lift came from asking less often, at better moments.
How to test your own ATT prompt
- Pick one variable per test: pre-prompt versus none, pre-prompt copy, or placement in the flow.
- Track opt-in rate among users who saw Apple's alert, plus trial start rate and day-7 retention, so a gain in consent doesn't hide a loss in revenue.
- Run the test long enough to cover weekdays and weekends. Our guide to A/B testing in apps covers sample sizes for small apps.
- Have each variant reviewed against Apple's pre-alert rules before shipping. A rejected build costs more than a weak variant.
When you get a result, write down the context: app category, countries (EU users see a different sheet) and where the prompt sat in onboarding.
That's what makes it useful the next time.