How to Fix App Store ATT Permission Request Not Found Rejection
Fix an AppTrackingTransparency permission request that App Review cannot locate, or remove tracking and reconcile the submitted binary with App Privacy answers.
Direct answer
Choose one truthful path for the exact submitted build. If the app or an embedded SDK tracks users as Apple defines tracking, include NSUserTrackingUsageDescription, request authorization through AppTrackingTransparency while the app is active, and block every tracking-dependent data flow until authorization is granted. Give App Review numbered steps that reach the prompt on a clean review path. If the app does not track, remove the ATT request, tracking code and SDK behavior from the release, then update App Privacy answers so they no longer claim tracking. Do not add a prompt only to satisfy the rejection: the signed binary, SDK behavior, permission flow, and App Store Connect disclosures must agree.
Match the wording in your rejection
“We are unable to locate the App Tracking Transparency permission request”
Reproduce the exact reviewer path and permission state in the submitted build. If tracking can start, the system request must be reachable before any tracking-dependent collection or sharing begins; tell App Review exactly how to reach it.
App Review asks where the ATT request appears
This can be an information gap only when the prompt already works in the reviewed build. Reply with the build number, prerequisites, numbered taps, expected screen, and a short recording instead of uploading an unchanged build without explanation.
The app does not track, but App Privacy still declares tracking
Audit the final binary and every third-party SDK first. If the release truly performs no Apple-defined tracking, remove unnecessary ATT artifacts and publish accurate App Privacy responses before asking for another review.
The prompt appears for developers but not during review
Test a clean review account on every supported device family and inspect authorization state, launch timing, consent-manager order, remote configuration, geography, login gates, and SDK initialization. Do not assume a screen recording from a previously authorized device proves the review path.
What this rejection usually means
This rejection is a consistency failure across four surfaces: what the signed app and embedded SDKs actually do, whether the ATT system request can appear in the reviewer’s state, when tracking-related data starts moving, and what App Privacy declares. Apple defines tracking by the data linkage and purpose, not by whether the app merely contains an ad or analytics SDK. Apple also makes the developer responsible for third-party code. A purpose string alone does not display the request, while calling the API does not excuse a tracking SDK that initializes or sends governed identifiers first. The opposite mismatch is common too: a release has stopped tracking, but its binary or App Privacy answers still signal tracking. Start from the exact archive and observed network or SDK behavior so you fix the real branch.
Likely rejection signals
- NSUserTrackingUsageDescription exists, but no reachable code path calls the ATT authorization request
- The request runs during an unreliable launch transition, behind login, after a remote flag, or only on one device layout
- The reviewer account, region, consent-manager state, or ad configuration follows a path your development account never tested
- An advertising, attribution, analytics, SSO, webview, or deferred-deep-linking component may create cross-company identity or share governed identifiers
- A third-party SDK initializes before ATT is resolved or ignores the denied and restricted outcomes
- App Privacy says data is used for tracking although the new release removed that behavior, or says it is not used for tracking although the release still performs it
- The team tested a previously answered permission state rather than a clean not-determined review path on every supported device family
Recovery plan
- Preserve the complete rejection, screenshot or attachment, review device and OS, app version, build number, and any path the reviewer attempted. Confirm that the build you inspect is the same build Apple reviewed.
- Classify the real data flow using Apple's definition. Inventory first-party code and every embedded SDK, including advertising, attribution, analytics, SSO, consent management, webviews, and deferred deep linking. Record which user or device identifiers leave the app, the recipient, purpose, and whether they are linked with data from other companies.
- Choose the no-tracking branch when the release does not perform Apple-defined tracking. Remove unused ATT framework calls and NSUserTrackingUsageDescription, remove or reconfigure SDK behavior that implies or performs tracking, archive again, and inspect the final app and embedded frameworks. Update and publish accurate App Privacy responses for the app and its third-party partners.
- Choose the tracking branch only when tracking is part of the shipped behavior. Add a clear NSUserTrackingUsageDescription purpose string, call the AppTrackingTransparency authorization API from a stable, visible app state, and ensure the system request is reachable on each supported device family. A custom explainer may provide context, but it cannot replace the system request.
- Put a hard gate in front of tracking. Before authorization, do not access the advertising identifier or transmit another identifier or data flow for tracking. Handle authorized, denied, restricted, and not-determined states deliberately, and make ordinary app functionality usable without forcing consent.
- Test the exact Release archive or TestFlight build from a clean review scenario. Cover iPhone and iPad when supported, fresh and returning accounts, login and logged-out states, tracking requests allowed at the system level, every consent-manager outcome, network delay, remote configuration, and the latest production OS. Confirm both that the prompt appears where documented and that no tracking request occurs first.
- Make the review path deterministic. Avoid requiring undisclosed content, a paid entitlement, a particular campaign, or a remote flag to reveal the prompt. If the request follows onboarding or a feature action, provide that shortest legitimate path and keep the review backend and credentials working.
- Update Review Notes with the exact build number, numbered taps, the screen where the system dialog appears, prerequisites, and what happens after Allow and Ask App Not to Track. Attach a short recording when the path or timing could be missed. State whether the build tracks and make that statement match App Privacy.
- If implementation, SDK configuration, purpose strings, or the binary changed, upload and resubmit the corrected build. If the exact reviewed build was already correct and only the path was missed, reply in the existing App Review conversation and request a retest before making unrelated changes.
- Appeal only after a precise clarification and retest fail despite evidence from the exact reviewed build. If App Store Connect prevents you from publishing accurate privacy responses, preserve the error, roles, app and version identifiers, and contact Apple Developer Support rather than misdeclaring the data practice.
Evidence to prepare
- Full rejection message, reviewer attachment, device and OS, app version, and build number
- Data-flow inventory for first-party code and every embedded SDK, with recipients, purposes, identifiers, and tracking classification
- Final archive check covering NSUserTrackingUsageDescription, ATT references, embedded frameworks, and release configuration
- Network or SDK initialization evidence showing that no tracking occurs before authorization or after a non-authorized result
- Clean-state test matrix for supported device families, accounts, consent-manager paths, remote flags, and authorization outcomes
- Short recording of the exact numbered path to the Apple system prompt in the submitted build
- Published App Privacy answers that match the submitted release and third-party partners
- Review Notes with working credentials, prerequisites, expected prompt screen, and build-specific behavior
Appeal or fix first?
Clarify first when the exact reviewed build already presents ATT before any tracking, App Privacy is accurate, and the reviewer likely missed a reproducible path. Give Apple release-specific steps and a recording and ask for a retest. Appeal only when the same factual finding remains after that clarification and your evidence covers the exact build, review state, and pre-authorization data flow.
Fix and resubmit when the prompt is unreachable or unreliable, the purpose string or API call is missing, tracking begins before authorization, a third-party SDK is not gated, supported iPad flow differs, or App Privacy conflicts with the release. Also fix when the app does not track but stale ATT code, SDK behavior, or disclosures still signal that it does.
Reviewer response framework
Your response should be factual, short, and limited to the submitted build. Cover these points:
- Identify the exact app version and build Apple should review.
- State plainly whether that build performs tracking under Apple's definition; do not equate all analytics or ads with tracking.
- If it tracks, provide numbered taps to the system request and confirm tracking-dependent data is gated until authorization.
- If it does not track, name the removed or reconfigured components and confirm the published App Privacy answers match the build.
- Attach concise release-specific evidence and request review of the corrected build or a retest of the documented path.
Frequently asked questions
Does adding NSUserTrackingUsageDescription make the ATT prompt appear?
No. The purpose string supplies the explanation shown by the system, but the app must also request authorization through AppTrackingTransparency from a reachable, stable flow.
Do all apps with ads or analytics need the ATT prompt?
Not automatically. ATT is required when the app tracks as Apple defines it, such as linking app data with third-party data for advertising or measurement or sharing it with a data broker. Audit each SDK's actual practices and configuration.
Can tracking start while the ATT prompt is still pending?
No. Apple says tracking requires explicit permission. Keep tracking-related identifier access, collection, and sharing gated until the authorization result permits it.
What if my new build no longer tracks users?
Remove tracking behavior and unnecessary ATT artifacts from the final release, audit embedded SDKs, and publish App Privacy responses that accurately describe the new data flow. Do not add a meaningless prompt solely because an older release tracked.
Should I appeal when App Review cannot find a prompt that works in TestFlight?
First reproduce the exact device, account, permission, consent, and configuration path, then reply with numbered steps and a recording from the same build. Appeal only if a retest still contradicts complete build-specific evidence.
Need a rejection-specific plan?
Start with the free diagnosis. The $29 Fix Pack adds the prioritized remediation plan, evidence checklist, reviewer-ready reply, and preflight.
Source: Apple Developer — User Privacy and Data Use. Platform policies change. Verify the official rule before submitting. Resubmit AI provides technical and editorial decision support, not an approval guarantee or legal advice.