There is a comfortable mistake in ad-supported apps: treat every consent prompt as one privacy surface. The player sees a GDPR or UMP form, makes a choice, and the app records a consent state. From the product point of view that feels like the privacy work happened. From Apple's point of view, if data is used to track the user, that is not enough. The App Tracking Transparency framework has its own permission request, its own timing rule and its own review expectation.
The release blocker is usually not that ATT was never added. It is that it is not visible in the reviewable path. A prompt hidden behind a country branch, a previous local decision, a delayed ad initialization, a debug-only path, or a settings screen the reviewer never reaches is functionally absent. Review does not read intent. It launches the app on a fresh install and looks for the system permission before tracking data can be collected.
That creates a strict ordering contract. If the app declares tracking in App Store Connect, it has to request ATT before collecting data used for tracking. If GDPR applies, the GDPR flow can still run, but it does not replace ATT. If the app does not track, the store privacy declaration must say that instead, and the ad stack must be configured consistently. The dangerous middle is declaring tracking, showing a custom consent form, and assuming the system prompt is optional because another consent decision exists.
The implementation shape should be explicit. On first launch, before ad SDKs are allowed to request identifiers or personalized demand, resolve the regional consent requirements. Present the GDPR or UMP form where applicable. Then, when tracking is still possible and the system status is not determined, request ATT. Only after those gates settle should the ad eligibility service decide what kind of request may be made. Settings then need a visible place to revisit privacy choices: manage GDPR consent where the CMP permits it, link to system tracking settings for ATT, and display the current state without pretending the app can override an OS-level denial.
The test has to be physical-device oriented because review is. Reset tracking permissions or use a fresh install. Launch. Record the GDPR flow if it appears. Record the ATT system sheet appearing before ad collection. Continue into the app. Include that recording in review notes with the exact screen path. A unit test that mocks an ATT status is useful, but it does not answer the reviewer's complaint: we could not locate the permission request on this OS and device.
There is one more discipline point: do not solve an ATT rejection by hiding the prompt behind a more aggressive first-run wall. Consent is not a conversion funnel. The app still has to work after refusal, with non-personalized or limited ads where supported and no tracking where permission was denied. The refusal path is part of the product, not an edge case.
The release rule is blunt because it needs to be. If an app declares tracking, ATT is a release blocker. Not legal copy, not a settings preference, not a nice-to-have. A prompt the reviewer cannot find is the same as no prompt.
Notes
This post is part of the recovered daily-publisher backlog after the site publication service drifted and stopped producing dated blog results. It is intentionally written as an engineering note, not as a legal, financial, or store-policy guarantee.
Keep reading: all posts on the WizusLabs Engineering blog.