Xcode 27 : PrivacyInfo.xcprivacy absent de l’Archive ? Diagnostic 2026

Symptôme → solution rapide : si PrivacyInfo.xcprivacy manque dans votre Archive, inspectez d’abord l’application et ses dépendances dans le fichier .xcarchive, puis remontez vers les réglages de ressources du target, la déclaration des ressources Swift Package ou le contenu du SDK. La présence du fichier dans le dépôt ne prouve ni son inclusion dans l’Archive ni la validité de ses déclarations.

Ce diagnostic s’adresse aux développeurs iOS dont l’Archive ne contient pas le manifeste attendu, aux ingénieurs CI qui vérifient les ressources des packages et des SDK, ainsi qu’aux équipes DevOps qui doivent expliquer une différence entre le poste local et un Mac distant.

Dernière vérification : 5 octobre 2026, d’après la documentation Apple sur les manifestes de confidentialité, la note TN3181 sur les manifestes invalides et les pages Apple consacrées à Xcode 27.

Xcode 27, PrivacyInfo.xcprivacy et Archive : partir du produit livré

Xcode 27 est le contexte de l’outil de construction, pas la preuve qu’une règle de confidentialité aurait changé. La page Apple présente cette version de Xcode, mais, pour expliquer un manifeste absent, vous devez établir ce que l’Archive contient réellement, puis comparer ce résultat aux réglages et aux dépendances du build. Ne déduisez pas une nouvelle obligation de la seule présence de la version dans le titre de l’article : vérifiez les exigences dans les documents Apple sur les manifestes et les exigences applicables aux SDK tiers.

Un Archive est un résultat de construction, pas une copie fidèle de l’arborescence affichée dans le navigateur de projet. Le fichier peut exister dans Git sans être membre du bon target ; un package peut le contenir dans ses sources sans le déclarer comme ressource ; un framework tiers peut ne pas fournir son propre manifeste ; enfin, le fichier peut être livré mais échouer à la validation parce que son format ou ses déclarations ne conviennent pas.

Commencez par repérer le produit archivé et ses bundles. Remplacez les chemins ci-dessous par ceux de votre build :

ARCHIVE="[CHEMIN]/[PRODUIT].xcarchive"
find "$ARCHIVE/Products" -name "PrivacyInfo.xcprivacy" -print
find "$ARCHIVE/Products" -name "*.app" -o -name "*.framework"

L’emplacement observé doit être interprété selon le type de produit. Apple distingue le contenu destiné à une application de celui destiné à un framework ; ne transposez donc pas une règle de chemin à tous les bundles. La documentation Apple sur le placement du contenu dans un bundle donne le cadre à confronter à la structure réelle de votre Archive. Une recherche récursive est utile pour trouver le fichier, mais ne prouve pas à elle seule qu’il se trouve à l’emplacement attendu.

À retenir : séparez trois constats dans vos journaux : le fichier source existe, le fichier a été copié dans le produit, le contenu satisfait les règles applicables. Un contrôle qui ne vérifie que le premier constat laisse les deux autres inconnus.

Manifeste de l’application : présence dans le projet ou ressource archivée

Pourquoi le manifeste n’apparaît-il pas dans l’Archive iOS ?

Pour le manifeste propre à l’application, vérifiez d’abord le bundle .app produit, puis les réglages du target qui fabrique ce produit. Une entrée visible dans le navigateur de projet ne garantit pas qu’elle appartient au target archivé. De même, un fichier ajouté à un target différent — par exemple une cible de test au lieu de l’application distribuée — ne sera pas nécessairement copié dans l’application finale.

Affichez le chemin exact trouvé sous le produit archivé. Si la commande ne renvoie rien, remontez au target de l’application : confirmez que PrivacyInfo.xcprivacy est inclus dans ses ressources et que le Scheme utilisé pour l’Archive construit bien ce target. Si le fichier est présent, comparez son emplacement avec le type de bundle concerné au lieu de le déplacer au hasard.

Rejouez ensuite l’Archive avec le même Scheme et la même configuration que ceux du build en échec. Si vous changez simultanément de configuration, de destination ou de résolution des dépendances, vous ne saurez pas quelle modification a corrigé le résultat. Conservez le chemin de l’Archive examinée et la sortie de find avec le journal du build : vous aurez ainsi une preuve exploitable, au lieu d’une impression basée sur l’interface du projet.

Réglage du target et configuration d’Archive

Une différence entre une compilation locale et un Archive peut venir du fait que les deux opérations ne construisent pas le même produit ou n’utilisent pas le même Scheme. Contrôlez notamment :

• le target réellement sélectionné pour la distribution ;
• la configuration utilisée par l’action Archive ;
• les phases de copie ou de ressources du target ;
• la source du fichier et son appartenance au target ;
• la version du dépôt et les modifications locales non validées.

Ne compensez pas une ressource absente en éditant le contenu de l’Archive après sa création. Une telle modification peut invalider la signature du produit. Corrigez la configuration ou le fichier source, reconstruisez l’Archive, puis recommencez les contrôles sur ce nouvel artefact.

Ressources Swift Package : déclaration dans le package ou présence dans l’application

Comment intégrer la ressource d’un package Swift à l’application finale ?

Un fichier placé dans un répertoire Sources n’est pas automatiquement une ressource empaquetée. Le package doit déclarer ses ressources conformément au modèle Swift Package ; vérifiez cette déclaration dans son manifeste de package et confrontez-la au produit effectivement généré. Apple détaille le mécanisme dans son guide sur l’empaquetage de ressources d’un Swift Package.

Le contrôle doit distinguer le bundle du package du bundle de l’application. Un manifeste peut être présent dans une ressource produite par le package sans se trouver à la racine de l’application, ou le package peut ne pas avoir empaqueté cette ressource du tout. Cela ne signifie pas automatiquement que le target applicatif est mal configuré : examinez d’abord le produit associé au package, puis le produit final et les chemins de bundle correspondants.

Pour isoler le problème, examinez les étapes dans cet ordre :

• repérez PrivacyInfo.xcprivacy dans les sources du package concerné ;
• vérifiez que le package déclare explicitement la ressource selon ses règles ;
• examinez les produits compilés et les bundles générés pour ce package ;
• recherchez ensuite le fichier dans l’Archive finale ;
• comparez le résultat à celui du même commit avec les mêmes dépendances résolues.

Si le fichier manque déjà dans le produit du package, concentrez-vous sur sa déclaration et sa construction. S’il existe dans le produit du package mais pas dans l’Archive finale, vérifiez l’intégration et la structure de bundles conservée par l’application. Si le manifeste est présent dans un bundle approprié, passez au contrôle de validité : la recherche du fichier a alors répondu à la question de l’empaquetage, pas à celle de son contenu.

Attention : évitez de copier mécaniquement le manifeste d’un package à la racine de l’application. Cette opération peut brouiller la responsabilité des déclarations et ne remplace pas le manifeste associé au code d’une dépendance.

SDK tiers : bundle fourni ou déclaration manquante

Un SDK intégré sous forme de framework peut disposer de son propre manifeste. Vérifiez d’abord si le fournisseur livre PrivacyInfo.xcprivacy dans le framework ou le produit du SDK, puis assurez-vous que la structure de ce bundle est conservée dans l’Archive. Un manifeste absent à l’intérieur du produit du SDK relève d’abord de la livraison ou de l’intégration de cette dépendance ; un fichier supprimé ou déplacé pendant la construction de l’application relève aussi de votre chaîne d’empaquetage.

La responsabilité doit rester attribuée au bon niveau. L’application ne peut pas remplacer un manifeste manquant du SDK en affirmant, dans son propre manifeste, les pratiques de code d’une dépendance sans les vérifier. Consultez la liste Apple des SDK tiers concernés et les exigences associées, puis demandez au fournisseur une version conforme lorsque le problème vient de son artefact. La liste et les règles doivent être revalidées au moment de la publication : ne traitez pas une copie ancienne de la liste comme une référence immuable.

La déclaration du manifeste doit aussi correspondre au comportement réel du code. Apple explique les informations de collecte dans sa documentation sur la description de l’utilisation des données dans les manifestes. Pour les API nécessitant une raison, consultez les règles Apple sur les API à raison obligatoire. La présence d’un fichier ne suffit donc pas à prouver que les données ou les raisons déclarées sont exactes.

Contrôle du contenu : fichier empaqueté ou manifeste valide

Quand le fichier est présent au bon endroit, passez à une autre classe de diagnostic. Une erreur de syntaxe de plist, une clé ou une valeur non acceptée, ou une déclaration d’API à raison obligatoire qui ne correspond pas à l’usage ne se corrigent pas en ajoutant une seconde copie du manifeste. Distinguez le défaut de contenu du défaut de packaging dans vos tickets et dans vos journaux de CI.

Vous pouvez contrôler la syntaxe du plist source avec l’outil livré avec macOS :

plutil -lint "[CHEMIN]/PrivacyInfo.xcprivacy"

Un résultat valide pour le parseur confirme que le fichier est lisible comme plist ; il ne garantit pas que toutes les clés, valeurs ou déclarations sont conformes aux exigences Apple. Pour les erreurs spécifiques aux manifestes, suivez la note TN3181 d’Apple sur le diagnostic des manifestes de confidentialité invalides. Corrigez le manifeste dans le dépôt ou dans la dépendance concernée, puis reconstruisez et inspectez l’Archive. Ne modifiez pas directement un bundle déjà signé en espérant conserver un artefact distribuable.

CI sur Mac distant : même commit ou environnement différent

Comment vérifier le manifeste d’un Archive produit par une CI sur Mac distant ?

Si le poste local contient le manifeste et que l’Archive CI ne le contient pas, commencez par établir que vous comparez bien le même commit et le même produit. Relevez la version active de Xcode, le Scheme et la configuration d’Archive, ainsi que les versions de dépendances résolues. La page officielle de Xcode 27 permet de vérifier le contexte de l’outil ; elle ne permet pas, à elle seule, de conclure que deux builds ont les mêmes réglages.

Reproduisez ensuite le contrôle de l’Archive sur les deux environnements. Dans les journaux, conservez le chemin de l’artefact, les résultats de la recherche des manifestes, le journal d’Archive et l’état des dépendances. Si les entrées diffèrent avant la construction, investiguez la révision du code ou la résolution des packages. Si elles correspondent mais que le produit diffère, comparez le Scheme, la configuration et les phases qui copient les ressources.

Cette distinction évite deux fausses pistes fréquentes : accuser le Mac distant parce que le fichier est visible dans l’éditeur local, ou conclure que le dépôt est correct parce que le build local passe. Une CI reproductible doit contrôler l’artefact construit, et non seulement l’état du répertoire de travail.

Pour formaliser la décision, appliquez ces branches :

• Si le fichier manque dans le bundle de l’application, corrigez l’appartenance au target, les ressources ou la configuration d’Archive, puis reconstruisez.
• S’il manque dans le produit du Swift Package, corrigez la déclaration de ressource du package et vérifiez son produit généré.
• S’il manque dans le bundle d’un SDK tiers, vérifiez la version fournie, la structure du framework et les exigences Apple applicables ; sollicitez le fournisseur si son artefact est incomplet.
• S’il est présent mais rejeté, vérifiez le plist, les clés, les valeurs et les raisons d’API avec les documents Apple, puis repartez des sources.
• Si les résultats local et distant diffèrent, alignez commit, Xcode, Scheme, configuration et dépendances avant de modifier le projet.

Matrices de décision avant de modifier le pipeline

Les tableaux suivants servent à choisir le prochain contrôle. Ils ne remplacent pas la validation du produit réel : les chemins de bundle dépendent du type de produit et doivent être confirmés dans l’Archive.

Si votre chaîne locale repose sur un Mac déjà occupé, une machine virtuelle non équivalente ou un nœud difficile à maintenir, ces solutions peuvent ajouter des écarts d’environnement, des limites de contrôle des ressources et du temps d’administration. Un Mac distant dédié à la construction offre un environnement macOS accessible pour reproduire l’Archive ; il ne corrigera toutefois ni un manifeste erroné ni une ressource absente. Pour comparer les coûts d’un nœud temporaire avec l’achat d’une machine, consultez le guide des tarifs Mac mini et tenez compte de la durée d’utilisation, de la maintenance et du besoin d’accès physique.

Si vous devez isoler une CI macOS pour reproduire ces vérifications sans acheter immédiatement un Mac, vous pouvez examiner les nœuds de calcul Mac proposés par MacDate. Pour une équipe dont les builds sont réguliers et durablement lourds, comparez aussi cette option à l’achat et à l’administration d’un Mac dédié ; dans tous les cas, faites de l’inspection du .xcarchive une étape explicite de votre pipeline.