Comment implémenter PrivacyInfo.xcprivacy pour les applications et SDKs iOS

Comment implémenter PrivacyInfo.xcprivacy pour les applications iOS ? L'implémentation de PrivacyInfo.xcprivacy nécessite d'ajouter un manifeste de confidentialité valide à votre application ou à votre cible SDK, de déclarer les codes de motifs approuvés pour toutes les API soumises à des motifs requis utilisées (telles que User Defaults ou System Boot Time), et de vérifier que les dépendances tierces satisfont aux exigences de manifeste de confidentialité et de signature applicables à leur forme de distribution.

Un manifeste de confidentialité (PrivacyInfo.xcprivacy) est un fichier de liste de propriétés standardisé intégré aux applications iOS et aux SDKs tiers qui déclare les catégories de collecte de données, les configurations de domaines de suivi et les justificatifs approuvés pour l'accès aux API à motifs requis désignées par Apple. Depuis le 1er mai 2024, les applications soumises à App Store Connect doivent inclure des motifs approuvés pour les API à motifs requis utilisées par le code de l'application, y compris le code des SDKs tiers applicables.

Comprendre les exigences d'Apple en matière de manifeste de confidentialité pour les SDKs iOS

L'architecture des manifestes de confidentialité : manifeste de l'application principale vs manifestes de SDKs intégrés

Le framework de manifeste de confidentialité d'Apple établit un modèle de transparence modulaire dans l'ensemble de la chaîne d'approvisionnement logicielle iOS. Plutôt que d'exiger de l'application hôte qu'elle audite et déclare manuellement les détails d'implémentation internes de chaque bibliothèque importée, Apple divise la gouvernance de la confidentialité en couches distinctes :

• Manifeste de l'application principale : couvre la collecte de données de première partie, les domaines de suivi au niveau de l'application et les API à motifs requis invoquées directement par le code de la cible de l'application principale.
• Manifestes de SDKs intégrés : les déclarations d'API à motifs requis doivent appartenir à l'application ou au code du SDK tiers qui utilise ces API. Pour les exécutables et les bibliothèques dynamiques, le bundle contenant cet exécutable ou cette bibliothèque doit inclure le manifeste de confidentialité pertinent ; un SDK tiers ne peut pas s'appuyer sur le manifeste de l'application hôte pour signaler l'utilisation par le SDK d'une API à motifs requis.
• Agrégation automatisée des dépendances : lorsqu'une application est archivée dans Xcode 15 ou version ultérieure, le système de build parcourt le graphique des dépendances, découvre tous les fichiers PrivacyInfo.xcprivacy regroupés et les agrège en un rapport de confidentialité unique et unifié.

Les quatre clés de configuration racine

Chaque fichier PrivacyInfo.xcprivacy est structuré sous la forme d'un dictionnaire de liste de propriétés XML contenant jusqu'à quatre clés de niveau racine :

• NSPrivacyTracking (Booléen) : déclare si l'application ou le SDK utilise des données collectées à partir de l'application à des fins de suivi selon les définitions de la transparence du suivi des applications (ATT) d'Apple.
• NSPrivacyTrackingDomains (Tableau de chaînes) : répertorie les domaines Internet connectés par l'application ou le SDK qui effectuent un suivi. Si un utilisateur n'accorde pas l'autorisation ATT, iOS bloque les connexions réseau vers les domaines déclarés dans ce tableau. Si une application ou un SDK ne se connecte pas à des domaines de suivi, cette clé peut être omise.
• NSPrivacyCollectedDataTypes (Tableau de dictionnaires) : rapporte les catégories de données définies par Apple que l'application ou le SDK collecte sur les personnes utilisant l'application, ainsi que le fait de savoir si les données sont liées à l'identité de l'utilisateur, si elles sont utilisées pour le suivi et les finalités opérationnelles pour lesquelles elles sont collectées.
• NSPrivacyAccessedAPITypes (Tableau de dictionnaires) : déclare les API à motifs requis désignées par Apple invoquées par le binaire, accompagnées de codes de motifs textuels approuvés.

Application par App Store Connect et diagnostics d'erreurs

App Store Connect applique les manifestes de confidentialité lors de l'ingestion des binaires :

• Déclaration d'API manquante (ITMS-91053) : déclenchée lorsqu'un binaire compilé ou une bibliothèque liée appelle un symbole d'API à motifs requis, mais que la clé de catégorie correspondante est absente de NSPrivacyAccessedAPITypes.
• Déclaration de code de motif invalide : se produit lorsqu'un manifeste déclare une chaîne de motif non approuvée, mal formatée ou obsolète pour une catégorie d'API spécifique.
• Manifeste de SDK tiers requis manquant : appliqué dans les scénarios de soumission définis par les exigences actuelles d'Apple en matière de SDK tiers pour les SDKs répertoriés, exigeant à la fois des manifestes de confidentialité et des signatures numériques valides pour les distributions binaires.

Les développeurs intégrant l'attribution client et le deep linking peuvent consulter la documentation d'intégration du SDK iOS pour connaître les spécifications techniques concernant les déclarations de manifestes.

Voir aussi : SDK iOS ──> Architecture d'attribution mobile

Catégories d'API à motifs requis et codes de motifs approuvés

Les cinq catégories d'API à motifs requis

Selon la note technique TN3183 d'Apple Developer, Apple définit cinq catégories d'API spécifiques qui nécessitent des codes de justification explicites dans NSPrivacyAccessedAPITypes. Les SDKs mobiles et les applications iOS interagissent généralement avec quatre catégories principales :

• NSPrivacyAccessedAPICategoryUserDefaults : accès aux paramètres locaux de l'application via UserDefaults ou NSUserDefaults.
• NSPrivacyAccessedAPICategorySystemBootTime : mesure du temps écoulé ou des horodatages à l'aide d'API de démarrage du système telles que sysctl(KERN_BOOTTIME) ou systemUptime.
• NSPrivacyAccessedAPICategoryDiskSpace : inspection de la capacité du système de fichiers via statfs, statvfs ou volumeAvailableCapacityKey.
• NSPrivacyAccessedAPICategoryFileTimestamp : vérification des dates de création ou de modification de fichiers via stat, getattrlist ou contentModificationDateKey.
• NSPrivacyAccessedAPICategoryActiveKeyboards : inspection des extensions de claviers personnalisés actifs (principalement utilisées par des utilitaires de clavier spécialisés).

Mappages de codes de motifs approuvés sélectionnés pour les cas d'utilisation courants des SDKs

Le tableau ci-dessous se concentre sur les catégories couramment rencontrées dans les SDKs mobiles polyvalents ; consultez la documentation actuelle d'Apple pour obtenir la liste complète des motifs, y compris les claviers actifs. Pour se conformer aux directives d'Apple, les développeurs doivent sélectionner des codes de motifs qui correspondent strictement à leur utilisation réelle des données au moment de l'exécution :

Construction d'un exemple de liste de propriétés PrivacyInfo.xcprivacy

Configuration des types de collecte de données

Le tableau NSPrivacyCollectedDataTypes rapporte les catégories de données définies par Apple que l'application ou le SDK collecte sur les personnes utilisant l'application, ainsi que le fait de savoir si les données sont liées à l'identité de l'utilisateur, si elles sont utilisées pour le suivi et les finalités opérationnelles pour lesquelles elles sont collectées :

• NSPrivacyCollectedDataType : l'identifiant textuel standard d'Apple (par ex., NSPrivacyCollectedDataTypeDeviceID).
• NSPrivacyCollectedDataTypeLinked : un booléen indiquant si les données sont liées à l'identité d'un utilisateur individuel.
• NSPrivacyCollectedDataTypeTracking : un booléen indiquant si les données sont utilisées pour le suivi inter-applications.
• NSPrivacyCollectedDataTypePurposes : un tableau de chaînes de finalités standard (par ex., NSPrivacyCollectedDataTypePurposeAnalytics).

Déclaration des domaines de suivi

Si un SDK ou une application effectue un suivi selon les définitions de l'ATT, tous les domaines de suivi correspondants doivent être déclarés sous NSPrivacyTrackingDomains. Si l'autorisation de suivi n'est pas accordée par l'utilisateur, iOS bloque les connexions réseau vers les domaines déclarés. Si l'application ou le SDK n'effectue pas de suivi, NSPrivacyTracking doit être défini sur false et NSPrivacyTrackingDomains peut être omis.

La configuration de liste de propriétés ci-dessous illustre un exemple de schéma PrivacyInfo.xcprivacy. N'incluez que les catégories et les motifs qui reflètent l'implémentation réelle de votre application :

```xml
<?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>NSPrivacyCollectedDataTypes</key>
    <array>
        <dict>
            <key>NSPrivacyCollectedDataType</key>
            <string>NSPrivacyCollectedDataTypeDeviceID</string>
            <key>NSPrivacyCollectedDataTypeLinked</key>
            <false/>
            <key>NSPrivacyCollectedDataTypeTracking</key>
            <false/>
            <key>NSPrivacyCollectedDataTypePurposes</key>
            <array>
                <string>NSPrivacyCollectedDataTypePurposeAnalytics</string>
                <string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
            </array>
        </dict>
    </array>
    <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>NSPrivacyAccessedAPICategorySystemBootTime</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>35F9.1</string>
            </array>
        </dict>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryDiskSpace</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>E174.1</string>
            </array>
        </dict>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>C617.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

Résolution des erreurs de signature de code de bundles de ressources CocoaPods

La cause racine : échecs de signature de bundles de ressources dans Xcode 15 et 16

Lors de l'intégration de dépendances via CocoaPods dans Xcode 15 ou 16, les développeurs rencontrent fréquemment des arrêts de compilation :

Signing for "libOpoInstallSDK-OPPrivacy" requires a development team. Select a development team in the Signing & Capabilities editor.

Cet échec de build est un problème d'intégration entre Xcode et CocoaPods :

• Une bibliothèque statique .a traditionnelle ne peut pas contenir directement des ressources telles que PrivacyInfo.xcprivacy. Apple recommande de regrouper le code et les ressources d'un SDK statique au sein d'un framework statique.
• Certaines intégrations CocoaPods génèrent à la place des cibles de bundles de ressources distinctes pour distribuer les ressources aux côtés des bibliothèques statiques.
• Certaines cibles de bundles de ressources générées par CocoaPods peuvent hériter de configurations de signature qui provoquent l'arrêt des builds Xcode en demandant une équipe de développement. Il s'agit d'un problème d'intégration du système de build plutôt que d'une exigence du schéma PrivacyInfo.xcprivacy.

Application de contournements ciblés du système de build dans le Podfile

Pour résoudre cette erreur dans les builds automatisés, les développeurs peuvent utiliser un hook post_install ciblé dans le fichier Podfile de leur projet. Comme il s'agit d'un contournement du système de build pour les bundles de ressources non exécutables, les équipes doivent le limiter à des cibles de bundles spécifiques affectées ou valider les dépendances concernées avant d'appliquer les modifications de manière globale.

Le script Ruby ci-dessous montre comment parcourir les cibles CocoaPods et désactiver la signature sur des cibles de bundles de ressources désignées :

post_install do |installer|
  # Specify non-executable resource bundle targets that encounter signing errors without a development team
  target_bundle_names = [
    'libOpoInstallSDK-OPPrivacy'
  ]

  installer.pods_project.targets.each do |target|
    if target.respond_to?(:product_type) &&
       target.product_type == "com.apple.product-type.bundle" &&
       target_bundle_names.include?(target.name)
      target.build_configurations.each do |config|
        # Strip code signing requirement from designated non-executable resource bundles
        config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
        config.build_settings['CODE_SIGN_IDENTITY'] = ''
      end
    end
  end
end

Audit et génération du rapport de confidentialité agrégé dans Xcode

Génération du rapport de confidentialité unifié via l'organisateur d'archives de Xcode

Pour vérifier que toutes les cibles de première partie et les dépendances tierces sont correctement déclarées avant de soumettre un binaire :

1. Ouvrez votre projet dans Xcode 15 ou version ultérieure.
2. Sélectionnez Product > Archive pour créer une archive de publication.
3. Dans l'organisateur Xcode, faites un clic droit (ou Control-clic) sur l'archive et sélectionnez Generate Privacy Report.
4. Enregistrez et inspectez le rapport PDF généré pour confirmer que toutes les API à motifs requis, catégories de données et manifestes de SDKs tiers apparaissent correctement.

Analyse statique en ligne de commande : scans heuristiques pré-soumission

Les équipes de développement peuvent implémenter des audits heuristiques pré-soumission dans les pipelines d'intégration continue (CI/CD) en scannant les binaires compilés à la recherche de symboles restreints à l'aide de nm et otool :

# Scan unpacked application binary for candidate Required Reason API symbols
nm -u /path/to/Payload/YourApp.app/YourApp | grep -E 'sysctl|statfs|statvfs|getattrlist|NSUserDefaults'

# Check embedded frameworks and bundles for PrivacyInfo.xcprivacy manifests
find /path/to/Payload/YourApp.app -name "PrivacyInfo.xcprivacy"

La présence d'un symbole n'établit pas à elle seule quel motif approuvé s'applique ; examinez le chemin d'appel réel et le cas d'utilisation avant de modifier le manifeste. Les équipes doivent utiliser la fonction Generate Privacy Report de Xcode et les vérifications préalables d'App Store Connect pour une vérification officielle.

Matrice de diagnostic : causes racines des rejets de manifestes de confidentialité sur l'App Store

Résumé et cadre de décision

Le framework de manifeste de confidentialité d'Apple impose la transparence dans l'ensemble de la chaîne d'approvisionnement logicielle iOS. Garantir des soumissions fluides sur l'App Store exige des équipes de développement qu'elles auditent le code de première partie pour l'utilisation d'API à motifs requis, qu'elles vérifient que les dépendances de SDKs tiers satisfont aux exigences de manifeste de confidentialité applicables à leur utilisation d'API et qu'elles gèrent correctement la signature des bundles de ressources CocoaPods.

Pour les déclarations de manifestes de confidentialité spécifiques à votre produit, consultez la documentation OpoInstall et comparez le manifeste fourni avec l'intégration réelle de l'application et les exigences actuelles d'Apple.

Documents associés

• Concepts : Manifestes de confidentialité, API à motifs requis, Signature de code de bundles de ressources, Rapports de confidentialité, Conformité App Store

• Technologies : Xcode 15+, Gestionnaire de dépendances CocoaPods, Swift Package Manager, SDK iOS OpoInstall

• Normes : Spécification du manifeste de confidentialité d'Apple, Directives d'évaluation de l'App Store, Section 5.1.1

• API et configurations : PrivacyInfo.xcprivacy, NSPrivacyAccessedAPITypes, Hook post_install du Podfile

Documentation officielle

• Documentation Apple Developer sur la description de l'utilisation d'API à motifs requis

• Documentation Apple Developer sur les fichiers de manifestes de confidentialité

• Documentation Apple Developer sur les futures exigences relatives aux SDKs tiers

• Directives d'évaluation de l'App Store d'Apple, Section 5.1.1