iOS-Datenschutzmanifest fehlt? Archive-Fehlersuche 2026

Prüfen Sie zuerst Fehlercode, Meldungstext und Komponentenpfad; stellen Sie danach fest, ob das iOS-Datenschutzmanifest fehlt, ungültig ist oder zu einem eingebundenen Drittanbieter-SDK gehört. Ändern Sie nicht vorschnell das App-Manifest: Kontrollieren Sie nach der Korrektur immer das tatsächlich erzeugte Archive und verifizieren Sie erst dann den Upload erneut. Das Vorgehen gilt besonders, wenn Sie kurz vor einer Einreichung eine SDK-Version aktualisiert oder Abhängigkeiten neu aufgelöst haben.

Dieser Leitfaden ist für Sie gedacht, wenn App Store Connect eine ITMS-91061- oder eine ähnliche Meldung anzeigt und Sie den betroffenen Bestandteil nicht sofort erkennen. Er hilft kleinen Teams, CocoaPods-, Swift-Package- und XCFramework-Abhängigkeiten gezielt zu prüfen. Auch wenn Sie Releases über einen Remote Mac oder eine CI-Umgebung erstellen, können Sie die abschließende Archive-Kontrolle in Ihren Ablauf aufnehmen.

Die Meldung ist der Ausgangspunkt, nicht schon die Diagnose

Ein Upload-Hinweis ist zunächst ein technischer Befund zum eingereichten Build. Er sagt nicht automatisch aus, dass die gesamte App gegen eine Datenschutzvorgabe verstößt oder dass eine Review-Entscheidung gefallen ist. Lesen Sie deshalb die vollständige Benachrichtigung, bevor Sie Dateien hinzufügen oder Projektziele ändern. Apple beschreibt Anforderungen an betroffene Drittanbieter-SDKs in der Dokumentation zu Third-Party-SDK-Anforderungen.

Bei ITMS-91061 ist insbesondere der angegebene SDK-Name oder Paketpfad wichtig. Er kann auf eine Abhängigkeit verweisen, die in der gebauten App enthalten ist, nicht unbedingt auf eine Datei, die Sie selbst im Quellcode angelegt haben. Behandeln Sie den Code deshalb als Suchhinweis und lesen Sie den konkreten Wortlaut: Meldungen zu einem fehlenden Manifest verlangen eine andere Prüfung als Hinweise auf eine vorhandene, aber ungültige Datei.

Die Tabelle grenzt die erste Untersuchung ein; sie ersetzt nicht den Abgleich mit dem vollständigen Apple-Bericht. Apple erläutert in der technischen Anmerkung TN3181 zur Fehlerbehebung bei ungültigen Datenschutzmanifesten, wie Sie typische Ursachen wie eine fehlerhafte Property List oder unzulässige Einträge systematisch untersuchen.

Wichtig: Kopieren Sie keine Angaben aus der Datenschutzdokumentation eines SDK in das Manifest Ihrer App, nur damit eine Meldung verschwindet. Ein SDK-Manifest beschreibt die relevanten Angaben des SDK; das App-Manifest muss die tatsächliche Verwendung in Ihrer App widerspiegeln.

App-Manifest und SDK-Manifest haben unterschiedliche Zuständigkeiten

Der Dateiname des Apple-Manifests lautet PrivacyInfo.xcprivacy. Apple beschreibt die Datei sowohl für Apps als auch für Drittanbieter-SDKs; das bedeutet aber nicht, dass eine einzelne Datei im Projekt automatisch alle eingebundenen Komponenten abdeckt. Die Apple-Anleitung zum Hinzufügen eines Datenschutzmanifests zu einer App oder einem Drittanbieter-SDK erklärt, wo die Datei im jeweiligen Paketkontext vorgesehen ist.

Bei der App sind drei Zustände auseinanderzuhalten: Die Datei kann im Quellordner liegen, dem richtigen Target zugeordnet sein und trotzdem im finalen Produkt fehlen. Das passiert etwa, wenn eine Datei nur in der Projektansicht sichtbar ist, aber nicht als Ressource des App-Targets verarbeitet wird. Umgekehrt kann eine Datei im App-Bundle vorhanden sein, während die Meldung einen anderen Pfad innerhalb eines eingebetteten SDKs bezeichnet.

Für SDKs liegt die Verantwortung nicht automatisch bei Ihnen, nur weil die App das Paket einbindet. Apple verlangt für bestimmte betroffene SDKs ein Datenschutzmanifest; prüfen Sie deshalb die aktuelle Liste der Anforderungen an Drittanbieter-SDKs und die Angaben des Paketherstellers. Ob ein SDK als Framework, XCFramework oder statische Abhängigkeit eingebunden ist, beeinflusst, wie Sie dessen Dateien im erzeugten Produkt wiederfinden. Leiten Sie den Ablageort daher aus dem konkreten Paket und der Apple-Anleitung ab, statt eine allgemeine Pfadregel auf alle Integrationsformen zu übertragen.

Die Dokumentation zu Datenschutzmanifest-Dateien beschreibt die Struktur und den Zweck der Datei. Darin können unter anderem Angaben zu Tracking, erfassten Datentypen, Tracking-Domains und verwendeten APIs enthalten sein. Wenn Ihre App eine in Apples Liste aufgeführte Required-Reason-API verwendet, muss der angegebene Grund zur tatsächlichen Nutzung passen; Apples Dokumentation zu Required-Reason-APIs ist dafür die maßgebliche Referenz.

Fehlerklasse vor der Reparatur festlegen

Fehlende Datei im App-Target: Prüfen Sie zunächst, ob PrivacyInfo.xcprivacy im Projekt vorhanden und dem App-Target zugewiesen ist. Öffnen Sie die Target-Einstellungen und die Build-Phasen, in denen Ressourcen in das Produkt kopiert werden. Verlassen Sie sich nicht allein auf die Projekt-Navigation: Entscheidend ist, was der aktuelle Build in das App-Bundle geschrieben hat.

Fehlende Datei in einem SDK: Verfolgen Sie den in App Store Connect genannten Pfad bis zum eingebetteten Framework oder Paket. Ermitteln Sie anschließend, wie die Abhängigkeit eingebunden wurde und welche Version tatsächlich im Archive steckt. Bei einem SDK, das Apples Anforderungen unterliegt, ist eine aktualisierte Anbieterversion mit gültigem Manifest der bevorzugte Korrekturweg. Falls die aktuelle Version keine passende Datei enthält, fragen Sie den Anbieter nach einer korrigierten Fassung und dokumentieren Sie die Abhängigkeit, die Version und den betroffenen Pfad.

Vorhandene, aber ungültige Datei: Behandeln Sie diesen Fall nicht als bloßes Fehlen. Ein Manifest kann wegen eines falschen Property-List-Formats, eines falschen Datentyps oder eines nicht unterstützten Werts abgelehnt werden. Apple nennt in TN3181 Prüfansätze für diese Fehlerklasse. Vergleichen Sie die beanstandete Stelle mit der offiziellen Struktur, statt erforderliche Felder oder Gründe zu erraten.

App-Nutzung einer Required-Reason-API: Prüfen Sie, ob die betreffende API tatsächlich verwendet wird und welcher dokumentierte Grund dafür zutrifft. Der Eintrag muss die Nutzung beschreiben, nicht eine Vermutung darüber, was die App möglicherweise tut. Wenn ein SDK die API verwendet, klären Sie die Angaben für dessen Manifest mit dem SDK-Anbieter; übernehmen Sie nicht ungeprüft einen Grund aus einem anderen Projekt.

Das finale Archive liefert den entscheidenden Nachweis

Führen Sie die Prüfung erst am Archive durch, das Sie wirklich hochladen möchten. In Xcode können Sie nach einem erfolgreichen Archive das erzeugte .xcarchive-Paket öffnen. Das App-Produkt liegt typischerweise unter Products/Applications; prüfen Sie darin PrivacyInfo.xcprivacy. Bei einer Meldung zu einem eingebetteten Framework kontrollieren Sie zusätzlich den betreffenden SDK- oder Framework-Pfad im Paket. Der genaue Ablageort ist abhängig davon, wie die Komponente ausgeliefert und in die App integriert wurde.

Wenn Sie ein Archive über die Oberfläche prüfen, notieren Sie den Build, den verwendeten Scheme-Namen und den Speicherort des Pakets. Bei einer wiederholbaren Veröffentlichung können Sie außerdem die Dateisuche auf das entpackte Archive anwenden und das Ergebnis als Prüfnachweis sichern. Eine mögliche lokale Kontrolle lautet:

find "/Pfad/zum/Produkt.xcarchive/Products/Applications" \
  -name "PrivacyInfo.xcprivacy" -print

Der Befehl zeigt, wo gleichnamige Dateien im App-Produkt liegen; er bewertet nicht selbst, ob jede Datei gültig ist oder zum beanstandeten SDK gehört. Vergleichen Sie die Ausgabe mit dem Pfad aus der Meldung und prüfen Sie die Datei mit den von Apple dokumentierten Regeln. Bei statischen Abhängigkeiten kann die Paketstruktur von der eines dynamischen Frameworks abweichen; wenden Sie deshalb die passenden Anbieterdokumente auf genau die verwendete Integrationsform an.

Gehen Sie bei der Korrektur in einer festen Reihenfolge vor:

1. Meldung sichern: Kopieren Sie Fehlercode, vollständigen Text und den darin genannten Bundle- oder SDK-Pfad in Ihr Release-Protokoll.
2. Build-Eingaben erfassen: Notieren Sie den Branch, die Abhängigkeitsdatei und die tatsächlich aufgelöste SDK-Version. Bei einem CocoaPods- oder Swift-Package-Projekt ist die deklarierte Version allein nicht immer der beste Nachweis für das gebaute Produkt.
3. Zuständigkeit bestimmen: Entscheiden Sie, ob die App selbst oder ein SDK betroffen ist. Bei einem SDK prüfen Sie die Anbieterinformationen und die Apple-Anforderungen für diese Komponente.
4. Korrektur gezielt vornehmen: Ordnen Sie eine App-Datei dem richtigen Target zu oder aktualisieren Sie die betroffene Abhängigkeit. Ändern Sie SDK-Angaben nicht eigenmächtig im App-Manifest.
5. Neu auflösen und archivieren: Erzeugen Sie nach einer Abhängigkeitskorrektur ein frisches Archive. Verwenden Sie nicht versehentlich ein älteres Produkt, nur weil dessen Dateiname ähnlich ist.
6. Paketinhalt abgleichen: Prüfen Sie die Manifestdatei im App-Bundle und an den relevanten SDK-Pfaden. Stimmen die Pfade nicht mit dem Bericht überein, untersuchen Sie zunächst die eingebundenen Komponenten statt die Meldung als erledigt zu markieren.
7. Upload erneut verifizieren: Reichen Sie genau dieses Archive ein und prüfen Sie den angezeigten Status. Apple trennt Build-Upload-Status von App- und Submission-Status. Ein verarbeiteter Upload ist daher kein Nachweis, dass die App Review abgeschlossen oder die App freigegeben ist.

Bewertung der Diagnosewege

Wenn Sie die Ursache schnell und belastbar eingrenzen möchten, bewerten Sie die Vorgehensweise nicht danach, ob eine Meldung kurzfristig verschwindet, sondern danach, ob Sie den Verantwortlichen und den tatsächlich eingereichten Inhalt nachweisen können. Die folgende Einordnung hilft bei der Wahl des nächsten Schritts.

Häufige Fragen

ITMS-91061: Wo soll ich zuerst nachsehen?

Beginnen Sie mit dem vollständigen Wortlaut und dem genannten SDK- oder Bundle-Pfad. ITMS-91061 allein ersetzt keine Prüfung des konkreten Berichts: Der Pfad weist häufig auf eine eingebundene Abhängigkeit, während die Meldung erläutert, welche Anforderung betroffen ist. Vergleichen Sie diesen Hinweis mit dem tatsächlichen Inhalt des Archivs und der verwendeten SDK-Version, bevor Sie das App-Manifest ändern.

Wie gehen Sie vor, wenn einem Drittanbieter-SDK das Manifest fehlt?

Prüfen Sie zunächst, ob eine neuere SDK-Version ein Manifest mitliefert und ob das SDK zu den von Apple genannten betroffenen Komponenten gehört. Wenn die Datei zum SDK gehört, lassen Sie den Anbieter die Angaben für dessen APIs und Datenverarbeitung korrigieren. Ein App-eigener Eintrag ist kein zuverlässiger Ersatz für die Deklaration des SDK. Halten Sie Version, Paketpfad und Anbieterantwort für die erneute Prüfung fest.

Wie lässt sich die Datei im finalen Archive nachweisen?

Öffnen Sie das konkrete XCArchive, das Sie hochladen wollen, und untersuchen Sie das App-Bundle unter Products/Applications. Suchen Sie dort nach PrivacyInfo.xcprivacy; prüfen Sie bei einem SDK-Hinweis zusätzlich das genannte eingebettete Framework oder Paket. Stimmen Build und Pfad mit der Meldung überein, können Sie die Datei im tatsächlich erzeugten Produkt statt nur im Projektordner beurteilen.

Was unterscheidet ein ungültiges von einem fehlenden Manifest?

Eine fehlende Datei ist im erwarteten Paket nicht vorhanden. Eine ungültige Datei ist zwar vorhanden, erfüllt aber möglicherweise nicht die Format- oder Wertanforderungen. Prüfen Sie bei einem Formatfehler die Property List und bei einem beanstandeten Eintrag dessen Schlüssel, Typ und zulässigen Wert anhand der Apple-Dokumentation. Diese Unterscheidung ist wichtig, weil das bloße Hinzufügen einer zweiten Datei eine ungültige vorhandene Datei nicht repariert.

Wenn Sie Archive und Meldungspfad korrekt abgleichen, lässt sich meist unterscheiden, ob Ihre App-Datei, eine Abhängigkeit oder die Paketierung den Fehler verursacht. Eine lokale Mac-Umgebung ist sinnvoll, wenn Sie Builds dauerhaft und unter eigener Kontrolle erstellen; für sporadische Fehleranalyse oder eine zeitlich begrenzte Release-Prüfung kann ein Remote Mac dagegen den Kauf und die Wartung eines zusätzlichen Rechners vermeiden. Prüfen Sie dabei nüchtern, ob Ihre bisherige Lösung an fehlendem macOS-Zugriff, wechselnden Build-Eingaben oder unklaren Artefaktpfaden scheitert; ein gemieteter Mac verbessert die Nachvollziehbarkeit nicht automatisch, wenn Sie die Archive nicht selbst kontrollieren.

Wenn Sie den vollständigen Xcode-Archivierungs- und Upload-Ablauf auf einer entfernten Mac-Umgebung reproduzieren möchten, prüfen Sie die aktuell beschriebenen Optionen auf der VPSMAC-Übersichtsseite. Für Angaben zu verfügbaren M4-Knoten können Sie außerdem die Übersicht zur Bestellung eines M4-Knotens mit Ihrem Projektbedarf abgleichen. Vergleichen Sie die dort beschriebenen Umgebungsinformationen, bevor Sie sich für eine zeitlich begrenzte Nutzung entscheiden; für dauerhaft hohe Auslastung oder zwingend benötigte lokale Hardware-Schnittstellen kann ein eigener Mac weiterhin die passendere Lösung sein.