# ITMS-91064 : corriger « Invalid tracking information »

> ITMS-91064 Invalid tracking information : ce que l'erreur veut dire, pourquoi le manifeste de confidentialité est refusé et comment le corriger dans une app Expo.

Page originale : [ITMS-91064 : corriger « Invalid tracking information »](https://devoria.fr/blog/itms-91064-invalid-tracking-information)
Auteur : [Mehdi Azizi](https://devoria.fr/mehdi-azizi)
Publication : 2026-10-16
Dernière révision du contenu : 2026-10-16


ITMS-91064 est un refus automatique d'Apple, envoyé par e-mail après la livraison de ton build. Il veut dire que les deux clés de suivi de ton manifeste de confidentialité se contredisent. **La correction : mettre `NSPrivacyTracking` et `NSPrivacyTrackingDomains` d'accord**, puis refaire un build.

Je l'ai pris sur TradaZen, mon app d'entraînement au trading, après avoir ajouté un outil de mesure publicitaire. Voici la cause et la correction.

## Que veut dire l'erreur ITMS-91064 ?

Le message s'intitule « ITMS-91064: Invalid tracking information ». Il vise un fichier `PrivacyInfo.xcprivacy`, le manifeste de confidentialité que chaque app et chaque SDK peut embarquer. Ce fichier contient notamment deux clés liées au suivi, au sens d'App Tracking Transparency :

- `NSPrivacyTracking` : vrai si l'app ou le SDK utilise des données pour le suivi.
- `NSPrivacyTrackingDomains` : la liste des domaines contactés pour ce suivi.

Apple décrit les trois combinaisons refusées dans sa note technique sur les [manifestes invalides](https://developer.apple.com/documentation/technotes/tn3181-debugging-invalid-privacy-manifest) :

- `NSPrivacyTracking` vaut vrai et la liste des domaines est vide. Il faut remplir la liste. C'était mon cas.
- `NSPrivacyTracking` vaut vrai mais un domaine est mal écrit. Un domaine s'écrit sans chemin ni barre finale.
- Des domaines sont listés alors que `NSPrivacyTracking` vaut faux. Il faut retirer la liste.

La règle de fond est dans la documentation sur les [manifestes de confidentialité](https://developer.apple.com/documentation/bundleresources/privacy-manifest-files) : quand `NSPrivacyTracking` vaut vrai, il faut fournir la liste des domaines.

**L'e-mail d'Apple donne le nom et le chemin du fichier fautif.** Lis ce chemin : il dit si le problème vient du manifeste de ton app ou de celui d'un SDK embarqué.

Comme pour les autres erreurs ITMS, ce n'est pas le refus d'un reviewer. Le contrôle est automatique, à la livraison du build, et le build est écarté.

## Pourquoi ça arrive : un manifeste par cible

C'est le piège. Un SDK embarque souvent son propre manifeste, avec ses domaines. Tu pourrais croire que c'est suffisant. Mais ton app a aussi le sien, et **c'est celui de l'app qu'Apple a refusé chez moi**.

Mon cas, le 21 juillet 2026. En branchant un outil de mesure publicitaire sur TradaZen, j'avais déclaré `NSPrivacyTracking: true` dans la configuration de l'app, ce qui est exact. Mais je n'avais pas ajouté `NSPrivacyTrackingDomains`. Le manifeste du SDK était complet. Celui de l'app, généré par Expo à partir de ma configuration, disait « vrai » avec une liste vide. Le build a été refusé au traitement.

**La leçon** : le manifeste du SDK ne couvre pas celui de ton app. Si tu déclares du suivi dans ta configuration, tu déclares aussi les domaines.

## Corriger ITMS-91064 dans une app Expo

Avec Expo, le manifeste de l'app se règle dans la configuration, sous `ios.privacyManifests`. Le principe est dans la [documentation d'Expo sur la confidentialité](https://docs.expo.dev/guides/apple-privacy/), et la clé dans la [référence de configuration](https://docs.expo.dev/versions/latest/config/app/).

1. **Retrouve les domaines de suivi du SDK.** Recopie la liste du manifeste de la version que ton build embarque, pas celle de la dernière version en ligne : elles peuvent différer. Ne les invente pas.
2. **Ajoute-les à ta configuration.** Les deux domaines ci-dessous sont des exemples à remplacer :

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

3. **Vérifie le fichier généré avant de payer un build**, si ton dossier `ios` est généré par Expo et ignoré par git. Lance `npx expo prebuild -p ios`, puis ouvre le fichier `PrivacyInfo.xcprivacy` créé dans le dossier `ios`. Il doit contenir `NSPrivacyTracking` à `true` et la liste complète des domaines.
4. **Refais un build et renvoie-le.** Le manifeste fait partie du binaire : une mise à jour à distance ne le modifie pas.

Attention à l'étape 3 : cette commande peut supprimer puis recréer le dossier `ios`. Si tu y as fait des modifications à la main, ne la lance pas sur ton projet. Travaille sur une copie.

Si ton app ne fait aucun suivi, le chemin est plus court : passe `NSPrivacyTracking` à `false` et retire la liste.

## Ce que ces domaines changent pour tes utilisateurs

Déclarer ces domaines n'est pas une formalité. D'après la documentation d'Apple, si l'utilisateur n'a pas accepté le suivi dans la fenêtre d'App Tracking Transparency, les requêtes vers ces domaines échouent. C'est le comportement attendu : le suivi ne part que si la personne a dit oui.

Ta fiche App Store doit raconter la même chose. Si ton manifeste déclare du suivi, les déclarations de confidentialité de ta fiche et ta politique de confidentialité doivent le dire aussi. Sinon tu risques ensuite le refus d'un reviewer, au titre des guidelines 5.1.1 ou 5.1.2 : le détail est dans [politique de confidentialité d'une application](https://devoria.fr/blog/politique-confidentialite-app-ios).

## Envoyer ton build sans mauvaise surprise

Les erreurs ITMS se corrigent vite quand on sait les lire. Les refus qui viennent ensuite demandent plus de recul : la démarche est sur la page [application refusée par Apple](https://devoria.fr/expertise/application-refusee-par-apple), et les motifs les plus fréquents sont dans [pourquoi Apple refuse une app](https://devoria.fr/blog/pourquoi-apple-refuse-votre-app).

Pour vérifier ton dossier avant l'envoi, le [Kit Review Apple](https://devoria.fr/kits/review-apple) réunit ma checklist et des skills Claude Code qui relisent ton projet. Si ton envoi bloque et que tu veux un regard humain, [réserve une heure avec moi](https://devoria.fr/coaching) : on reprend ton projet en visio, sur ton écran. Et si tu prépares ta première sortie, [fais ton diagnostic gratuit](https://devoria.fr/diagnostic) : il remet les étapes dans l'ordre et t'envoie ma checklist anti-refus Apple.

## Questions fréquentes

### ITMS-91064 est-il un refus d'App Review ?

Pas au sens d'un reviewer humain. C'est un contrôle automatique fait sur le build à sa livraison, avant la mise en revue. Le build est écarté : il faut corriger le manifeste de confidentialité et envoyer un nouveau build.

### Que faut-il mettre dans NSPrivacyTrackingDomains ?

Les domaines que ton app ou tes SDK contactent pour le suivi. Recopie ceux que le SDK liste dans le manifeste de la version que ton build embarque. Une liste vide avec `NSPrivacyTracking` à `true` fait partie des combinaisons qu'Apple refuse.

### Le manifeste de mon SDK ne suffit-il pas ?

Non. Sur TradaZen, le manifeste du SDK était complet et le build a quand même été refusé : celui de l'app déclarait du suivi sans aucun domaine. Si la configuration de ton app déclare du suivi, elle doit aussi lister les domaines.

### Mon app ne fait pas de suivi : que faire ?

Passe `NSPrivacyTracking` à `false` dans ta configuration et retire la liste des domaines. Vérifie ensuite que ta fiche App Store et ta politique de confidentialité disent bien la même chose.

### Peut-on corriger ITMS-91064 sans refaire un build ?

Non. Le manifeste de confidentialité fait partie du binaire envoyé à Apple. Il faut corriger la configuration, refaire un build et le renvoyer.


## Ton projet

[Kit Review Apple](https://devoria.fr/kits/review-apple) : Tout ce que je vérifie avant d'envoyer une app à Apple, et deux skills qui font la relecture avec Claude Code. 29 €, paiement unique. Inclus : La checklist avant l'envoi ; Les refus que j'ai pris, et ce que j'ai corrigé ; Les notes pour le testeur ; Les skills de vérification. Prérequis : une app iPhone presque prête et Claude Code ou Cursor. Téléchargement immédiat après le paiement.

[Kit iOS Devoria](https://devoria.fr/kits/ios) : Le code de départ de mes apps, le parcours avec les messages à donner à Claude, et tous les kits. Claude part d'une app qui tourne déjà. 129,99 €, paiement unique. Inclus : Le code de départ de ton app ; Les styles visuels ; Le parcours pas à pas ; Kit Review Apple ; Kit Captures ; Kit ASO ; 1 an de mises à jour ; Bonus : la séance 1:1 à moitié prix. Prérequis : un Mac avec Xcode 26 ou plus, Claude Code (abonnement payant) ou Cursor, et un compte Apple Developer (99 $ par an) pour publier. Téléchargement immédiat après le paiement.

[Diagnostic gratuit](https://devoria.fr/diagnostic) : quelques questions sur ton projet. Il dit ce qui te bloque vraiment, l'ordre des quatre étapes et le kit qui correspond. En laissant ton e-mail, tu reçois la checklist anti-refus Apple : les points vérifiés avant chaque envoi, tirés des refus reçus par les apps du studio.

[Une heure avec moi](https://devoria.fr/coaching) : On regarde ton app ou ton projet Claude, écran partagé : ce qui bloque, ce que je change en premier, et dans quel ordre. 100 € la séance d'une heure, en visio, paiement en une fois. Sujets : L'audit de ton app ; Ton travail avec Claude ; Ta fiche et ton paywall ; Un refus d'Apple.