# ATT Prompt Rejected by Apple: The Four Fixes That Work

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-05. 5 min read.
> Source: https://vp0.com/blogs/att-prompt-rejected-by-apple-fix

ATT rejections come in four flavors, and three of them live outside the prompt: what your SDKs do before it, what your pre-prompt pressures, and what your labels claim.

**TL;DR.** App Tracking Transparency rejections sort into four families with four fixes. Tracking before or without permission: an SDK in your binary fingerprints or tracks regardless of the prompt, and the fix is an SDK audit plus configuration, not prompt copy. The pressuring pre-prompt: explainer screens are allowed, but gating features on Allow, incentivizing it, or styling buttons to mimic the system sheet is manipulation Apple rejects on sight. The generic purpose string: NSUserTrackingUsageDescription must say specifically what tracking enables in your app. And the contradicting privacy labels: declaring no tracking while the binary contains tracking SDKs is the mismatch reviewers now scan for. Sequence consent context before the prompt, ask once at a sensible moment, respect Ask App Not to Track absolutely, and the rejection family never returns.

## Why is the prompt rarely the real problem?

Because [App Tracking Transparency](https://developer.apple.com/documentation/apptrackingtransparency) is a system about behavior, and the prompt is just its visible corner. Apple's reviewers evaluate what the binary does before, during, and regardless of the prompt, what the pre-prompt pressures, and what the privacy labels claim, and the four rejection families map onto exactly those surfaces. Fixing the copy when the SDK is the problem resubmits the same rejection with nicer words.

## What are the four families and their fixes?

| Family | The violation | The fix | Verdict |
| --- | --- | --- | --- |
| Tracking without permission | An SDK fingerprints or tracks pre/sans prompt | SDK audit + consent-gated init + removals | The big one; lives in configuration, not copy |
| The pressuring pre-prompt | Gating, incentives, system-alike buttons | Inform-only context screen, both answers fine | Manipulation is rejected on sight |
| Generic purpose string | Boilerplate or app-mismatched NSUserTrackingUsageDescription | One specific sentence about your app's use | Also the sentence that moves opt-in |
| Contradicting labels | "No tracking" declared, tracking SDKs shipped | Labels match the audited binary | The mismatch reviewers scan for |

**Family one is the iceberg.** Ad, attribution, and some analytics SDKs track or fingerprint by default, before any prompt fires, and your binary answers for them. The fix is the audit: list every third-party SDK, read each one's tracking defaults, configure consent-gated initialization where offered (the [consent-before-requests sequencing](/blogs/best-admob-mediation-setup-react-native-2026/) from the ads setup is this same machinery), and remove what cannot be gated. [Apple's user-privacy expectations](https://developer.apple.com/app-store/user-privacy-and-data-use/) are the reference, and "we didn't know the SDK did that" has never once worked as an appeal.

## What may a pre-prompt do, and what gets it rejected?

Inform, only. A context screen before the system prompt is legitimate and often good design, what tracking enables in your app, in your words, with the standing craft of [the ATT prompt UI guide](/blogs/att-tracking-transparency-prompt-ui-swiftui/). The rejected versions share a fingerprint: **engineering the answer.** Feature-gating on Allow ("continue" only after consent), rewards for allowing, guilt for declining, repeated asks, or buttons styled to mimic the system sheet so users think they already answered, each is manipulation under [the guidelines](https://developer.apple.com/app-store/review/guidelines/), each is rejected on sight, and each also poisons the trust the permission was supposed to formalize.

The honest pre-prompt is one screen: what tracking enables, the statement that either answer keeps the app fully working, and a single continue into the real prompt, asked **once**, at a moment with context (after the user has seen the app, not at cold launch), and never again after a no.

## How do the string and the labels stay consistent?

The purpose string renders inside the system prompt and answers for your app specifically: one sentence grounding the identifier's use in your actual product, the same specificity bar as [the purpose-string guide](/blogs/react-native-expo-missing-purpose-string-rejection-fix/) holds for every permission, and it is simultaneously compliance and conversion copy, the only sentence in the flow that moves opt-in rates.

The labels close the loop: App Store privacy labels declaring "no tracking" while the binary carries tracking SDKs is the contradiction reviewers increasingly scan for, and the fix is mechanical once the audit exists, the labels describe the audited binary, updated whenever the SDK roster changes, with the deeper data-collection declarations covered in [the 5.1.1 guide](/blogs/ios-guideline-5-1-1-data-collection-ui-template/).

**"Ask App Not to Track" gets absolute respect**: no fingerprinting fallbacks, no workaround identifiers, no per-session re-asks, and a product that works identically minus personalization, because the setting is also a market signal, and designs that require tracking for core value are designs the platform has already voted against. The screens around the flow, the context screen, settings, the privacy explainer, scaffold from a free [VP0](https://vp0.com) design via Claude Code or Cursor at $0, with the contract in the prompt: "inform-only ATT context screen, both answers first-class, one ask, string specific to the product."

The wider family these system-alike prompts belong to, lying badges, fabricated activity, resetting countdowns, is audited in [the fake-notification dark-pattern guide](/blogs/fake-notification-ui-dark-pattern/).

## Key takeaways: ATT rejection fixes

- **Four families, audited in order**: SDK behavior, pre-prompt pressure, string specificity, label consistency; the prompt's copy is rarely the disease.
- **The SDK audit is the real work**: consent-gated initialization or removal; the binary answers for everything it contains.
- **Pre-prompts inform, never engineer**: no gating, incentives, shame, re-asks, or system-alike buttons; one ask at a contextual moment.
- **The string is specific and doubles as conversion copy**; the labels describe the audited binary, always.
- **Ask App Not to Track is absolute**, the product works identically without it, and the flow's screens start from a free VP0 design.

## Frequently asked questions

**Why was my app rejected for the ATT prompt?** Almost always one of four: SDKs tracking before consent, a pressuring pre-prompt, a generic purpose string, or labels contradicting the binary. Audit in that order; the fix is usually configuration and honesty.

**Are pre-prompt explainer screens allowed at all?** Yes, inform-only: what tracking enables, both answers fully functional, one continue into the system prompt, no gating, rewards, or look-alike buttons.

**What makes a purpose string pass for ATT?** One sentence specific to your app's actual use of the identifier; it renders in the system prompt and is also the sentence that moves opt-in.

**How do I find the SDK that tracks without asking?** List every SDK, read tracking defaults, gate initialization on consent where offered, remove what cannot be gated; ads and attribution are the usual suspects.

**What does respecting "Ask App Not to Track" require?** No fallbacks, no workarounds, no re-asks, and identical product function minus personalization.

## Frequently asked questions

### Why was my app rejected for the ATT prompt?

Usually one of four reasons: an SDK tracks before or without permission, your pre-prompt pressures users toward Allow (gating, incentives, or system-mimicking buttons), your purpose string is generic or mismatched, or your privacy labels contradict what the binary actually contains. Audit in that order, the prompt itself is rarely the real problem, and the fix is usually in SDK configuration and honesty, not copy.

### Are pre-prompt explainer screens allowed at all?

Yes, context screens before the system prompt are fine and often good UX, but they must inform, not engineer: no feature-gating on the answer, no rewards for Allow, no shame for declining, and never buttons styled to look like the system sheet's. The explainer says what tracking enables and that either answer keeps the app working, then hands off to the real prompt.

### What makes a purpose string pass for ATT?

Specificity about your app: 'Your data will be used to show you ads for products you might actually want' is the genre; 'This identifier will be used to deliver personalized ads to you' grounded in your app's actual use passes, while generic boilerplate or strings contradicting the app's behavior draw scrutiny. It renders inside the system prompt, so it is also the one sentence that moves opt-in rates.

### How do I find the SDK that tracks without asking?

Audit the binary's behavior, not the marketing: list every third-party SDK, check each one's documentation for tracking and fingerprinting defaults, configure consent-gated initialization where offered, and remove what cannot be gated. Ad, attribution, and some analytics SDKs are the usual suspects, and the consent-before-requests sequencing from the ads setup is the same machinery.

### What does respecting 'Ask App Not to Track' require?

Absolute compliance and graceful product behavior: no fingerprinting fallbacks, no workaround identifiers, no second asks every session, and an app that works identically minus the personalization. The setting is also a product signal, designs that depend on tracking for core value are designs Apple's platform has already voted against.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*