Was tun, wenn App Store Connect PrivacyInfo.xcprivacy als ungültig meldet? (2026)

App Store Connect weist Ihr Upload wegen einer ungültigen PrivacyInfo.xcprivacy zurück.
Schnellste Lösung: Lesen Sie den Dateipfad in der Apple-Mitteilung, ordnen Sie die Datei dem App-Ziel, einem Swift Package oder einem Drittanbieter-SDK zu und korrigieren Sie die jeweilige Quelle. Erstellen Sie danach ein neues Xcode Archive und validieren Sie genau dieses vor dem Upload.

Dieser Leitfaden ist für Sie, wenn Sie eine Ablehnung wegen eines Datenschutzmanifests erhalten haben und die betroffene Datei finden müssen.
Er hilft kleinen Teams, die Manifeste von SDKs und Paketen prüfen, statt die Verantwortung vorschnell dem App-Hauptziel zuzuschieben.
Auch wenn Sie Xcode auf einem entfernten Mac für Archivierung und Einreichung verwenden, können Sie mit dem Ablauf eine überprüfbare Freigabe aufbauen.

App Store Connect PrivacyInfo.xcprivacy ungültig: zuerst den Pfad lesen

Die Meldung von App Store Connect ist der erste Anhaltspunkt, nicht bloß ein allgemeiner Hinweis auf „Datenschutz“. Apple kann bei einer ungültigen Manifestdatei den Dateinamen und den Pfad im betroffenen Archive nennen. Folgen Sie diesem Pfad, bevor Sie eine Datei bearbeiten oder ersetzen. Apples TN3181 zur Diagnose ungültiger Datenschutzmanifeste beschreibt, wie die Meldung eingeordnet werden soll.

Der Pfad klärt meist bereits, wer die Datei bereitstellt:

• Liegt sie im Haupt-App-Bundle, untersuchen Sie das App-Ziel und dessen Ressourcen.
• Verweist sie auf eine Paketabhängigkeit, prüfen Sie die Ressourcenregeln des Swift Package.
• Zeigt sie in ein eingebettetes Framework oder XCFramework, verfolgen Sie die Datei bis zum betreffenden SDK und dessen Version.

Öffnen Sie außerdem das tatsächlich eingereichte Archive. Ein Manifest im Quellverzeichnis beweist nicht, dass dieselbe Datei in den Build gelangt ist. Umgekehrt kann ein Fehler in einer eingebetteten Abhängigkeit auftreten, obwohl das Manifest des App-Ziels korrekt ist.

Verwechseln Sie das Manifest nicht mit den Datenschutzangaben des App Store-Eintrags. PrivacyInfo.xcprivacy enthält Angaben zu bestimmten Datennutzungen und APIs innerhalb der App oder eines SDK. Die Angaben in App Store Connect sind eine separate Erklärung. Eine Änderung an der einen Stelle repariert nicht automatisch die andere.

Das App-Hauptziel und seine Ressourcen

Wenn die Fehlermeldung auf das Haupt-App-Bundle verweist, prüfen Sie zwei Fragen getrennt: Ist die Datei für das tatsächlich gebaute Ziel eingebunden, und enthält sie die passenden Angaben? Apple unterscheidet die Deklarationen einer App von denen eines Drittanbieter-SDK. Ein App-Manifest ist nicht dazu gedacht, sämtliche Abhängigkeiten pauschal abzudecken. Apples Anleitung zum Hinzufügen eines Datenschutzmanifests zur App oder zu einem SDK erläutert diese Zuordnung.

Gehen Sie in Xcode vom betroffenen App-Ziel aus. Kontrollieren Sie die Projektkonfiguration und die Ressourcen, die beim Build tatsächlich berücksichtigt werden. Eine Datei kann im Repository liegen und dennoch im falschen Ziel, in einer nicht verwendeten Build-Konfiguration oder an einer Stelle abgelegt sein, die nicht in das Bundle übernommen wird.

Danach prüfen Sie die resultierende Struktur im Archive. Apple beschreibt in der Dokumentation zum Aufbau von Datenschutzmanifesten, wo Manifestdateien in den jeweiligen App- und SDK-Bundles erwartet werden. Orientieren Sie sich an dieser Dokumentation und am konkreten Pfad aus der Fehlermeldung; nehmen Sie nicht an, eine Datei am Projektstamm werde automatisch an die passende Stelle kopiert.

Inhaltlich dürfen Sie die Verantwortlichkeiten ebenfalls nicht vermischen. Angaben zur Datennutzung beziehen sich auf tatsächliche Abläufe Ihrer App. Required-reason-API-Angaben beziehen sich dagegen auf die Verwendung bestimmter APIs, für die Apple eine zulässige Begründung verlangt. Apples Beschreibung der Datennutzung in Datenschutzmanifesten hilft, diese Bereiche voneinander abzugrenzen.

Typischer Fall: Ihr Projekt enthält ein Manifest, aber die Fehlermeldung zeigt keinen Fehler in der App-Datei, sondern einen Pfad innerhalb eines eingebetteten Frameworks. In diesem Fall ist es keine belastbare Korrektur, das App-Manifest mit zusätzlichen, geratenen Einträgen zu füllen. Ermitteln Sie erst, ob die App selbst die betreffende API oder Datennutzung verantwortet.

Swift Package: Quelldatei ist nicht gleich Build-Ressource

Ein häufiger Paketfehler entsteht durch eine falsche Annahme: Eine PrivacyInfo.xcprivacy liegt im Verzeichnis des Swift Package und müsse deshalb im fertigen App-Archive auftauchen. Das ist nicht automatisch der Fall. Das Paket muss die Datei für das entsprechende Target als Ressource einbinden. Apples Dokumentation zum Bündeln von Ressourcen in einem Swift Package beschreibt, wie Ressourcen in der Package-Definition behandelt werden.

Prüfen Sie die Package-Konfiguration des Targets, das die Bibliothek bereitstellt. Stimmen Dateiname und relativer Pfad mit der Ressourcendeklaration überein? Wird das richtige Target vom App-Projekt verwendet? Liegt das Manifest eventuell in einem anderen Paket-Target, das beim konkreten Build gar nicht eingebunden wird? Diese Fragen sind aussagekräftiger als eine bloße Suche nach dem Dateinamen im Repository.

Anschließend bauen Sie die App erneut und untersuchen das Archive. Suchen Sie an dem Ort, den Apple für die jeweilige Paket- und Bundle-Struktur dokumentiert. Fehlt die Datei weiterhin, kontrollieren Sie, ob das verwendete Paket tatsächlich die bearbeitete Version ist. Ein lokaler Quellstand, ein aufgelöster Abhängigkeitsstand und das in einem Archive verwendete Paket können voneinander abweichen.

Wenn das Paket von einem Drittanbieter stammt, ändern Sie die Manifestdatei nicht dauerhaft in einer lokal zwischengespeicherten Kopie. Eine solche Änderung kann beim nächsten Auflösen der Abhängigkeiten verschwinden und ist für Ihr Team kaum reproduzierbar. Melden Sie dem Paketverantwortlichen den konkreten Archive-Pfad, die verwendete Paketversion und den Validierungsfehler. Verwenden Sie eine veröffentlichte Korrektur oder eine nachvollziehbar dokumentierte Paketänderung.

Drittanbieter-SDK: Fehlerzuständigkeit anhand des Bundle-Pfads

Zeigt die Mitteilung auf einen Pfad unterhalb eines Frameworks oder XCFrameworks, behandeln Sie das zunächst als SDK-Problem. Halten Sie den Namen des Bundles und die im Projekt verwendete SDK-Version fest. Prüfen Sie anschließend, ob der Anbieter für genau diese Version eine PrivacyInfo.xcprivacy bereitstellt und ob sie im gelieferten SDK enthalten ist.

Die Zuständigkeit richtet sich nach dem tatsächlichen Verhalten und der Herkunft der Komponente. Ihr App-Manifest ersetzt keine ungültige Datei, die ein SDK mitbringt. Ebenso sollten Sie eine gültige SDK-Datei nicht entfernen, nur weil eine Meldung auf eine andere Manifestdatei im Archive verweist. Die Apple-Anleitung zum Einbinden von Manifesten in Apps und Drittanbieter-SDKs ist die passende Grundlage für diese Abgrenzung.

Prüfen Sie die Reihenfolge der verfügbaren Korrekturen:

• Gibt es eine neuere SDK-Version mit korrigiertem Manifest, aktualisieren Sie gezielt und testen Sie den Build erneut.
• Ist die bereitgestellte Datei fehlerhaft, bitten Sie den SDK-Anbieter um eine korrigierte Version und teilen Sie den vollständigen Pfad sowie die Validierungsrückmeldung.
• Müssen Sie vorübergehend auf eine eigene Paketkopie oder einen Patch zurückgreifen, dokumentieren Sie Quelle, Änderung und spätere Ablösung. Klären Sie außerdem, ob Ihr Verfahren mit Lizenz, Signatur und Build-Prozess vereinbar ist.

Eine einzelne fehlerhafte SDK-Version belegt nicht, dass alle Projekte mit diesem SDK oder alle Apps mit einer bestimmten Architektur betroffen sind. Für Ihre Entscheidung zählt die Datei in Ihrem konkreten Archive. Notieren Sie deshalb die SDK-Version und den Pfad, statt den Fehler nur als „SDK-Problem“ zu protokollieren.

Inhaltliche Prüfung: Schlüssel, Werte und API-Begründungen

Ist die richtige Datei im Archive vorhanden, bleibt aber ungültig, prüfen Sie ihren Inhalt anhand der aktuellen Apple-Regeln. Entscheidend sind die erlaubten Schlüssel, der erwartete Datentyp und die zugelassenen Werte. Ein formal ähnlich klingender Eintrag ist nicht automatisch gültig. Verwenden Sie Apples Dokumentation zu Required-Reason-APIs, um die für die tatsächlich genutzte API zulässigen Angaben nachzuschlagen.

Ergänzen Sie keinen Grund, weil er plausibel klingt oder eine Prüfung möglicherweise beruhigt. Eine Begründung muss die reale Verwendung der API in Ihrer App oder Abhängigkeit abbilden und zu Apples aktueller Liste passen. Wenn eine Bibliothek die API verwendet, sollte die Verantwortung dafür anhand der SDK-Dokumentation und des Bundle-Pfads geklärt werden.

Bei Angaben zur Datennutzung gilt dieselbe Sorgfalt. Beschreiben Sie nicht pauschal jede denkbare Erhebung. Prüfen Sie, welche Datennutzung der Code tatsächlich ausführt und ob das Manifest des betreffenden Bestandteils dazu gehört. Ändern Sie nicht gleichzeitig mehrere Dateien und Werte, wenn Sie den Fehler eingrenzen wollen. Sonst lässt sich bei einer erneuten Validierung schwer erkennen, welche Änderung wirksam war.

Halten Sie die Rückmeldung von App Store Connect oder Xcode zusammen mit der geprüften Manifestdatei fest. So können Sie einem Teammitglied oder SDK-Anbieter zeigen, welcher Schlüssel beanstandet wurde und in welcher Datei die Korrektur erfolgte. Das ist besonders wichtig, wenn ein Projekt mehrere Ziele, Paketprodukte oder eingebettete Frameworks enthält.

Bearbeiten oder löschen Sie nicht einfach eine Datei innerhalb eines fertigen Archive. Eine Änderung am signierten Inhalt kann die Codesignatur ungültig machen. Apple erläutert die Zusammenhänge in den Technotes zur Codesignierung. Korrigieren Sie nach Möglichkeit die Quelle und erstellen Sie ein neues Archive.

Xcode Archive: vom Fehlerpfad zur geprüften Einreichung

Das Archive ist der Prüfgegenstand. Nicht die Datei, die Sie zuletzt im Editor geöffnet haben. Apple beschreibt die Archivierungs- und Distributionsschritte in der Xcode-Dokumentation zur Verteilung von Apps. Nutzen Sie Xcode Organizer, um das betreffende Archive auszuwählen und dessen Inhalt zu untersuchen. Vergleichen Sie den Pfad aus der Ablehnung mit dem enthaltenen Bundle.

Ein reproduzierbarer Ablauf sieht so aus:

1. Sichern Sie die Ablehnungsmitteilung und notieren Sie Dateiname und vollständigen Pfad.
2. Öffnen Sie in Xcode Organizer das Archive, das tatsächlich zur Einreichung verwendet wurde.
3. Ordnen Sie die Datei dem App-Ziel, einem Swift Package oder einem Framework beziehungsweise XCFramework zu.
4. Ändern Sie die zuständige Quelldatei oder aktualisieren Sie die betroffene Abhängigkeit. Erfassen Sie die Änderung im Versionsverlauf.
5. Erstellen Sie ein neues Archive und prüfen Sie, ob die korrigierte Manifestdatei am erwarteten Ort enthalten ist.
6. Starten Sie den Validierungs- oder Distributionsschritt für genau dieses neue Archive und bewahren Sie das Ergebnis auf.

Dieser Ablauf verhindert mehrere typische Fehlentscheidungen: Sie laden nicht versehentlich einen alten Build hoch, behandeln nicht die falsche Manifestdatei und verlassen sich nicht auf eine lokale Datei, die gar nicht archiviert wurde. Wenn die Validierung weiterhin denselben Pfad beanstandet, prüfen Sie, ob Xcode wirklich den neuen Quellstand und die aktualisierte Abhängigkeit verwendet hat.

Prüfen Sie vor dem Upload auch die Signatur des neu erstellten Archive. Das manuelle Ersetzen oder Entfernen von Dateien in einem bereits signierten Paket kann dazu führen, dass die Signatur nicht mehr zum Inhalt passt. Apples Hinweise zur Codesignierung sind daher keine Randnotiz: Sie sprechen gegen eine nachträgliche Änderung am fertigen Artefakt und für eine Korrektur im Projekt oder in der Abhängigkeit.

Abhakliste für die nächste Einreichung

• [ ] Die Mitteilung von App Store Connect ist gespeichert; Dateiname und vollständiger Archive-Pfad sind notiert.
• [ ] Die betroffene Datei ist dem Haupt-App-Ziel, einem Swift Package oder einem Drittanbieter-SDK zugeordnet.
• [ ] Die Korrektur erfolgte an der zuständigen Quelle und nicht durch eine unbegründete Änderung an einer anderen Manifestdatei.
• [ ] Schlüssel, Werte und erforderliche API-Begründungen wurden gegen Apples aktuelle Dokumentation geprüft.
• [ ] Das neue Archive enthält die korrigierte Datei am passenden Ort.
• [ ] Die Xcode-Validierung wurde für genau das neue Archive durchgeführt und das Ergebnis ist nachvollziehbar abgelegt.
• [ ] Es wurde nicht nachträglich in einem signierten Archive gelöscht oder ersetzt, ohne die Auswirkungen auf die Signatur zu berücksichtigen.

Wenn Sie für wiederholbare Prüfungen eine Mac-Umgebung benötigen, können Sie den Ablauf zunächst mit einer vorhandenen lokalen oder gemieteten Maschine testen. Für den Arbeitsablauf auf einem entfernten Mac finden Sie weitere Hinweise in der OsxNode-Dokumentation. Halten Sie dort ebenso wie lokal fest, welcher Quellstand, welche Paketversion und welches Archive geprüft wurden. Ein entfernter Rechner beseitigt nicht die Notwendigkeit, die Abhängigkeiten und Artefakte selbst zu kontrollieren.

Häufige Fragen zur ungültigen PrivacyInfo.xcprivacy

Wie lokalisieren Sie die konkrete Datei?

Beginnen Sie mit dem Pfad in der App-Store-Connect-Mitteilung und vergleichen Sie ihn mit dem Inhalt des eingereichten Archive. Eine Suche im Quellcode kann ergänzen, aber nicht beweisen, dass die Datei in genau diesem Build enthalten ist. Der Pfad hilft, App-Ziel, Paketressource und eingebettetes SDK voneinander zu unterscheiden.

Weshalb fehlt das Manifest eines Swift Package im Archive?

Eine Datei im Paketverzeichnis wird nicht automatisch als Ressource gebündelt. Prüfen Sie die Ressourcendeklaration des zuständigen Package-Targets und ob die App tatsächlich dieses Target verwendet. Bestätigen Sie die Änderung anschließend am neu erstellten Archive. Ein korrekt aussehender Quellbaum allein sagt nicht, was Xcode in das App-Bundle übernommen hat.

Wer muss ein fehlerhaftes SDK-Manifest korrigieren?

Zeigt der Fehlerpfad auf ein Framework oder XCFramework, erfassen Sie dessen Namen und Version. Prüfen Sie die vom SDK-Anbieter veröffentlichte Manifestdatei und fragen Sie bei einem Fehler nach einer korrigierten Version. Das App-Hauptmanifest ist kein verlässlicher Ersatz für eine fehlerhafte Deklaration innerhalb einer Drittanbieterkomponente.

Wie weisen Sie die Korrektur vor dem Upload nach?

Bauen Sie nach der Änderung ein neues Archive. Prüfen Sie darin den beanstandeten Pfad und führen Sie anschließend den Xcode-Validierungsschritt für dieses Archive aus. Dokumentieren Sie Quellstand, Abhängigkeitsversion und Prüfergebnis, damit Ihr Team zwischen einem reparierten Build und einem versehentlich erneut ausgewählten älteren Archive unterscheiden kann.

Wenn Sie die Manifestdatei korrekt zugeordnet und das neue Archive validiert haben, sollten Sie den nächsten Upload erst mit genau diesem geprüften Artefakt fortsetzen. Ohne einen verfügbaren Mac kann die wiederholte Archivierung und Abnahme den Arbeitsablauf erschweren; ein eigener Mac ist dafür nicht in jedem Fall nötig, aber ein dauerhaft hoher Build-Bedarf kann eine eigene Maschine sinnvoller machen als eine Miete. Wenn Sie nur zeitweise Xcode-Archive erstellen oder eine Einreichung kontrollieren müssen, können Sie die Mietoptionen für einen entfernten Mac von OsxNode prüfen und vorab abwägen, ob sie zu Ihrem Build- und Prüfprozess passen.

Häufig gestellte Fragen