Zum Hauptinhalt springen

Privacy Manifest für iOS-Apps

Compliance- und Troubleshooting-Guide 2026 für PrivacyInfo.xcprivacy in Capacitor iOS-Apps: Required Reason APIs, ITMS-91053, ITMS-91061 und Third-Party SDK Manifests.

Privacy Manifest für iOS-Apps Capgo Blog-Illustration

Apple Privacy Manifests sind für App Store Uploads verpflichtend: Jede App benötigt ein PrivacyInfo.xcprivacy das die Datenerfassung deiner App, Tracking-Domains und alle weiteren Informationen beschreibt erforderlichen Reason APIs beschreibt, deine code Aufrufe. Third-Party SDKs auf Apples Pflichtliste müssen eigene Manifeste (und Signaturen bei Verteilung als Binaries) mitliefern. 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 fasst beim Archivieren alle Manifeste zu einem einzigen Privacy Report zusammen.

Schlüssel Zweck
NSPrivacyTracking Ob Ihre App oder SDK Daten zum 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

Apples Übersicht: Ein Privacy Manifest für Ihre App oder Drittanbieter-SDK hinzufügen.

Sie sind für alle code in der Binary verantwortlich, inklusive eingebetteter SDKs. Ihr Manifest sollte nur Ihre App beschreiben. Kopieren Sie nicht die Datennutzung eines anderen SDK in Ihre Datei.

Erforderliche Gründe für API Kategorien

Seit 1. Mai 2024, lehnt der App Store Connect Uploads ab, wenn deine App eine gelistete API ohne genehmigten Grund in NSPrivacyAccessedAPITypes. Apple dokumentiert die APIs und genehmigten Gründe in Verwendung der erforderlichen API Gründe beschreiben.

Seit Apples TN3183, die Kategorie Werte sind:

NSPrivacyAccessedAPIType Wert Typische Trigger in Hybrid-Apps
NSPrivacyAccessedAPICategoryUserDefaults Einstellungen, Plugin-Status, kleine Persistenzdaten
NSPrivacyAccessedAPICategoryFileTimestamp Datei-Metadaten, Caches, Update-Bundles
NSPrivacyAccessedAPICategoryDiskSpace Speicherplatzprüfung vor Downloads
NSPrivacyAccessedAPICategorySystemBootTime Vergangene 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 die von Apple gelisteten Reason-Codes für diese Kategorie. Falsche Codes führen zu Review-Ablehnungen.

Beispiel-Fragment (passe Kategorien und Codes nach der Analyse 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 steht auf Apples Drittanbieter-SDK-Anforderungen Liste, daher liefert das Framework ein Manifest für die eigene API-Nutzung von Capacitor mit. Du brauchst trotzdem ein Manifest auf App-Ebene für deine 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 eine Required-Reason-API in deinem Build erkannt hat, für die es keinen passenden Eintrag in einem zusammengeführten Privacy Manifest gibt.

So geht's:

  1. Lies die Ablehnungs-E-Mail oder das Upload-Log. Dort wird die API- Kategorie sein (zum Beispiel NSPrivacyAccessedAPICategoryDiskSpace).
  2. Öffne den Privacy Report im Xcode-Archiv (Produkte > Archiv, dann Privacy Report generieren im Archiv) und prüfe, ob die Lücke in deinem App-Target oder einer Dependency liegt.
  3. Falls die API in deine code oder ein eigenes Plugin: Füge die Kategorie und einen validen Grund hinzu, um ios/App/PrivacyInfo.xcprivacy.
  4. Wenn API aus einer Abhängigkeitstammt, aktualisiere das Pod- oder SPM-Package auf eine Version mit Manifest oder patche das Plugin und deklariere nur das, was dein Fork tatsächlich aufruft.
  5. Erstelle ein neues Archiv und prüfe, ob die Kategorie im Report erscheint, bevor du erneut uploadest.

Deklariere keine Kategorien, die du nicht nutzt. Apples statische Analyse ist an Symbole in der Binary gebunden.

ITMS-91061: Fehlendes Privacy Manifest eines Drittanbieters

ITMS-91061 bedeutet ein datenschutzrelevantes SDK in deinem App-Bundle kein Privacy Manifest hat PrivacyInfo.xcprivacy. Apple gibt an, dass, wenn du eine neue App oder ein Update veröffentlichst, das fügt hinzu SDK hinzufügt, dieses SDK ein Manifest enthalten muss; auch binäre SDKs brauchen eine gültige Signatur, Signatur vom SDK-Anbieter.

Lösung:

  1. Kopiere den Framework-Pfad aus der E-Mail (z. B. Frameworks/FirebaseCore.framework/FirebaseCore).
  2. Identifiziere das CocoaPods-, SPM- oder vendored Binary-Paket.
  3. Upgrade auf ein Vendor-Release, das PrivacyInfo.xcprivacy im Framework-Root.
  4. Clean, Rebuild und Verifizierung der Datei im .xcarchive vor dem Upload.

Nicht Verschiebe 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 das SDK nicht mehr gepflegt wird, ersetze es oder nutze einen compliant Build.

Zu den aufgeführten SDKs gehören gängige Mobile Stacks (Firebase, Flutter, Capacitor, shared_preferences_iosund andere). Prüfe vor jedem Release die aktuelle Liste auf der Apple-Seite.

Manifeste und Signaturen von Drittanbieter-SDK

Beim Update einer Dependency prüft Xcode, ob Binary Frameworks vom selben Entwickler wie bei früheren Releases signiert wurden. Das schützt die Supply Chain, wenn sich Manifeste ändern.

Praktischer Workflow:

  • Danach pod install oder SPM auflösen, durchsuche ios/ für PrivacyInfo.xcprivacy Dateien.
  • Archivieren und nutzen Privacy Report generieren um das Gesamtbild zu sehen.
  • Vergleiche den Report mit deinen Antworten im App-Store-Datenschutzfragebogen.

Deklariere für live update-Tooling die Required-Reason-APIs, die dein Updater tatsächlich nutzt (z. B. Speicherplatz, Dateizeitstempel oder User Defaults). Netzwerkzugriff ist keine Required-Reason-API-Kategorie. Wenn der Updater personenbezogene Daten sammelt, gib diese Daten in deinen App-Store-Datenschutzangaben und Antworten im Datenschutzfragebogen an; das bloße Abrufen eines Updates über HTTPS begründet keine neue Offenlegungskategorie. Behalte Capgo live update Compliance beim Dokumentieren des OTA-Verhaltens bedenken.

Füge PrivacyInfo.xcprivacy in einem Capacitor iOS-Projekt

  1. Das native Projekt synchronisieren: bunx cap sync ios.
  2. Öffne den Xcode-Workspace unter ios/App.
  3. Datei > Neu > Datei, wähle App-Datenschutz (oder füge eine leere PrivacyInfo.xcprivacy plist hinzu).
  4. Speichere die Datei unter ios/App (im selben Ordner wie AppDelegate ist in Ordnung).
  5. In der Zielgruppe Build Phases &gt; Copy Bundle Resources, bestätige PrivacyInfo.xcprivacy ist aufgeführt.
  6. Trage Tracking, gesammelte Datentypen und die erforderlichen Reason-APIs basierend auf deiner App und den Plugins ein.
  7. Archiviere das Projekt, erstelle den Privacy-Report und behebe fehlende Kategorien, bevor du zu App Store Connect hochlädst.

Falls du die plist direkt als XML bearbeitest, öffne Xcode neu, damit die Target-Membership korrekt bleibt.

Jede App oder jedes SDK Target behält sein eigenes 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 wird, füge PrivacyInfo.xcprivacy unter dem Plugin- ios/Plugin/ Ordner (oder Äquivalent) und führen Sie ihn im Plugin-Target auf Bundle-Ressourcen kopieren, nicht nur im App-Target.

Wenn NSPrivacyTracking stimmt oder du bettest Ad- oder Analytics-SDKs ein, gleiche das Manifest mit den App Store Privacy Labels ab und zeige den App Tracking Transparency Prompt an, wenn iOS dies verlangt. @capgo/capacitor-app-tracking-transparency deckt den ATT-Flow für Capacitor-Apps ab.

Validierungs-Checkliste vor dem Submit

  • App-Target enthält PrivacyInfo.xcprivacy in einem Bundle-Ressourcen kopieren.
  • Jede erforderliche Reason-Kategorie in der Ablehnung oder im Bericht enthält genehmigte Reason-Codes.
  • Jedes 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 Quellcode in deinem Repo verteilt wird, ist dessen API-Nutzung Teil deiner App-Binary. Deklariere die APIs, die das Plugin aufruft, im App Manifest oder steuere ein Manifest innerhalb des Plugin-Targets 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 App dokumentieren.

Wo sind Apples Richtlinien-Termine dokumentiert?

Required Reason APIs: verpflichtend seit 1. Mai 2024. Regeln für Third-Party-Manifeste und Signaturen der gelisteten SDKs finden sich in Third-Party-SDK-Anforderungen.

Weiterlesen: Privacy Manifest für iOS Apps

Wenn du es nutzt Privacy Manifest für iOS-Apps um Sicherheit und Compliance zu planen, verbinden Sie es mit Verschlüsselung für die Implementierungsdetails in Encryption, Compliance für das Implementierungsdetail 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.

Live-Updates für Capacitor-Apps

Wenn ein Bug im Web-Layer live ist, liefere den Fix über Capgo aus, statt Tage auf die App-Store-Freigabe zu warten. Nutzer bekommen das Update im Hintergrund, während native Änderungen im normalen Review-Prozess bleiben.

Neues aus unserem Blog

Capgo gibt dir die besten Insights, um eine wirklich professionelle Mobile App zu erstellen.