App Store Compliance

App Tracking Transparency requirements: the NSUserTrackingUsageDescription string, ATT prompt, and disclosures App Review checks

App Tracking Transparency requires an ATT prompt, an Info.plist string, and matching disclosures. What triggers App Review rejection and how to comply.

By · · 8 min read

App Tracking Transparency (ATT) is the framework Apple introduced in iOS 14.5 that forces your app to ask the user for permission before it tracks them across other companies’ apps and websites. If your app — or any SDK you bundle — does anything Apple defines as “tracking,” you must show the ATT prompt, and you must disclose the tracking in your privacy policy and your nutrition label. Skip any of those three and App Review rejects you.

The most common rejection isn’t “you tracked without asking.” It’s the inverse: the reviewer sees tracking declared somewhere, can’t find the prompt, and bounces the build. ATT is one of the few areas where Apple’s tooling actively cross-checks your binary, your Info.plist, your App Store Connect answers, and your privacy policy URL against each other. This post is what counts as tracking, the exact Info.plist string you need, when App Review rejects, and how the disclosure has to line up across all three places Apple looks.

If you’re working through a full submission, this is one item on the broader checklist of every URL and file Apple requires for an iOS App Store submission.

What Apple counts as “tracking”

Apple’s definition is narrower than most developers assume, and wider than they hope. Tracking means linking data collected in your app to data collected from other companies’ apps, websites, or offline properties, for the purpose of targeted advertising or advertising measurement — or sharing your collected data with a data broker.

Concretely, you are tracking if your app:

  • Displays ads targeted using data (like the IDFA) shared with other apps you don’t own.
  • Sends device or user data to a third-party advertising or attribution SDK (Meta, Google AdMob, AppLovin, AppsFlyer, Adjust, Branch, etc.).
  • Shares email, phone, or device identifiers with a data broker.

You are not tracking — and don’t need the prompt — when data stays inside your own apps, when it’s linked only to first-party data, or when it’s shared solely for fraud prevention or by the user’s explicit instruction. The grey area is third-party SDKs: most analytics and attribution SDKs track by Apple’s definition even if you never call an ad API yourself. If you bundle one, assume you’re tracking until you’ve read its documentation and confirmed otherwise.

Why the IDFA matters

The IDFA (Identifier for Advertisers) is the device-level advertising identifier that ad networks use to attribute installs and target ads. Before iOS 14.5, every app could read it freely. Now ASIdentifierManager.advertisingIdentifier returns all zeros until the user grants ATT permission. So if your monetization depends on attribution or targeted ads, the ATT prompt is the gate to a usable IDFA — and a “Denied” response means you get zeros and have to fall back to SKAdNetwork.

The reason this matters for App Review: accessing the IDFA at all is one of the signals that you’re tracking, and it has to be declared in your privacy nutrition label under Identifiers → used to track you. That declaration is what triggers Apple to look for the prompt.

The NSUserTrackingUsageDescription Info.plist string

To call the ATT API you must add a purpose string to your Info.plist under the key NSUserTrackingUsageDescription. Without it, the prompt never appears — calling ATTrackingManager.requestTrackingAuthorization on a build with no string is undefined behavior and the request silently fails.

<key>NSUserTrackingUsageDescription</key>
<string>We use your activity to measure ad performance and show you more relevant ads.</string>

This string is the body text of the system prompt, rendered above Apple’s fixed “Allow Tracking” / “Ask App Not to Track” buttons. Rules App Review enforces on the string itself:

  1. It must describe the actual use. Vague filler like “We respect your privacy” or “Enable for a better experience” gets rejected. State what data and why.
  2. It must not bribe, threaten, or pre-prompt deceptively. You can’t offer a reward for tapping Allow, and you can’t show a fake “you must allow this” screen before the real prompt.
  3. It must be present in every localization your app ships. A missing localized string shows the development-language fallback, which reviewers in other locales flag.

Then you call the API — and you must do it from an active app state, not at launch before the UI is up:

import AppTrackingTransparency

ATTrackingManager.requestTrackingAuthorization { status in
    // .authorized, .denied, .restricted, or .notDetermined
}

When App Review rejects for ATT

The rejections cluster into four patterns, all under Guideline 5.1.2 — Data Use and Sharing:

  1. Declared tracking, no prompt. Your nutrition label says data is “used to track you,” or a known ad SDK is in your binary, but the reviewer never sees the ATT prompt. This is the single most common ATT rejection. The fix is to actually present requestTrackingAuthorization on a screen the reviewer will reach.
  2. Prompt with no NSUserTrackingUsageDescription string. The API is called but the key is missing from Info.plist, so nothing appears. Add the string.
  3. Tracking despite a “Denied” response. The reviewer denies the prompt, then Apple’s tooling still sees the IDFA being accessed or data going to an ad SDK. You must honor the denial — no IDFA, no cross-app linking.
  4. Pre-prompt or incentivized prompt. A custom “soft ask” screen is allowed if it’s honest and informational, but it can’t look like the system dialog, can’t promise rewards, and can’t punish “Ask App Not to Track.”

Note the asymmetry: if you genuinely don’t track, you don’t need the prompt at all — and you should not add it, because an unnecessary tracking prompt can itself draw a rejection asking why you’re requesting tracking permission you don’t use.

Disclosing tracking in your privacy policy

App Review reads your privacy policy URL and expects the tracking practices to be spelled out there in plain language. At minimum the policy must:

  • State that the app engages in tracking as defined by Apple’s ATT framework.
  • Name the categories of data used for tracking (typically Identifiers, sometimes Usage Data).
  • Identify the third parties or types of third parties the data is shared with (ad networks, attribution providers, data brokers).
  • Explain that the user can decline via the ATT prompt and through iOS Settings → Privacy & Security → Tracking.

A generic privacy policy generator won’t include this unless you explicitly toggle “we use third-party advertising,” which most developers skip during the wizard. If your policy is silent on tracking but your nutrition label declares it, that’s a mismatch App Review can flag. OrbitKit’s privacy policy generator adds the tracking and ATT disclosures by construction when you indicate the app shares data with advertisers, so the policy text and the label agree.

Disclosing tracking in the nutrition label

Your App Privacy Details questionnaire in App Store Connect — the data that renders as the privacy nutrition label on your product page — has a per-data-type setting: “Used to Track You.” Any data type you mark there moves into the label’s “Data Used to Track You” section, and that is the declaration that obligates the ATT prompt.

So the chain is: marking a data type as “used to track you” → label shows tracking → App Review looks for the ATT prompt → prompt requires the NSUserTrackingUsageDescription string → and your privacy policy must describe the same practice. All four have to be consistent. Our category-by-category guide to the nutrition label walks through which data types commonly end up in the tracking bucket and why.

You can build the label itself with OrbitKit’s privacy nutrition label generator, which uses the same data-type and purpose taxonomy as the policy generator — so the categories you declare for tracking in one show up the same way in the other, with no translation step.

Making the three disclosures line up

The whole point is consistency. Run this check before you submit:

Surface What it must say if you track
Info.plist NSUserTrackingUsageDescription present, specific, localized
ATT prompt Actually shown via requestTrackingAuthorization; denial honored
Nutrition label Data type(s) marked “Used to Track You”
Privacy policy Tracking, IDFA/Identifiers, third parties, and opt-out disclosed

If any row contradicts another — label says tracking, policy is silent; prompt is shown, no Info.plist string; IDFA accessed after denial — App Review has a concrete reason to reject. The fastest path to approval is making the label and the policy say the same thing about tracking, then confirming the prompt and the Info.plist string back them up.

OrbitKit generates the privacy policy and the nutrition label from one questionnaire, so the tracking disclosures stay aligned across both. It’s free to build and preview every page; you pay $5/mo per app only when you take a site live on your own domain. Start free.

For the full picture of what Apple checks before approval — ATT is one of about a dozen things — see every URL and file Apple requires for iOS and macOS App Store submission.