Guideline 5.1.2 Data Use and Sharing: how to fix ATT and tracking rejections

What Guideline 5.1.2 actually requires

Guideline 5.1.2 governs what you do with personal data after collecting it: using it, sharing it and tracking people with it. Collection itself (purpose strings, privacy policy, login walls) is Guideline 5.1.1. Nearly every 5.1.2 rejection comes from sub-clause (i):

• Unless the law permits otherwise, get permission before you use, transmit or share personal data, and clearly disclose sharing with third parties. The current text explicitly includes "third-party AI".
• You "must receive explicit permission from users via the App Tracking Transparency APIs to track their activity" (Apple).
• You may not require tracking, push notifications or location to use the app or its content, or to receive compensation such as gift cards and codes.

Sub-clauses (ii) to (vii) cover repurposing data, secret profiling and re-identifying anonymous users, building contact databases or collecting which other apps are installed, and limits on HealthKit, HomeKit and Apple Pay data.

What counts as "tracking"

Apple defines tracking as linking user or device data from your app with other companies' data for targeted advertising or advertising measurement, or sharing it with data brokers. An SDK that does this counts even if you never use that feature yourself.

Fingerprinting (deriving data from the device to uniquely identify it) is not a workaround: Apple's FAQ says the Developer Program License Agreement forbids it, and apps that use it, or include SDKs that do, may be rejected.

Common reasons apps get rejected under 5.1.2

• Labels declare tracking, but the app never asks. The most common message: data types in App Privacy are marked as used for tracking, often copied from an SDK vendor's guide, but there's no ATT prompt.
• The reviewer can't find the prompt. The app uses the AppTrackingTransparency framework or contains NSUserTrackingUsageDescription, yet the alert never shows. Developers report this often arrives as a 2.1 Information Needed request ("we are unable to locate the App Tracking Transparency permission request"), frequently naming an iPad as the review device.
• Tracking before consent. Ad, attribution or social SDKs start at launch and send identifiers before the user has answered.
• Overlooked tracking SDKs. Apple's FAQ says third-party deep-linking or deferred deep-linking tools that pass unique identifiers or create a shared identity across different companies' apps for ads, ad measurement or data brokers need ATT. The same applies to third-party single sign-on that tracks users.
• Manipulative pre-prompts. An "Allow" button on your own screen, a fake copy of the system alert, or arrows pointing at "Allow". These are sometimes cited under 5.1.1(iv), which bans manipulating or tricking people into consenting.
• Gating or incentives. Coins, discounts or content in exchange for allowing tracking, notifications or location, or blocking the app until users agree.
• Labels that don't match your SDKs. "Data Not Collected" while an ads SDK sends device IDs, or user content passed to an external AI provider without disclosure and permission. Apple holds you responsible for all code in your app, including third-party SDKs.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

How to fix a 5.1.2 rejection step by step

1. Classify the rejection: labels without ATT, prompt not found, or a pre-prompt or incentive issue. Attached screenshots usually show the screen in question.
2. Inventory what tracks. In Xcode, choose Product → Archive, then Control-click the archive in the Organizer and choose Generate Privacy Report. It aggregates the privacy manifests of your app and its SDKs, including tracking declarations, but SDKs that ship without a manifest won't show up. So also search your code and dependencies for ASIdentifierManager, advertisingIdentifier, AdSupport and ATTrackingManager.
3. Decide honestly whether you track. Personalized ads from a network, identifier-based campaign measurement, retargeting or sharing with data brokers mean yes. First-party analytics and crash reporting usually mean no; then follow the section on removing ATT below.
4. Add a specific purpose string. Set NSUserTrackingUsageDescription in the target's Info tab and localize it. Apple's documentation says the app crashes if it uses ATT without this key.
5. Request at the right moment with ATTrackingManager.requestTrackingAuthorization(completionHandler:): while the app is active, on a screen every reviewer reaches (see the next section).
6. Gate the SDKs, not the user. Start ad and attribution SDKs in the completion handler. For any status other than .authorized, configure them without tracking while the app keeps working fully.
7. Align your privacy manifest: set NSPrivacyTracking to true in PrivacyInfo.xcprivacy and list your NSPrivacyTrackingDomains. On iOS 17 and later, requests to those domains fail until the user grants permission, so don't list a domain your app also needs for normal features.
8. Update App Privacy under Apps → your app → App Privacy: mark exactly the data used for tracking and click Publish. This needs the Account Holder, Admin or App Manager role.
9. Test a fresh install of the release build on an iPhone and an iPad, upload a new build and state in the review notes where the prompt appears.

Making the ATT prompt visible to the reviewer

Per Apple's documentation, requestTrackingAuthorization runs your completion handler without showing anything if tracking is restricted, if the user turned off Allow Apps to Request to Track in Settings → Privacy & Security → Tracking (called "Allow Apps to Request to Link Your Activity Across Companies" in the EU), if a request is already pending, if it's called from an extension, or if the app isn't in the UIApplicationStateActive state. That last case is a frequent cause of "we can't find it" rejections.

• Not in didFinishLaunching. Call it from sceneDidBecomeActive(_:) or when SwiftUI's scenePhase becomes .active, once your first screen is visible. Developers on the Apple Developer Forums reported that on iOS 17, apps opened from TestFlight could start behind TestFlight's info screens, so a launch-time request never appeared.
• One system alert at a time. Chain notification, location and ATT requests through their completion handlers.
• On every path. A prompt that only appears after sign-up or a paywall may never be reached by the reviewer.
• Check the status first. Request only when trackingAuthorizationStatus is .notDetermined; the alert normally appears only once per install (see the EU exception below).
• Be specific. "Your data will be used to show you more relevant ads." beats generic plugin defaults like Expo's "Allow this app to collect app-related data that can be used for tracking you or your device."
• Record proof of a fresh install of the submitted build, and note that the alert requires Allow Apps to Request to Track to be on.

EU changes to the ATT prompt

Apple has announced an alternative ATT prompt for the EU, beginning with iOS 27.2 and iPadOS 27.2. In France, Germany, Italy, Poland and Romania the system shows a full-page sheet instead of the alert. It can display rich text from the optional NSUserTrackingMarkdownUsageDescription key, and requestTrackingAuthorization(preferExpandedInterface:additionalInformationAction:completionHandler:) adds an optional "Additional Information" button. EU users can also be asked again one year after their last answer. When the sheet is closed through "Additional Information", the status stays .notDetermined, so call the request again after your info screen. The rules on when you need permission stay the same.

Flutter, React Native, Expo and WebView apps

Plugins like app_tracking_transparency (Flutter), react-native-tracking-transparency and expo-tracking-transparency wrap the same API, so call them after the first screen renders, not in main(). Expo reads the purpose string from the userTrackingPermission config plugin option, and changing it needs a new native build. Apple treats tracking inside a webview used for app functionality like native tracking.

If you don't actually track: remove ATT and fix your labels

Many apps rejected under 5.1.2 never track anyone: crash data was marked as used for tracking, or a plugin added the ATT key. Adding a prompt "just in case" isn't the fix; Apple's rejection explicitly offers correcting your labels instead.

1. In App Privacy, answer "No" to the tracking question for each data type, keep the types you still collect (for example Crash Data for App Functionality) and click Publish.
2. Remove NSUserTrackingUsageDescription and every ATT request, including plugin code.
3. Swap SDK variants that can read the IDFA. Firebase says its SDKs don't access the IDFA themselves, though some Google Analytics integrations may. Its docs recommend the FirebaseAnalyticsCore Swift package (CocoaPods: FirebaseAnalytics/Core) to install Analytics without IDFA collection; the older WithoutAdIdSupport variants were removed in Firebase 12.
4. Turn off ad personalization in SDK dashboards and drop the AdSupport framework if nothing uses it.
5. Confirm in a new Privacy Report that no SDK sets NSPrivacyTracking to true.

If your ad network personalizes ads across apps, keep ATT and serve non-personalized ads to people who decline. For campaign measurement without tracking permission, look at Apple's privacy-preserving attribution frameworks, AdAttributionKit and SKAdNetwork.

Pre-prompt screens, incentives and gating: what's allowed

You may explain tracking before the system alert, as long as you're transparent about the data use. The rules come from Apple's Human Interface Guidelines, Guideline 5.1.1(iv) and 5.1.2(i):

Google states that accepting the ATT prompt doesn't count as consent under its EU user consent policy for personalized ads, so apps serving EU users often need both a consent message and the ATT alert, shown in a clear sequence. The reverse also applies: Apple requires you to respect the ATT answer even if a consent tool says otherwise, so a "yes" in your consent banner never overrides "Ask App Not to Track".

How to respond to App Review

Reply in the App Review section of your app in App Store Connect and repeat the key facts in the review notes of your next submission.

• Labels-only fix: App Privacy answers can be changed without an app update, so explain that the app doesn't track and ask for a re-review. If the build still contains NSUserTrackingUsageDescription, remove it in a new build.
• ATT added or fixed: upload a new build and state the screen where the alert appears, the iOS version you tested on and a link to a screen recording.
• Pre-prompt or incentive fix: describe what you removed and attach a screenshot.

If the reviewer treated first-party analytics as tracking, quote Apple's definition in your reply. If that fails, you can appeal to the App Review Board.

How to prevent 5.1.2 rejections next time

• CI consistency check: after archiving, check the built Info.plist for NSUserTrackingUsageDescription and bundled manifests for NSPrivacyTracking, compare both with a "tracks: yes/no" flag that mirrors your App Privacy answers, and fail the pipeline on a mismatch.
• SDK update review: diff the Privacy Report whenever you bump an ads, analytics or attribution SDK.
• UI test: on a fresh simulator, assert that the tracking alert appears; query it through the Springboard app in XCUITest.
• One inventory, both stores: the same audit feeds your privacy manifests and your Google Play Data safety form.

AI-assisted checks are good at scanning dependencies and drafting App Privacy answers, but a human should confirm what each SDK actually sends. For a second opinion, book a free consultation call. appsubmitter.io can also build these checks into your CI/CD pipeline and handle the resubmission via the order wizard; code changes are discussed and quoted upfront.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App Name] [version] (build [build number]). We have resolved the Guideline 5.1.2 issue:

[If the app does not track]
- [App Name] does not track users as defined by Apple: we don't link app data with third-party data for advertising or advertising measurement, and we don't share data with data brokers.
- Our App Privacy information has been updated and published. We collect [data types] only for [purpose].
- Build [build number] no longer contains an App Tracking Transparency request.

[If the app tracks]
- The App Tracking Transparency request now appears [on first launch, after the welcome screen], before any data used for tracking is collected.
- [SDK names] start only after the user responds. If tracking is declined, the app remains fully functional.
- We removed [the "Allow" button / the reward for allowing tracking] from our explanation screen.

To verify: install the app fresh on a device with Settings > Privacy & Security > Tracking > "Allow Apps to Request to Track" enabled, then [steps]. Screen recording: [link]

Best regards,
[Your name], [Company]

Checklist before you resubmit

• Your App Privacy answers match whether the app tracks under Apple's definition.
• The Xcode Privacy Report shows no SDK declaring tracking that your labels don't reflect.
• If you track: NSUserTrackingUsageDescription is present, specific and localized.
• If you don't track: the key and all ATT requests are gone from the release build, including plugins.
• The ATT request runs only while the app is active and the status is notDetermined.
• On a fresh install on both an iPhone and an iPad, the alert appears on a screen every reviewer reaches.
• No SDK sends identifiers before the user has answered the alert.
• The app works fully after "Ask App Not to Track", and nothing is rewarded for allowing it.
• Any pre-prompt screen has one "Continue" or "Next" button, no "Allow" wording and no close option.
• Data shared with third parties, including AI providers, is disclosed and explicitly permitted.

Frequently asked questions

Official source: App Store Review Guidelines – 5.1.2 Data Use and Sharing. Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.