Manifeste de confidentialité iOS manquant : que faire ? Diagnostic d’archive 2026

Apple nomme le fichier de manifeste de confidentialité PrivacyInfo.xcprivacy et documente son emplacement dans le paquet de l’app ou du SDK (instructions officielles d’ajout). Si vous recevez une alerte de manifeste de confidentialité iOS manquant, ne modifiez pas d’abord votre fichier au hasard : partez du code et du chemin indiqués, déterminez si le manifeste est absent, invalide ou manquant dans un SDK tiers, puis contrôlez le contenu de l’archive finale avant de relancer la vérification de l’envoi.

Cet article s’adresse aux développeurs indépendants qui reçoivent ITMS-91061 ou une notification similaire, aux petites équipes qui intègrent des dépendances CocoaPods, Swift Package ou XCFramework, et aux responsables d’une chaîne de publication qui doivent valider l’archive avant son envoi.

Manifeste de confidentialité iOS manquant : distinguer l’erreur avant de corriger

Une notification portant sur la confidentialité ne désigne pas nécessairement un défaut dans le manifeste de votre application. Elle peut viser un fichier absent, un fichier présent mais invalide, ou un SDK intégré qui ne fournit pas le manifeste attendu. Ces cas conduisent à des corrections différentes : ajouter un fichier à la mauvaise cible ne répare pas un manifeste invalide dans une dépendance.

Pour interpréter l’alerte, relevez son code, le texte exact et le chemin du composant signalé. ITMS-91061 est associé à un avertissement concernant l’absence d’un manifeste pour un SDK tiers visé par les exigences d’Apple ; consultez les exigences Apple applicables aux SDK tiers et comparez-les avec le composant mentionné dans votre notification. Ne déduisez pas que tous les SDK de votre projet sont nécessairement concernés : la règle dépend des exigences documentées pour les SDK visés.

Le chemin affiché est souvent plus utile que le résumé du message. Il peut vous orienter vers l’app, un framework intégré ou une autre dépendance présente dans le produit envoyé. Conservez ce chemin avec la notification originale : vous pourrez ensuite vérifier si la même branche existe dans l’archive, sans confondre le nom d’une dépendance dans le gestionnaire de paquets avec le nom du binaire réellement embarqué.

ITMS-91061 signifie-t-il que le manifeste de l’app est absent ?

Pas automatiquement. Cette alerte peut concerner un SDK tiers. Faites correspondre le chemin de la notification avec les éléments intégrés au produit, puis établissez si le composant désigné est votre application ou une dépendance. La documentation d’Apple sur les exigences des SDK tiers est la référence à utiliser pour déterminer si le fournisseur doit livrer un manifeste.

À retenir : une alerte de traitement de l’envoi n’est pas, à elle seule, une conclusion d’examen de l’app. Vérifiez le statut de traitement dans les états d’envoi des builds App Store Connect, puis distinguez-le de l’état de la soumission présenté dans la référence des statuts d’app et de soumission.

Vérifier le fichier de l’app et celui du SDK séparément

Première étape : établir si le manifeste de l’app est réellement embarqué

Un fichier visible dans le navigateur de projet Xcode ne prouve pas qu’il est inclus dans la bonne cible, et une entrée correcte dans les réglages du projet ne prouve pas davantage que le fichier figure dans le produit archivé. Vérifiez successivement ces trois états : le fichier existe dans les sources, il est associé à la cible prévue, et il est présent dans le paquet construit.

Pour l’app, contrôlez l’appartenance à la cible iOS concernée, puis créez une nouvelle archive avec les paramètres de publication habituels. Inspectez ensuite le paquet .app de cette archive et recherchez PrivacyInfo.xcprivacy à l’emplacement attendu pour l’app. Apple décrit le fichier de manifeste et son rôle dans la documentation sur les fichiers de manifeste de confidentialité. Appuyez-vous sur cette structure documentée plutôt que sur l’affichage du projet ou sur une archive ancienne.

Si le fichier est absent du produit, revenez à la configuration de la cible et à la manière dont les ressources sont copiées dans le paquet. Si le fichier est présent mais que l’alerte persiste, comparez le chemin du message avec celui de l’archive : vous pourriez vérifier le manifeste de l’app alors que la notification vise un framework inclus séparément.

Deuxième étape : remonter du chemin d’alerte au fournisseur du SDK

Identifiez le binaire effectivement intégré, puis reliez-le à sa dépendance d’origine. Selon la structure du projet, le composant peut provenir d’un paquet Swift, d’une dépendance CocoaPods ou d’un XCFramework ; le nom affiché dans le gestionnaire ne correspond pas toujours exactement au nom du répertoire ou du framework conservé dans l’archive. Vérifiez la version résolue, la source déclarée et le contenu livré par cette version.

Si Apple signale un manifeste manquant dans un SDK soumis aux exigences documentées, la correction durable doit venir du fournisseur : demandez une version conforme ou mettez à jour la dépendance après avoir confirmé que la nouvelle version inclut le fichier attendu. En attendant, vous pouvez isoler le SDK dans une archive de test ou comparer l’archive obtenue avant et après la mise à jour, mais évitez de traiter une modification locale comme une réparation du composant fourni par un tiers.

Que faire si un SDK tiers ne fournit pas PrivacyInfo.xcprivacy ?

Confirmez d’abord que le chemin de l’alerte correspond bien à ce SDK et que celui-ci entre dans le périmètre des exigences Apple. Contactez ensuite le fournisseur ou adoptez une version qui contient un manifeste valide. Ne copiez pas les données de collecte, les raisons d’accès aux API ou les domaines de suivi du SDK dans le manifeste de votre application : votre fichier doit décrire l’app elle-même, tandis que le composant tiers doit fournir les informations qui lui sont propres.

Point de vigilance : ajouter un manifeste à votre application ne remplace pas le fichier attendu à l’intérieur d’un SDK. Un assemblage apparemment complet dans le projet source peut donc produire une archive qui conserve encore le défaut signalé.

Traiter un manifeste invalide sans inventer de déclarations

Un manifeste présent peut être rejeté parce que sa structure, le type d’une valeur ou son contenu ne respecte pas le format attendu. Ce problème n’est pas équivalent à une absence : ajouter une seconde copie du fichier ne corrigera pas une clé mal formée, une valeur du mauvais type ou une raison d’accès non reconnue.

Commencez par le diagnostic documenté dans la note technique TN3181 consacrée aux manifestes invalides. Distinguez une erreur de format plist d’un problème de valeur. Dans le premier cas, vérifiez que le fichier est un plist lisible et que les clés ainsi que leurs valeurs ont les types attendus. Dans le second, confrontez les entrées concernées aux valeurs autorisées et à la documentation Apple, au lieu de modifier plusieurs champs simultanément.

Lorsque le message renvoie aux API nécessitant une raison déclarée, examinez les API réellement utilisées et les raisons admissibles décrites par Apple dans la documentation sur la déclaration de l’utilisation des API à raison requise. Ne choisissez pas une raison parce qu’elle semble proche de votre fonctionnalité : la déclaration doit correspondre à l’usage effectif. Si l’information relève du SDK, demandez au fournisseur les éléments exacts plutôt que de les deviner.

Gardez une copie de la notification et notez chaque modification apportée. Après une correction, construisez une nouvelle archive, vérifiez le manifeste qui y figure et confirmez que le message suivant porte bien sur le même chemin et la même catégorie d’erreur. Cette discipline évite de traiter comme un succès un simple changement du texte d’alerte.

Un manifeste invalide et un manifeste manquant désignent-ils le même problème ?

Non. Un manifeste manquant n’est pas trouvé à l’emplacement attendu ; un manifeste invalide est présent, mais son format ou ses valeurs ne passent pas la vérification. La première correction consiste à rétablir le fichier au bon endroit. La seconde exige d’identifier précisément la structure ou la déclaration rejetée et de la corriger selon les règles publiées par Apple.

Contrôler l’archive de publication, pas seulement les sources

Le contrôle doit porter sur l’archive que vous comptez réellement envoyer. Un fichier corrigé dans le dépôt ne garantit pas qu’il figure dans l’archive courante : une dépendance verrouillée peut encore désigner une ancienne version, une étape de copie peut utiliser un chemin différent, ou vous pouvez inspecter un produit produit avant la correction.

Procédez dans cet ordre :

• Résolvez les dépendances utilisées par la configuration de publication et vérifiez leurs versions effectives.
• Créez une nouvelle archive à partir de cette configuration, sans réutiliser un produit antérieur à la correction.
• Examinez le paquet de l’application et les frameworks intégrés à l’archive ; recherchez le manifeste dans chacun des composants visés.
• Comparez les chemins obtenus avec celui de la notification App Store Connect, en tenant compte des différences entre l’app et ses SDK.
• Si un fichier manque encore, corrigez l’entrée de dépendance ou la configuration de copie concernée avant de reconstruire.
• Soumettez de nouveau l’archive et lisez le résultat du traitement séparément du statut d’examen de la soumission.

Comment confirmer que le manifeste est bien dans l’archive iOS finale ?

Ouvrez l’archive fraîchement construite, inspectez le paquet .app et les SDK intégrés, puis comparez leurs chemins avec ceux de la notification. Ne vous limitez pas au fichier visible dans Xcode. Une vérification d’envoi favorable renseigne sur le traitement du produit soumis ; elle ne signifie pas que l’examen de l’app est terminé ou qu’elle a été approuvée.

Le dossier de diagnostic utile comporte le texte de l’alerte, le chemin signalé, la version de la dépendance, le résultat de l’inspection de l’archive et le statut de traitement reçu après le nouvel envoi. Vous pouvez ainsi expliquer si le problème venait du fichier de l’app, d’un SDK ou d’une archive périmée, plutôt que de refaire des changements sans savoir lequel a eu un effet.

Choisir le prochain contrôle selon les éléments disponibles

Le tableau ci-dessous permet de sélectionner la vérification adaptée au symptôme. La colonne « niveau de preuve » évalue la capacité de l’élément à confirmer le diagnostic, et non la gravité du problème.

Si vous changez plusieurs dépendances en même temps, vous perdez une partie de la valeur du diagnostic : une alerte qui disparaît ne permet plus d’identifier clairement la correction responsable. Pour une petite équipe, privilégiez donc une modification ciblée, une archive nouvelle et un relevé du contenu avant de passer à l’étape suivante.

Faire de la vérification une étape de publication

Le tableau suivant compare les preuves à conserver et leur portée. Il aide à éviter deux conclusions trop rapides : croire qu’un fichier source suffit, ou considérer le traitement de l’envoi comme une approbation de l’application.

Vous pouvez intégrer ce contrôle à votre routine de versionnement sans en faire un audit général des données personnelles. Conservez pour chaque envoi l’archive examinée, le chemin des manifestes pertinents, la version des dépendances et la notification qui a déclenché le diagnostic. Si une nouvelle version d’un SDK modifie le contenu livré, refaites le rapprochement avec le produit construit, même si le fichier source de l’application n’a pas changé.

Pour les projets créatifs combinant édition audio ou vidéo, interfaces graphiques et dépendances spécialisées, la difficulté peut venir du nombre de composants intégrés plutôt que du code de l’app. Dans ce cas, séparez la vérification par cible et par SDK : vous éviterez d’attribuer à l’app une déclaration qui appartient à une bibliothèque, ou de manquer un framework inclus seulement dans une configuration de publication particulière.

Si votre archive reste difficile à reproduire sur votre poste, comparez d’abord les dépendances, les réglages de construction et le contenu effectivement envoyé ; un autre environnement ne corrigera pas un manifeste erroné par lui-même. En revanche, si vous avez besoin d’un Mac distant pour refaire l’archive et examiner la chaîne de publication, consultez les informations publiées sur les environnements Mac proposés par VPSMAC et la présentation des solutions Mac à distance de VPSMAC avant de décider si ce mode de travail correspond à vos besoins. Un Mac local reste plus adapté si vous devez disposer en permanence d’interfaces ou de périphériques physiques ; une location ponctuelle peut être plus pertinente pour reproduire un défaut ou valider un envoi sans acheter une machine dédiée.

La décision pratique est donc de traiter chaque alerte à son niveau : le manifeste de l’app relève de sa cible et de son archive, le manifeste d’un SDK relève du composant et de son fournisseur, et une erreur de contenu doit être corrigée à partir des règles Apple plutôt que par supposition. Si vous devez répéter cette vérification dans un environnement macOS accessible à distance, examinez les conditions réelles proposées par VPSMAC, puis ne retenez cette option que si elle vous permet de reproduire votre propre chaîne Xcode et de contrôler l’archive avant l’envoi.