Xcode 27: PrivacyInfo.xcprivacy fehlt im Archive? Fehlerdiagnose 2026

Apple führt Xcode 27 auf seiner offiziellen Xcode-Seite als aktuelle Entwicklungsumgebung. Das ist der Versionskontext, kein Beleg für geänderte Regeln zu PrivacyInfo.xcprivacy.

Symptom → schnellster Nachweis: Fehlt das Manifest im Upload, prüfen Sie zuerst das endgültige .xcarchive – nicht nur den Projektordner. Suchen Sie in der App und ihren eingebetteten Bundles, grenzen Sie danach Target-Ressourcen, Swift-Package-Erklärungen und SDK-Artefakte ein. Eine gefundene Datei kann trotzdem ungültig oder inhaltlich unzutreffend sein.

Dieser Runbook richtet sich an iOS-Entwickler, deren App-Archive ein eigenes Manifest vermissen oder bei der Einreichung beanstandet werden.
CI-Ingenieure können damit Package- und SDK-Ressourcen im erzeugten Artefakt prüfen.
DevOps-Verantwortliche erhalten eine wiederholbare Prüfung für Remote-Mac-CI und einen belastbaren Vergleich zwischen lokalem Build und Knoten.

Zuletzt geprüft am 05.10.2026 anhand der Apple-Dokumentation zu Privacy Manifests, TN3181 zur Diagnose ungültiger Manifeste und den aktuellen Apple-Anforderungen an Drittanbieter-SDKs. Prüfen Sie diese Quellen vor einer Veröffentlichung erneut, falls Apple Bundle-Pfade, zulässige Angaben oder SDK-Vorgaben aktualisiert.

Xcode 27 und PrivacyInfo.xcprivacy im Archive: zuerst den Befund sichern

Die Suche beginnt beim gebauten Produkt. Eine Datei im Quellbaum beantwortet nicht, ob Xcode sie in die App, ein Framework oder ein Ressourcen-Bundle kopiert hat. Öffnen Sie das Archive in Xcode oder ermitteln Sie seinen tatsächlichen Pfad aus Ihrem Build-Protokoll. Verwenden Sie danach diesen Pfad als Prüfgegenstand, statt eine erwartete Ablagestruktur vorauszusetzen.

In einem Terminal können Sie die Manifeste unterhalb des Archive-Produkts suchen:

find "$ARCHIVE_PATH/Products" -name PrivacyInfo.xcprivacy -print

ARCHIVE_PATH steht dabei für den Pfad des tatsächlich erzeugten Archives. Prüfen Sie die Ausgabe sowohl für die App als auch für eingebettete Frameworks und Ressourcen-Bundles. Ein Treffer sagt zunächst nur, wo eine Datei liegt. Er beweist weder, dass das richtige Target sie erzeugt hat, noch, dass ihr Inhalt gültig ist oder die beobachtete Datennutzung korrekt beschreibt.

Notieren Sie außerdem den verwendeten Scheme-Namen, die Build-Konfiguration und den Archive-Pfad. Wenn Sie nach einer Änderung nur einen normalen Build prüfen, während der Fehler im Archive entsteht, vergleichen Sie unterschiedliche Build-Aktionen. Wiederholen Sie die Prüfung mit demselben Scheme und derselben Konfiguration, die auch Ihr CI-Knoten verwendet.

App-Target und Archive-Konfiguration: Projektdatei gegen fertige App

Fehlt das Manifest im Hauptbundle Ihrer App, prüfen Sie zunächst dessen Target-Zuordnung. Bei einer Datei, die im Projekt sichtbar ist, kann die Target-Mitgliedschaft fehlen oder auf ein anderes Produkt zeigen. Auch eine Ressource, die nur in einer bestimmten Build-Konfiguration verarbeitet wird, ist nicht automatisch im Archive des Release-Schemes vorhanden.

Gehen Sie gezielt vor:

1. Öffnen Sie die Datei im Projekt und prüfen Sie, ob das App-Target als Mitglied ausgewählt ist.
2. Prüfen Sie die Ressourcen-Build-Phase des betreffenden Targets. Suchen Sie dort nach dem Manifest oder der Regel, die es in das Produkt kopiert.
3. Kontrollieren Sie Scheme und Build-Konfiguration des Archive-Laufs. Vergleichen Sie diese Werte mit dem fehlerhaften CI-Auftrag.
4. Erzeugen Sie ein neues Archive mit derselben Aktion und Konfiguration. Suchen Sie erneut im fertigen .xcarchive.
5. Wenn das Manifest weiterhin fehlt, vergleichen Sie die Build-Protokolle und die tatsächlich erzeugten App-Bundles, bevor Sie andere Projekteinstellungen ändern.

Der letzte Schritt ist wichtig: Projekt-Navigator und Dateisystem können eine Datei anzeigen, obwohl sie nicht in die finale App gelangt. Für die Bundle-Ablage verweist Apple auf produktspezifische Regeln zum Platzieren von Inhalten in Bundles. Leiten Sie daraus nicht ab, dass eine einzige Position für App, Framework und andere Produkttypen passt. Entscheidend ist die Struktur des Produkts, das Sie tatsächlich archiviert haben.

Eine weitere Fehlerquelle ist die Abweichung zwischen Debug- und Archive-Einstellungen. Eine manuelle Kopierregel kann im lokalen Lauf wirken und im Release-Scheme fehlen. Umgekehrt kann ein Script das Manifest in ein anderes Bundle kopieren, als die spätere Validierung erwartet. Sichern Sie den Pfad des gefundenen Manifests und den betreffenden Abschnitt des Build-Protokolls; damit bleibt die Diagnose überprüfbar.

Swift Package und Ressourcen-Bundle: Quelldatei gegen Paketprodukt

Bei einem Swift Package müssen Sie zwischen einer Datei im Package-Repository und einer Ressource unterscheiden, die Package Manager tatsächlich verarbeitet. Apple beschreibt die Paketierung im Leitfaden zum Bündeln von Ressourcen in einem Swift Package. Prüfen Sie dort die Deklaration des passenden Package-Targets; allein der Ort der Datei im Quellverzeichnis belegt keine spätere Aufnahme.

Suchen Sie im aufgelösten Package und im erzeugten Bundle nach PrivacyInfo.xcprivacy. Wenn das Manifest im Paketprodukt fehlt, liegt der Fehler wahrscheinlich in der Ressourcendeklaration oder der Paketverarbeitung. Ist es im Package-Bundle vorhanden, aber nicht im finalen App-Archive, untersuchen Sie als Nächstes die Einbettung und Bundle-Struktur des App-Targets. So trennen Sie einen Package-Fehler von einer nachgelagerten Integrationslücke.

Prüfen Sie dabei, welche Abhängigkeit im konkreten Archive aufgelöst wurde. Ein lokaler Package-Stand und die von CI verwendete Auflösung müssen nicht übereinstimmen, etwa wenn der Lockfile-Stand fehlt oder nicht berücksichtigt wird. Erfassen Sie den Commit, die Package-Auflösung und die tatsächlich archivierten Produkte. Das ist aussagekräftiger, als allein aus dem Manifest im Checkout auf das Verhalten des Builds zu schließen.

Die Regeln sind auch für Bibliotheken mit eigenen Ressourcen relevant: Ein App-Manifest ersetzt nicht automatisch das Manifest einer Abhängigkeit. Apple erklärt, dass ein Privacy Manifest Datenverwendung einer App oder eines Drittanbieter-SDKs beschreibt; vergleichen Sie die Verantwortlichkeiten mit der Apple-Dokumentation zur Beschreibung von Datennutzung. Die Zuordnung muss der tatsächlichen Software-Komponente folgen.

Drittanbieter-SDKs und Produkttypen: eigenes Bundle gegen Haupt-App

Bei einem binären SDK suchen Sie zunächst im SDK-Artefakt, bevor Sie das fertige Archive untersuchen. Enthält das gelieferte Framework oder Ressourcen-Bundle kein eigenes Manifest, kann die App-Integration keine fehlende Quelldatei aus dem SDK herbeizaubern. Fragen Sie den Anbieter nach dem vorgesehenen Paket, der Manifest-Datei und einer aktualisierten Version, falls die ausgelieferte Struktur unvollständig ist.

Ist das Manifest im SDK vorhanden, aber nach dem Archive nicht mehr auffindbar, prüfen Sie Einbettung, Kopierphasen und Bundle-Nesting. Apple führt Anforderungen für bestimmte Drittanbieter-SDKs in einer aktuellen offiziellen Liste samt Hinweisen. Prüfen Sie den konkreten SDK-Namen und die jeweils geltende Anforderung in dieser Liste, statt pauschal anzunehmen, jedes SDK unterliege denselben Vorgaben.

Auch der Ablageort hängt vom Produkttyp ab. Vergleichen Sie die Dokumentation für App, Framework und andere betroffene Bundle-Typen mit der Struktur im Archive. Wenn eine Suche im App-Hauptbundle leer bleibt, heißt das nicht zwangsläufig, dass die Datei in einem eingebetteten Framework ebenfalls fehlt. Umgekehrt beweist ein Treffer im Projektordner nicht, dass sie im vorgesehenen Bundle liegt.

Achtung: Kopieren Sie ein SDK-Manifest nicht einfach in das App-Hauptbundle, um eine fehlende SDK-Ressource zu kaschieren. Das kann die eigentliche Integrationslücke verdecken und ersetzt nicht die korrekte Beschreibung des Verhaltens der betreffenden Komponente.

Für die Zuordnung gilt: Der SDK-Anbieter muss seine Auslieferung und die Beschreibung seines Codes verantworten; Sie müssen die verwendete SDK-Version, deren Einbindung und das resultierende Archive überprüfen. Apple verlangt für betroffene SDKs die Umsetzung seiner jeweiligen Vorgaben, aber daraus folgt keine pauschale Aussage, jedes Projekt brauche identische Inhalte.

Remote-Mac-CI: lokales Ergebnis gegen archivierten CI-Nachweis

Wenn das Manifest lokal vorhanden ist und in CI fehlt, vergleichen Sie Eingaben und Artefakte für denselben Commit. Der Ausdruck „gleicher Code“ genügt nicht, wenn Xcode-Auswahl, Scheme, Build-Konfiguration oder Abhängigkeiten voneinander abweichen. Erfassen Sie die aktive Xcode-Installation, das verwendete Build-Kommando, die aufgelösten Packages und den vollständigen Archive-Pfad.

Ein wiederholbarer Prüfablauf sieht so aus:

1. Lassen Sie den CI-Lauf Commit, Scheme, Konfiguration und verwendete Xcode-Version protokollieren.
2. Sichern Sie das erzeugte .xcarchive als Artefakt, bevor ein nachfolgender Schritt es verschiebt oder bereinigt.
3. Führen Sie die Suche nach PrivacyInfo.xcprivacy im App-Produkt und in eingebetteten Bundles aus.
4. Speichern Sie Suchausgabe und relevante Build-Protokolle zusammen mit dem Artefakt.
5. Wiederholen Sie denselben Lauf auf einem zweiten Durchgang mit unveränderten Eingaben. Weichen die Befunde ab, vergleichen Sie zuerst die Umgebung und Abhängigkeitsauflösung.
6. Wenn beide Läufe identisch sind, aber das Manifest fehlt, untersuchen Sie die Target- und Ressourcen-Konfiguration des betroffenen Produkts.

Dieser Vergleich verursacht zwar zusätzlichen Speicher- und Aufbewahrungsaufwand für Archive und Protokolle. Er verhindert jedoch, dass ein Team aus einer lokalen Xcode-Ansicht auf den Inhalt des CI-Artefakts schließt. Legen Sie fest, wer auf Build-Protokolle und Archive zugreifen darf, und schützen Sie dort enthaltene Projektinformationen nach Ihren internen Berechtigungsregeln. Ein Mac-Knoten mit administrativen Rechten löst keine Datenschutz- oder Geheimnisverwaltung automatisch.

Wenn Sie dafür einen separaten Knoten evaluieren, vergleichen Sie auch Betriebsform und Wartungsaufwand: Ein dedizierter Mac kann vom Build-Team kontrolliert werden; eine virtualisierte Umgebung bringt andere Grenzen bei Host-Zugriff und Ressourcen mit sich. Die Unterschiede sind in unserem Vergleich Bare Metal und macOS-Virtualisierung eingeordnet. Die Entscheidung sollte sich an Ihrer konkreten CI-Wiederholbarkeit und den erforderlichen Zugriffen orientieren, nicht an einem vermuteten Effekt auf Privacy-Manifests.

Datei vorhanden, Prüfung fehlgeschlagen: Format gegen Erklärung

Wenn die Datei im erwarteten Bundle liegt, aber eine Prüfung weiter scheitert, behandeln Sie das als Inhalts- oder Validierungsproblem, nicht als Paketierungsfehler. Prüfen Sie zuerst, ob die Datei syntaktisch eine gültige Property List ist:

plutil -lint "$MANIFEST_PATH"

Ein erfolgreicher Syntaxcheck bestätigt nicht, dass alle Schlüssel und Werte von Apple akzeptiert werden. Kontrollieren Sie anschließend die Manifeststruktur anhand der offiziellen Hinweise zum Hinzufügen eines Privacy Manifests. Stimmen Sie deklarierte Datennutzung mit den tatsächlichen Funktionen Ihrer App und den eingebundenen SDKs ab. Eine syntaktisch korrekte Datei kann inhaltlich trotzdem unvollständig oder unzutreffend sein.

Prüfen Sie auch erforderliche Begründungen für Required-Reason-APIs. Apple beschreibt die entsprechenden Anforderungen und Angaben in der Dokumentation zu Required-Reason-API-Erklärungen. Wenn eine verwendete API nicht zur angegebenen Begründung passt oder die erforderliche Angabe fehlt, hilft das erneute Kopieren derselben Datei nicht. Ziehen Sie zusätzlich Apples TN3181 zur Diagnose ungültiger Privacy Manifests heran und ordnen Sie die dortigen Prüfungen dem konkreten Fehler zu.

Ändern Sie keine Datei im bereits signierten Archive als vermeintlichen Schnellfix. Eine nachträgliche Änderung kann die Signatur ungültig machen und lässt zudem die eigentliche Build-Quelle unverändert. Korrigieren Sie die Manifest-Quelle, erzeugen Sie ein neues Archive und führen Sie die Artefaktprüfung erneut aus. Bewahren Sie die Validierungsausgabe zusammen mit dem neuen Build auf.

Fehlerbilder und Nachweise im Vergleich

Verwenden Sie diese Tabelle als Priorisierung, nicht als automatische Diagnose. Ein fehlender Treffer in einer einzelnen Bundle-Ebene sagt nichts über andere eingebettete Produkte aus. Grenzen Sie deshalb zuerst ein, welches Produkt betroffen ist, und prüfen Sie dann dessen erwartete Struktur.

Entscheidung nach Befund: Reparaturpfad statt Sammeländerung

Wählen Sie den nächsten Schritt nach dem nachgewiesenen Fehlerbild:

• Wenn das Manifest nur im Quellbaum liegt, prüfen Sie Target-Zuordnung und Ressourcenphase; andernfalls nicht gleichzeitig Package- oder SDK-Einstellungen ändern.
• Wenn das Package-Produkt die Datei nicht enthält, korrigieren Sie die Ressourcendeklaration des Swift Package und bauen Sie das Package neu; andernfalls untersuchen Sie dessen Einbettung in die App.
• Wenn das SDK-Artefakt bereits ohne Manifest geliefert wird, eskalieren Sie an den Anbieter oder aktualisieren Sie die Abhängigkeit; fügen Sie nicht ersatzweise eine fremde SDK-Erklärung in das App-Manifest ein.
• Wenn die Datei im richtigen Bundle liegt, aber ungültig ist, prüfen Sie Format, akzeptierte Angaben und Required-Reason-API-Erklärungen; andernfalls behandeln Sie den Fehler nicht länger als reines Inhaltsproblem.
• Wenn nur Remote-Mac-CI abweicht, gleichen Sie Xcode, Scheme, Konfiguration und Package-Auflösung ab; andernfalls sammeln Sie zunächst Artefakt und Build-Protokoll, bevor Sie den Knoten austauschen.

Ein Remote-Mac-Knoten bietet eine kontrollierbare macOS-Umgebung für Archive und CI-Vergleiche. Er bestätigt aber weder, dass ein Manifest korrekt gepackt wurde, noch, dass seine Erklärungen stimmen. Wenn Sie einen solchen Knoten für reproduzierbare Builds evaluieren, finden Sie Informationen zu Mac-Rechenknoten und Verfügbarkeit; prüfen Sie dabei getrennt, welche Betriebs- und Zugriffsform zu Ihrer Pipeline passt.

FAQ zur Prüfung des Privacy Manifests

Die Antworten im FAQ unterscheiden Paketierung, Inhalt und CI-Nachweis. Verwenden Sie den jeweils passenden Prüfpfad, statt jede Beanstandung als denselben Xcode-Fehler zu behandeln.

Archive-Prüfung und Remote-Mac-CI: Entscheidungstabellen

Diese Abfolge verhindert zwei kostspielige Umwege: eine vermeintliche Inhaltskorrektur, obwohl die Datei gar nicht im Produkt liegt, und eine erneute Paketierungsänderung, obwohl nur ein ungültiger Wert beanstandet wird. Halten Sie pro Lauf fest, welche Frage mit welchem Artefakt beantwortet wurde.

Wenn Ihr lokaler Mac und die CI-Umgebung trotz festgehaltener Eingaben unterschiedliche Archive erzeugen, ist ein separater macOS-Buildknoten eine sinnvolle Option für reproduzierbare Gegenproben. Ein eigener Kauf bindet Kapital und Wartung an ein Gerät; ein allgemeiner Linux-Host kann Xcode und macOS-spezifische Werkzeuge nicht ersetzen; eine wechselnde CI-Umgebung erschwert den Vergleich von Abhängigkeiten und Artefakten. Für zeitlich begrenzte Tests oder zusätzliche Build-Kapazität können Sie daher MacDate als Mietoption prüfen. Die Miete verbessert die Verfügbarkeit eines passenden macOS-Testsystems, ersetzt aber weder Ihre Manifestvalidierung noch die Kontrolle des finalen Archive.