ATT on iOS in 2026: how to ask for tracking permission within Apple’s rules

October 21, 2026

Tin Le

This article does not show you how to write the code that calls the ATT iOS prompt. Apple already has official documentation for that. I only cover which permission screens Apple allows, which ones get an app rejected in review, and how to write the explanation so users agree without you breaking the rules.

In Q1 2026, an average of 38% of iOS users agreed to tracking when they saw the prompt, up from 35% a year earlier (Adjust, 02/2026). Put another way, about 62 of every 100 people who see the prompt tap no. Many guides written in 2021, including one we published back then, recommend tactics Apple now prohibits: showing an image of the prompt, offering rewards, asking again and again. This article replaces those guides.

ATT (App Tracking Transparency) is Apple’s framework that requires an app to ask permission before tracking users across apps and websites owned by other companies. Since iOS 14.5 (April 26, 2021), if a user does not agree, the device’s advertising identifier (IDFA) returns all zeros and the app may not track that user by any other means.

When an app has to show the ATT iOS prompt

Tracking, in Apple’s definition, means linking data collected from your app with data from other companies’ apps and websites for targeted advertising or ad measurement. Sharing user data with a data broker also counts as tracking (Apple, User Privacy and Data Use).

In practice, you need the ATT prompt if your app does any of the following:

Sends email lists, IDFA or other IDs to an ad network for retargeting or to find similar users.
Includes a third-party SDK that combines your app’s data with data from other apps to target or measure ads. Even if you do not use the SDK for that purpose, you are still responsible for every piece of code inside your app.
Uses third-party deep linking or deferred deep linking tools that pass user identifiers between apps from different companies.
Tracks users inside an in-app webview. Apple treats a webview like native app functionality, unless the user is browsing the open web.

You do not need ATT when you use the IDFV (identifier for vendor) for analytics across your own company’s apps, or when you share data only for fraud prevention and security.

Two things are off limits when the user has not agreed: using a hashed email address or phone number in place of the IDFA, and fingerprinting the device from its configuration, location or network connection. Apps that use SDKs doing this may be rejected from the App Store.

A quick calculation: a campaign brings in 10,000 installs and the opt-in rate is 38%, so only 3,800 people have an IDFA you can measure at the device level. The other 6,200 installs are measured through AdAttributionKit or SKAdNetwork, with aggregated and delayed data. Raising the opt-in rate by a few percentage points gives you a few hundred more precisely measured users, which feeds straight into the app marketing KPIs you report every week.

The explanation screen before the prompt

Apple lets you show your own screen before the system prompt, as long as you are transparent about how the data is used (App Review Guidelines 5.1.1(iv)). This screen is usually called a pre-prompt or soft opt-in.

Think of a shop assistant asking whether you want to receive promotions. Ask once, say what it is for, and the customer decides comfortably. Stand in the doorway and refuse to let them leave until they say yes, and they get annoyed. In this case, Apple rejects the app.

The rules for this screen are in the Human Interface Guidelines, Privacy section:

One button only. Tapping it opens the system prompt. Label it “Continue” or “Next”, not “Allow”, because the user is not allowing anything on this screen.
No way out. No “Later”, “Close” or “Cancel” button, no X. Once a user reaches this screen, they must see the system prompt.
No imitation of the prompt. Do not insert a screenshot of Apple’s prompt, and do not design a screen that looks like a permission request.
No pointing. No arrows, circles or annotations that steer the user’s eye toward the prompt’s allow button.
No rewards. No coins, vouchers or extra plays in exchange for consent. Do not lock features or content until the user agrees (App Review Guidelines 5.1.2(i)).

A consent screen required by local law, such as a GDPR consent banner in Europe, may appear before or after the ATT prompt. If you use one, make clear that the choice there does not replace the ATT choice the user already made.

What not to do on the explanation screen

Bad example	Why it gets rejected
Two buttons, “Allow” and “Later”	One button does not open the prompt, and “Allow” duplicates the system button
A screenshot of the ATT prompt with an arrow pointing at the allow button	Shows an image of the prompt and annotations that steer the user
“Allow tracking to get 50 coins”	Offers a reward for consent
A screen that shakes, changes color or comes back every time the user declines	Manipulates and pressures the user into consenting
Blocking access to the app until the user agrees	Locks features behind consent

Writing the purpose string in the prompt

The purpose string is the sentence you write; the system shows it right below your app name in the ATT prompt. You declare it in the NSUserTrackingUsageDescription key. The key is mandatory: if it is missing and the app calls ATT, the app crashes.

Apple asks for a short, complete, specific sentence in the active voice, ending with a period. The system already shows the app name, so do not repeat it.

The formula I use:

[What the data is used for] + [what the user gets]

Example for a food delivery app: “This data helps show you ads for dishes and deals that are closer to your tastes.”

Avoid:

“Allow for a better experience.” Vague reason, and the passive phrasing is exactly the kind Apple uses as a bad example.
“Turn on tracking.” An order with no reason.
“Agree to get a VND 20,000 voucher.” A reward, which breaks the rules above.

When to ask

Apple advises against requesting permission at launch unless the app needs that data to function. But if you want to track from the very first launch, you must show the system prompt before collecting any tracking data. That means SDKs that need the IDFA should only initialize after you have the ATT result.

Two technical notes from Apple’s documentation. The prompt only appears while the app is active; call it before the app shows its interface and nothing appears. If the system dismisses the prompt before the user chooses, the status stays not determined (notDetermined) and the app needs to ask again.

Say I am building the ATT flow for a food delivery app that runs install campaigns:

Audit the SDKs. List every SDK in the app: MMP, Meta SDK, Google, ad SDKs. Mark the ones that read the IDFA or send data to third parties for ad measurement. Those SDKs must wait for the ATT result.
Pick the moment. Do not ask on the first screen. The user goes through 2 welcome screens and picks a delivery area, then sees the explanation screen. By then they understand what the app does. Most MMP SDKs have an option to wait a few seconds for the ATT result before sending the install event; ask your MMP’s technical team to set a wait time that matches this flow.
Build the explanation screen. Title: “Ads that fit you better”. Two sentences: the app uses data to show deals closer to your tastes and to measure which ads brought you to the app; every feature works the same whatever you choose. One “Continue” button.
Write the purpose string using the formula above.
Handle a decline. The app keeps working normally and does not show the explanation screen again. The app’s own settings have a “Privacy” item with a shortcut to iPhone Settings. Apple allows this shortcut when the user has turned tracking off for your app specifically.
Measure the result. Opt-in rate = users who agreed / users who saw the prompt. If 2,000 people see the prompt and 760 agree, the rate is 38%, right at the Adjust average. If you are well below that, test a different timing or purpose string, changing one thing at a time.

This flow has no exit button, no reward, no image of the prompt, and users who decline still get every feature.

Users in the EU: asking again after one year

For users in the European Union (EU), an app may show the ATT prompt again one year after the previous choice, whether the user agreed or declined last time. It may not ask again if the user has turned off “Allow Apps to Request to Track” in Settings (renamed “Allow Apps to Request to Link Your Activity Across Companies” in the EU).

Starting with iOS 27.2, Apple adds an alternative version of the ATT prompt for the EU, with different formatting and wording and an optional “Additional Information” text button for further explanation. Apps distributed in Germany, France, Italy, Poland and Romania may only use this alternative version there. The purpose string can be written in markdown in the NSUserTrackingMarkdownUsageDescription key.

Outside the EU, the prompt in practice appears only once per app. Users who want to change their choice go to Settings > Privacy & Security > Tracking. That single ask needs the right moment and the right words.

ATT checklist before you submit the app

The NSUserTrackingUsageDescription key is present, in the active voice, and says what the data is used for.
The explanation screen (if any) has a single “Continue” button, no X, no “Later”.
No image of the prompt, no arrows, no rewards, no locked features.
Users who decline can still use every feature.
SDKs that need the IDFA initialize after the ATT result; sign-in and deep linking SDKs have been audited too.
No hashed email, hashed phone number or fingerprinting in place of the IDFA without consent.
In-app webviews follow the same rules as native features.
Any consent screen required by local law does not make users think it replaces their ATT choice.
The app’s privacy section has a shortcut to Settings.
Distributing in the EU: logic to ask again after 365 days, and the alternative prompt tested on iOS 27.2.

Run this checklist alongside your checklist for an app launch on the App Store. If the app is rejected over its ATT screen, both the launch date and the ad schedule slip.

With 62% of users declining, you still need a way to evaluate ads that does not depend on the IDFA. Incrementality testing answers whether ads actually bring in additional users, even when device-level data is missing. On Meta, how the system delivers ads with fewer signals is covered in our article on Meta advertising in 2026.

Adtek reviews ATT permission flows, audits SDKs and sets up measurement with an MMP before app install campaigns go live. If your app still uses a permission screen based on older guidance, talk to the Adtek team before you submit your next update.