Pass App Review when your app may need tracking permission
Tracking risk often hides in attribution and advertising integrations. The question is not whether the app displays ads; it is whether data is linked with third-party data for tracking as Apple defines it.
Inventory identifiers and data sharing before deciding whether to show the App Tracking Transparency prompt. Apple policy governs tracking and permission; AppReviewReady interpretation is that teams should prove the negative when they claim no tracking, especially after adding ad, attribution, analytics, or data-broker integrations.
Apply Apple's tracking question to each data flow
Apple's privacy materials focus on tracking users across apps and websites owned by other companies. That means the review question can involve device identifiers, advertising identifiers, account identifiers, email hashes, events, purchases, or other signals when they are combined with third-party data for tracking.
Do not reduce the decision to a single SDK name. The same vendor can be configured for measurement, diagnostics, ads, or cross-app attribution. Document the configuration actually shipped in the release candidate and the business purpose that uses the data.
Make the permission prompt testable and honest
- Request permission only at a moment when the user can understand why the app is asking.
- Keep the system prompt text and any pre-prompt explanation consistent with actual data use.
- Do not gate core app functionality behind granting tracking permission unless the feature truly requires it.
- Test the denied, allowed, not-determined, and restricted states on a clean device.
- Confirm the app does not start tracking before permission when permission is required.
Reconcile ATT, privacy labels, and SDK behavior
The ATT decision should match App Store privacy details. If the app says data is used for tracking, the runtime behavior and prompt strategy should support that statement. If the app says no tracking occurs, the SDK inventory should explain why advertising, attribution, or analytics code does not cross the tracking line.
This is an AppReviewReady interpretation layer, not extra Apple policy: maintain a tracking matrix with columns for data element, recipient, purpose, linked identifier, third-party combination, permission state, and code owner. It prevents teams from arguing from memory during review.
Show App Review the path without forcing real ad behavior
- Install the submitted build on a device with reset privacy state.
- Navigate to the screen that triggers the prompt or document why the release does not prompt.
- Capture the expected behavior after Allow and Ask App Not to Track.
- Verify ad, attribution, analytics, and personalization SDKs respect the recorded permission state.
- Place a concise explanation in Review Notes only when the reviewer needs a non-obvious path to observe the prompt.
Reply to a tracking rejection with the data flow
A persuasive reply does not say only that the team follows ATT. It identifies the contested data flow and explains the correction. If a vendor integration was misconfigured, name the configuration change and resubmit the build or metadata that actually changed.
Tracking review response: Data involved: [identifier/event/profile field] Recipient or SDK: [name and configuration] Purpose: [ads, attribution, analytics, fraud, app functionality] Permission behavior: [when ATT prompt appears or why it does not apply] Privacy details updated: [yes/no and field] Verification: [device, OS, permission states tested]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check tracking risk
Review ATT, privacy labels, SDKs, and reviewer evidence together.
Open the tool