Guideline 5.1.2 — App Tracking Transparency
Your app tracks users across apps or websites and either does not ask, asks in a way the reviewer could not find, or asks while the privacy labels say you do not track.
What the rejection usually says
Your app uses the AppTrackingTransparency framework, but we were unable to locate the permission request.
Your app collects data for tracking without requesting permission.
Wording varies between reviewers; the substance does not.
Why it gets triggered
- An advertising or analytics SDK collects the IDFA without an ATT prompt.
- The prompt exists but appears after the tracking begins, or behind a flow the reviewer never reached.
- Privacy nutrition labels declare no tracking while an SDK does exactly that.
- A custom pre-prompt effectively pressures the user before the system dialog.
How to fix it
1.Audit what your SDKs actually collect
Check each third-party SDK for identifier use. Attribution and ad SDKs usually count as tracking even when you never touch the IDFA yourself.
2.Show the prompt before any tracking
Request authorisation first, and tell the reviewer in App Review notes exactly where the prompt appears.
3.Make the labels match the code
Update the privacy questionnaire so the declared data types and tracking answer match reality.
A reply you can adapt
Short, specific, and stating what changed — reviewers read hundreds of these.
Thank you. The ATT prompt is now shown on first launch of the home screen, before any SDK initialises — reviewer steps are in the notes. We have also corrected the privacy labels to declare identifier use for tracking.
AppSubmit does this for your app, specifically
Paste the rejection and the decoder reads it against your actual listing, build and release history — then writes the fix plan and drafts the reply. It also watches your submissions, so the next rejection reaches you as a notification rather than a surprise.
Decode a rejection free