LaunchLint Academy
Die kurze Antwort
- Ein Apple Privacy Manifest ist eine Datei namens PrivacyInfo.xcprivacy. Sie beschreibt Datenschutzpraktiken von App- und Drittanbieter-Code in einem standardisierten Format und enthält unter anderem zulässige Gründe für bestimmte Required Reason APIs.
- In React Native und Expo stammen relevante API-Aufrufe häufig aus nativen Abhängigkeiten. Prüfe deshalb nicht nur dein eigenes Manifest, sondern SDK-Versionen, Pods und den von Xcode zusammengeführten Privacy Report des finalen Release-Builds.
- Das Manifest ersetzt weder App Privacy in App Store Connect noch deine Datenschutzerklärung oder gegebenenfalls die App-Tracking-Transparency-Einwilligung. Diese Ebenen müssen sich ergänzen und den tatsächlichen Datenpraktiken entsprechen.
1. Was PrivacyInfo.xcprivacy tatsächlich beschreibt
Apple führte Privacy Manifests ein, damit Apps und SDKs Datenschutzpraktiken maschinenlesbar deklarieren können. Xcode kann die Manifeste der eingebetteten Drittanbieter zu einem Report zusammenführen. Das hilft, die im finalen Produkt enthaltenen SDK-Praktiken zu prüfen und App-Privacy-Angaben fundierter zu erstellen.
Das Manifest kann Kategorien erfasster Daten, Tracking-Domains, Tracking-Verhalten und Required-Reason-API-Zugriffe enthalten. Nicht jeder Schlüssel ist für jede App erforderlich. Kopiere deshalb kein großes Muster blind: Jeder Eintrag ist eine technische Behauptung über Code, der im ausgelieferten Bundle vorhanden ist.
| Ebene | Aufgabe | Ersetzt sie die anderen? |
|---|---|---|
| PrivacyInfo.xcprivacy | Technische Manifest-Deklaration | Nein |
| Xcode Privacy Report | Zusammenführung der Bundle-Manifeste | Nein |
| App Privacy | Öffentliche Store-Angaben zu Datenpraktiken | Nein |
| Datenschutzerklärung | Erklärung von Erhebung, Nutzung, Schutz, Aufbewahrung und Rechten | Nein |
2. Required Reason APIs brauchen einen erlaubten, tatsächlichen Grund
Bestimmte API-Kategorien können für Fingerprinting missbraucht werden und benötigen deshalb einen von Apple vorgesehenen Grund. Dazu gehören aktuell unter anderem Zugriffe rund um UserDefaults, Dateizeitstempel, System-Bootzeit, freien Speicher und aktive Tastaturen. Apple kann die Liste und zulässigen Gründe erweitern; prüfe daher stets die aktuelle Dokumentation.
Ein Reason Code ist keine freie Beschreibung. Wähle nur einen von Apple zugelassenen Grund, der zur tatsächlichen Verwendung passt. Ein Code darf nicht vorsorglich eingetragen werden, um eine Warnung verschwinden zu lassen. Wenn die App oder ein SDK die API für einen anderen Zweck nutzt, muss die Implementierung beziehungsweise Abhängigkeit korrigiert werden.
3. Drittanbieter-SDKs sind Teil deiner Einreichung
Apple führt eine Liste häufig verwendeter SDKs, für die bei bestimmten Einreichungen Privacy Manifest und bei binären Abhängigkeiten eine Signatur erforderlich sind. Auf der Liste stehen Komponenten, die auch in React-Native-Stacks häufig indirekt vorkommen, etwa hermes, Firebase-Bibliotheken, GoogleUtilities, Protobuf, OneSignal oder SDWebImage.
Du bleibst für eingebundenen Drittanbieter-Code verantwortlich. Aktualisiere ein problematisches SDK bevorzugt auf eine Version mit korrektem Hersteller-Manifest. Ein eigenes Sammelmanifest sollte nicht dazu dienen, falsche oder veraltete Angaben eines SDKs ohne Kontext zu überdecken. Dokumentiere Version, Quelle, enthaltenes Manifest und die tatsächlich aktivierte SDK-Funktion.
SDK-Prüfung:
- Direkte und transitive native Abhängigkeiten erfassen
- Apple-Liste der betroffenen SDKs gegenprüfen
- Hersteller-Dokumentation und Release Notes lesen
- PrivacyInfo.xcprivacy im Pod oder Framework lokalisieren
- SDK-Signatur bei binären Abhängigkeiten beachten
- Nicht genutzte Module und alte SDK-Versionen entfernen
- Nach jedem SDK-Update den finalen Report neu erzeugen
4. Privacy Manifest in Expo und React Native konfigurieren
Bei Expo mit Continuous Native Generation kann das Manifest über expo.ios.privacyManifests in app.json oder app.config gesetzt werden. In einem bestehenden Bare-React-Native-Projekt legst du PrivacyInfo.xcprivacy im iOS-Projekt an und fügst sie dem richtigen App-Target hinzu. Änderungen an diesem Bereich erfordern einen neuen nativen Build; ein JavaScript-OTA-Update genügt nicht.
{
"expo": {
"ios": {
"privacyManifests": {
"NSPrivacyAccessedAPITypes": [
{
"NSPrivacyAccessedAPIType":
"NSPrivacyAccessedAPICategoryUserDefaults",
"NSPrivacyAccessedAPITypeReasons": ["CA92.1"]
}
]
}
}
}
}Das Beispiel ist keine universelle Vorlage. Prüfe den Code CA92.1 und jede weitere Kategorie gegen Apples aktuelle Beschreibung und deinen konkreten Zugriff. Bei dynamischer app.config muss außerdem klar sein, welche Werte das Produktionsprofil erzeugt. Committe die Konfiguration und dokumentiere den Build, in dem sie erstmals enthalten ist.
- Konfiguration im Produktionsprofil auflösen
- Syntax und erlaubte Keys prüfen
- Reason Codes mit konkreter Nutzung verbinden
- Manifest dem richtigen iOS-Target zuordnen
- Nach Änderung neues Binary bauen
- Build-Nummer erhöhen und Artefakt erneut validieren
5. Das finale Bundle ist die belastbare Nachweis
Eine Datei im Projekt beweist nur eine Absicht. Entscheidend ist der archivierte Release-Build mit allen Pods, Frameworks und Resource Bundles. Öffne den Xcode-Privacy-Report beziehungsweise untersuche das Archiv und prüfe, welche Manifeste tatsächlich enthalten und zusammengeführt wurden. Statische CocoaPods-Abhängigkeiten können besondere Aufmerksamkeit benötigen; Expo weist auf Grenzen der automatischen Auswertung hin.
Validiere außerdem mehrere Targets: Haupt-App, Extensions, Widgets oder Notification Service Extensions können eigene Abhängigkeiten und Manifeste haben. Ein korrektes Manifest im Haupt-Target heilt keine fehlende Deklaration in einem separaten ausgelieferten Target. Bewahre Report, Build-Nummer und Dependency-Lockfile als Dokumentation zur Veröffentlichung auf.
Finale Kontrolle:
- Release statt Development archiviert
- Alle App- und Extension-Targets erfasst
- Zusammengeführten Privacy Report gelesen
- Unerwartete Datentypen oder Tracking-Domains untersucht
- Required-Reason-Kategorien gegen Nutzung geprüft
- Upload-Warnungen dem exakten Build zugeordnet
- Fix im neu gebauten Artefakt bestätigt
6. Manifest, App Privacy und ATT nicht verwechseln
App Privacy in App Store Connect beschreibt öffentlich, welche Daten die App und ihre Partner erheben und wie sie verwendet werden. PrivacyInfo.xcprivacy ist eine technische Deklaration im Bundle. Die Werte können sich gegenseitig informieren, werden aber nicht automatisch zu einer vollständigen Store-Antwort. Eigene Backends und dynamische Konfiguration bleiben außerhalb eines reinen SDK-Manifests relevant.
Auch App Tracking Transparency ist eine andere Ebene. Wenn Daten für Tracking im Sinne von Apple verwendet werden, kann eine Einwilligung erforderlich sein. Ein NSPrivacyTracking-Eintrag erteilt keine Erlaubnis und ein ATT-Dialog ersetzt keine korrekte App-Privacy-Angabe. Prüfe Zweck, Verknüpfung und Drittanbieterzugriff gemeinsam.
7. Fehlende Manifest-Angaben systematisch beheben
Ordne jede Warnung zuerst einer API-Kategorie und dann dem verursachenden Modul zu. Suche im eigenen nativen Code, in Pods und Frameworks, prüfe Hersteller-Updates und verifiziere den tatsächlichen Verwendungszweck. Ändere erst danach das Manifest oder die Abhängigkeit. Diese Reihenfolge verhindert unzulässige Reason Codes und dauerhafte Workarounds.
LaunchLint kann PrivacyInfo-Dateien, Expo-Konfiguration, SDK-Versionen und Required-Reason-Kategorien statisch mit Dateipfaden inventarisieren. Es führt aber keinen Build aus und kann deshalb nicht behaupten, den finalen Xcode-Report gesehen zu haben. Die Fix-Aufgabe sollte klar zwischen Nachweise in den Projektdateien und einer manuellen Bundle-Verifikation unterscheiden.
Fix-Protokoll:
- Upload-Warnung und Build-ID sichern
- API-Kategorie dem Modul zuordnen
- Zulässigen Grund fachlich prüfen
- SDK aktualisieren oder Nutzung entfernen
- Manifest eng und korrekt anpassen
- Neues Release-Binary erzeugen
- Xcode-Report und erneuten Upload prüfen
- App Privacy und Datenschutzerklärung bei Bedarf aktualisieren
Häufige Fragen
Braucht jede React-Native-App eine eigene PrivacyInfo.xcprivacy?
Nicht jede App braucht dieselben eigenen Einträge. Relevant sind die im finalen Bundle enthaltenen API-Nutzungen und SDKs. Viele Projekte benötigen wegen eigener oder eingebetteter Required-Reason-APIs ein Manifest beziehungsweise korrekte SDK-Manifeste.
Kann ich die Reason Codes aus einem anderen Projekt kopieren?
Nein. Ein Code ist nur zulässig, wenn der von Apple beschriebene Grund auf die tatsächliche Nutzung passt. Kopieren kann eine Warnung verdecken und eine falsche Deklaration erzeugen.
Ersetzt das Privacy Manifest das App-Privacy-Label?
Nein. Das Manifest ist Bundle-Metadaten; App Privacy ist die öffentliche Store-Erklärung. Zusätzlich bleiben Datenschutzerklärung und gegebenenfalls ATT relevant.
Reicht ein OTA-Update für eine Manifest-Korrektur?
Nein. PrivacyInfo.xcprivacy ist Teil des nativen iOS-Artefakts. Eine Änderung erfordert einen neuen Build und eine neue Einreichung mit höherer Build-Nummer.