App Store Connect Datenschutzliste ungültig: 2026 beheben?

Speichern Sie zunächst die vollständige Nachricht von App Store Connect. Erstellen Sie für die interne Dokumentation eine anonymisierte Kopie. Entfernen Sie Projektname, Bundle ID, Kontodaten, interne Pfade und private SDK-Bezeichnungen. Bewahren Sie jedoch Fehlercode, Dateiname, Bundle-Pfad und Plattform auf.

Apple unterscheidet mehrere Fehlerklassen. Diese dürfen Sie nicht mit derselben Maßnahme behandeln:

• Ungültiges Privacy Manifest: Die Datei ist vorhanden, entspricht aber nicht dem erwarteten plist-Aufbau oder enthält unzulässige Werte.
• Fehlendes Privacy Manifest: Das betroffene Bundle enthält keine Datei am erwarteten Ort.
• Fehlende Required Reason API: Ein Bundle verwendet eine deklarationspflichtige API, nennt aber keinen passenden offiziellen Grund.
• SDK- oder Signaturproblem: Ein Drittanbieter-SDK erfüllt zusätzliche Anforderungen nicht oder wurde nach einer Änderung nicht korrekt signiert.

Apple bestätigt, dass eine Einreichung mit einem ungültigen PrivacyInfo.xcprivacy abgelehnt werden kann. Die offizielle Anleitung zur Fehlersuche bei ungültigen Privacy Manifests ist deshalb die Referenz für die erste Zuordnung.

Warum reicht der Blick in den Projektordner nicht aus?
App Store Connect erhält nicht Ihre Quelldateien, sondern das signierte und exportierte Produkt. Xcode führt beim Archivieren Ressourcen aus mehreren Targets, Packages und Build-Phasen zusammen. Eine Datei kann im Repository korrekt sein und trotzdem im finalen Bundle fehlen.

Legen Sie eine unveränderte Kopie des Archives an. Arbeiten Sie anschließend nur mit einer Analysekopie. Das Original bleibt die Beweisquelle, falls ein späterer Reparaturversuch die Bundle-Struktur oder Signatur verändert.

Verwenden Sie die folgende Checkliste als Entscheidungsinstrument. Arbeiten Sie die Punkte in der angegebenen Reihenfolge ab und markieren Sie jeden Nachweis erst dann, wenn Sie ihn aus dem finalen Archive belegen können.

• [ ] Fehlerpfad gesichert: Fehlercode, Dateiname und vollständiger Bundle-Pfad sind aus der App-Store-Connect-Meldung übernommen.
• [ ] Archive gesichert: Das ursprüngliche xcarchive wurde kopiert und bleibt unverändert.
• [ ] Verantwortliches Bundle gefunden: Der genannte Pfad wurde im Archive einem Haupt-App-Bundle, einer Extension, einem Framework, einem App Clip, einem Mac-Catalyst-Produkt oder einer macOS-Komponente zugeordnet.
• [ ] Dateiinhalt gelesen: Die tatsächlich ausgelieferte PrivacyInfo.xcprivacy wurde geprüft, nicht nur die Datei im Quellverzeichnis.
• [ ] Syntax bestanden: plutil -lint meldet keinen plist-Fehler.
• [ ] Typen geprüft: Wurzelobjekt, Arrays, Dictionaries und Boolean-Werte besitzen die erwarteten Typen.
• [ ] Reason geprüft: Jede deklarierte Required Reason API entspricht einer tatsächlichen Nutzung und einem zulässigen approved reason.
• [ ] SDK-Herkunft geklärt: Es ist dokumentiert, ob die Datei aus Swift Package Manager, CocoaPods, einem dynamischen Framework oder einem XCFramework stammt.
• [ ] Signatur geprüft: Nach jeder Änderung an einem eingebetteten Bundle wurde die Signatur erneut bewertet.
• [ ] Neues Archive erstellt: Der korrigierte Build stammt nicht aus dem alten Archive.
• [ ] Upload vollständig geprüft: Export, Upload-Annahme und anschließende Verarbeitung in App Store Connect wurden getrennt bestätigt.

Nutzen Sie danach diese Bedingungen:

• Wenn der Fehler auf die Haupt-App zeigt und die Datei syntaktisch ungültig ist, korrigieren Sie Struktur und Werte im Quellprojekt und archivieren neu.
• Wenn der Fehler auf eine Extension oder ein Framework zeigt, prüfen Sie zuerst dessen Target Membership und Ressourcen. Eine Datei im Haupt-Target genügt nicht automatisch.
• Wenn nur eine Required Reason API fehlt, verfolgen Sie die Nutzung bis zum Code oder SDK zurück. Wählen Sie keinen beliebigen Grund.
• Wenn ein Drittanbieter-SDK betroffen ist, suchen Sie zuerst nach einer korrigierten Version. Eine manuelle Archive-Änderung bleibt ein begrenzter Rückfall.
• Wenn plutil erfolgreich ist, App Store Connect aber ablehnt, wechseln Sie von der Syntaxprüfung zu Semantik, Bundle-Pfad, SDK-Anforderungen und Signatur.
• Wenn Quelle und Archive voneinander abweichen, untersuchen Sie Build-Phasen, Package-Ressourcen, Konfiguration und Dependency-Auflösung.

Damit unterscheiden Sie nicht nur „Datei vorhanden“ und „Datei fehlt“, sondern auch die Zustände „syntaktisch lesbar“, „regelkonform“, „im richtigen Bundle“ und „gültig signiert“.

Prüfen Sie die Datei zuerst mit dem Xcode-Property-List-Editor oder mit plutil. Verwenden Sie Platzhalter für Ihre lokalen Pfade:

ARCHIVE_PATH="/Pfad/zum/Projekt.xcarchive"
APP_PATH="$ARCHIVE_PATH/Products/Applications/Beispiel.app"
MANIFEST_PATH="$APP_PATH/PrivacyInfo.xcprivacy"

plutil -lint "$MANIFEST_PATH"
plutil -p "$MANIFEST_PATH"

plutil -lint beantwortet nur die Syntaxfrage: Kann macOS die Datei als Property List lesen? plutil -p zeigt Ihnen die gespeicherten Ebenen und Datentypen. Beide Befehle sollten auf einer Analysekopie ausgeführt werden. Die ursprüngliche Archive-Datei darf durch die Prüfung nicht verändert werden.

Prüfen Sie mindestens diese Eigenschaften:

• Das Wurzelelement ist ein Dictionary, nicht versehentlich ein Array oder eine Zeichenkette.
• Arrays und Dictionaries liegen auf der erwarteten Ebene.
• Die Schlüssel verwenden die von Apple dokumentierten Namen.
• Boolean-Werte sind echte Boolean-Werte und keine Zeichenketten wie "true".
• Leere Arrays oder Dictionaries wurden nicht als Platzhalter exportiert.
• Interne Testschlüssel und nicht dokumentierte Felder gelangen nicht in die Release-Datei.
• Es existiert keine zweite Datei mit ähnlichem Namen, die durch eine Build-Phase in das Bundle kopiert wird.

Warum kann App Store Connect trotz erfolgreichem plutil-Check ablehnen?
Weil plutil weder die zulässigen Apple-Schlüsselwerte noch die inhaltliche Richtigkeit eines approved reason prüft. Der Befehl bestätigt auch nicht, dass die Datei im verantwortlichen Bundle liegt. Ein erfolgreiches Ergebnis ist deshalb nur ein bestandener Syntaxschritt.

Wenn die erwartete Datei nicht gefunden wird, suchen Sie im gesamten Archive:

find "$ARCHIVE_PATH" -name "PrivacyInfo.xcprivacy" -print
find "$ARCHIVE_PATH" \( -name "*.app" -o -name "*.appex" -o -name "*.framework" \) -print

Vergleichen Sie diese Ausgabe mit dem Pfad aus der Fehlermeldung. Eine Aussage wie „die Datei befindet sich im Projekt“ ist für den Upload nicht ausreichend.

Die nächste Prüfung betrifft die Bedeutung der Einträge. Ermitteln Sie zunächst die API-Kategorie und danach den tatsächlichen Aufrufer. Das kann Ihr eigener Swift- oder Objective-C-Code, eine Extension oder ein eingebettetes SDK sein.

Apple beschreibt die zulässigen Kategorien und Gründe in der Dokumentation zur Required Reason API. Die Technote zum Hinzufügen von Required-Reason-Einträgen erklärt die Konfiguration im Manifest.

Gehen Sie in dieser Reihenfolge vor:

1. Suchen Sie im eigenen Quellcode nach APIs, die Apple als Required Reason API einstuft.
2. Prüfen Sie die aufgelösten Abhängigkeiten und erzeugten Build-Produkte.
3. Ordnen Sie die Nutzung der korrekten API-Kategorie zu.
4. Wählen Sie nur einen offiziellen approved reason, der die reale Funktion beschreibt.
5. Vergleichen Sie den Eintrag mit dem Manifest des verantwortlichen Bundles.

Eine formal gültige, aber sachlich falsche Begründung ist keine nachhaltige Reparatur. Sie sollten die API nicht entfernen, nur damit die Meldung verschwindet. Ebenso darf das Haupt-App-Manifest nicht automatisch die Verantwortung eines SDKs ersetzen, das dieselbe API für seinen eigenen Zweck nutzt.

Suchen Sie nicht nur nach sichtbaren Swift-Aufrufen. Eine Abhängigkeit kann Objective-C-Code, vorgefertigte Frameworks oder binäre XCFrameworks enthalten. Prüfen Sie deshalb die Dependency-Liste, die Package-Auflösung und die finalen Produkte.

Ein Privacy Report kann die Analyse ergänzen. Apples Dokumentation zu Privacy Reports hilft bei der Einordnung der deklarierten Nutzung. Der Report ersetzt jedoch nicht die Prüfung der Manifest-Datei im Archive.

Bei einem ungültigen Manifest in einem SDK ist zuerst zu klären, wer das Bundle erzeugt und signiert. Die Integrationsart entscheidet über den nächsten Schritt:

• Swift Package Manager: Prüfen Sie, ob das Package die Datei als Ressource mitliefert und ob die Resource-Zuordnung im Zielprodukt aktiv ist.
• CocoaPods: Kontrollieren Sie, ob die Pod-Integration die Datei in das richtige Framework oder Bundle kopiert.
• Dynamisches Framework: Öffnen Sie die Manifest-Datei innerhalb des Frameworks und prüfen Sie die Signatur nach der Integration.
• Binäres XCFramework: Ermitteln Sie, welcher Plattform- und Architektur-Slice genutzt wird und ob genau dieser Slice die erwartete Datei enthält.

Für bestimmte SDKs aus Apples offizieller Anforderungsliste gelten zusätzliche Bedingungen. Dazu gehören Anforderungen an Privacy Manifests und je nach SDK auch an die Signatur. Maßgeblich ist Apples Übersicht zu Drittanbieter-SDK-Anforderungen.

Sollten Sie die PrivacyInfo.xcprivacy eines Drittanbieter-SDKs selbst ändern?
Nicht als dauerhafte Lösung. Eine Änderung im bereits erzeugten Archive kann die Codesignatur ungültig machen. Wenn Sie ein eingebettetes Bundle verändern, müssen Sie es mit den korrekten Identitäten und Entitlements neu signieren. Anschließend benötigen Sie ein neues Archive und einen neuen Upload.

Die bessere Langzeitmaßnahme ist normalerweise ein Update des Maintainers, ein Austausch der Abhängigkeit oder eine dokumentierte Korrektur im Quellpaket. Speichern Sie dazu die Paketversion, die Lock-Datei und den verwendeten Commit. Andernfalls kann der nächste CI-Lauf dieselbe fehlerhafte Version erneut einbauen.

Eine PrivacyInfo.xcprivacy wirkt nur dort, wo sie im finalen Produkt erwartet wird. Prüfen Sie jedes relevante Bundle separat:

• Haupt-App
• App Extension
• Framework
• App Clip
• Mac-Catalyst-Produkt
• macOS-App oder verschachtelte macOS-Komponente

Benötigen mehrere Targets und Extensions eine getrennte Prüfung?
Ja, wenn sie eigene Nutzung oder eigene Anforderungen besitzen. Eine Datei im Haupt-App-Bundle macht eine fehlende oder fehlerhafte Datei in einer Extension oder einem eingebetteten Framework nicht automatisch gültig.

Häufige Abweichungen zwischen Quelle und Archive entstehen durch:

• fehlende Target Membership,
• nicht deklarierte Swift-Package-Ressourcen,
• ein Copy-Files-Skript mit falschem Zielverzeichnis,
• eine andere Build-Konfiguration für Release,
• ein vorgebautes Framework mit älterer Manifest-Version,
• eine Abhängigkeit, die aus einem Cache statt aus der erwarteten Lock-Datei stammt.

Suchen Sie im Archive nach dem genauen Bundle-Pfad aus der App-Store-Connect-Meldung. Öffnen Sie anschließend den Privacy Report in Xcode und vergleichen Sie beide Befunde. Der Fehlerpfad, der Target-Name und die physische Datei müssen zusammenpassen.

Nach einer Korrektur dürfen Sie nicht einfach das alte Archive erneut exportieren. Erstellen Sie einen neuen Build mit einer eindeutig erkennbaren Kennzeichnung.

Führen Sie diese Schritte aus:

1. Sichern Sie die ursprüngliche Fehlermeldung und das fehlerhafte Archive unverändert.
2. Dokumentieren Sie Änderung, Dependency-Version, Build-Konfiguration und verantwortliches Target.
3. Erzeugen Sie ein vollständig neues Archive.
4. Suchen Sie darin nach allen relevanten PrivacyInfo.xcprivacy-Dateien.
5. Wiederholen Sie Syntax- und Inhaltsprüfungen an den finalen Dateien.
6. Prüfen Sie die Signatur jedes Bundles, das nach der Korrektur verändert wurde.
7. Exportieren Sie genau dieses neue Produkt mit Xcode.
8. Laden Sie genau dieses Produkt hoch.
9. Prüfen Sie die Upload-Annahme und danach die Verarbeitung in App Store Connect.

Die Xcode-Dokumentation zur Verteilung für Beta-Tests und Releases beschreibt den Distributionsschritt. Lokal bestanden, archiviert, signiert, vom Upload angenommen und serverseitig verarbeitet sind unterschiedliche Zustände.

Für eine CI/CD- oder Remote-Mac-Umgebung sollten Sie zusätzlich diese Nachweise speichern:

• Dependency-Lock-Datei,
• Build-Log,
• Archive-Pfad,
• Privacy Report,
• anonymisierte Fehlermeldung,
• Upload-Referenz,
• verwendete Build-Konfiguration.

Entfernen Sie aus Diagnoseartefakten private Zertifikate, Zugangsdaten und Kontoinformationen. Eine reproduzierbare Umgebung ist nur dann hilfreich, wenn sie keine neuen Datenschutz- oder Sicherheitsrisiken erzeugt.

Wenn der Upload weiter scheitert, vergleichen Sie das alte und neue Archive Datei für Datei. Die Änderung muss sich auf den verantwortlichen Bundle-Pfad, den Manifest-Inhalt, die Dependency-Version oder die Signatur zurückführen lassen. Ein pauschales „Clean Build“ ohne diesen Vergleich liefert keinen ausreichenden Nachweis.

Ein eigener Mac ist sinnvoll, wenn Sie täglich umfangreich entwickeln, regelmäßig physische iPhones anschließen oder spezielle lokale Hardware benötigen. Für isolierte Release-Läufe, wiederholbare CI/CD-Builds und zeitweise Xcode-Arbeiten kann eine getrennte macOS-Umgebung organisatorisch einfacher sein.

Ein Remote Mac bei CALMVPS eignet sich als Option, wenn Sie Archive, Dependency-Auflösung und vollständige Upload-Protokolle über den gesamten Prüfzyklus aufbewahren möchten. Er ersetzt keine korrekte Manifest-Konfiguration. Er stellt jedoch einen festen macOS-Arbeitsplatz für eine saubere Neuarchivierung bereit, wenn Ihr Hauptrechner knapp an Speicher ist oder im Team kein ständig verfügbarer Mac existiert. Prüfen Sie die deutschen Remote-Mac-Optionen anhand Ihrer Anforderungen an Laufzeit, Zugriff und Ablage.

Treffen Sie die Entscheidung nach diesen Bedingungen:

• Wenn Sie dauerhaft täglich und mit hoher Last bauen, ist ein eigener Mac häufig planbarer als eine laufende Miete.
• Wenn Sie physische Geräte, USB-Zubehör oder lokale Entwicklungswerkzeuge brauchen, bleibt ein Remote Mac unvollständig.
• Wenn Sie nur für Releases, Signierung, CI/CD-Wiederholungen oder einen begrenzten Xcode-Test eine stabile Umgebung benötigen, kann Mieten den Kauf zusätzlicher Hardware vermeiden.
• Wenn Ihre aktuelle Windows- oder Linux-Umgebung bereits den Quellcode-Build erledigt, aber beim macOS-Archive scheitert, benötigen Sie für diesen Schritt trotzdem eine zuverlässige macOS-Umgebung.

Ein ständig wechselnder Cloud-Arbeitsplatz erschwert die Nachvollziehbarkeit, wenn Archive, Zertifikatskonfiguration, Abhängigkeiten und Logs nicht erhalten bleiben. Für einen begrenzten Reparatur- oder Release-Zyklus kann ein gemieteter Mac bei CALMVPS deshalb die passendere Zwischenlösung sein, sofern Sie keinen eigenen Dauer-Host und keine physische Hardware benötigen. Die deutsche Preisübersicht von CALMVPS unterstützt den Vergleich mit einem Hardwarekauf.

Die entscheidende Regel bleibt unabhängig von der Umgebung gleich: Folgen Sie dem Bundle-Pfad aus der Fehlermeldung bis in das finale xcarchive. Trennen Sie Syntax, Semantik, SDK-Verantwortung, Target-Zuordnung und Signatur. Akzeptieren Sie die Reparatur erst, wenn ein neues Archive erstellt, korrekt signiert, real hochgeladen und in App Store Connect vollständig verarbeitet wurde.