Que faire si App Store Connect indique que PrivacyInfo.xcprivacy est invalide ? (2026)

Apple indique que les notifications liées à un manifeste de confidentialité invalide peuvent préciser le nom du fichier et son chemin dans l’archive (TN3181). App Store Connect PrivacyInfo.xcprivacy invalide : partez de ce chemin, déterminez si le fichier appartient à l’app, à un Swift Package ou à un SDK, corrigez sa source, puis recréez et validez l’archive Xcode. Ne supprimez pas un manifeste au hasard et ne recopiez pas les déclarations d’un composant dans celui de l’app.

Cette procédure s’adresse aux développeurs indépendants qui ont reçu une notification et doivent localiser le fichier en cause.
Elle concerne aussi les petites équipes qui intègrent ou mettent à jour des SDK tiers.
Enfin, elle vous aide à fiabiliser la préparation d’une archive sur un Mac local ou distant.

Ce que le chemin du manifeste permet de trancher

Le chemin de l’erreur est un indice de responsabilité, pas un simple détail technique. Un fichier situé dans le produit de l’app n’a pas nécessairement la même origine qu’un fichier inclus dans un framework ou un composant livré par une dépendance. Commencez donc par identifier le bundle parent et le target de construction concernés.

Apple distingue les manifestes associés à une app et ceux fournis par des SDK tiers. La documentation sur l’ajout d’un manifeste à une app ou à un SDK est utile pour déterminer cette responsabilité. Les règles de structure et d’emplacement des fichiers de manifeste servent ensuite à comparer l’emplacement attendu au contenu construit.

Cette distinction évite une erreur fréquente : modifier le manifeste de l’application alors que la notification désigne un fichier interne à un SDK. Elle évite aussi de conclure que l’app est exemptée de toute déclaration simplement parce qu’un package ou un fournisseur possède son propre manifeste. Les fichiers sont liés à leurs composants respectifs ; ils ne se remplacent pas les uns les autres.

Autre source de confusion : un manifeste de confidentialité n’est pas l’étiquette de confidentialité affichée sur la fiche App Store. Le premier décrit des usages et des pratiques de collecte selon le format exigé par Apple. L’étiquette est une déclaration distincte destinée à présenter les pratiques de l’app. Modifier l’étiquette ne répare donc pas un fichier de manifeste absent, mal placé ou invalide.

Lorsque le fichier appartient au target de l’app

Si le chemin mène au bundle principal, vérifiez d’abord la configuration du projet plutôt que de réécrire le contenu à l’aveugle. Dans Xcode, repérez le target utilisé pour la distribution et confirmez que PrivacyInfo.xcprivacy est associé à ce target. Un fichier visible dans le navigateur de projet peut ne pas être copié dans le produit final si sa configuration de construction ne l’inclut pas.

Contrôlez également les configurations de compilation utilisées pour l’archive. Un projet peut avoir plusieurs targets, des variantes de marque ou des configurations distinctes pour le développement et la distribution. L’archive soumise peut provenir d’un target différent de celui que vous avez ouvert ou testé dans l’éditeur. Il faut donc relier le fichier au produit réellement construit, pas seulement au nom du projet.

Le contenu doit refléter les pratiques de l’application. Ne recopiez pas dans le manifeste principal les déclarations d’un SDK simplement parce qu’il est inclus dans l’app. Consultez la documentation Apple sur la description des usages de données dans les manifestes pour distinguer les déclarations de données des autres catégories du fichier.

Attention : un manifeste absent et un manifeste invalide sont deux défauts différents. Avant de modifier le contenu, vérifiez si le fichier existe dans l’archive et s’il appartient bien au composant désigné par la notification.

Lorsque la dépendance est un Swift Package

Pour un Swift Package, la présence de PrivacyInfo.xcprivacy dans les sources ne suffit pas à prouver qu’il est livré avec le produit. Vérifiez la configuration des ressources du target concerné et la manière dont Swift Package Manager les traite. Apple explique les règles d’intégration dans sa documentation sur le conditionnement des ressources d’un Swift Package.

Examinez le manifeste de package et les ressources déclarées pour le target qui fournit le code intégré. Puis construisez l’application et contrôlez le produit généré, jusqu’à l’archive. Cela permet de distinguer un fichier oublié dans la configuration d’un problème de contenu. Si la dépendance est indirecte, relevez aussi la version effectivement résolue : le package présent dans votre fichier de dépendances n’est pas toujours suffisant pour identifier le code livré.

Si vous maintenez le package, corrigez la déclaration de ressource à sa source, puis reconstruisez l’application consommatrice. Si le package appartient à un tiers, vérifiez sa documentation et ses notes de version, puis demandez au fournisseur si le manifeste doit être inclus dans une version particulière. Évitez de placer une copie manuelle dans le bundle de l’app pour contourner l’absence du fichier : vous pourriez produire une déclaration qui ne correspond pas au composant concerné.

La vérification doit porter sur l’archive résultante. C’est elle que vous soumettez, et non le répertoire source du package. Si le manifeste n’apparaît toujours pas, comparez le target qui fournit le package, ses ressources configurées et le chemin relevé dans le produit construit. Cette méthode réduit le risque de corriger un fichier local qui n’est jamais utilisé dans la compilation de distribution.

Lorsque la notification désigne un SDK tiers

Si le chemin traverse un framework ou un XCFramework, identifiez précisément le composant. Le nom du dossier parent, le nom du framework et les informations de résolution des dépendances peuvent vous aider à relier le fichier à un SDK et à sa version. Gardez une trace de cette correspondance : elle sera utile pour reproduire le problème ou le signaler au fournisseur.

La responsabilité de la déclaration doit rester auprès du composant concerné. Si l’erreur se trouve dans le manifeste livré par un SDK, commencez par consulter les informations de version du fournisseur et recherchez une mise à jour corrigeant le fichier. Si aucune version corrigée n’est disponible, transmettez au fournisseur le chemin de l’archive et le détail de la validation. Ne déplacez pas automatiquement les entrées dans le manifeste de l’app : cela peut masquer le défaut sans réparer la déclaration du SDK.

Il faut aussi distinguer un problème de contenu d’un problème d’intégration. Un manifeste peut être absent de l’archive parce que le SDK est mal intégré ; il peut aussi être présent mais contenir une entrée qu’Apple ne reconnaît pas comme valide. Suivez l’analyse de TN3181, consacré au diagnostic des manifestes invalides, puis vérifiez la version du composant et son emplacement réel dans le produit.

Dans une petite équipe, cette vérification évite de faire porter à l’application une déclaration que son code n’utilise pas, ou de supprimer une dépendance sans savoir si elle est en cause. Si l’éditeur confirme qu’un correctif est nécessaire, documentez la version remplacée et la version retenue. Vous pourrez ainsi expliquer pourquoi la nouvelle archive diffère de la précédente, au lieu de répéter des changements non traçables.

Lorsque le fichier existe, mais que son contenu est refusé

Suivez l’erreur jusqu’à l’entrée concernée et comparez-la au format Apple en vigueur. Vérifiez la structure, les clés et les valeurs signalées ; ne partez pas du principe qu’un fichier valide en apparence dans un éditeur l’est aussi pour la validation de soumission. La procédure de diagnostic de TN3181 aide à isoler les causes courantes et à relier le message d’erreur à l’entrée à corriger.

Ne confondez pas les déclarations d’API nécessitant une raison avec les déclarations sur l’utilisation ou la collecte de données. Pour les API concernées, la raison doit correspondre à l’usage réel du code et à une valeur actuellement autorisée par Apple. Consultez la liste officielle des API nécessitant une raison et de leurs motifs admis avant de modifier le fichier. N’ajoutez pas une raison par approximation pour faire disparaître une erreur.

Pour les données, décrivez les pratiques effectivement mises en œuvre par votre app ou le composant concerné. La documentation sur la description des usages de données permet de vérifier le sens attendu des déclarations. Si le comportement vient d’un SDK, revenez à son éditeur pour confirmer ce qu’il collecte et comment sa version courante doit être décrite.

Conservez une copie du manifeste initial et notez la modification apportée ainsi que le retour de validation. Cette précaution est particulièrement utile si plusieurs personnes interviennent sur les dépendances ou si le projet comprend des composants audio, vidéo ou graphiques qui utilisent des bibliothèques tierces. Dans ces domaines, une déclaration ne doit pas être déduite du seul nom d’une bibliothèque : vérifiez son comportement réel et sa documentation.

Contrôle de l’archive avant une nouvelle soumission

Une fois la source corrigée, reprenez le processus de construction depuis le projet. Une modification du fichier local ne corrige pas une archive déjà créée. Dans l’organiseur de Xcode, sélectionnez l’archive qui sera distribuée, examinez son contenu et comparez le chemin signalé à la version nouvellement construite. La documentation Apple sur la distribution d’une app pour les versions et les tests décrit le flux d’archive et de validation dans Xcode.

Procédez dans cet ordre :

• [ ] Confirmez le target et la configuration utilisés pour l’archive de distribution.
• [ ] Relevez le chemin complet et le nom du fichier mentionnés dans la notification.
• [ ] Localisez le manifeste dans l’archive sélectionnée, puis identifiez son bundle parent.
• [ ] Vérifiez si le propriétaire est l’app, un Swift Package ou un SDK tiers.
• [ ] Corrigez le fichier à sa source, avec les règles Apple et les usages réels du composant.
• [ ] Créez une nouvelle archive, puis vérifiez à nouveau le fichier et son contenu.
• [ ] Lancez la validation dans Xcode avant de transmettre l’archive.

Évitez d’éditer ou de supprimer un fichier directement dans un paquet déjà archivé pour « réparer » la soumission. Une archive distribuable est signée ; toucher aux éléments du produit peut avoir des conséquences sur la signature. Apple décrit les exigences et le fonctionnement de la signature de code. Si une intervention sur un paquet signé est inévitable, suivez une procédure de reconstruction et de signature conforme plutôt que de supposer qu’une modification manuelle est sans effet.

Une validation réussie ne dispense pas de vérifier que vous avez sélectionné la bonne archive. Dans un projet avec plusieurs branches, configurations ou versions de dépendances, il est possible de valider une ancienne construction par erreur. Notez le commit ou la version du projet, les dépendances intégrées, la modification apportée au manifeste et le résultat de la validation. Ces éléments rendent la correction réexaminable si le même message réapparaît.

Pour préparer une soumission sur un environnement distant, gardez une copie des journaux de construction et des informations de l’archive accessible à l’équipe. Si vous souhaitez établir une procédure d’accès et de contrôle, la documentation d’OsxNode peut vous aider à examiner le fonctionnement d’un Mac distant. Cela ne remplace ni la vérification du paquet ni la validation dans Xcode : le point décisif reste le contenu de l’archive que vous envoyez.

Questions fréquentes

Retrouver le fichier exact signalé par App Store Connect

Ouvrez la notification et relevez le nom ainsi que le chemin complets. Depuis l’organiseur de Xcode, sélectionnez l’archive correspondant à l’envoi et confrontez le chemin à son contenu. Le parent du fichier indique généralement le composant à examiner. Si le chemin ne correspond pas à l’archive ouverte, vérifiez que vous n’avez pas sélectionné une construction antérieure.

Comprendre l’absence du manifeste d’un Swift Package

Un fichier placé dans les sources du package n’est pas nécessairement copié dans l’application. Vérifiez que la ressource est déclarée pour le target concerné selon les règles de Swift Package Manager, puis inspectez le produit compilé et l’archive. Si le package est externe, contrôlez sa version résolue et ses consignes d’intégration avant d’ajouter vous-même un fichier dans le bundle de l’app.

Déterminer qui corrige un SDK tiers

Si le chemin désigne le framework ou le XCFramework d’un fournisseur, vérifiez le manifeste livré et la version du SDK. Une erreur propre à ce composant doit être corrigée par une version valide de celui-ci ou par une instruction fiable de son éditeur. Ne transférez pas ses déclarations dans le manifeste principal de l’application pour contourner l’erreur : cela ne garantit pas que le composant soit corrigé.

Vérifier la nouvelle archive après correction

Repartez de la source corrigée et créez une archive neuve. Inspectez le même chemin que celui mentionné par App Store Connect, confirmez le contenu du manifeste, puis lancez la validation de distribution dans Xcode. Gardez une trace de la version construite et du résultat. Une correction faite uniquement dans une archive précédente ne garantit pas que le prochain envoi contiendra le bon fichier.

Si vous disposez déjà d’un Mac adapté et que vos soumissions sont occasionnelles, conserver une chaîne de construction locale reste souvent le choix le plus simple. En revanche, un poste qui manque d’espace, une machine indisponible au moment d’une livraison ou l’absence d’un environnement macOS accessible peuvent compliquer la reconstruction et la validation. Dans ces cas, un Mac distant peut fournir un environnement de travail distinct sans achat immédiat de matériel ; vous pouvez examiner les options Mac distant d’OsxNode si vous avez réellement besoin d’un Mac pour reconstruire et valider vos archives. Avant de choisir, comparez cette solution à votre poste actuel et vérifiez que votre méthode de gestion des certificats, des accès et des fichiers de livraison convient à un environnement distant.

Questions fréquentes