Manifeste de confidentialité iOS (PrivacyInfo.xcprivacy) en 2026 : API à motif obligatoire, SDK et ITMS-91053

Le manifeste de confidentialité iOS est une liste de propriétés nommée PrivacyInfo.xcprivacy, intégrée au bundle de votre app et à celui de chaque SDK tiers. Il indique si le code suit les utilisateurs, quels domaines de suivi il contacte, quelles données il collecte et pourquoi il appelle des API « à motif obligatoire » (required reason APIs) : UserDefaults, dates des fichiers, durée depuis le démarrage, espace disque et claviers actifs. Depuis le 1er mai 2024, App Store Connect refuse tout build dont le code utilise l’une de ces API sans code de motif approuvé, et c’est l’e-mail ITMS-91053 qui vous le signale. Ce guide détaille chaque clé, chaque code de motif listé aujourd’hui par Apple, un manifeste minimal prêt à copier, et le lien entre ce fichier et vos étiquettes de confidentialité sur l’App Store.

Points clés

• Le fichier doit s’appeler PrivacyInfo.xcprivacy et faire partie des ressources de votre cible. Xcode le crée à partir du modèle App Privacy.
• Il compte quatre clés de premier niveau : NSPrivacyTracking, NSPrivacyTrackingDomains, NSPrivacyCollectedDataTypes et NSPrivacyAccessedAPITypes.
• Les API à motif obligatoire se répartissent en cinq catégories, chacune avec une courte liste de codes approuvés. CA92.1 (préférences lues et écrites par votre seule app) concerne presque toutes les apps.
• Chaque SDK déclare son propre usage dans son propre manifeste. Depuis le 12 février 2025, les SDK de la liste d’Apple doivent en fournir un, ainsi qu’une signature lorsqu’ils sont livrés sous forme binaire.
• Trois e-mails à connaître : ITMS-91053 (motif manquant), ITMS-91056 (manifeste invalide) et ITMS-91061 (SDK listé sans manifeste).
• Le rapport de confidentialité de Xcode regroupe tous les manifestes de l’archive, mais c’est toujours à vous de remplir la section « Confidentialité de l’app » dans App Store Connect.

Qu’est-ce que le manifeste de confidentialité iOS ?

Apple a présenté les manifestes de confidentialité à la WWDC23. Selon la documentation officielle, le fichier consigne deux choses : les types de données que l’app ou le SDK collecte (sur toutes les plateformes) et les API à motif obligatoire qu’il utilise (sur iOS, iPadOS, tvOS, visionOS et watchOS).

Chaque bundle porte son propre manifeste. Sur iOS, celui de l’app se trouve à la racine du bundle .app, celui d’un framework à la racine du .framework ; sur macOS et Mac Catalyst, il va dans Contents/Resources/. Votre manifeste ne décrit que votre code. Un SDK tiers ne peut pas compter sur le vôtre pour couvrir ses appels, et le vôtre n’a pas à décrire les pratiques du SDK.

Pourquoi Apple s’intéresse-t-il à des API aussi banales que UserDefaults ou la durée depuis le démarrage ? Parce que ces valeurs, combinées, permettent de calculer une empreinte de l’appareil (fingerprinting). Apple est catégorique : que l’utilisateur ait accepté le suivi ou non, le fingerprinting est interdit. En déclarant un motif, vous vous engagez à n’utiliser l’API, et tout ce qui en découle, que pour ce motif.

Ce qu’Apple impose en 2026

Les règles sont arrivées par étapes ; toutes s’appliquent aujourd’hui :

En octobre 2026, la documentation d’Apple liste cinq catégories d’API à motif obligatoire. Apple précise qu’il revoit périodiquement la liste et les motifs : relisez la page consacrée aux required reason APIs avant chaque version majeure.

Les quatre clés de PrivacyInfo.xcprivacy

NSPrivacyTracking et NSPrivacyTrackingDomains

Si vous listez des domaines de suivi et que l’utilisateur n’a pas donné son accord via App Tracking Transparency, les requêtes réseau vers ces domaines échouent. La note technique TN3181 recense les combinaisons qui rendent un manifeste invalide : NSPrivacyTracking à true avec une liste de domaines vide, ou à false avec des domaines listés. Chaque domaine se limite au nom d’hôte, sans chemin, sans paramètres et sans barre oblique finale.

NSPrivacyCollectedDataTypes

Chaque entrée est un dictionnaire de quatre clés exactement : NSPrivacyCollectedDataType (par exemple NSPrivacyCollectedDataTypeEmailAddress, NSPrivacyCollectedDataTypeHealth ou NSPrivacyCollectedDataTypeCrashData), NSPrivacyCollectedDataTypeLinked, NSPrivacyCollectedDataTypeTracking et NSPrivacyCollectedDataTypePurposes. Les finalités viennent d’une liste fermée : fonctionnement de l’app, analyse, personnalisation du produit, publicité du développeur, publicité tierce et autre. N’utilisez que les valeurs d’Apple : avec des valeurs inventées, Xcode ne peut pas produire un rapport correct.

« Collecter » a un sens précis dans les règles App Privacy d’Apple : transmettre des données hors de l’appareil d’une manière qui vous permet, à vous ou à vos partenaires, d’y accéder plus longtemps que nécessaire pour traiter la requête en temps réel. Des données traitées uniquement sur l’appareil ne sont pas collectées.

Les API à motif obligatoire et leurs codes

Pour chaque catégorie utilisée par votre code, ajoutez un dictionnaire à NSPrivacyAccessedAPITypes, avec la chaîne de catégorie (NSPrivacyAccessedAPIType) et un tableau d’un ou plusieurs codes de motif (NSPrivacyAccessedAPITypeReasons). Voici la liste complète de la documentation d’Apple :

Choisir le bon motif

• Réglages enregistrés avec UserDefaults ou @AppStorage, lus par votre seule app : CA92.1.
• Valeurs partagées avec un widget ou une extension via une suite App Group : 1C8F.1, en plus de CA92.1 si vous utilisez aussi les préférences standard.
• Lecture des dates ou de la taille de fichiers de votre conteneur, du conteneur App Group ou du conteneur CloudKit de l’app, par exemple pour vider un cache : C617.1.
• Affichage d’une date de modification dans une liste de fichiers : DDA9.1. Fichiers choisis par l’utilisateur avec un sélecteur de documents : 3B52.1.
• Vérification de l’espace libre avant d’écrire un gros export ou de télécharger du contenu : E174.1. L’app doit alors se comporter différemment, de façon visible pour l’utilisateur.
• Mesure d’un temps écoulé entre deux événements de l’app, ou minuteur, avec systemUptime : 35F9.1.

Lisez les conditions, pas seulement les intitulés. La plupart des motifs interdisent d’envoyer l’information, ou ce qui en est dérivé, hors de l’appareil. C56D.1 et 0A2A.1 sont réservés aux SDK qui encapsulent l’API pour l’app. Si aucun motif ne correspond à un usage légitime, Apple propose un formulaire pour en demander un nouveau ; sinon, passez par une autre API.

Créer le manifeste dans Xcode, étape par étape

1. Choisissez File › New › File from Template (File › New File dans les versions plus anciennes de Xcode), descendez jusqu’à la section Resource, sélectionnez App Privacy puis Next.
2. Cochez la cible de votre app dans la liste Targets, gardez le nom par défaut PrivacyInfo.xcprivacy (c’est le nom exigé) et cliquez sur Create. Vérifiez que le fichier figure dans la phase Copy Bundle Resources de la cible.
3. Ouvrez le fichier et choisissez Editor › Raw Keys and Values pour voir les vrais noms de clés plutôt que leurs libellés.
4. Ajoutez NSPrivacyTracking (Boolean), à NO sauf si vous pratiquez le suivi, auquel cas ajoutez aussi NSPrivacyTrackingDomains.
5. Ajoutez NSPrivacyAccessedAPITypes (Array) avec un dictionnaire par catégorie utilisée, contenant NSPrivacyAccessedAPIType et NSPrivacyAccessedAPITypeReasons.
6. Si votre propre code collecte des données, ajoutez NSPrivacyCollectedDataTypes avec un dictionnaire par type de données.
7. Validez le fichier, archivez, puis générez le rapport de confidentialité (voir plus bas).

Voici un manifeste minimal pour une app qui ne pratique pas le suivi, stocke ses réglages dans UserDefaults et lit les dates de fichiers dans son propre conteneur :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>NSPrivacyTracking</key>
  <false/>
  <key>NSPrivacyAccessedAPITypes</key>
  <array>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array>
        <string>CA92.1</string>
      </array>
    </dict>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array>
        <string>C617.1</string>
      </array>
    </dict>
  </array>
</dict>
</plist>

Si l’app envoie aussi une adresse e-mail à votre serveur pour créer un compte, ajoutez une entrée de données collectées :

<key>NSPrivacyCollectedDataTypes</key>
<array>
  <dict>
    <key>NSPrivacyCollectedDataType</key>
    <string>NSPrivacyCollectedDataTypeEmailAddress</string>
    <key>NSPrivacyCollectedDataTypeLinked</key>
    <true/>
    <key>NSPrivacyCollectedDataTypeTracking</key>
    <false/>
    <key>NSPrivacyCollectedDataTypePurposes</key>
    <array>
      <string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
    </array>
  </dict>
</array>

Avant l’envoi, vérifiez la syntaxe dans le Terminal. plutil prouve seulement que la liste de propriétés est bien formée ; les clés et valeurs, elles, sont contrôlées par App Store Connect.

plutil -lint PrivacyInfo.xcprivacy

Les éditeurs de SDK suivent les mêmes étapes sur la cible de leur framework. Dans un package Swift, placez le fichier dans le dossier des sources de la cible et déclarez-le explicitement, par exemple avec resources: [.process("PrivacyInfo.xcprivacy")], car Xcode ne le considère pas comme une ressource par défaut. Une bibliothèque statique simple (.a) ne peut pas embarquer de ressources : Apple recommande de livrer un framework statique à la place.

SDK tiers : manifestes et signatures

Apple tient une liste des SDK qui exigent un manifeste et une signature. On y trouve des bibliothèques réseau et image (Alamofire, AFNetworking, Kingfisher, SDWebImage), des modules Firebase et Google (FirebaseCore, FirebaseCrashlytics, FirebaseMessaging, GoogleSignIn…), le SDK Facebook, OneSignal, RealmSwift, Lottie, SnapKit, le moteur Flutter et de nombreux plugins Flutter, Hermes pour React Native, Capacitor, Cordova et UnityFramework. Toutes les versions d’un SDK listé sont concernées, de même que tout SDK qui en réemballe un.

• La règle. Quand vous soumettez une nouvelle app qui inclut un SDK listé, ou une mise à jour qui en ajoute un, ce SDK doit contenir son manifeste. Depuis le 12 février 2025, son absence déclenche ITMS-91061: Missing privacy manifest.
• Les signatures. Quand un SDK listé est une dépendance binaire (un XCFramework), il doit être signé. Sélectionnez le XCFramework dans le navigateur de projet : l’inspecteur de fichier indique qui l’a signé. Si la signature change ou disparaît, le build échoue avec une erreur indiquant que le framework « is not signed with the expected identity ». N’acceptez le changement qu’après vérification auprès de l’éditeur.
• La correction. Passez à une version du SDK qui embarque son manifeste. La plupart des mainteneurs l’ont ajouté en 2024 : une ancienne version figée est le coupable habituel.
• Le code lié statiquement. La règle d’Apple s’applique par bundle : si une bibliothèque statique sans manifeste est liée à votre exécutable, ses appels sont attribués au binaire de votre app, et c’est votre manifeste qui doit les couvrir tant que l’éditeur ne livre pas un framework statique avec manifeste.

Corriger ITMS-91053 et les autres e-mails d’App Store Connect

Xcode ne signale pas de motif manquant à la compilation. C’est App Store Connect qui analyse le binaire après l’envoi : si du code appelle une API à motif obligatoire sans motif déclaré, le build est refusé et vous recevez un e-mail intitulé « ITMS-91053: Missing API declaration ». Il nomme le fichier concerné et les catégories en cause, par exemple NSPrivacyAccessedAPICategoryUserDefaults.

1. Lisez le chemin indiqué dans l’e-mail. S’il désigne l’exécutable de votre app, la correction se fait dans votre manifeste. S’il pointe dans Frameworks/, c’est l’affaire du SDK : mettez-le à jour.
2. Repérez les appels dans votre code. Une recherche depuis le dossier du projet en trouve l’essentiel :
   grep -rnE "UserDefaults|AppStorage|systemUptime|mach_absolute_time|volumeAvailableCapacity|creationDate|modificationDate|activeInputModes" --include="*.swift" .
3. Choisissez le motif qui correspond à chaque usage (voir le tableau plus haut) et ajoutez le dictionnaire à NSPrivacyAccessedAPITypes.
4. Incrémentez le numéro de build, archivez et renvoyez. Aucune métadonnée n’est à modifier dans App Store Connect.

Le rapport de confidentialité et les étiquettes de l’App Store

Xcode sait regrouper les manifestes de votre app et de chaque SDK lié en un seul rapport de confidentialité. Pour le générer :

1. Choisissez Product › Archive. Xcode ouvre l’archive dans l’Organizer.
2. Faites un Contrôle-clic sur l’archive et choisissez Generate Privacy Report.
3. Enregistrez le rapport et ouvrez-le dans Aperçu : c’est un PDF avec une section par bundle doté d’un manifeste.

Le rapport suit la structure des « étiquettes nutritionnelles » de confidentialité, mais il ne les remplit pas. La section « Confidentialité de l’app » d’App Store Connect reste un questionnaire auquel vous répondez vous-même, et elle doit couvrir les données collectées par vos partenaires tiers, SDK compris. Servez-vous du rapport comme d’une checklist : chaque type de données qu’il liste doit figurer dans vos réponses et dans votre politique de confidentialité, sauf si vous pouvez établir qu’il n’est jamais collecté. Les API à motif obligatoire n’apparaissent pas sur les étiquettes : elles décrivent la façon dont le code utilise certaines API, pas les données collectées. Vos réponses peuvent être modifiées à tout moment, sans nouveau build.

Un exemple dans la santé rend la distinction claire. Une app comme Pillio, qui synchronise l’historique des prises avec Apple Santé, n’a pas besoin d’entrée de manifeste pour HealthKit : HealthKit ne fait pas partie des API à motif obligatoire. Ce qui compte pour les étiquettes, c’est de savoir si des données de santé quittent l’appareil pour vous parvenir, à vous ou à un partenaire, ce qui correspond à la définition de la collecte selon Apple. La règle 5.1.3 ajoute que les données HealthKit ne doivent pas servir à la publicité.

Comment Develak gère le manifeste de confidentialité

Develak publie plus de 30 apps sur l’App Store, et le manifeste fait partie de chaque soumission dans notre checklist de soumission App Store. Avant d’archiver, nous cherchons les API à motif obligatoire dans le code, vérifions que chaque version de SDK embarque son propre manifeste, puis générons le rapport de confidentialité pour le comparer aux réponses « Confidentialité de l’app » et à la politique de confidentialité. Pour une app SwiftUI sans SDK tiers, le manifeste est souvent court : NSPrivacyTracking et une ou deux entrées d’API à motif obligatoire. Les apps qui vendent des abonnements ont davantage à vérifier lors de la validation ; notre guide sur la validation des abonnements App Store détaille ce point.

Apple ajuste régulièrement ces exigences, et une mise à jour de SDK peut changer le contenu d’un build. Notre service de maintenance d’application iOS tient manifestes, versions de SDK et étiquettes de confidentialité à jour à chaque version, et notre service de développement d’application iOS les intègre dès la première version.

FAQ