App Store Compliance

Guideline 5.1.2 — Data Use and Sharing rejection: why, and the fix

App Review rejected your app under Guideline 5.1.2. What 'Data Use and Sharing' actually prohibits, the common triggers, and how to get the resubmission approved.

By · · 8 min read

App Review sent a rejection citing Guideline 5.1.2 — Data Use and Sharing. Unlike a processing-time ITMS error, this is a human reviewer telling you the app’s behavior around data doesn’t match what you disclosed — or that it’s doing something Apple flatly prohibits. These take longer to resolve than ITMS errors because there’s a judgment call involved.

This post is what 5.1.2 actually covers, the five patterns that trigger it, and how to structure the resubmission.

For the broader privacy-guideline context, see our complete walkthrough of Guideline 5.1.1 and every URL and file Apple requires for submission.

What Guideline 5.1.2 says

5.1.2 sits in the 5.1 Privacy → Data Use and Sharing section of the App Store Review Guidelines. The core requirements:

  • You must have permission before collecting data, and must explain how it’s used.
  • Apps must not repurpose data for anything beyond what the user consented to.
  • Data must not be shared with third parties except for purposes directly relevant to the app or by legal request.
  • Apps must not attempt to build a user profile from data collected in a way the user wouldn’t expect.
  • Apps that share user data without consent with data brokers are prohibited.
  • You must provide access to your privacy policy and adhere to it.

It’s the “what you do with the data after you collect it” guideline. 5.1.1 governs collection; 5.1.2 governs use, sharing, and repurposing.

The 5 patterns that trigger a 5.1.2 rejection

1. Tracking without an ATT prompt

The most common 5.1.2 rejection. Your app (or an embedded SDK) links user/device data with data from other companies for advertising or measurement — Apple’s definition of “tracking” — but doesn’t call the App Tracking Transparency API to request permission first.

Fix: call ATTrackingManager.requestTrackingAuthorization before any tracking SDK initializes, and declare the tracking in your PrivacyInfo.xcprivacy (NSPrivacyTracking = true, plus NSPrivacyTrackingDomains). Gate the SDK init on the authorization result.

import AppTrackingTransparency
import AdSupport

ATTrackingManager.requestTrackingAuthorization { status in
    switch status {
    case .authorized:
        // Only now initialize the tracking SDK
        AnalyticsSDK.start(idfa: ASIdentifierManager.shared().advertisingIdentifier)
    default:
        AnalyticsSDK.startWithoutTracking()
    }
}

2. Privacy policy doesn’t match observed behavior

App Review reads your privacy policy URL and watches what the app actually does. If the policy says “we do not share data with third parties” but the app sends device identifiers to an ad network on launch, that’s a 5.1.2 mismatch.

Fix: make the policy accurately describe every third party the app shares data with and why. Our iOS privacy policy generator post covers what App Review cross-checks.

3. Sharing data with data brokers

Sending user data to a company whose business is aggregating and reselling personal data is prohibited regardless of consent UI. Some “monetize your app’s data” SDKs fall in this bucket.

Fix: remove the SDK. There’s no disclosure that makes this compliant.

4. Repurposing data beyond the consented purpose

Collecting email “to send your receipt” then using it for marketing without separate consent. Collecting location “for nearby results” then selling location traces.

Fix: collect a separate, explicit consent for each purpose, or stop the secondary use.

5. Fingerprinting / building a profile the user wouldn’t expect

Using device signals (font list, installed-app probing, hardware identifiers) to build a persistent identifier that survives “Ask App Not to Track.” Apple specifically prohibits fingerprinting as a tracking workaround.

Fix: remove the fingerprinting SDK or behavior. Apple treats fingerprinting-to-circumvent-ATT as a hard violation.

How to structure the resubmission

A 5.1.2 rejection is reviewed by a human, so the resubmission needs a human-readable response in App Review notes, not just a silent re-upload:

  1. State exactly what changed. “Removed the X SDK that shared device identifiers with an ad network. Tracking is now gated behind an ATT prompt; SDK only initializes on .authorized.”
  2. Point to the privacy policy line that now matches the behavior.
  3. If you disagree with the rejection, use the Resolution Center to explain why — but only if you genuinely believe the reviewer misread the behavior. Arguing without changing anything usually fails.

App Review re-tests the specific behavior. If your notes say you fixed it and the behavior still happens, the second rejection is harder to recover from.

Prevention: audit before you submit

Most 5.1.2 rejections come from an SDK doing something the developer didn’t know about. Before submitting:

# See what network endpoints your app actually hits
# (use a proxy like Charles/Proxyman, or Console.app + a network filter)
# Look for ad-network / data-broker domains on first launch
# BEFORE the user has interacted with anything.

If anything fires before the user takes an action — especially before an ATT prompt — that’s a 5.1.2 risk. Cross-check every SDK against Apple’s privacy-manifest-required SDK list and read each one’s data practices.