Docs

iOS Privacy Manifest Tracking Compliance

How to track and audit NSPrivacyTracking declarations so your analytics SDK doesn't get your iOS app flagged or rejected.

Analytics

Apple’s PrivacyInfo.xcprivacy manifest is no longer a box-ticking exercise — enforcement is strict enough in 2026 that a missing or inaccurate NSPrivacyTrackingDomains entry can get a binary rejected or an existing app flagged for review. For teams running Firebase, Mixpanel, Amplitude, or any ad-attribution SDK, that means every domain those tools call out to has to be declared, accurate, and kept in sync every time a vendor changes its endpoints.

The problem most teams hit isn’t ignorance of the requirement — it’s drift. The manifest gets filled in correctly once, at integration time, and then nobody revisits it as SDKs update, add new domains, or introduce features that trigger a “required reason” API. Six months later the declared privacy surface no longer matches what the app actually does, and that gap is exactly what App Review and automated scanning tools are built to catch.

Data Points to Track

  • Declared tracking domains vs. observed network calls: a periodic diff between what’s listed in NSPrivacyTrackingDomains and the domains your app’s SDKs actually connect to at runtime
  • SDK version and manifest version pairing: which version of each third-party SDK was installed when the manifest was last updated, so version bumps trigger a review
  • Required-reason API usage: every call to an API covered by Apple’s required-reason list (e.g. file timestamp APIs, UserDefaults), tagged with the SDK responsible
  • NSPrivacyTracking flag status: whether the manifest correctly marks the app as engaging in tracking, matched against actual ATT (App Tracking Transparency) prompt usage
  • App Store Connect rejection or warning history: logged against the manifest version in place at the time, to correlate compliance gaps with review outcomes

Setup Steps

  1. Generate a baseline manifest for the current build using Xcode’s built-in privacy report or a third-party auditing tool, and store it alongside the app’s version history.
  2. Add an automated CI check that flags any new outbound domain in a release build that isn’t already declared in NSPrivacyTrackingDomains.
  3. Subscribe to changelog or release notes for every analytics and ad SDK in use, since vendors are required to publish their own privacy manifests that your app’s manifest should reference or match.
  4. Re-run the domain diff and required-reason audit on every SDK version bump, not just on major app releases.
  5. Document the ATT prompt trigger conditions alongside the manifest so tracking declarations and actual user-facing consent stay aligned.

Actionable Insights

Treating the privacy manifest as a living artefact rather than a one-time form is what actually prevents review friction. The domain diff is the single highest-value check here: it turns “did a vendor quietly add a new tracking endpoint” from a surprise rejection email into a routine CI failure you catch before submission. Teams that automate this rarely see manifest-related rejections; teams that fill it in once and forget it are the ones getting flagged months later for drift they didn’t know existed.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert