Privacy Manifest — définition, fichier PrivacyInfo.xcprivacy et exigences

Qu'est-ce que Privacy Manifest ?

Privacy Manifest est un fichier PrivacyInfo.xcprivacy au format property list (XML) qui déclare quels types de données l'application collecte et pourquoi elle utilise certaines API. Apple a introduit les manifestes dans le cadre d'une initiative visant à accroître la transparence de la confidentialité, similaire à Privacy Nutrition Label, mais au niveau du code et du binaire.

L'objectif principal du manifeste est de documenter l'utilisation des API dites Required Reason API. Ce sont des catégories d'API qui peuvent être utilisées pour la prise d'empreinte numérique de l'appareil (fingerprinting), donc chaque utilisation doit être accompagnée d'une déclaration d'une raison spécifique de la liste approuvée par Apple.

À partir du 1er mai 2024, Apple rejette les compilations qui ne contiennent pas de Privacy Manifest. Cela s'applique à la fois aux cibles principales de l'application et à tous les SDK et dépendances intégrés. Selon la WWDC 2023, le manifeste est obligatoire pour toutes les applications distribuées via l'App Store.

Le manifeste doit être présent dans chaque binaire — non seulement dans l'application principale, mais aussi dans chaque framework et bibliothèque statique. Si un SDK tiers n'a pas fourni de manifeste, le développeur doit l'ajouter manuellement ou contacter le fournisseur du SDK pour obtenir une mise à jour.

Pourquoi Apple a introduit Privacy Manifest

Avant les manifestes, les développeurs pouvaient utiliser de vastes API système (accès au système de fichiers, date/heure, journaux système) sans explication transparente de l'objectif d'utilisation. Cela créait un risque de fuite de données via des SDK tiers qui pouvaient collecter des informations à l'insu du développeur.

Selon Mysk Inc. (2023), de nombreux SDK populaires utilisaient des API pour la prise d'empreinte numérique de l'appareil sans nécessité explicite — par exemple, en lisant le temps de fonctionnement pour déterminer le fuseau horaire ou en scannant des répertoires pour collecter des métadonnées. Privacy Manifest oblige à déclarer chacune de ces actions.

En plus de Required Reason API, le manifeste inclut la section NSPrivacyTracking — un indicateur signalant si l'application utilise le suivi (nécessite ATT), et NSPrivacyCollectedDataTypes — une liste des types de données collectées au format Privacy Nutrition Label.

Différence entre Privacy Manifest et Privacy Nutrition Label

Privacy Nutrition Label est une représentation destinée à l'utilisateur sur la page de l'application dans l'App Store, montrant quelles données l'application collecte. Privacy Manifest est un fichier technique à l'intérieur du binaire qu'Apple vérifie automatiquement. Si les données du manifeste ne correspondent pas aux étiquettes dans App Store Connect, Apple rejette la compilation.

Ainsi, le manifeste est la source de vérité pour le système de vérification d'Apple. Les étiquettes de confidentialité sont générées automatiquement à partir de celui-ci, mais le développeur doit maintenir les deux représentations à jour. Modifier le manifeste après la publication nécessite l'envoi d'une nouvelle compilation pour examen.

Structure de PrivacyInfo.xcprivacy

Le fichier PrivacyInfo.xcprivacy utilise le format property list avec un type racine Dictionary. Les principales clés de niveau supérieur sont : NSPrivacyTracking (Boolean), NSPrivacyTrackingDomains (Array), NSPrivacyCollectedDataTypes (Array), NSPrivacyAccessedAPITypes (Array).

Clés de niveau supérieur

La clé NSPrivacyTracking — une valeur booléenne indiquant si l'application applique le suivi (nécessite ATT). Si true, vous devez également spécifier NSUserTrackingUsageDescription dans Info.plist. La clé NSPrivacyTrackingDomains — un tableau de domaines sur lesquels le suivi est appliqué.

La clé NSPrivacyCollectedDataTypes — un tableau de dictionnaires, chacun décrivant un type de données collectées : catégorie (NSPrivacyCollectedDataType), liaison (NSPrivacyCollectedDataLinked), objectif (NSPrivacyCollectedDataTypePurposes). Les objectifs incluent : la publicité tiers, l'analyse, le développement de produit et la personnalisation de contenu.

La clé NSPrivacyAccessedAPITypes — un tableau de dictionnaires pour chaque catégorie de Required Reason API : catégorie (NSPrivacyAccessedAPITypeReasons) — une raison spécifique de la liste approuvée par Apple, et NSPrivacyAccessedAPIType — l'identifiant de la catégorie d'API.

<!-- PrivacyInfo.xcprivacy -->
<?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>NSPrivacyAccessedAPICategoryFileTimestamp</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>C617.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

Catégories de données dans NSPrivacyCollectedDataTypes

Les types de données sont divisés en plusieurs catégories : informations de contact (nom, email, téléphone), finances (données de paiement), identifiants (IDFA, ID utilisateur), données d'utilisation (journaux, clics), diagnostic (journaux de crash) et contenu utilisateur (photos, vidéos, fichiers). Chaque catégorie est en outre marquée comme « liée à l'utilisateur » ou « non liée ».

Liée signifie que les données sont associées au compte de l'utilisateur ; non liée signifie que les données sont agrégées ou anonymisées. Ce marquage affecte la façon dont Apple affiche l'étiquette de confidentialité : les données liées sont marquées en jaune, non liées — en vert.

Quelles API nécessitent une indication des raisons

Apple a identifié plusieurs catégories d'API, dont chaque utilisation doit être accompagnée d'une raison spécifique de la liste approuvée. Une raison est un code unique, par exemple C617.1 ou 35F9.1, qui correspond à un objectif spécifique autorisé par Apple.

Catégories principales de Required Reason API

La catégorie NSPrivacyAccessedAPICategoryFileTimestamp inclut les API pour accéder aux horodatages des fichiers (creationDate, modificationDate). Raisons : C617.1 (synchronisation de fichiers), 3B52.1 (sauvegarde), 0A2A.1 (antifraude).

La catégorie NSPrivacyAccessedAPICategoryDiskSpace inclut les API pour vérifier l'espace disque libre (NSFileManager. Vérifications (NSFileManager). Raisons : E174.1 (gestion du cache), 85F4.1 (téléchargement de contenu), B728.1 (diagnostic).

La catégorie NSPrivacyAccessedAPICategorySystemBootTime inclut les API d'accès au temps de démarrage du système (uptime). Une seule raison : 35F9.1 (mesure du temps de session pour l'analyse). Toute autre utilisation est considérée comme du fingerprinting.

Liste complète des catégories d'API

• FileTimestamp — accès aux horodatages des fichiers, autorisé pour la synchronisation et la sauvegarde
• DiskSpace — vérification de l'espace libre, autorisé pour la gestion du cache et les téléchargements
• SystemBootTime — temps de fonctionnement, autorisé uniquement pour l'analyse des sessions
• UserDefaults — accès aux UserDefaults d'autres applications, complètement interdit
• ActiveKeyboards — liste des claviers actifs, autorisé pour les développeurs IME
• SystemAperture — taille de l'encoche sur l'écran, autorisé pour les applications photo et AR

Chaque catégorie a de 1 à 5 raisons approuvées. Le développeur doit choisir la raison qui correspond le plus précisément à l'utilisation réelle de l'API. Fournir une raison inexacte peut entraîner le rejet de la compilation ou le bannissement du compte.

Exigences pour les SDK tiers

À partir du 1er mai 2024, tous les SDK tiers — qu'ils soient binaires ou open source — doivent inclure un Privacy Manifest dans leur package. Apple vérifie les manifestes de toutes les dépendances, et si au moins un SDK n'a pas de manifeste, la compilation sera rejetée.

Les principaux SDK (Firebase, Adjust, AppsFlyer, Facebook SDK) ont déjà mis à jour leurs packages. Si votre projet utilise un SDK peu connu, vérifiez sa version et si nécessaire mettez-le à jour ou contactez le développeur. Une solution temporaire consiste à ajouter un manifeste pour le SDK manuellement dans le projet, mais cela n'est pas recommandé en raison des divergences lors des mises à jour.

Comment créer Privacy Manifest dans Xcode

Vous pouvez créer PrivacyInfo.xcprivacy via le modèle intégré dans Xcode 15+ ou manuellement. Examinons les deux options.

Création via Xcode 15

Xcode 15 inclut un modèle Privacy Manifest : File → New → File → Resource → Privacy Manifest. Xcode crée un fichier avec une structure de base et remplit NSPrivacyTracking et des tableaux vides pour les API et les données. Après la création, vous devez spécifier manuellement les raisons pour chaque Required Reason API utilisée.

Le modèle ajoute automatiquement le fichier à la cible principale. Si le projet a plusieurs cibles (Extensions, Watch app), vous devez ajouter le manifeste à chacune. Xcode ne vérifie pas la présence du manifeste dans les dépendances au moment de la compilation — seulement à l'étape d'archivage.

// AppDelegate : vérification du manifeste en phase de développement
import Foundation

func validatePrivacyManifest() {
    guard let path = Bundle.main.path(
        forResource: "PrivacyInfo", ofType: "xcprivacy"
    ) else {
        print("PrivacyInfo.xcprivacy introuvable")
        return
    }
    guard let dict = NSDictionary(contentsOfFile: path)
    else { return }
    print("Privacy manifest loaded: \(dict.count) keys")
}

Création manuelle via XML

Vous pouvez créer PrivacyInfo.xcprivacy manuellement comme un fichier XML property list ordinaire. Pour ce faire, créez un fichier nommé PrivacyInfo.xcprivacy, écrivez l'en-tête plist standard et ajoutez un dictionnaire racine avec les clés nécessaires. Assurez-vous que le fichier est ajouté à la cible (Target Membership).

La méthode manuelle est utile lorsque vous devez ajouter un manifeste à une bibliothèque statique ou à une dépendance Package Manager sans utiliser l'interface Xcode. Après la compilation, vérifiez que le fichier est inclus dans le binaire à l'aide de la commande nm ou de l'archivage.

Validation du manifeste avant publication

Avant d'envoyer la compilation à l'App Store, vous devez vérifier que Privacy Manifest est correct et complet. Apple fournit plusieurs outils de validation.

Validateur intégré Xcode

Lors de l'archivage d'un projet (Product → Archive), Xcode effectue la validation du manifeste. Si une erreur est trouvée — manifeste manquant, raison incorrecte, catégorie vide — l'archivage échoue avec une erreur. Le journal d'erreurs s'affiche dans le navigateur d'issues, indiquant le SDK problématique et la catégorie d'API.

Une validation supplémentaire est effectuée du côté d'App Store Connect lors du téléchargement de la compilation. Si la validation échoue, la compilation est rejetée avec un email automatique contenant l'identifiant de l'API problématique et la correction recommandée.

Validation en ligne de commande

Pour automatiser la validation, utilisez des scripts qui analysent le binaire à la recherche d'utilisation de Required Reason API. Apple fournit l'outil libtool et des scripts de vérification de symboles, mais la communauté a développé des utilitaires plus pratiques.

# Recherche d'utilisation de l'API FileTimestamp dans le binaire
nm MyApp.app/MyApp | grep "NSFileCreationDate"

# Vérification de la présence de PrivacyInfo.xcprivacy dans l'application
find MyApp.app -name "*.xcprivacy"

Erreurs de validation courantes

L'erreur la plus courante est l'absence de manifeste dans l'un des SDK. Même si la cible principale contient un manifeste, Apple vérifie chaque binaire individuellement. La deuxième erreur la plus courante est un code de raison incorrect : utiliser une raison pour une catégorie d'API avec une API d'une autre catégorie.

La troisième erreur est la déclaration excessive d'API qui ne sont pas réellement utilisées. Les développeurs ajoutent toutes les raisons possibles « au cas où », ce qui alerte les réviseurs d'Apple. Ajoutez uniquement les catégories réellement utilisées. Utilisez l'analyseur statique Xcode pour vérifier.