Implementierung von PrivacyInfo.xcprivacy für iOS-Apps und SDKs

Wie implementiert man PrivacyInfo.xcprivacy für iOS-Apps? Die Implementierung von PrivacyInfo.xcprivacy erfordert das Hinzufügen eines gültigen Datenschutz-Manifests zu Ihrer Anwendungs- oder SDK-Ziel, die Deklaration genehmigter Begründungscodes für alle verwendeten Required Reason APIs (wie User Defaults oder System Boot Time) und die Überprüfung, ob Drittanbieter-Abhängigkeiten die für ihre Vertriebsform geltenden Anforderungen an Datenschutz-Manifeste und Signaturen erfüllen.

Ein Datenschutz-Manifest (PrivacyInfo.xcprivacy) ist eine standardisierte Eigenschaftslistendatei, die in iOS-Apps und Drittanbieter-SDKs gebündelt ist. Sie deklariert Datenerhebungskategorien, Tracking-Domain-Konfigurationen und genehmigte Begründungen für den Zugriff auf von Apple festgelegte Required Reason APIs. Seit dem 1. Mai 2024 müssen Apps, die bei App Store Connect eingereicht werden, genehmigte Gründe für die vom Code der App – einschließlich anwendbarem Drittanbieter-SDK-Code – verwendeten Required Reason APIs enthalten.

Grundlegendes zu Apples Anforderungen an Datenschutz-Manifeste für iOS-SDKs

Die Architektur von Datenschutz-Manifesten: Hauptanwendungs-Manifest vs. eingebettete SDK-Manifeste

Das Datenschutz-Manifest-Framework von Apple etabliert ein modulares Transparenzmodell über die gesamte iOS-Software-Lieferkette hinweg. Anstatt zu verlangen, dass die Host-Anwendung die internen Implementierungsdetails jeder importierten Bibliothek manuell überprüft und deklariert, unterteilt Apple die Datenschutz-Governance in verschiedene Ebenen:

• Hauptanwendungs-Manifest: Deckt die Erfassung von Erstanbieterdaten, App-weite Tracking-Domains und Required Reason APIs ab, die direkt vom Code des primären Anwendungsziels aufgerufen werden.
• Eingebettete SDK-Manifeste: Deklarationen für Required Reason APIs müssen von der App oder dem Drittanbieter-SDK-Code verwaltet werden, der diese APIs verwendet. Bei ausführbaren Dateien und dynamischen Bibliotheken muss das Bündel, das diese ausführbare Datei oder Bibliothek enthält, das relevante Datenschutz-Manifest einschließen; ein Drittanbieter-SDK kann sich nicht auf das Manifest der Host-App verlassen, um die Nutzung der Required Reason API des SDKs zu melden.
• Automatisierte Abhängigkeits-Aggregierung: Wenn eine Anwendung in Xcode 15 oder höher archiviert wird, durchläuft das Build-System den Abhängigkeitsgraphen, findet alle gebündelten PrivacyInfo.xcprivacy-Dateien und fasst sie zu einem einzigen, einheitlichen Datenschutzbericht zusammen.

Die vier Stammkonfigurationsschlüssel

Jede PrivacyInfo.xcprivacy-Datei ist als XML-Eigenschaftslistern-Wörterbuch strukturiert, das bis zu vier Schlüssel auf Stammebene enthält:

• NSPrivacyTracking (Boolean): Deklariert, ob die Anwendung oder das SDK Daten verwendet, die von der App für das Tracking gemäß den Definitionen von Apples App Tracking Transparency (ATT) gesammelt wurden.
• NSPrivacyTrackingDomains (Array von Strings): Listet die Internetdomains auf, mit denen sich die App oder das SDK verbindet und die Tracking durchführen. Wenn ein Benutzer keine ATT-Autorisierung erteilt, blockiert iOS Netzwerkverbindungen zu den in diesem Array deklarierten Domains. Wenn sich eine App oder ein SDK nicht mit Tracking-Domains verbindet, kann dieser Schlüssel weggelassen werden.
• NSPrivacyCollectedDataTypes (Array von Wörterbüchern): Meldet die von Apple definierten Kategorien von Daten, die die App oder das SDK über Personen sammelt, die die App verwenden, zusammen mit der Angabe, ob die Daten mit der Benutzeridentität verknüpft sind, ob sie für das Tracking verwendet werden und den betrieblichen Zwecken, für die sie erhoben werden.
• NSPrivacyAccessedAPITypes (Array von Wörterbüchern): Deklariert von Apple festgelegte Required Reason APIs, die von der Binärdatei aufgerufen werden, begleitet von genehmigten String-Begründungscodes.

App Store Connect Ingestion Enforcement and Error Diagnostics

App Store Connect erzwingt die Einhaltung von Datenschutz-Manifesten während der Binärdatenaufnahme:

• Fehlende API-Deklaration (ITMS-91053): Wird ausgelöst, wenn eine kompilierte Binärdatei oder verknüpfte Bibliothek ein Required Reason API-Symbol aufruft, der entsprechende Kategorienschlüssel jedoch in NSPrivacyAccessedAPITypes fehlt.
• Ungültige Begründungscode-Deklaration: Tritt auf, wenn ein Manifest eine nicht genehmigte, fehlerhafte oder veraltete Begründungszeichenfolge für eine bestimmte API-Kategorie deklariert.
• Fehlendes Required Third-Party SDK Manifest: Wird in den von Apples aktuellen Anforderungen für aufgeführte Drittanbieter-SDKs definierten Einreichungsszenarien durchgesetzt, wobei sowohl Datenschutz-Manifeste als auch gültige digitale Signaturen für Binärverteilungen erforderlich sind.

Entwickler, die Client-Attribution und Deep Linking integrieren, können die iOS SDK-Integrationsdokumentation für technische Spezifikationen bezüglich der Manifestdeklarationen konsultieren.

Siehe auch: iOS SDK ──> Mobile Attribution Architecture

Required Reason API-Kategorien und genehmigte Begründungscodes

Die fünf Required Reason API-Kategorien

Gemäß Apple Developer Technote TN3183 definiert Apple fünf spezifische API-Kategorien, die explizite Begründungscodes in NSPrivacyAccessedAPITypes erfordern. Mobile SDKs und iOS-Anwendungen interagieren üblicherweise mit vier Hauptkategorien:

• NSPrivacyAccessedAPICategoryUserDefaults: Zugriff auf lokale App-Einstellungen über UserDefaults oder NSUserDefaults.
• NSPrivacyAccessedAPICategorySystemBootTime: Messung vergangener Zeit oder von Zeitstempeln mithilfe von Systemstart-APIs wie sysctl(KERN_BOOTTIME) oder systemUptime.
• NSPrivacyAccessedAPICategoryDiskSpace: Überprüfung der Dateisystemkapazität über statfs, statvfs oder volumeAvailableCapacityKey.
• NSPrivacyAccessedAPICategoryFileTimestamp: Überprüfung von Erstellungs- oder Änderungsdaten von Dateien über stat, getattrlist oder contentModificationDateKey.
• NSPrivacyAccessedAPICategoryActiveKeyboards: Inspektion aktiver benutzerdefinierter Tastaturerweiterungen (wird hauptsächlich von spezialisierten Tastaturdienstprogrammen verwendet).

Ausgewählte Zuordnungen genehmigter Begründungscodes für gängige SDK-Anwendungsfälle

Die folgende Tabelle konzentriert sich auf Kategorien, die häufig in Allzweck-Mobil-SDKs vorkommen; konsultieren Sie Apples aktuelle Dokumentation für die vollständige Liste der Gründe, einschließlich Active Keyboards. Um den Apple-Richtlinien zu entsprechen, müssen Entwickler Begründungscodes auswählen, die genau ihrer tatsächlichen Laufzeit-Datennutzung entsprechen:

Erstellen einer beispielhaften PrivacyInfo.xcprivacy-Eigenschaftsliste

Konfigurieren von Datenerhebungstypen

Das Array NSPrivacyCollectedDataTypes meldet die von Apple definierten Kategorien von Daten, die die App oder das SDK über Personen sammelt, die die App verwenden, zusammen mit der Angabe, ob die Daten mit der Benutzeridentität verknüpft sind, ob sie für das Tracking verwendet werden und den betrieblichen Zwecken, für die sie erhoben werden:

• NSPrivacyCollectedDataType: Der standardmäßige Apple-String-Bezeichner (z. B. NSPrivacyCollectedDataTypeDeviceID).
• NSPrivacyCollectedDataTypeLinked: Ein Boolescher Wert, der angibt, ob die Daten mit der Identität eines einzelnen Benutzers verknüpft sind.
• NSPrivacyCollectedDataTypeTracking: Ein Boolescher Wert, der angibt, ob die Daten für app-übergreifendes Tracking verwendet werden.
• NSPrivacyCollectedDataTypePurposes: Ein Array von Standard-Zweck-Strings (z. B. NSPrivacyCollectedDataTypePurposeAnalytics).

Deklarieren von Tracking-Domains

Wenn ein SDK oder eine Anwendung Tracking gemäß ATT-Definitionen durchführt, müssen alle entsprechenden Tracking-Domains unter NSPrivacyTrackingDomains deklariert werden. Wenn die Tracking-Autorisierung vom Benutzer nicht erteilt wird, blockiert iOS Netzwerkverbindungen zu deklarierten Domains. Wenn die App oder das SDK kein Tracking durchführt, sollte NSPrivacyTracking auf false gesetzt und NSPrivacyTrackingDomains kann weggelassen werden.

Die folgende Eigenschaftslisternkonfiguration veranschaulicht ein beispielhaftes PrivacyInfo.xcprivacy-Schema. Fügen Sie nur Kategorien und Gründe hinzu, die der tatsächlichen Implementierung Ihrer Anwendung entsprechen:

```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>

Beheben von Code-Signierfehlern bei CocoaPods-Ressourcen-Bundles

Die Grundursache: Fehlschläge beim Signieren von Ressourcen-Bundles in Xcode 15 und 16

Beim Integrieren von Abhängigkeiten über CocoaPods in Xcode 15 oder 16 stoßen Entwickler häufig auf Kompilierungsstopps:

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

Dieser Build-Fehler ist ein Integrationsproblem zwischen Xcode und CocoaPods:

• Eine herkömmliche statische .a-Bibliothek kann Ressourcen wie PrivacyInfo.xcprivacy nicht direkt enthalten. Apple empfiehlt, statischen SDK-Code und Ressourcen gemeinsam in einem statischen Framework zu verpacken.
• Einige CocoaPods-Integrationen generieren stattdessen separate Ressourcen-Bundle-Ziele, um Ressourcen neben statischen Bibliotheken zu verteilen.
• Bestimmte von CocoaPods generierte Ressourcen-Bundle-Ziele können Signierkonfigurationen erben, die dazu führen, dass Xcode-Builds anhalten und ein Entwicklungsteam anfordern. Dies ist ein Problem bei der Integration des Build-Systems und keine Anforderung des PrivacyInfo.xcprivacy-Schemas.

Anwenden gezielter Build-System-Workarounds im Podfile

Um diesen Fehler bei automatisierten Builds zu beheben, können Entwickler einen bereichsbezogenen post_install-Hook in ihrem Projekt-Podfile verwenden. Da es sich hierbei um einen Workaround für das Build-System bei nicht-ausführbaren Ressourcen-Bundles handelt, sollten Teams diesen auf bestimmte betroffene Bundle-Ziele beschränken oder betroffene Abhängigkeiten validieren, bevor sie Änderungen global anwenden.

Das folgende Ruby-Skript veranschaulicht, wie man durch CocoaPods-Ziele iteriert und das Signieren für bestimmte Ressourcen-Bundle-Ziele deaktiviert:

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

Prüfung und Generierung des aggregierten Datenschutzberichts in Xcode

Generieren des einheitlichen Datenschutzberichts über den Xcode Archive Organizer

So überprüfen Sie, ob alle Erstanbieter-Ziele und Drittanbieter-Abhängigkeiten vor dem Einreichen einer Binärdatei ordnungsgemäß deklariert wurden:

1. Öffnen Sie Ihr Projekt in Xcode 15 oder höher.
2. Wählen Sie Product > Archive, um ein Release-Archiv zu erstellen.
3. Klicken Sie im Xcode Organizer mit der rechten Maustaste (oder bei gedrückter Control-Taste) auf das Archiv und wählen Sie Generate Privacy Report.
4. Speichern und untersuchen Sie den generierten PDF-Bericht, um zu bestätigen, dass alle Required Reason APIs, Datenkategorien und Drittanbieter-SDK-Manifeste korrekt angezeigt werden.

Statische Analyse über die Befehlszeile: Heuristische Scans vor der Einreichung

Entwicklungsteams können heuristische Vorab-Prüfungen in Continuous-Integration-Pipelines (CI/CD) implementieren, indem sie kompilierte Binärdateien mit nm und otool nach eingeschränkten Symbolen durchsuchen:

# 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"

Das Vorhandensein eines Symbols allein begründet noch nicht, welcher genehmigte Grund zutrifft; überprüfen Sie den tatsächlichen Aufrufpfad und Anwendungsfall, bevor Sie das Manifest ändern. Teams müssen Xcodes Generate Privacy Report und die Vorab-Prüfungen von App Store Connect für eine verbindliche Verifizierung verwenden.

Diagnosematrix: Grundursachen für Ablehnungen von Datenschutz-Manifesten im App Store

Zusammenfassung und Entscheidungsrahmen

Das Datenschutz-Manifest-Framework von Apple erzwingt Transparenz über die gesamte iOS-Software-Lieferkette hinweg. Um reibungslose App Store-Einreichungen zu gewährleisten, müssen Entwicklungsteams Erstanbieter-Code auf die Verwendung von Required Reason APIs überprüfen, sicherstellen, dass Drittanbieter-SDK-Abhängigkeiten die für ihre API-Nutzung geltenden Anforderungen an das Datenschutz-Manifest erfüllen, und das Signieren von CocoaPods-Ressourcen-Bundles entsprechend verwalten.

Für produktspezifische Deklarationen von Datenschutz-Manifesten lesen Sie die OpoInstall-Dokumentation und vergleichen Sie das ausgelieferte Manifest mit der tatsächlichen Integration der Anwendung sowie den aktuellen Anforderungen von Apple.

Verwandte Materialien

• Konzepte: Datenschutz-Manifeste, Required Reason APIs, Signieren von Ressourcen-Bundles, Datenschutzberichte, App Store-Konformität

• Technologien: Xcode 15+, CocoaPods Dependency Manager, Swift Package Manager, OpoInstall iOS SDK

• Standards: Apple Privacy Manifest Specification, App Store Review Guidelines Abschnitt 5.1.1

• APIs & Konfigurationen: PrivacyInfo.xcprivacy, NSPrivacyAccessedAPITypes, Podfile post_install Hook

Offizielle Dokumentation

• Apple Developer Documentation on Describing Use of Required Reason API

• Apple Developer Documentation on Privacy Manifest Files

• Apple Developer Documentation on Upcoming Third-Party SDK Requirements

• Apple App Store Review Guidelines Section 5.1.1