Stop the Lite manifest from claiming tracking it cannot name - #134
Merged
Conversation
Build 43 of the Lite app came back ITMS-91064 Invalid Binary: its PrivacyInfo.xcprivacy set NSPrivacyTracking to true while NSPrivacyTrackingDomains was empty, which App Review rejects. The Pro manifest passed the same upload with false and an empty list. The manifests only landed in #107, after 1.35 shipped, so this file had never been through App Store validation before. Listing the AdMob endpoints would satisfy the rule but cost more than it buys: iOS blocks the domains named here whenever ATT authorization is missing, so it would also cut off the non-personalized ads served to users who decline. The Google SDKs ship no domains of their own for that reason, and GoogleMobileAds already marks DeviceID as tracking in its own manifest, which Apple aggregates with this one. Also corrects the 1.37 release notes to the copy actually submitted: 1.36 was tagged but never went to the store, so the store jumps 1.35 to 1.37 and the notes have to cover the 1.36 work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019sHnwXJEjogZDLATrBgMQS
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Build 43 of the Lite app came back ITMS-91064 / Invalid Binary: its
PrivacyInfo.xcprivacysetNSPrivacyTrackingtotruewhileNSPrivacyTrackingDomainswas empty, which App Review rejects. Pro passed the same upload withfalseand an empty list, so this mirrors it.The manifests only landed in #107, after 1.35 shipped, so this file had never been through App Store validation before — 1.37 build 43 was its first upload.
Why not just list the AdMob domains
That would satisfy the rule but cost more than it buys. iOS blocks the domains named in
NSPrivacyTrackingDomainswhenever ATT authorization is missing, so listing the AdMob endpoints would also cut off the non-personalized ads served to users who decline the prompt. The Google SDKs ship no domains of their own for that reason, andGoogleMobileAdsalready marksDeviceIDasNSPrivacyCollectedDataTypeTrackingin its own manifest, which Apple aggregates with this one. The tracking disclosure is still made.Verified against the shipped artifacts from run 30767906998, not just the source:
NSPrivacyTrackingNSPrivacyTrackingDomainsfalsetrueAlso
Corrects
1.37.txtto the copy actually submitted. 1.36 was tagged but never reached the store, so App Store Connect jumps 1.35 → 1.37 and the notes have to cover the 1.36 work.Pro 1.37 (build 43) is unaffected and still Waiting for Review. Lite needs a new build from this branch.
🤖 Generated with Claude Code