Le privacy manifest est-il toujours obligatoire pour les uploads sur l’App Store en 2026 ?

Oui. Depuis le 1er mai 2024, les uploads doivent inclure PrivacyInfo.xcprivacy, qui déclare chaque raison requise pour la catégorie API que votre app ou les SDK code intégrés utilisent réellement. Si vous n’appelez aucune de ces API, n’ajoutez pas d’entrées vides. Les SDK tiers listés doivent inclure leurs propres manifests lorsqu’une nouvelle app les intègre ou qu’une mise à jour les ajoute ; les signatures s’appliquent lorsque ces SDK sont des dépendances binaires.

Quelle est la différence entre ITMS-91053 et ITMS-91061 ?

ITMS-91053 signifie que le binaire de votre application utilise une raison requise API sans déclaration correspondante dans un manifeste de confidentialité. ITMS-91061 signifie qu'un SDK tiers ayant un impact sur la confidentialité dans votre bundle est manquant de son propre PrivacyInfo.xcprivacy. Corrigez 91053 dans le manifeste de votre application ; corrigez 91061 en mettant à niveau le SDK, et non en copiant ses pratiques dans le manifeste de votre application.

Où placer PrivacyInfo.xcprivacy dans un projet iOS Capacitor ?

Ajoutez PrivacyInfo.xcprivacy sous ios/App, incluez-le dans les ressources de copie du bundle de la cible App dans Xcode, puis archivez et générez un rapport de confidentialité. Chaque cible a toujours besoin de son propre manifeste ; le rapport agrège les manifestes de votre application, de Capacitor, de CocoaPods et des dépendances Swift Package Manager.

Privacy Manifest pour les apps iOS

Apple privacy manifests are mandatory for App Store uploads: chaque app doit inclure un PrivacyInfo.xcprivacy qui décrit la collecte de données de votre application, les domaines de suivi et API de raison requise que votre code appelle. Les SDK tiers sur la liste obligatoire d’Apple doivent livrer leurs propres manifests (et signatures lorsqu’ils sont distribués sous forme de binaires). Ce guide se concentre sur la conformité 2026 et le dépannage pour Capacitor Apps iOS : quoi déclarer, comment corriger ITMS-91053 et ITMS-91061, et comment valider avant de soumettre.

Ce que couvre un privacy manifest

Un privacy manifest est une property list fournie avec votre app ou SDK. Xcode agrège tous les manifests lors de l’archivage en un seul rapport de confidentialité.

Clé	Objectif
`NSPrivacyTracking`	Si votre app ou SDK utilise des données à des fins de suivi au sens d’Apple
`NSPrivacyTrackingDomains`	Domaines concernés par le suivi
`NSPrivacyCollectedDataTypes`	Types de données collectés et leur utilisation
`NSPrivacyAccessedAPITypes`	Les API à raison requise que votre propre code utilise, avec les codes de raison approuvés

La présentation d’Apple : Ajouter un manifeste de confidentialité à votre application ou à un SDK tiers.

Vous êtes responsable de tous les code présents dans le binaire, y compris les SDK intégrés. Votre manifeste doit décrire votre application uniquement. Ne copiez pas les pratiques de confidentialité d’un autre SDK dans votre fichier.

Catégories d'API à motif requis

Depuis 1er mai 2024, App Store Connect rejette les uploads lorsque votre application utilise une API listée sans raison approuvée dans NSPrivacyAccessedAPITypes. Apple documente les API et les raisons approuvées dans Décrire l'utilisation de l'API à raison requise.

D'après la note d'Apple TN3183, les catégorie sont :

`NSPrivacyAccessedAPIType` valeur	Déclencheur typique dans les apps hybrides
`NSPrivacyAccessedAPICategoryUserDefaults`	Paramètres, état des plugins, persistance légère
`NSPrivacyAccessedAPICategoryFileTimestamp`	Métadonnées de fichiers, caches, bundles de mise à jour
`NSPrivacyAccessedAPICategoryDiskSpace`	Vérification de l'espace libre avant téléchargement
`NSPrivacyAccessedAPICategorySystemBootTime`	Temps écoulé, minuteries ou horodatages absolus
`NSPrivacyAccessedAPICategoryActiveKeyboards`	Extension de clavier ou détection de la saisie

Pour chaque catégorie utilisée, ajoutez un dictionnaire avec NSPrivacyAccessedAPIType et NSPrivacyAccessedAPITypeReasons. Choisissez uniquement les codes de raison Apple pour cette catégorie. Des codes erronés font échouer la revue.

Exemple de fragment (adaptez les catégories et les codes à votre application après avoir consulté le rapport de confidentialité) :

<key>NSPrivacyAccessedAPITypes</key>
<array>
  <dict>
    <key>NSPrivacyAccessedAPIType</key>
    <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
    <key>NSPrivacyAccessedAPITypeReasons</key>
    <array>
      <string>CA92.1</string>
    </array>
  </dict>
</array>

Capacitor figure lui-même sur la les exigences SDK de tiers liste d'Apple, donc le framework livre un manifeste pour l'usage de API par Capacitor. Vous avez toujours besoin d'un manifeste au niveau de l'app pour votre les couches natives et JavaScript, les plugins et toutes les API non couvertes par les dépendances.

ITMS-91053 : déclaration API manquante

ITMS-91053 signifie qu'App Store Connect a détecté une raison API requise dans votre build sans entrée correspondante dans un manifeste de confidentialité fusionné.

Corriger :

Lisez l'e-mail de rejet ou le log d'upload. Il indique l’API catégorie (par exemple NSPrivacyAccessedAPICategoryDiskSpace).
Ouvrez le rapport de confidentialité de l'archive dans Xcode (Product > Archive, puis Générer le rapport de confidentialité de l'archive) et vérifiez si l'écart vient de la cible de votre app ou d'une dépendance.
Si l’API se trouve dans votre code ou un plugin que vous maintenez, ajoutez la catégorie et une raison approuvée à ios/App/PrivacyInfo.xcprivacy.
Si l’API provient d'une dépendance, passez le pod ou le package SPM à une version qui inclut un manifeste, ou patchez le plugin pour ne déclarer que ce que votre fork appelle réellement.
Refaites une archive et vérifiez que la catégorie apparaît dans le rapport avant de refaire un upload.

Ne déclarez pas de catégories que vous n'utilisez pas. L'analyse statique d'Apple est liée aux symboles du binaire.

ITMS-91061 : manifeste de confidentialité tiers manquant

ITMS-91061 signifie qu'un SDK impactant la confidentialité dans votre bundle d'application n'a pas de PrivacyInfo.xcprivacy. Apple précise que lorsque vous publiez une nouvelle application ou une mise à jour qui ajoute un SDK répertorié, ce SDK doit inclure un manifeste ; les SDK binaires nécessitent également une signature du fournisseur de SDK.

Corriger :

Copiez le chemin du framework depuis l'e-mail (par exemple Frameworks/FirebaseCore.framework/FirebaseCore).
Identifiez le package CocoaPods, SPM ou le binaire vendoré.
Passez à une release vendor qui embarque PrivacyInfo.xcprivacy à la racine du framework.
Nettoyez, recompilez et vérifiez le fichier dans le .xcarchive avant l'upload.

Ne pas déplacez les déclarations de collecte ou de API de SDK dans le manifeste de votre application. Apple avertit explicitement que le manifeste doit décrire uniquement l’application. Si SDK n’est plus maintenu, remplacez-l’ou utilisez une version conforme.

Les SDK listés incluent des stacks mobiles courants (Firebase, Flutter, Capacitor, shared_preferences_ios, et d’autres). Vérifiez la liste actuelle sur le site d’Apple avant chaque release.

Manifestes et signatures de SDK tiers

Lorsque vous mettez à jour une dépendance, Xcode vérifie que les frameworks binaires ont été signés par le même développeur que les versions précédentes. Cela protège la supply chain lorsque les manifestes changent.

Workflow pratique :

Après pod install ou pour résoudre SPM, recherchez ios/ pour PrivacyInfo.xcprivacy fichiers.
Archivez et utilisez Générer le rapport de confidentialité pour obtenir une vue d'ensemble.
Comparez le rapport avec vos réponses au questionnaire de confidentialité de l'App Store.

Pour les outils live update, déclarez les API à raison d'utilisation requise que votre updater utilise réellement (par exemple l'espace disque, les horodatages de fichiers ou les user defaults). L'accès au réseau n'est pas une catégorie API à raison requise. Si l'updater collecte des données personnelles, déclarez ces données dans vos étiquettes de confidentialité App Store et vos réponses au questionnaire ; le simple fait de récupérer une mise à jour via HTTPS ne crée pas de nouvelle catégorie de divulgation. Gardez Conformité Capgo live update in mind when you document OTA behavior.

Ajoutez `PrivacyInfo.xcprivacy` dans un projet iOS Capacitor

Synchronisez le projet natif : bunx cap sync ios.
Ouvrez l’espace de travail Xcode situé dans ios/App.
Fichier > Nouveau > Fichier, choisissez App Privacy (ou ajoutez un fichier PrivacyInfo.xcprivacy plist vide).
Enregistrez le fichier sous ios/App (même dossier que AppDelegate convient).
Dans la cible Phases de build > Copier les ressources du bundle, vérifiez que PrivacyInfo.xcprivacy est listé.
Renseignez le suivi, les types de données collectées et les API de raison requises selon votre app et vos plugins.
Archivez, générez le rapport de confidentialité et corrigez les catégories manquantes avant de l’envoyer sur App Store Connect.

Si vous modifiez le plist en XML sur le disque, rouvrez Xcode pour que l’appartenance à la cible reste correcte.

Chaque app ou cible SDK conserve son propre PrivacyInfo.xcprivacy. Lors de l’archivage, Xcode agrège ces manifests en un seul rapport de confidentialité. Vous n’avez pas à fusionner manuellement les plists des dépendances dans le fichier de votre app.

Pour un plugin Capacitor personnalisé livré comme framework iOS à part, ajoutez PrivacyInfo.xcprivacy sous ce plugin ios/Plugin/ dossier de ce plugin (ou équivalent) et listez-le dans la cible du plugin Copier les ressources du bundle, et pas seulement dans la cible de l'app.

Quand NSPrivacyTracking est vrai ou si vous intégrez des SDK de pub ou d'analytics, alignez le manifeste avec les labels de confidentialité de l'App Store et affichez le prompt App Tracking Transparency quand iOS l'exige. @capgo/capacitor-app-tracking-transparency couvre le flux ATT pour les apps Capacitor.

Checklist de validation avant soumission

La cible de l'app inclut PrivacyInfo.xcprivacy dans Copier les ressources du bundle.
Chaque catégorie de motif requise dans le rejet ou le rapport dispose de codes de motif approuvés.
Chaque SDK tiers listé dans le build inclut son propre manifeste au chemin attendu.
Le rapport de confidentialité correspond à votre compréhension des SDK d’analyse, de publicité et d’authentification.
App Store privacy labels align with the merged report.

FAQ

Les plugins Capacitor ont-ils besoin de leurs propres privacy manifests ?

Si un plugin est distribué en source dans votre dépôt, son utilisation de API fait partie du binaire de votre application. Déclarez les API que le plugin appelle dans le manifeste de l’application, ou ajoutez un manifeste dans la cible du plugin s’il est livré comme framework séparé. Les pods binaires doivent respecter les règles d’Apple applicables aux SDK de tiers.

Puis-je corriger ITMS-91061 en modifiant uniquement le PrivacyInfo.xcprivacy de mon application ?

Non. Le SDK doit embarquer le manifeste. Votre fichier ne doit documenter que les pratiques de votre application.

Où sont documentées les dates des politiques d’Apple ?

API à motif requis : appliquées depuis 1er mai 2024. Les règles de manifeste et de signature tiers pour les SDK listés sont décrites dans Exigences pour les SDK tiers.

Continuer avec Privacy Manifest pour les apps iOS

Si vous utilisez Privacy Manifest pour les apps iOS pour planifier la sécurité et la conformité, connectez-l’à Chiffrement pour les détails d'implémentation du chiffrement, Conformité pour les détails d'implémentation de la conformité, Scanner de sécurité Capgo pour le workflow produit dans Capgo Security Scanner, Capgo et la sécurité pour le workflow produit dans Capgo Security, et Capgo Centre de confiance pour le workflow produit dans Capgo Trust Center.