xcodebuild-Export der IPA fehlgeschlagen: Remote-Mac 2026 beheben?

Der xcodebuild-Export der IPA ist fehlgeschlagen, obwohl das Archive erfolgreich war? Verwenden Sie zuerst dieselbe xcarchive-Datei für einen Vergleich zwischen Xcode-Oberfläche und xcodebuild; prüfen Sie danach ExportOptions.plist, Signatur, Provisioning Profile und die Berechtigungen der SSH-Sitzung. Starten Sie nicht wiederholt den Build, bevor der erste gültige Exportfehler gesichert ist.

Diese Anleitung richtet sich an Sie, wenn Sie über SSH oder ein CI/CD-Skript arbeiten und das Exportverzeichnis leer bleibt. Sie ist außerdem für Betreiber eines Remote-Mac gedacht, bei denen der Export in einer grafischen Sitzung funktioniert, im unbeaufsichtigten Prozess aber scheitert. Kleine Teams erhalten dabei eine prüfbare Trennung zwischen Build, Archive, Export und Upload.

Archive erfolgreich, IPA fehlt: Wo endet der erste Schritt?

Ein typisches, anonymisiertes Log sieht so aus:

** ARCHIVE SUCCEEDED **
Exporting archive...
error: exportArchive failed
The specified item could not be found

Die erste Zeile bestätigt nur, dass ein xcarchive erzeugt wurde. Sie bestätigt nicht, dass daraus eine IPA für eine konkrete Verteilung erstellt werden kann. Apple beschreibt Archive und die anschließende Verteilung als getrennte Verarbeitungsschritte; xcodebuild verwendet dafür unter anderem archivePath, exportOptionsPlist und exportPath.Apple beschreibt den Ablauf von Archive und App-Verteilung

Für die Diagnose teilen Sie den Ablauf in vier Zustände:

1. Build: Quellcode, Abhängigkeiten und Targets werden kompiliert.
2. Archive: Das Ergebnis wird als xcarchive für ein generisches Gerät abgelegt.
3. Export: Das Archive wird entsprechend der Verteilungsart signiert und als IPA ausgegeben.
4. Upload: Die IPA oder ein anderes Distributionsartefakt wird an den vorgesehenen Dienst übertragen.

Damit ist auch erklärt, warum ein erfolgreicher Archive-Schritt und ein leerer Ausgabeordner gleichzeitig möglich sind. Der Export prüft erneut, ob Verteilungsziel, Signaturmaterial, Profile, Entitlements und Ausgabeumgebung zusammenpassen.

Warum ist exit code 70 kein ausreichender Befund?

xcodebuild exportArchive kann mit exit code 70 abbrechen. Dieser Code ist jedoch kein Beweis für genau eine Ursache. Behandeln Sie ihn als Sammelsignal: Entscheidend ist die erste konkrete Fehlermeldung davor, nicht der letzte Rückgabewert der Shell.

Sichern Sie deshalb unmittelbar:

• den vollständigen Terminalauszug einschließlich Warnungen;
• den Pfad zur unveränderten xcarchive;
• die verwendete ExportOptions.plist;
• die Xcode-Version und den aktiven Developer-Pfad;
• die Distribution-Logs sowie den Inhalt des temporären Exportordners.

Verwenden Sie für alle Vergleichsläufe denselben Projektstand, dieselbe xcarchive, dieselbe Konfigurationsdatei und dasselbe Ausgabeziel. Wenn Sie zwischen den Versuchen neu archivieren, verändern Sie mehrere Variablen und können nicht mehr feststellen, ob der Fehler im Archive oder im Export lag.

ExportOptions.plist gegen Verteilungsziel: Passt die Konfiguration wirklich?

Die Exportkonfiguration muss dem tatsächlichen Ziel entsprechen. Eine Einstellung für registrierte Testgeräte ist nicht automatisch für die Veröffentlichung über den App-Vertriebsdienst geeignet. Ebenso sollten Sie eine aus einem alten Projekt kopierte Datei nicht als allgemeingültige Vorlage behandeln.

ExportOptions.plist und Signatur im direkten Vergleich prüfen

Erzeugen Sie zunächst über die Xcode-Oberfläche einen erfolgreichen Export desselben Archives, sofern das in einer interaktiven Sitzung möglich ist. Kopieren Sie die dabei verwendeten Werte nicht blind, sondern nutzen Sie sie als Vergleichsbasis für Ihr Skript.

Prüfen Sie anschließend in dieser Reihenfolge:

1. Verteilungsart: Passt das gewählte Verfahren zu Testgeräten, Beta-Verteilung oder Store-Veröffentlichung?
2. Signaturverwaltung: Wird automatisch signiert oder werden Zertifikat und Profile manuell zugeordnet?
3. Team-Zuordnung: Verweist das Projekt auf das erwartete Entwicklerteam?
4. Profile-Mapping: Sind Haupt-App, Erweiterungen und zusätzliche Targets jeweils korrekt zugeordnet?
5. Ausgabeziel: Existiert der Exportpfad, und darf der Remote-Benutzer dort schreiben?

Welche Schlüssel und Werte für Ihre Xcode-Version zulässig sind, müssen Sie auf dem Zielrechner mit xcodebuild -help und der aktuellen Apple-Dokumentation prüfen. Übernehmen Sie keine alte Datei aus einem Blog, einem fremden Repository oder einem früheren Projektzustand. Die verfügbaren Optionen können sich mit dem verwendeten Xcode ändern.

Ein sauberer Vergleich sieht beispielsweise so aus:

xcodebuild -exportArchive \
  -archivePath "/arbeitsbereich/App.xcarchive" \
  -exportOptionsPlist "/arbeitsbereich/ExportOptions.plist" \
  -exportPath "/arbeitsbereich/export"

Die Pfade sind hier absichtlich neutralisiert. Verwenden Sie in veröffentlichten Logs niemals echte Benutzernamen, Team-IDs, Bundle-IDs, Profile-UUIDs oder Zertifikatsnamen.

Weshalb lässt sich die lokale IPA exportieren, aber nicht per SSH?

Eine grafische Anmeldung und eine SSH-Sitzung verwenden nicht zwangsläufig denselben Zustand. Häufig unterscheiden sich:

• der macOS-Benutzer;
• die geöffnete Keychain;
• der aktive Developer-Pfad;
• das Home-Verzeichnis;
• die Arbeits- und Temp-Verzeichnisse;
• die Schreibrechte im Ausgabeordner;
• die Freigabe für den Zugriff auf den privaten Schlüssel.

Ein lokaler Xcode-Export kann daher erfolgreich sein, während der SSH-Prozess das Zertifikat zwar sieht, aber den privaten Schlüssel nicht verwenden darf. Ebenso kann ein Skript eine andere ExportOptions.plist laden, als Sie bei der interaktiven Prüfung erwarten.

Führen Sie den Export zunächst interaktiv unter genau dem Benutzer aus, der später den CI/CD-Job startet. Danach führen Sie denselben Befehl unbeaufsichtigt aus. Vergleichen Sie vor beiden Läufen:

whoami
echo "$HOME"
xcode-select -p
pwd
ls -ld "/arbeitsbereich/export"

Diese Befehle beweisen noch keine gültige Signatur, zeigen aber, ob beide Sitzungen überhaupt dieselbe Umgebung verwenden. Für die Berechtigungsseite müssen Sie zusätzlich die tatsächlich sichtbaren Signaturidentitäten und Profile prüfen, ohne private Schlüssel oder geheime Inhalte in die Logdatei zu schreiben.

Signaturkette gegen Archive-Inhalt: Was muss übereinstimmen?

Der Export scheitert häufig nicht am Vorhandensein eines Zertifikats, sondern an einer unvollständigen oder widersprüchlichen Signaturkette. Ein importiertes Zertifikat ohne den zugehörigen privaten Schlüssel reicht nicht aus. Apple unterscheidet Zertifikatstypen nach ihrer Verwendung; die Übersicht zu Zertifikaten und ihren Einsatzzwecken ist deshalb die passende Referenz, bevor Sie ein Asset ersetzen.

Prüfen Sie getrennt:

• Zertifikat und gültige Signaturidentität;
• zugehöriger privater Schlüssel in der verwendeten Keychain;
• Provisioning Profile für jedes betroffene Target;
• Bundle-ID und aktivierte Capabilities;
• Entitlements des Archivs;
• eingebettete Frameworks und Erweiterungen.

Öffnen Sie die xcarchive nicht nur als Datei im Finder. Prüfen Sie die enthaltene App, Erweiterungen, Frameworks und Info.plist. Bei mehreren Targets muss jedes Bundle einzeln betrachtet werden. Ein Hauptziel kann korrekt signiert sein, während ein Widget, eine Share Extension oder ein App Clip eine nicht passende Bundle-ID oder Capability enthält.

Entitlements und Profile nicht nur nach Dateinamen beurteilen

Ein Profile mit passendem Dateinamen ist kein Nachweis, dass es zum Archive gehört. Vergleichen Sie die tatsächlich eingebetteten Entitlements mit den im Profile gewährten Fähigkeiten. Achten Sie besonders auf Push-Benachrichtigungen, App Groups, Associated Domains und andere projektspezifische Berechtigungen.

Für Profile gelten außerdem Verwaltungsregeln: Laden Sie ein benötigtes Profile kontrolliert neu herunter, sichern Sie die bisherige Datei und dokumentieren Sie die Zuordnung. Apple erklärt das Bearbeiten, Herunterladen und Löschen von Provisioning Profiles. Löschen Sie ein Profile nicht als ersten Reparaturversuch.

Achtung: Bevor Sie Profile löschen, Zertifikate widerrufen, Keychain-Zugriffe ändern oder Archive bereinigen, sichern Sie die Originaldateien und notieren Sie die Rückfalloption. Ein Widerruf kann andere laufende Builds oder Testgeräte betreffen; ein gelöschtes Archive lässt sich nicht aus dem Exportfehler rekonstruieren.

Automatische Signaturverwaltung und manuelle Signaturverwaltung sollten Sie nicht gleichzeitig halb aktiv betreiben. Entscheiden Sie für den Diagnoseversuch, welcher Pfad verwendet wird. Bei automatischer Verwaltung prüfen Sie Team, Bundle-ID, Netzwerkzugriff und Account-Berechtigung. Bei manueller Verwaltung dokumentieren Sie jedes Target, jedes Profile und jede Signaturidentität.

Remote-Mac als Exportmaschine: Welche Bedingungen gelten für den unbeaufsichtigten Lauf?

Ein Remote-Mac ist erst dann als iOS-Exportmaschine geeignet, wenn ein nicht-interaktiver Lauf denselben Zustand wie der geprüfte grafische Lauf erreicht. Die Entfernung allein ist nicht das Problem; problematisch sind versteckte Sitzungsabhängigkeiten.

Schritt für Schritt zur reproduzierbaren Exportprüfung

1. Einen unveränderten Prüfdatensatz anlegen

Legen Sie eine Kopie der erfolgreichen xcarchive, der Exportkonfiguration und der relevanten Logs in einem geschützten Arbeitsverzeichnis ab. Benennen Sie die Dateien so, dass Xcode-Version, Projektstand und Prüfzweck erkennbar sind. Entfernen oder anonymisieren Sie vor einer Weitergabe persönliche Pfade und Kontodaten.

2. Den Archive-Inhalt validieren

Öffnen Sie das Archive über Xcode Organizer und prüfen Sie App, Erweiterungen, Frameworks und Metadaten. Führen Sie, sofern verfügbar, eine Validierung oder den Distribute-App-Dialog aus. Wenn bereits diese Prüfung fehlschlägt, korrigieren Sie zuerst das Archive und nicht die SSH-Konfiguration.

3. Die ExportOptions.plist am Zielrechner abgleichen

Vergleichen Sie die Datei aus dem erfolgreichen grafischen Lauf mit der Datei im Skript. Prüfen Sie Verteilungsart, Signaturmodus, Team-Zuordnung, Profile und Ausgabeziel. Bestätigen Sie alle verwendeten Schlüssel mit xcodebuild -help auf genau diesem Mac.

4. Signaturidentität und privaten Schlüssel prüfen

Stellen Sie fest, ob der Benutzer des unbeaufsichtigten Jobs die erwartete Signaturidentität sieht und den privaten Schlüssel verwenden darf. Prüfen Sie die Keychain-Auswahl und die Entsperrung innerhalb der vorgesehenen Sicherheitsregeln. Geben Sie niemals private Schlüssel, Passwörter oder komplette Keychain-Inhalte in CI/CD-Logs aus.

5. Entitlements pro Target vergleichen

Lesen Sie die Entitlements der archivierten Haupt-App und aller Erweiterungen aus. Vergleichen Sie sie mit den Fähigkeiten der zugeordneten Profile. Ein einzelnes nicht passendes verschachteltes Bundle kann den gesamten Export stoppen.

6. Interaktiv und per SSH mit demselben Benutzer testen

Führen Sie den identischen Exportbefehl zunächst in einer interaktiven Sitzung und anschließend im unbeaufsichtigten Job aus. Vergleichen Sie Benutzer, Home-Verzeichnis, Developer-Pfad, Keychain-Zugriff, Arbeitsverzeichnis und Schreibrechte. Verwenden Sie dabei weiterhin dieselbe xcarchive.

7. Fehlerbehandlung und Wiederanlauf testen

Bewahren Sie Exportprotokolle und Zwischenstände nach einem Fehlschlag auf. Prüfen Sie, ob ein Verbindungsabbruch, ein Neustart oder die Bereinigung des Arbeitsbereichs die Beweislage zerstört. Erst wenn ein wiederholter Lauf mit derselben Eingabe reproduzierbar endet, sollten Sie die Umgebung als stabil bewerten.

Welche Berechtigungen braucht die Veröffentlichung?

Für das Erzeugen einer IPA sind lokale Signatur- und Profileinstellungen entscheidend. Für die spätere Übertragung kommen zusätzlich Rollen und Zugriffsrechte des Kontos hinzu. Prüfen Sie daher die offizielle Übersicht der Rollenberechtigungen, statt eine fehlende Upload-Berechtigung mit einem Exportfehler zu verwechseln.

Auch ein korrekt exportiertes Artefakt kann beim nächsten Schritt abgelehnt oder in einen anderen Uploadstatus versetzt werden. Die Dokumentation zu Build-Upload-Statuswerten hilft Ihnen, Export und Upload getrennt zu protokollieren. Wenn der App-Eintrag selbst fehlt oder falsch zugeordnet ist, prüfen Sie außerdem die offizielle Anleitung zum Erstellen eines App-Eintrags.

Für eine unbeaufsichtigte Pipeline sollten Sie den Upload deshalb erst aktivieren, nachdem der lokale Export mit derselben xcarchive wiederholbar gelingt. So vermeiden Sie, dass ein Uploadproblem die Diagnose des Exporters verdeckt.

Entscheidung vor der nächsten Änderung: Reparatur oder Wechsel der Remote-Umgebung

Bewerten Sie nicht nur, ob einmal eine IPA entsteht. Entscheidend ist, welche Eingabe, welcher Benutzer und welche Sitzung dafür erforderlich waren. Die folgende Matrix trennt die häufigsten Befunde und die angemessene nächste Aktion:

Für den Remote-Betrieb kann ein eigener physischer Mac im Rechenzentrum sinnvoller sein als eine Umgebung, deren Export von einer geöffneten Benutzersitzung abhängt. Lesen Sie dazu die Informationen zu Bare-Metal-Mac gegenüber Virtualisierung, wenn Sie die Stabilität der Ausführungsumgebung bewerten. Bei der Auswahl sollten Sie neben Kosten auch Zugriffskontrolle, Datenstandort, DSGVO-Anforderungen, Wiederanlauf und die Möglichkeit zur Logaufbewahrung berücksichtigen.

Wenn die aktuelle Maschine nur deshalb funktioniert, weil Xcode zuvor interaktiv geöffnet wurde, ist das kein belastbarer CI/CD-Nachweis. Wenn dagegen dieselbe xcarchive unter demselben Benutzer wiederholt exportiert wird und ein Neustart die Bedingungen nicht verändert, spricht das für eine brauchbare Dauerlösung.

Ein fremder oder gemieteter Mac ersetzt keine korrekte Signaturkonfiguration. Er kann aber die Diagnose beschleunigen, wenn Ihr aktuelles System unklare Keychain-Zustände, fehlende Schreibrechte oder einen nicht reproduzierbaren Sitzungswechsel aufweist. Für einen ersten Vergleich können Sie die MacDate-Übersicht für Remote-Mac-Umgebungen heranziehen.

Wenn Ihre lokale Oberfläche exportiert, der bestehende SSH-Job aber wiederholt an Sitzung, Keychain oder Arbeitsverzeichnis scheitert, ist ein unabhängiger Remote-Mac als Gegenprobe sinnvoll. Testen Sie dort zuerst dieselbe xcarchive, denselben Exportbefehl und anschließend einen Neustart mit erneutem Export. Erst wenn diese Prüfung ohne manuelle Nacharbeit besteht, sollten Sie die Maschine als dauerhafte iOS-Build- und Exportumgebung einsetzen.