Apple Privacy Manifests sind für App Store Uploads verpflichtend: jede App benötigt ein PrivacyInfo.xcprivacy das die Datenerhebung deiner App, Tracking-Domains und alle weiteren Informationen beschreibt Required Reason APIs deine code Aufrufe beschreibt. Third-Party SDKs auf Apples Pflichtliste müssen eigene Manifeste mitliefern (und Signaturen, wenn sie als Binaries verteilt werden). Dieser Guide konzentriert sich auf Compliance 2026 und Troubleshooting für Capacitor iOS-Apps: Was deklarieren, wie Fehler beheben ITMS-91053 und ITMS-91061, und wie du sie vor dem Submit validierst.
Was ein Privacy Manifest abdeckt
Ein Privacy Manifest ist eine Property List, die mit deiner App oder SDK gebündelt wird. Xcode aggregiert beim Archivieren alle Manifeste zu einem einzigen Privacy Report.
| Wichtig | Zweck |
|---|---|
NSPrivacyTracking |
Ob Ihre App oder SDK Daten für Tracking gemäß Apples Definition nutzt |
NSPrivacyTrackingDomains |
Am Tracking beteiligte Domains |
NSPrivacyCollectedDataTypes |
Erfasste Datentypen und deren Verwendung |
NSPrivacyAccessedAPITypes |
Erforderliche Reason-APIs, die Ihre eigene code nutzt, mit genehmigten Reason-Codes |
Übersicht von Apple: Ein Privacy Manifest zu Ihrer App oder einem Drittanbieter-SDK hinzufügen.
Sie sind für alle code im Binary verantwortlich, inklusive eingebetteter SDKs. Ihr Manifest sollte nur Ihre App beschreiben. Kopieren Sie nicht die Datennutzung eines anderen SDK in Ihre Datei.
Erforderliche API-Kategorien
Seit 1. Mai 2024, lehnt App Store Connect Uploads ab, wenn deine App eine aufgeführte API ohne genehmigten Grund in NSPrivacyAccessedAPITypes. Apple dokumentiert die APIs und genehmigten Gründe in Verwendung der erforderlichen API beschreiben.
Laut Apples TN3183 sind die Kategorie- Werte:
NSPrivacyAccessedAPIType Wert |
Typische Trigger in Hybrid-Apps |
|---|---|
NSPrivacyAccessedAPICategoryUserDefaults |
Einstellungen, Plugin-Status, kleine Persistenzdaten |
NSPrivacyAccessedAPICategoryFileTimestamp |
Datei-Metadaten, Caches, Update-Bundles |
NSPrivacyAccessedAPICategoryDiskSpace |
Verfügbarer Speicherplatz vor Downloads |
NSPrivacyAccessedAPICategorySystemBootTime |
Verstrichene Zeit, Timer oder absolute Zeitstempel |
NSPrivacyAccessedAPICategoryActiveKeyboards |
Keyboard-Extension oder Input-Erkennung |
Füge für jede genutzte Kategorie ein Dictionary mit NSPrivacyAccessedAPIType und NSPrivacyAccessedAPITypeReasons. Wähle nur den von Apple gelisteten Reason-Codes für diese Kategorie. Falsche Codes führen zur Ablehnung im Review.
Beispiel-Fragment (passe Kategorien und Codes nach der Prüfung des Privacy-Reports an deine App an):
<key>NSPrivacyAccessedAPITypes</key>
<array>
<dict>
<key>NSPrivacyAccessedAPIType</key>
<string>NSPrivacyAccessedAPICategoryUserDefaults</string>
<key>NSPrivacyAccessedAPITypeReasons</key>
<array>
<string>CA92.1</string>
</array>
</dict>
</array>
Capacitor selbst erscheint in Apples Drittanbieter-SDK-Anforderungen Liste, daher liefert das Framework ein Manifest für die eigene API-Nutzung von Capacitor. Du benötigst dennoch ein Manifest auf App-Ebene für deinem Native- und JavaScript-Layer, Plugins und alle APIs, die nicht durch Dependencies abgedeckt sind.
ITMS-91053: Fehlende API-Deklaration
ITMS-91053 bedeutet, dass App Store Connect einen erforderlichen API in deinem Build erkannt hat, ohne dass ein passender Eintrag im zusammengeführten Privacy Manifest existiert.
Beheben Sie es:
- Lies die Ablehnungs-E-Mail oder das Upload-Log. Dort wird der API genannt Kategorie- (zum Beispiel
NSPrivacyAccessedAPICategoryDiskSpace). - Öffne den Privacy Report des Archivs in Xcode (Produkte > Archiv, dann Privacy-Bericht erstellen für das Archiv) und prüfe, ob die Lücke in deinem App-Target oder einer Dependency liegt.
- Falls die API in deinem code oder einem eigenen Plugin liegt, füge die Kategorie und einen genehmigten Grund hinzu.
ios/App/PrivacyInfo.xcprivacy. - Kommt die API aus einer Dependency, aktualisiere das Pod- oder SPM-Package auf eine Version mit Manifest oder patche das Plugin und deklariere nur, was dein Fork tatsächlich aufruft.
- Erstelle erneut ein Archiv und bestätige, dass die Kategorie im Report erscheint, bevor du erneut hochlädst.
Deklariere keine Kategorien, die du nicht nutzt. Apples statische Analyse bezieht sich auf Symbole in der Binary.
ITMS-91061: Fehlendes Privacy Manifest eines Drittanbieters
ITMS-91061 bedeutet ein datenschutzrelevantes SDK in deinem App-Bundle kein PrivacyInfo.xcprivacyhat. Apple gibt an, dass beim Release einer neuen App oder eines Updates, das adds SDK hinzufügt, dieses SDK ein Manifest enthalten muss; binäre SDKs benötigen zudem eine gültige Signatur vom SDK Anbieter.
Beheben:
- Kopiere den Framework-Pfad aus der E-Mail (z. B.
Frameworks/FirebaseCore.framework/FirebaseCore). - Identifiziere das CocoaPods-, SPM- oder vendored Binary-Paket.
- Upgrade auf ein Vendor-Release mit gebündelten
PrivacyInfo.xcprivacyim Framework-Root. - Clean, Rebuild und Verifizierung der Datei im
.xcarchivevor dem Upload.
Nicht tun die SDK Collection oder API Deklarationen in dein App-Manifest. Apple warnt ausdrücklich, dass das App-Manifest nur die App selbst beschreiben darf. Falls SDK nicht mehr gepflegt wird, ersetze es oder nutze ein konformes Vendor-Build.
Zu den gelisteten SDKs gehören gängige Mobile-Stacks (Firebase, Flutter, Capacitor, shared_preferences_ios, u. a.). Prüfe vor jedem Release die aktuelle Liste auf Apples Website.
Third-party SDK Manifests und Signaturen
Beim Update einer Dependency prüft Xcode, ob Binary Frameworks vom selben Developer wie vorherige Releases signiert wurden. Das schützt die Supply Chain bei Änderungen an den Manifesten.
Praktischer Workflow:
- Danach
pod installoder SPM auflösen, suchenios/fürPrivacyInfo.xcprivacyDateien. - Archivieren und nutzen Privacy-Bericht erstellen um das Gesamtbild zu sehen.
- Vergleiche den Report mit deinen Antworten im App Store Privacy Questionnaire.
Für live update Tooling: Deklariere die Required Reason APIs, die dein Updater tatsächlich nutzt (z. B. Speicherplatz, Datei-Timestamps oder User Defaults). Netzwerkzugriff ist keine Required Reason API Kategorie. Wenn der Updater personenbezogene Daten sammelt, gib dies in deinen App Store Privacy Labels und im Questionnaire an; das reine Abrufen eines Updates über HTTPS begründet keine neue Disclosure-Kategorie. Beachte Capgo live update Compliance beim Dokumentieren des OTA-Verhaltens zu beachten.
Füge PrivacyInfo.xcprivacy in einem Capacitor iOS-Projekt
- Das native Projekt synchronisieren:
bunx cap sync ios. - Öffne das Xcode-Workspace unter
ios/App. - Datei > Neu > Datei, wähle App-Datenschutz (oder füge eine leere
PrivacyInfo.xcprivacyplist hinzu). - Speichere die Datei unter
ios/App(im selben Ordner wieAppDelegateist in Ordnung). - In der Zielgruppe Build Phases > Copy Bundle Resources, bestätige
PrivacyInfo.xcprivacyist aufgeführt. - Trage Tracking, erfasste Datentypen und erforderliche Reason-APIs basierend auf deiner App und deinen Plugins ein.
- Archiviere das Projekt, erstelle den Privacy-Report und behebe fehlende Kategorien, bevor du es zu App Store Connect hochlädst.
Falls du die plist auf der Festplatte als XML bearbeitest, öffne Xcode neu, damit die Target-Membership korrekt bleibt.
Jede App oder jedes SDK-Target behält seine eigenen PrivacyInfo.xcprivacy. Beim Archivieren fasst Xcode diese Manifeste zu einem Privacy-Report zusammen. Du musst Dependency-Plists nicht manuell in deine App-Datei mergen.
Für ein eigenes Capacitor Plugin als eigenes iOS-Framework ausgeliefert, füge PrivacyInfo.xcprivacy unter dem entsprechenden Plugin- ios/Plugin/ Ordner (oder Äquivalent) hinzu und liste es im Plugin-Target unter Bundle-Ressourcen kopieren, nicht nur im App-Target.
Wenn NSPrivacyTracking auf true gesetzt ist oder du Ad- oder Analytics-SDKs einbindest, stimme das Manifest mit den App Store Privacy Labels ab und zeige den App Tracking Transparency Prompt an, wenn iOS dies erfordert. @capgo/capacitor-app-tracking-transparency deckt den ATT-Flow für Capacitor Apps ab.
Validierungs-Checkliste vor dem Submit
- App-Target enthält
PrivacyInfo.xcprivacyin Bundle-Ressourcen kopieren. - Jede erforderliche Kategorie in der Ablehnung oder im Bericht enthält genehmigte Reason-Codes.
- Jeder aufgeführte Drittanbieter-SDK im Build enthält sein eigenes Manifest am erwarteten Pfad.
- Der Privacy-Bericht stimmt mit deinem Verständnis von Analytics-, Ads- und Authentication-SDKs überein.
- Die App Store Privacy Labels stimmen mit dem zusammengeführten Bericht überein.
FAQ
Benötigen Capacitor Plugins eigene Privacy Manifests?
Wenn ein Plugin als Source in deinem Repo verteilt wird, ist dessen API Usage Teil deiner App-Binary. Deklariere die vom Plugin aufgerufenen APIs im App Manifest oder steuere ein Manifest im Plugin-Target bei, falls es als separates Framework ausgeliefert wird. Binary Pods müssen Apples Drittanbieter-SDK Regeln folgen.
Kann ich ITMS-91061 beheben, indem ich nur die PrivacyInfo.xcprivacy meiner App bearbeite?
Nein. Das SDK muss das Manifest mitliefern. Deine Datei sollte nur die Praktiken deiner eigenen App dokumentieren.
Wo sind die Richtlinien-Daten von Apple dokumentiert?
Pflichtangaben für APIs: seit 1. Mai 2024. Drittanbieter-Manifest- und Signaturregeln für gelistete SDKs finden sich in Anforderungen für Drittanbieter-SDK.
Weiterlesen: Privacy Manifest für iOS Apps
Wenn Sie ... verwenden Privacy Manifest für iOS-Apps nutzen, um Security und Compliance zu planen, verbinden Sie es mit Verschlüsselung für die Implementierungsdetails bei der Verschlüsselung, Compliance für die Implementierungsdetails in Compliance, Capgo Security Scanner für den Produkt-Workflow im Capgo Security Scanner, Capgo Sicherheit für den Produkt-Workflow in Capgo Security und Capgo Trust Center für den Produkt-Workflow im Capgo Trust Center.