ITMS-91064: fix “Invalid tracking information”

ITMS-91064 is an automatic rejection from Apple, sent by email after you deliver your build. It means the two tracking keys in your privacy manifest contradict each other. The fix: make NSPrivacyTracking and NSPrivacyTrackingDomains agree, then run a new build.

I hit it on TradaZen, my trading practice app, after adding an ad measurement tool. Here's the cause and the fix.

What does the ITMS-91064 error mean?

The message is titled "ITMS-91064: Invalid tracking information". It points to a PrivacyInfo.xcprivacy file, the privacy manifest that every app and every SDK can ship. Among other things, this file holds two keys related to tracking, in the App Tracking Transparency sense:

• NSPrivacyTracking: true if the app or SDK uses data for tracking.
• NSPrivacyTrackingDomains: the list of domains contacted for that tracking.

Apple describes the three rejected combinations in its technical note on invalid manifests:

• NSPrivacyTracking is true and the domain list is empty. You need to fill in the list. That was my case.
• NSPrivacyTracking is true but a domain is badly written. A domain is written without a path or trailing slash.
• Domains are listed while NSPrivacyTracking is false. You need to remove the list.

The underlying rule is in the documentation on privacy manifests: when NSPrivacyTracking is true, you must provide the list of domains.

Apple's email gives the name and path of the faulty file. Read that path: it tells you whether the problem comes from your app's manifest or from an embedded SDK's.

Like other ITMS errors, this isn't a rejection from a reviewer. The check is automatic, at build delivery, and the build is discarded.

Why it happens: one manifest per target

Here's the trap. An SDK often ships its own manifest, with its domains. You might think that's enough. But your app has its own too, and in my case, it was the app's manifest that Apple rejected.

My case, July 21, 2026. When I hooked an ad measurement tool into TradaZen, I declared NSPrivacyTracking: true in the app's configuration, which is accurate. But I hadn't added NSPrivacyTrackingDomains. The SDK's manifest was complete. The app's, generated by Expo from my configuration, said "true" with an empty list. The build was rejected during processing.

The lesson: the SDK's manifest doesn't cover your app's. If you declare tracking in your configuration, you declare the domains too.

Fixing ITMS-91064 in an Expo app

With Expo, the app's manifest is set in the configuration, under ios.privacyManifests. The principle is in Expo's privacy documentation, and the key is in the configuration reference.

1. Find the SDK's tracking domains. Copy the list from the manifest of the version your build ships, not the latest version online: they can differ. Don't make them up.
2. Add them to your configuration. The two domains below are examples to replace:

{
  "expo": {
    "ios": {
      "privacyManifests": {
        "NSPrivacyTracking": true,
        "NSPrivacyTrackingDomains": [
          "exemple-domaine-de-suivi.com",
          "autre-domaine-de-suivi.com"
        ]
      }
    }
  }
}

3. Check the generated file before paying for a build, if your ios folder is generated by Expo and ignored by git. Run npx expo prebuild -p ios, then open the PrivacyInfo.xcprivacy file created in the ios folder. It should contain NSPrivacyTracking set to true and the full list of domains.
4. Rebuild and resubmit. The manifest is part of the binary: an over-the-air update doesn't change it.

Careful with step 3: this command can delete and recreate the ios folder. If you made manual changes in there, don't run it on your project. Work on a copy.

If your app does no tracking, the path is shorter: set NSPrivacyTracking to false and remove the list.

What these domains change for your users

Declaring these domains isn't a formality. According to Apple's documentation, if the user hasn't accepted tracking in the App Tracking Transparency prompt, requests to these domains fail. That's the expected behavior: tracking only goes out if the person said yes.

Your App Store listing has to tell the same story. If your manifest declares tracking, your listing's privacy declarations and your privacy policy must say so too. Otherwise you risk a reviewer rejection later, under guidelines 5.1.1 or 5.1.2: the details are in privacy policy for an app.

Sending your build without nasty surprises

ITMS errors are quick to fix once you know how to read them. The rejections that come after need more perspective: the approach is on the app rejected by Apple page, and the most common reasons are in why Apple rejects an app.

To check your submission before sending it, the Apple Review Kit bundles my checklist and Claude Code skills that review your project. If your submission is stuck and you want a human eye on it, book an hour with me: we go through your project on a video call, on your screen. And if you're preparing your first release, take the free diagnostic: it puts the steps in order and sends you my Apple anti-rejection checklist.

Frequently asked questions

Is ITMS-91064 an App Review rejection?

Not in the sense of a human reviewer. It's an automatic check run on the build when it's delivered, before it goes into review. The build is discarded: you need to fix the privacy manifest and send a new build.

What should go in NSPrivacyTrackingDomains?

The domains your app or your SDKs contact for tracking. Copy the ones the SDK lists in the manifest of the version your build ships. An empty list with NSPrivacyTracking set to true is one of the combinations Apple rejects.

Isn't my SDK's manifest enough?

No. On TradaZen, the SDK's manifest was complete and the build was still rejected: the app's manifest declared tracking without any domain. If your app's configuration declares tracking, it must also list the domains.

My app doesn't do any tracking: what should I do?

Set NSPrivacyTracking to false in your configuration and remove the domain list. Then check that your App Store listing and your privacy policy say the same thing.

Can you fix ITMS-91064 without a new build?

No. The privacy manifest is part of the binary sent to Apple. You need to fix the configuration, rebuild and resubmit.