Guideline 5.1.2 Rejection: How to Fix Data Use and Sharing Issues and Resubmit
Guideline 5.1.2 — Legal: Privacy — Data Use and Sharing — governs what you do with data after collecting it: tracking users across other companies' apps and websites, and sharing personal data with third parties. Since iOS 14.5, the enforcement centerpiece is App Tracking Transparency (ATT): if your app tracks, it must ask via the ATT prompt and respect the answer. Most 5.1.2 rejections are about tracking that happens without — or before, or regardless of — that permission.
What Apple's rejection email says
"Guideline 5.1.2 — Legal — Privacy — Data Use and Sharing. We found that your app collects user and device data to track users, but does not use App Tracking Transparency to request the user's permission before tracking. Next Steps: Please update your app to implement the AppTrackingTransparency framework and request permission from users before collecting data used to track them. You must also update your app privacy information in App Store Connect."
Typical App Review wording for Guideline 5.1.2. Exact text varies per app.
Why apps get rejected under 5.1.2
- Tracking without the ATT prompt. The app (usually via ads or analytics SDKs) accesses the IDFA or combines user data with third-party data for advertising, but never calls
ATTrackingManager.requestTrackingAuthorization. Apple's static and dynamic analysis catches SDKs known to track. - Ignoring the ATT answer. Showing the prompt but fingerprinting or sending identifiers to ad networks even when the user declines — or gating app functionality on accepting tracking, which is explicitly disallowed.
- Privacy label says "tracking", code says otherwise (or vice versa). The App Privacy questionnaire in App Store Connect declares "Data Used to Track You" but the binary has no ATT flow — or the label denies tracking while a bundled SDK plainly does it.
- Sharing personal data with third parties without consent. Selling or passing user data (contacts, location, usage) to data brokers, ad networks or "partners" without informed permission — including uploading the user's address book to build social graphs.
- Repurposing data. Using data collected for one feature (e.g. health, location for a store finder) for unrelated purposes like advertising, beyond what the privacy policy and consent covered.
- Pre-prompt manipulation. Custom screens that pressure users into tapping Allow, or incentives offered for accepting tracking.
Step-by-step fix
- Inventory who tracks in your binary. List every ads/analytics/attribution SDK (AppsFlyer, Adjust, Meta/Facebook SDK, Google Ads, etc.) and check each vendor's documentation for its ATT and IDFA behavior. Most modern SDKs have an explicit "don't track until authorized" configuration.
- Implement ATT properly. Add
NSUserTrackingUsageDescriptiontoInfo.plistwith an honest sentence ("This lets us show you more relevant ads"), then callATTrackingManager.requestTrackingAuthorizationat a sensible moment (after app launch UI is up) and only start tracking SDKs / read the IDFA when the status is.authorized. - Handle "denied" for real. Configure SDKs into non-tracking modes on denial, don't fall back to fingerprinting (device fingerprinting is prohibited regardless of ATT), and never block features because the user declined.
- Stop undeclared sharing. If the flag is about third-party sharing rather than ATT: remove the data flow, or gate it behind explicit, informed in-app consent and describe it in your privacy policy. Contact-list uploads and location resale are the patterns Apple names directly.
- Reconcile the privacy label. App Store Connect → App Privacy: your "Data Used to Track You" and "Data Linked to You" answers must match what the app and its SDKs actually do after the fix.
- Verify before submitting. On a test device, decline the ATT prompt and watch outbound traffic (Instruments or a proxy) to confirm identifiers stop flowing to ad endpoints.
How to resubmit
ATT and SDK-configuration fixes live in the binary, so upload a new build, update the App Privacy answers in App Store Connect to match, and submit for review with a reviewer note summarizing the change ("ATT prompt added; ad SDK initialized only after authorization; privacy label updated"). If Apple claims tracking you're certain doesn't exist, reply in the App Review thread asking which SDK or endpoint was detected — that's answerable; an appeal usually isn't, with about 85% of appeals denied.
How AscAuto handles 5.1.2 rejections
For 5.1.2, AscAuto reads the rejection, determines whether Apple flagged missing ATT, a label mismatch or third-party sharing, and produces a diagnosis naming the likely SDK culprits. Code changes — adding NSUserTrackingUsageDescription, wiring the ATT request, moving SDK initialization behind authorization — are proposed as a GitHub pull request for your review. The matching App Privacy label update is prepared as a metadata change for your approval, so the binary and the label stop contradicting each other, which is what usually causes the re-rejection loop.
FAQ
My app has no ads — why was I rejected for tracking?
Almost always a bundled SDK. Analytics and attribution SDKs can collect device identifiers that Apple classifies as tracking even if you never show an ad. Audit every third-party SDK's data behavior and either configure it into a non-tracking mode or add the ATT flow.
Can I show my own explainer screen before the ATT prompt?
Yes — a neutral pre-prompt explaining why you ask is allowed. What's not allowed is manipulating the choice: incentives for allowing, disabling features on denial, or designs that hide the option to decline.
If the user denies ATT, can I use fingerprinting instead?
No. Device fingerprinting is prohibited by Apple regardless of ATT status, and using it as a fallback after a denial is exactly the behavior 5.1.2 enforcement targets. Denied means no cross-app tracking, full stop.
Do I need the ATT prompt if I only use first-party analytics?
Not necessarily. Tracking, in Apple's definition, is linking user or device data with third-party data for advertising, or sharing it with data brokers. Purely first-party analytics with no third-party linkage generally doesn't require ATT — but your privacy label still has to declare what you collect.