Question about NSPrivacyTrackingDomains resolution after re-submitting build (Girls vs Boys Tapping v1.1.2)

Hi everyone,

I’m looking for some clarification regarding Privacy Manifest requirements (PrivacyInfo.xcprivacy) after resolving a validation issue on my latest submission.

In my previous build, I ran into an issue related to NSPrivacyTracking and NSPrivacyTrackingDomains. I updated the manifest to ensure NSPrivacyTracking is set to <true/> alongside our App Tracking Transparency (ATT) prompt, and restricted NSPrivacyTrackingDomains strictly to the required ad service endpoints (googleadservices.com, googlesyndication.com, doubleclick.net, etc.), removing any broad domains.

I have just submitted the corrected build:

• App Name: Girls vs Boys Tapping

• Version: 1.1.2

• Build: 112

• Apple ID: 6809284204

• Status: Waiting for Review

Since this is my first time submitting with the updated privacy manifest format after resolving that error, my question is:

Once the build enters the review queue with these specific tracking domains and ATT configured, does App Review require any additional documentation in the review notes regarding the ad network tracking domains, or is the .xcprivacy file inside the bundle sufficient for automated validation and review?

Just want to make sure everything is 100% in order so there are no unexpected hold-ups while it's in the queue.

Thanks in advance for any insights!

Answered by DTS Engineer in 904496022

@ToDoApp

Thanks for the question, I always encourage you to contact App Review if you have a questions for them as I do not work on that team nor I can speak about their policies. However I believe App Review does not strictly require additional documentation in the App Review notes regarding your ad network tracking domains. The .xcprivacy file inside your app bundle, combined with your matching App Store Connect "App Privacy" questionnaire, is sufficient.

Since your last build was successfully processed and is currently "Waiting for Review," it has already passed automated static analysis. If there were formatting issues with NSPrivacyTracking or NSPrivacyTrackingDomains, the build would have been flagged or rejected during the upload/processing phase with an ITMS warning or error.

The review team will let you know if there are issues with the implementation. They will check that your NSUserTrackingUsageDescription string explains why you are requesting tracking, I suggest you wait for their comments and address them.

It sounds like you have covered all your bases thoroughly. Good luck with the review process!

App Review contact https://developer.apple.com/contact/#!/topic/select

App Review FAQ https://developer.apple.com/forums/thread/810791

Albert  WWDR

Quick update while waiting in the queue:

I did some additional testing on our test devices to verify edge cases with the ATT prompt and the declared tracking domains.

Specifically, I confirmed that when a user selects "Ask App not to Track", all network calls to the declared ad tracking domains (googleadservices.com, doubleclick.net, etc.) are properly bypassed, and the game gracefully falls back to non-personalized delivery without any network exceptions or gameplay interruptions.

The app is already fully approved, live, and running smoothly on Android / Google Play with this identical ad setup and policy structure, so we are confident in the stability of the implementation.

I also double-checked that our App Store Connect "App Privacy" questionnaire answers align 1:1 with the .xcprivacy manifest inside Build 112.

I'll update this thread once the submission finishes review in case anyone else encountering the same NSPrivacyTrackingDomains configuration finds it helpful!

Accepted Answer

@ToDoApp

Thanks for the question, I always encourage you to contact App Review if you have a questions for them as I do not work on that team nor I can speak about their policies. However I believe App Review does not strictly require additional documentation in the App Review notes regarding your ad network tracking domains. The .xcprivacy file inside your app bundle, combined with your matching App Store Connect "App Privacy" questionnaire, is sufficient.

Since your last build was successfully processed and is currently "Waiting for Review," it has already passed automated static analysis. If there were formatting issues with NSPrivacyTracking or NSPrivacyTrackingDomains, the build would have been flagged or rejected during the upload/processing phase with an ITMS warning or error.

The review team will let you know if there are issues with the implementation. They will check that your NSUserTrackingUsageDescription string explains why you are requesting tracking, I suggest you wait for their comments and address them.

It sounds like you have covered all your bases thoroughly. Good luck with the review process!

App Review contact https://developer.apple.com/contact/#!/topic/select

App Review FAQ https://developer.apple.com/forums/thread/810791

Albert  WWDR

Thank you so much, Albert! Really appreciate the clear explanation and reassurance regarding the .xcprivacy manifest and the automated analysis.

We double-checked our NSUserTrackingUsageDescription string to ensure it clearly and transparently explains why tracking authorization is requested (to serve relevant ads and support free gameplay).

Everything is set on our end for Girls vs Boys Tapping (v1.1.2 - Build 112), so we will patiently await the review team's evaluation.

Thanks again for your time and guidance!

Quick follow-up question for the community:

Our build (Girls vs Boys Tapping v1.1.2 - Build 112) is still currently showing as "Waiting for Review".

For those who have submitted updates recently with the new privacy manifest declarations, are you seeing standard 24–48h queue times, or are review queues taking a bit longer this week?

Just want to make sure this is the normal pace right now and that no additional action is required on our end while we wait. Thanks!

Question about NSPrivacyTrackingDomains resolution after re-submitting build (Girls vs Boys Tapping v1.1.2)
 
 
Q