A 5.1.2 rejection means Apple found your app sending or sharing user data in a way that does not match what you declared in App Store Connect or your privacy policy. This guide helps an indie or small-team developer diagnose the disagreement, produce a reviewer-verifiable snapshot, and either stop pre-consent collection or sync your disclosures so you can resubmit.
Early proof - quick snapshot (30-90 minutes)
- What to capture
- Fresh-install network trace from a real iPhone during the first 1-2 minutes of onboarding; record top 3-5 outbound domains and whether payloads include identifiers (IDFA, device ID, hashed email).
- How to capture it
- Use Charles, Proxyman, or backend logs; test via TestFlight or an ad-hoc install and limit the run to initial screens only.
- What to include in reviewer notes
- For each risky call, state what was sent, why you think it was sent (SDK X init, web view, etc.), and the exact build number and reproduction steps.
- Practical interpretation
- If identifiers or ad/attribution calls occur before a disclosure or ATT/consent, you likely have the three-surface mismatch (runtime, privacy policy, App Store Connect) that triggers 5.1.2.
- Business impact
- Fixing the snapshot typically costs a few hours to a few days of engineering work depending on SDKs and onboarding complexity; it avoids repeated rejections and review delays.
What this guide will do: show focused fixes and reviewer-note content so you have a reproducible package for resubmission. Expect reviewer variability and plan for 1-2 review cycles; some cases need vendor coordination.
How to Publish a Kids App on App Store - Extra Rules Explained goes deeper on the ideas above and adds concrete next steps.
Why was my app rejected under App Store Guideline 5.1.2?
Apple rejects when app behavior, your privacy policy, and App Store Connect metadata disagree. In practice reviewers look for undisclosed or surprising data collection, especially identifiers or ad/attribution traffic sent before any consent.
Here is the thing: the common failure mode is pre-consent SDK initialization or a missing disclosure entry. What this guide fixes is the mismatch and the reviewer evidence you attach so verification is quick.
One thing worth noting: reviewers and regional rules vary, and some enterprise or MDM installs behave differently. Expect to iterate if a reviewer requests extra detail.
Quick diagnosis and the pass/fail gate
- What reviewers look for
- Undisclosed identifier sharing, ad/attribution traffic, or third-party forwarding that contradicts your metadata and policy.
- Pass/fail gate on a fresh install
- No analytics, attribution, or ad-related network calls before a clear disclosure and any required consent or ATT prompt.
- Immediate checks
- Confirm App Store Connect entries match what your snapshot shows.
- Verify onboarding order so disclosure and consent precede third-party SDK initialization.
Who needs to read this and realistic effort
- Audience
- Indie devs and small teams who manage builds, onboarding UX, or App Store metadata.
- Time commitment
- 30-90 minutes for the first snapshot and inventory; 2-6 hours for a focused SDK audit; several days if you must refactor onboarding or rework vendor integrations.
- Practical outcome
- Either stop pre-consent collection or produce synchronized disclosures and reviewer notes that let App Review verify behavior. Some SDKs may require vendor support or acceptance of reduced early analytics.
When you move from outline to execution, Does Your App Need a Privacy Policy? (Yes - Here's Why) helps close common gaps teams hit here.
How do I fix a 5.1.2 rejection - step-by-step?
A compact checklist block showing pre-flight items for a 5.1.2 resubmission: fresh-install capture attached, disclosure screen appears first, ATT/consent prompts contextually placed, App Store Connect fields updated, reviewer notes include reproduction steps and screenshots, and final verification on clean device.
Start by stopping what reviewers can see and then document the remaining behavior clearly.
Ordered workflow - exact steps to fix the rejection
Inventory data paths
Capture network traffic and list where data goes: analytics, crash, attribution, ad networks, identity providers, and any web views.
Tag purposes and consent needs
For each path record data types, whether it links to identity, whether it runs before onboarding completion, and whether users can opt out.
Stop pre-consent collection
Delay SDK initialization so analytics and ad SDKs start only after consent or ATT. If a vendor has no deferred init option, consider removing or replacing the SDK, or show a pre-consent disclosure before it runs.
Update App Store Connect and policy
Make App Store Connect entries and your privacy policy explicitly match the inventory. List identifiers and third parties used for each purpose and be conservative in language.
Prepare reviewer notes and retest
Attach the snapshot, exact reproduction steps, screenshots of disclosure/consent, and build number. Do a fresh-install retest yourself to confirm the snapshot matches your notes.
One tradeoff: gating SDKs reduces early telemetry and may complicate analytics; weigh that against faster approval and lower review friction. SDKs that cache identifiers or auto-init can require vendor coordination.
A complementary angle worth comparing lives in We Analyzed App Store Rejection Patterns: What Most Founders Miss Before Submission.
What checklist should I run and what mistakes should I avoid?
Run this checklist before submitting and avoid the frequent traps.
Checklist to run before resubmitting:
- Fresh-install network capture attached to reviewer notes with build number.
- Pre-consent disclosure and ATT prompt shown before any identifier leaves the device.
- App Store Connect privacy fields list all identifier types and third parties.
- Privacy policy text matches the inventory and is copy-paste friendly for reviewers.
- Fresh-install retest confirms the snapshot you submitted.
Common mistakes and edge cases:
- Analytics inside web views or SafariViewController firing independently of app gating.
- SDKs with cached consent or automatic initialization you missed - check vendor docs.
- Updating metadata or policy without changing runtime behavior - reviewers test the binary.
- Enterprise or MDM-managed devices behaving differently - mention this in notes if relevant.
Final practical note: plan for reviewer variability and one additional review cycle; complex third-party stacks or regional rules may need extra documentation or vendor changes.
For tradeoffs, checklists, and edge cases, Google app Store privacy policy requirements rounds out this section.
