App Tracking Transparency (ATT) Violations: How to Request IDFA Access Correctly

If you were rejected for App Tracking Transparency (ATT) or need IDFA support without risking another rejection, follow this repeatable workflow to produce validated prompt copy, runtime gating, App Review notes, and the screen recording reviewers expect. This guide focuses on concrete steps, realistic effort, and common tradeoffs so you can submit with fewer review cycles.

Early proof - quick evidence, interpretation, and impact

• Evidence - Illustrative reviewer triggers include accessing AdSupport before consent, a missing or vague NSUserTrackingUsageDescription, and no screen recording attached to the review submission.
• Interpretation - Fix the purpose string, gate IDFA access until after consent, and attach a short on-device recording that shows your in-app explanation and the system prompt.
• Impact - Doing those three items first typically reduces review iterations; if you miss them expect 3-7 day resubmissions and plan 1-3 engineering days plus 1 QA day to implement fixes.

What this means in practice: prioritize copy and artifacts before code work, then implement runtime gating and a QA pass. Reviewer judgments vary, so budget for at least one resubmission window.

IDFA, Analytics, and App Privacy: What to Declare goes deeper on the ideas above and adds concrete next steps.

Who gets rejected for IDFA and what can you fix?

Rejections usually happen when apps access IDFA APIs before consent or submit vague purpose strings. Those two issues are the bulk of ATT-related rejections and are fixable without major redesign.

Who is affected and the practical decision this article resolves

Apps that show personalized ads, use deterministic attribution, frequency capping, or include ad SDKs that require IDFA are affected. Expect to involve an iOS engineer, a product/privacy owner to craft copy, and QA. Tradeoff: IDFA gives deterministic attribution but requires explicit consent and usually reduces measurable coverage; SKAdNetwork is more privacy-preserving but less granular.

Cost of inaction: what an ATT violation looks like in review

If you access IDFA before consent you will likely be rejected and lose deterministic attribution revenue until fixed. Expect roughly 3-7 additional days to get a build live and at least 1-2 engineering days to patch and re-verify, depending on complexity.

When you move from outline to execution, Firebase Analytics and Apple Privacy Labels: What to Declare helps close common gaps teams hit here.

How do I request IDFA access correctly? Step-by-step

A step flow diagram showing: App event triggers contextual UI → show explanation screen → call ATTrackingManager.requestTrackingAuthorization() → if authorized then initialize ad SDKs & read IDFA, else fallback to SKAdNetwork and aggregated metrics. Each node lists the concrete file/setting (Info.plist key, App Review note) to update.

Do three priorities first: finalize truthful copy, produce a short recording showing the flow, and gate IDFA in code; then submit. Plan 1-3 engineering days for a typical app and an extra day for QA and recording.

Prerequisites you must have before coding

• Xcode target on iOS 14.5+ with AppTrackingTransparency and AdSupport linked.
• Final NSUserTrackingUsageDescription in Info.plist and identical text in App Store Connect.
• A documented product decision: why IDFA is required and a fallback (SKAdNetwork or aggregated metrics) if users deny tracking.
• A 10-20 second on-device screen recording showing the in-app explanation, the system prompt, and the dependent feature.

Implementation steps (in order)

1. Gate frameworks behind runtime checks

   Only call AdSupport or read IDFA after confirming ATTrackingManager.authorizationStatus; lazy-initialize ad SDKs and defer any init paths that touch IDFA. Expect 0.5-2 days to refactor depending on app size.

2. Set a clear, truthful NSUserTrackingUsageDescription

   Use one concise sentence that explains what tracking enables, for example "We use tracking to provide personalized ads and measure ad campaigns that fund this app." Updating this string and App Store Connect copy is quick but can trigger a resubmission if changed mid-review.

3. Request authorization at a contextual moment

   Call ATTrackingManager.requestTrackingAuthorization() when the user is engaged, such as after onboarding or when entering an ad-visible experience, not on cold start. Expect a few hours of UX iteration and testing.

4. Provide an in-app explanation UI before the system prompt

   Show a short, honest screen explaining benefits and what changes if the user consents; this helps reviewers and can modestly improve opt-in. Plan 1-2 small UI screens and a minor design pass.

5. Initialize ad SDKs only after authorization

   If the user grants permission, initialize third-party SDKs that read IDFA; otherwise rely on SKAdNetwork or other fallbacks. Track vendor changelogs: some SDKs may reintroduce AdSupport usage in updates, so add this check to your release checklist.

Validation checkpoint: how to prove the flow works before submission

• Runtime checks: log ATTrackingManager.authorizationStatus and confirm with device-level testing that no IDFA reads occur before consent. Simulators can miss third-party behavior; test on real devices.
• Test artifacts: record a 10-20 second video showing the in-app explanation, the system prompt, and the feature that needs tracking. Use that same clip in App Review.
• Pre-submit checklist: set NSUserTrackingUsageDescription in App Store Connect, attach the recording, and note your fallback to SKAdNetwork in the review notes. Allow 1-2 days for QA and artifact review.

A complementary angle worth comparing lives in How to Fix App Store Guideline 5.1.2 Data Use and Sharing Rejection.

What common mistakes cause ATT rejections and how do I checklist them?

A compact checklist block split into 'Pre‑flight' and 'Post‑launch' columns with actionable items: verify NSUserTrackingUsageDescription, attach screen recording, confirm no pre-consent IDFA calls, monitor opt‑in rate, and prepare rollback/hotfix steps.

The most frequent failures are calling IDFA before consent, vague purpose strings, and missing recordings; fix those and you sharply reduce appraisal friction. Even correct submissions can receive follow-up questions, so be explicit in attachments and notes.

Common ATT / IDFA anti-patterns to avoid

• Showing the system prompt at first cold start - leads to low opt-in and reviewer concern.
• Vague boilerplate strings - reviewers will ask for a specific, truthful purpose.
• Letting any SDK or code path access IDFA before consent - third-party SDKs can change behavior on update.

Execution checklist: pre-flight and post-launch actions

• Pre-flight:

  • Verify NSUserTrackingUsageDescription in Info.plist and App Store Connect.
  • Attach a 10-20 second screen recording showing the in-app explanation, the prompt, and the affected feature.
  • Confirm via logs that no AdSupport calls occur before consent.
  • Document fallback measurement (SKAdNetwork).

• Release day:

  • Monitor App Review feedback for 48 hours and be ready to respond within 24 hours.
  • Track opt-in rates for the first 72 hours.
  • Have a hotfix plan if reviewers request copy or technical changes.

• Post-launch:

  • Audit ad SDK updates periodically to ensure they do not reintroduce early IDFA access.
  • Monitor opt-in KPIs and revenue by cohort and adjust messaging if needed.

For tradeoffs, checklists, and edge cases, Where Founders Make Mistakes Before Launch rounds out this section.