App Tracking Transparency: The ATT Checks That Get Apps Rejected

Why "tracking without permission" rejections come straight from the binary

If your app reaches for the IDFA or bundles an advertising SDK, Apple expects an App Tracking Transparency prompt — and Guideline 5.1.2(i) is one of the most common privacy rejections when that prompt is missing or wired up wrong. The good news: every signal Apple looks for is already sitting in your compiled binary, so this is catchable before you upload.

What does App Tracking Transparency require?

ATT governs tracking — linking user or device data you collect to third-party data for advertising, or sharing it with a data broker. If your app tracks, three things must be true:

1. NSUserTrackingUsageDescription is present in your Info.plist and explains, in plain language, why you want to track.
2. Your app calls ATTrackingManager.requestTrackingAuthorization and shows the prompt before any tracking begins.
3. If the user denies, you do not access the IDFA and you do not track.

<!-- Info.plist: required whenever your app tracks -->
<key>NSUserTrackingUsageDescription</key>
<string>We use your activity to measure ad performance and improve recommendations.</string>

Which signals trigger a 5.1.2 rejection?

The classic rejection is a contradiction inside the build: a tracking SDK is linked in, the binary can reach the IDFA, but there is no prompt and no usage string. To a reviewer that reads as "this app tracks without asking." To a pre-submission scan it reads the same way, because all of it is statically present:

Signal in the binary	What it means
AppTrackingTransparency framework linked	The app can prompt — confirm that it does
NSUserTrackingUsageDescription missing/empty	No valid prompt copy — likely rejection if tracking
IDFA access (ASIdentifierManager)	Tracking identifier in use — ATT required
Ad / attribution / social SDKs present	Third-party tracking — ATT almost certainly required

When a tracking SDK is present but the prompt machinery is not, that is a detectable inconsistency to fix before submission — not after a rejection.

Is ATT the same as the privacy manifest?

No, and conflating them is a common mistake:

• App Tracking Transparency is runtime consent — the prompt, gated on NSUserTrackingUsageDescription.
• The privacy manifest (PrivacyInfo.xcprivacy) is a declaration of data use and required-reason API access, validated separately.

Both can independently flag or block a submission. An app can have a perfect privacy manifest and still get rejected for tracking without an ATT prompt — and both should agree with your App Privacy label.

AppCompliance detects ATT signals in the binary — the framework, the usage string, IDFA access, and the tracking SDKs that imply tracking — and can gate the check in CI. Whether your app tracks is a product decision; declaring it correctly is a technical one, and the technical part is fully checkable before you submit.

Summary

• If the binary links an ad/attribution/social SDK, decide whether the app tracks under Apple's definition.
• If it tracks: NSUserTrackingUsageDescription is present, specific, and honest.
• The ATT prompt fires before any IDFA access or tracking call.
• Denied authorization actually suppresses tracking — not just the prompt.
• ATT, the privacy manifest, and your App Privacy label all tell the same story.