xcodebuild exit code 65: Wie repariert man Remote Builds 2026?

Der Wert 65 ist bei xcodebuild zunächst nur ein zusammengefasster Fehlschlagsstatus. Die richtige Maßnahme lautet daher: vollständiges Log und xcresult sichern, anschließend den Fehler nach Build-, Abhängigkeits-, Test-, Signatur- oder Remote-Sitzungsphase eingrenzen. Erst wenn derselbe Commit in einer kontrollierten Umgebung stabil funktioniert oder scheitert, ist ein Austausch des Remote Mac sinnvoll.

Diese Anleitung hilft unabhängigen iOS- und macOS-Entwicklern, deren grafischer Xcode-Build funktioniert, während SSH oder CI fehlschlägt. Sie richtet sich außerdem an kleine Teams mit Simulator-Tests sowie an Maintainer, die Archive, Signierung und unbeaufsichtigte Exporte ausführen.

[ SECTION_01 ] Der Statuscode verrät noch nicht die Fehlerquelle

Ein gekürzter Fehlerauszug sieht häufig ungefähr so aus:

** TEST FAILED **
The following build commands failed:
    CompileSwift normal arm64 ...
xcodebuild: error: ...
Process completed with exit code 65

Der konkrete Projektname, das Scheme, der Benutzerpfad, die Gerätekennung und die Signaturdaten müssen in einer veröffentlichten Diagnose entfernt werden. Wichtig ist die Reihenfolge: Die letzte Zeile nennt den fehlgeschlagenen Prozess, aber die verwertbare Ursache kann deutlich früher stehen.

xcodebuild wird für unterschiedliche Aktionen verwendet. Ein Fehler beim reinen Kompilieren ist anders zu untersuchen als ein Fehler beim Teststart oder beim Export eines Archivs. Apple beschreibt das Ausführen und Auswerten von Tests einschließlich Ergebnisdaten in der offiziellen Dokumentation zur Testausführung und Ergebnisinterpretation.

Die erste Sortierung erfolgt deshalb nach der ausgeführten Aktion:

• Build: Prüfen, ob Projekt, Konfiguration, Abhängigkeiten, Quellcode oder Linker fehlschlagen.
• Test: Zuerst den Build des Testprodukts, danach Destination, Simulatorstart und eigentlichen Testlauf trennen.
• Archive: Feststellen, ob das Archiv erstellt wurde oder ob die Signierung bereits während des Archivierens scheitert.
• exportArchive: Erst nach erfolgreichem Archive die Exportoptionen, Profile und Signaturidentität prüfen.

Ein Upload an einen Store ist nochmals ein nachgelagerter Vorgang. Ein erfolgreicher Archive-Schritt beweist nicht, dass der Export oder Upload erfolgreich sein wird.

[ SECTION_02 ] Erste Sicherung: Log, Ergebnis-Paket und exakter Befehl

Ohne reproduzierbare Eingabedaten wird aus der Fehlersuche schnell ein Ratespiel. Die CI-Definition sollte deshalb für jeden Auftrag mindestens folgende Informationen sichern:

• den vollständigen Standardausgabestrom und den Fehlerausgabestrom,
• den exakt ausgeführten xcodebuild-Befehl,
• das aktuelle Arbeitsverzeichnis,
• die gewählte Projekt- oder Workspace-Datei,
• das verwendete Scheme und die Build-Konfiguration,
• die Destination,
• den Pfad zum .xcresult-Paket,
• Commit oder unveränderliche Quellcodeversion.

Ein Ergebnis-Paket ist nützlicher als die letzte Terminalzeile, weil dort strukturierte Test- und Diagnosedaten liegen können. Der Pfad sollte pro Auftrag eindeutig sein, damit ein späterer Lauf nicht die Beweise des ersten Laufs überschreibt. In CI muss das Artefakt auch bei einem Fehler hochgeladen werden. Ein Job, der nur bei Erfolg Logdateien speichert, beseitigt die wichtigste Diagnosequelle.

Vor dem Teilen sollten geheime Werte entfernt werden. Dazu gehören Zertifikatsnamen, private Repository-Adressen, Benutzerverzeichnisse, Team-IDs, Bundle-IDs und Token. Das ist nicht nur eine Frage der Lesbarkeit, sondern auch eine Maßnahme für Datenschutz und DSGVO-konforme Protokollierung.

[ SECTION_03 ] Projektdatei, Scheme und Konfiguration zuerst abgleichen

Ein häufiger Unterschied zwischen GUI und SSH entsteht bereits beim Projekteingang. Nach der Einrichtung einer Paketverwaltung wird weiterhin das Projekt geöffnet, obwohl der korrekte Build über eine Workspace-Datei laufen müsste. Der umgekehrte Fehler ist ebenfalls möglich: Der Automatisierungsjob erwartet einen Workspace, der auf dem Remote Mac gar nicht vorhanden ist.

Die Prüfung sollte in derselben Sitzung stattfinden, die später fehlschlägt:

1. Arbeitsverzeichnis ausgeben und in das Repository wechseln.
2. Vorhandene Projekt- und Workspace-Dateien auflisten.
3. Schemes der tatsächlich verwendeten Datei anzeigen.
4. Die Configuration und Destination ausdrücklich angeben.
5. Den Befehl zunächst ohne Signierung oder Testlauf auf einen reinen Build begrenzen.
6. Einen zweiten Lauf mit exakt derselben, zuvor bereinigten Befehlszeile starten.

Ein Scheme kann existieren, aber nicht für gemeinsame Nutzung freigegeben sein. Dann sieht eine lokale GUI-Sitzung das Scheme möglicherweise über benutzerspezifische Einstellungen, während der CI-Prozess nur die im Repository gespeicherten Daten liest. Apples Hinweise zur Anpassung von Build-Schemes sind hierfür die maßgebliche Referenz.

Auch eine abweichende Build-Konfiguration kann das Ergebnis verändern. Debug und Release verwenden oft unterschiedliche Flags, Suchpfade, Skripte oder Signaturwerte. Wenn Konfigurationen über eine .xcconfig-Datei gepflegt werden, muss die Remote-Sitzung genau diese Datei laden. Apple dokumentiert das Hinzufügen einer Build-Configuration-Datei. Die praktische Konsequenz lautet: Nicht nur den Scheme-Namen vergleichen, sondern die daraus resultierenden Einstellungen.

Achtung: Ein erfolgreiches xcodebuild in einer geöffneten Xcode-Sitzung ist kein Beweis für eine identische CI-Umgebung. GUI-Sitzung, SSH-Prozess und Hintergrunddienst können unterschiedliche Pfade, Schlüsselbunde und Umgebungsvariablen erhalten.

[ SECTION_04 ] Abhängigkeiten, Skripte und Linkerfehler getrennt behandeln

Der Status 65 kann nach einer fehlgeschlagenen Abhängigkeitsauflösung ebenso erscheinen wie nach einem Compiler- oder Linkerfehler. Eine pauschale Löschung aller Caches verschleiert dabei häufig die Ursache und macht den nächsten Lauf schwer vergleichbar.

Die Logsuche sollte die fehlerhafte Phase bestimmen:

• Abhängigkeiten: Sperrdatei, Paketquelle, private Repository-Anmeldung und Netzwerkzugriff prüfen.
• Kompilierung: Erste Swift- oder Objective-C-Fehlermeldung isolieren; Folgefehler zunächst ignorieren.
• Ressourcen: Pfade, Dateinamen, Zielmitgliedschaft und case-sensitive Unterschiede prüfen.
• Linken: Fehlende Bibliotheken, Architekturkonflikte und doppelte Symbole unterscheiden.
• Run Script: Interpreter, Dateirechte, Arbeitsverzeichnis und erforderliche Variablen kontrollieren.

Auf dem Remote Mac sollte der Commit frisch ausgecheckt werden. Ein Build aus einem bereits veränderten Arbeitsverzeichnis kann grün werden, obwohl der CI-Job mit einem sauberen Checkout weiterhin fehlschlägt. Umgekehrt kann ein lokaler Cache einen fehlenden Schritt verdecken.

Besonders wichtig sind private Paketquellen. Eine interaktive Sitzung besitzt unter Umständen eine gespeicherte Authentifizierung, der SSH-Prozess jedoch nicht. Das gleiche gilt für Variablen, die in einer IDE gesetzt, aber nicht an einen Hintergrunddienst vererbt werden. Die Prüfung sollte daher nicht nur „ist die Variable lokal vorhanden?“ lauten, sondern „ist sie in genau diesem Prozess vorhanden und enthält sie den erwarteten, nicht geheimen Steuerwert?“.

[ SECTION_05 ] Tests: Build, Simulator und Startzeit nicht vermischen

Bei Testaufträgen muss zuerst geklärt werden, ob das Testprodukt überhaupt gebaut wurde. Erst danach sind Simulator, App-Start und Testfall selbst an der Reihe. Ein nicht verfügbares Zielgerät ist kein Beweis für einen Quellcodefehler.

Für die Eingrenzung eignet sich die Trennung von Erzeugung und Ausführung:

• Mit build-for-testing wird das Testprodukt samt Testbeschreibung erstellt.
• Mit test-without-building wird ein bereits erzeugtes Testprodukt auf einer ausgewählten Destination ausgeführt.

Apple beschreibt in den Informationen zu Xcode-Cloud-Testaktionen die Aufteilung von Build- und Testaktionen. Das ist auch für eigene CI-Abläufe hilfreich: Wenn build-for-testing scheitert, liegt die Ursache vor dem Simulatorstart. Wenn dieser Schritt gelingt, aber test-without-building scheitert, rücken Destination, Startdienst, Test-Setup oder Laufzeitberechtigungen in den Vordergrund.

Für den Remote Mac sind folgende Prüfungen relevant:

• Ist das gewünschte Zielsystem tatsächlich installiert?
• Ist die angegebene Destination noch gültig?
• Nutzt der Job eine stabile Gerätekennung oder eine veraltete Auswahl?
• Kann der Prozess den Simulatordienst in einer nicht-interaktiven Sitzung starten?
• Wird der Test durch ein fehlendes UI- oder Netzwerk-Setup blockiert?
• Ist der Timeout ein echter Startfehler oder nur ein zu früh beendeter Prozess?

Umgebungsvariablen können Testverhalten und Diagnose beeinflussen. Eine belastbare Referenz bietet Apples Übersicht der Test-Umgebungsvariablen. Für die Fehlersuche sollte jede relevante Variable protokolliert werden, jedoch niemals ihr geheimes Token oder dessen vollständiger Inhalt.

[ SECTION_06 ] Archive, Signierung und Export als eigene Fehlerklassen

Ein Build kann erfolgreich sein, während das Archive oder der Export scheitert. Deshalb darf ein allgemeiner Hinweis auf „Signing“ nicht als Diagnose genügen. Die vier Zustände müssen getrennt dokumentiert werden:

1. Kompilierung abgeschlossen.
2. Archive erfolgreich erzeugt.
3. Archive korrekt signiert.
4. Export mit passender Exportkonfiguration abgeschlossen.

Für eine Distribution-Signierung benötigt der Schlüsselbund nicht nur ein Zertifikat, sondern die zugehörige private Schlüsselkomponente. Zudem muss das Provisioning Profile zum Ziel, Bundle Identifier und Team passen. Apples Technische Erläuterung zu Provisioning Profiles beschreibt, welche Informationen dabei zusammenwirken.

Bei einem Remote Mac kommt die Zugriffsfrage hinzu. Ein interaktiver Benutzer kann einen Schlüsselbund entsperrt haben, während ein SSH- oder Hintergrundprozess keine Berechtigung zur Nutzung des privaten Schlüssels besitzt. Das äußert sich dann möglicherweise erst beim Archive oder Export. Apple beschreibt außerdem das Teilen von Team-Signaturzertifikaten. Daraus folgt nicht, dass Zertifikate unkontrolliert kopiert werden sollten. Vor jeder Änderung muss feststehen, welche Identität betroffen ist und wie die Rückkehr zum vorherigen Zustand erfolgt.

Das Entfernen eines Zertifikats, das Ersetzen eines Profiles oder eine großzügige Änderung der Schlüsselbundrechte kann andere Projekte und laufende Releases beeinflussen. Solche Eingriffe gehören daher hinter eine Sicherung, eine dokumentierte Zuständigkeit und einen getesteten Rückweg.

[ SECTION_07 ] Sechs Schritte für eine belastbare Diagnose

Die folgende Liste dient als direkt ausführbares Prüfprotokoll. Jeder Punkt sollte mit einem Logverweis oder einem gespeicherten Artefakt abgeschlossen werden.

• [ ] Auftrag klassifizieren: Build, Test, Archive oder exportArchive im CI-Job eindeutig markieren.
• [ ] Fehlerbild sichern: Vollständiges Log, Befehl und .xcresult unter einem eindeutigen Artefaktnamen speichern.
• [ ] Eingang prüfen: Projekt oder Workspace, Scheme, Freigabe, Arbeitsverzeichnis und Commit im Remote-Prozess bestätigen.
• [ ] Konfiguration vergleichen: Aktive Build-Konfiguration, SDK, Destination und nicht geheime Umgebungsvariablen zwischen GUI und SSH gegenüberstellen.
• [ ] Erste Ursache isolieren: Abhängigkeit, Compiler, Ressource, Linker, Skript, Simulator oder Signierung anhand der ersten verwertbaren Fehlermeldung zuordnen.
• [ ] Testphasen trennen: Bei Tests build-for-testing und test-without-building getrennt ausführen und jeweils eigene Ergebnis-Pakete sichern.
• [ ] Signatur erst danach prüfen: Schlüsselbund, private Schlüsselkomponente, Profile und Exportoptionen nur untersuchen, wenn Build und Archive-Phase dies rechtfertigen.
• [ ] Sauber reproduzieren: Mit demselben Commit in einem frischen Checkout wiederholen, nicht nur im bereits veränderten Arbeitsverzeichnis.
• [ ] Umgebung bewerten: Tritt der Fehler nur bei einem Benutzer, einer Sitzung oder einem Host auf, die Remote-Umgebung untersuchen; folgt er dem Commit, das Projekt ändern.
• [ ] Wiederanlauf testen: Nach einer neuen Sitzung oder einem Neustart denselben Auftrag wiederholen und Log sowie Artefakt vergleichen.

[ SECTION_08 ] Reparatur oder Austausch des Remote Mac: die Entscheidungsregel

Die Entscheidung lässt sich ohne pauschale Neuinstallation treffen:

• Der Fehler folgt jedem frischen Checkout desselben Commits: Projekt, Abhängigkeit, Skript oder Signaturkonfiguration reparieren.
• Der Fehler verschwindet mit einer anderen Destination: Simulatorziel, installierte Laufzeit oder Testkonfiguration korrigieren.
• GUI funktioniert, SSH scheitert: Arbeitsverzeichnis, Scheme-Freigabe, Variablen, Schlüsselbund und Sitzungsrechte vergleichen.
• Nur ein Benutzer oder Hintergrunddienst scheitert: Berechtigungs- und Anmeldekontext reparieren, nicht sofort das Projekt ändern.
• Mehrere unabhängige Projekte scheitern am gleichen Host: Build-Werkzeuge, Abhängigkeiten, Schlüsselbund oder Hostzustand prüfen.
• Der Host bleibt nach Sitzungswechsel oder Neustart inkonsistent: Einen isolierten, dauerhaft reservierten Build-Host als Gegenprobe verwenden.

Damit wird xcodebuild exit code 65 von einem scheinbar einheitlichen Fehler zu einer Entscheidung über die betroffene Schicht. Ein neuer Host ist erst dann gerechtfertigt, wenn ein kontrollierter Gegenlauf zeigt, dass der gleiche Commit auf einer anderen Umgebung anders reagiert.

Für den Gegenlauf sollte ein isolierter Remote Mac denselben Commit, dieselbe Build-Aktion und dieselbe Destination erhalten. Build, Test oder Archive müssen einzeln bewertet werden. Ein passender Leitfaden zur Abnahme einer unbeaufsichtigten Remote-Mac-Buildumgebung kann dabei als organisatorische Ergänzung dienen. Wer dagegen die Anschaffung eines eigenen Hosts abwägt, sollte die Entscheidung zwischen eigener Mac-mini-Hardware und temporärer Nutzung anhand von Zugriffsdauer, Wartung und physischem Bedarf treffen.

Die Vorteile des aktuellen Ansatzes dürfen dabei nicht übertrieben werden: Eine gemeinsam genutzte oder unklar gepflegte CI-Umgebung kann voneinander abweichende Schlüsselbunde, schwer nachvollziehbare Sitzungen und nicht reproduzierbare Caches verursachen. Ein lokales Gerät ist außerdem nicht dauerhaft verfügbar, wenn es ausgeschaltet wird oder für andere Aufgaben benötigt wird. Für einen kontrollierten Vergleich ist ein isolierter Remote Mac von NOVAKVM deshalb oft die sauberere Zwischenlösung: derselbe Commit kann unter definierten Zugriffsbedingungen erneut gebaut, getestet oder archiviert werden. Für langfristige, konstant hohe Last oder den direkten Zugriff auf physische Geräte bleibt ein eigener Mac jedoch die passendere Wahl.

Wer nur eine temporäre Gegenprobe, einen reproduzierbaren Build-Host oder eine dauerhaft erreichbare Umgebung für iOS-Builds benötigt, kann die passende Mac-Nutzung bei NOVAKVM prüfen. Entscheidend ist nicht der Wechsel um des Wechsels willen, sondern der Nachweis, ob der Fehler dem Projekt oder der bisherigen Umgebung folgt.

[ SECTION_09 ] Häufige Fragen zur Diagnose

Warum funktioniert der Build in Xcode, aber nicht über xcodebuild?

Die grafische Sitzung und die automatisierte Sitzung verwenden nicht zwingend dieselbe Arbeitsmappe, Scheme-Freigabe, Build-Konfiguration, SDK-Auswahl, Umgebungsvariable oder denselben Schlüsselbund. Vergleichen Sie deshalb den vollständigen Befehl, die aktive Entwicklerumgebung, das Arbeitsverzeichnis und die Destination. Ein erfolgreicher GUI-Build beweist nur, dass diese konkrete Sitzung funktioniert.

Ist exit code 65 ein Fehler bei der Signierung oder beim Kompilieren?

Nein. exit code 65 ist kein eindeutiger Fingerabdruck für eine einzelne Ursache. Der Status kann nach einem fehlgeschlagenen Build, Testlauf, Archive oder Export erscheinen. Entscheidend ist die erste verwertbare Fehlermeldung im Log beziehungsweise im xcresult. Erst Begriffe wie Compilerfehler, Linkerfehler, fehlendes Profil oder nicht verfügbare Destination erlauben eine belastbare Zuordnung.

Was tun, wenn ein Remote Mac das Scheme nicht findet?

Prüfen Sie zuerst, ob der Befehl eine .xcodeproj- oder .xcworkspace-Datei verwendet. Danach muss das Scheme im Projekt vorhanden und für gemeinsame Nutzung freigegeben sein. Lassen Sie sich die Schemes in derselben SSH- oder CI-Sitzung anzeigen, in der der Build läuft. Stimmen Arbeitsverzeichnis oder Dateieingang nicht, wird häufig ein formal korrektes, aber falsches Projekt geladen.

Wie bleiben vollständige Logs und xcresult in CI erhalten?

Lassen Sie die Standardausgabe in eine Datei schreiben und vergeben Sie für Build, Test und Archive jeweils einen eigenen Ergebnis-Pfad. Speichern Sie Logdatei und xcresult als CI-Artefakte, auch wenn der Job fehlschlägt. Entfernen Sie vor dem Upload Geheimnisse, Team-IDs, Bundle-IDs, Benutzerpfade und Zertifikatsnamen. Die Auswertung sollte mit dem ersten Fehler beginnen, nicht mit der letzten Statuszeile.

Häufige Fragen

Warum funktioniert der Build in Xcode, aber nicht über xcodebuild?

Die grafische Sitzung und die automatisierte Sitzung verwenden nicht zwingend dieselbe Arbeitsmappe, Scheme-Freigabe, Build-Konfiguration, SDK-Auswahl, Umgebungsvariable oder denselben Schlüsselbund. Vergleichen Sie deshalb den vollständigen Befehl, die aktive Entwicklerumgebung, das Arbeitsverzeichnis und die Destination. Ein erfolgreicher GUI-Build beweist nur, dass diese konkrete Sitzung funktioniert.

Ist exit code 65 ein Fehler bei der Signierung oder beim Kompilieren?

Nein. exit code 65 ist kein eindeutiger Fingerabdruck für eine einzelne Ursache. Der Status kann nach einem fehlgeschlagenen Build, Testlauf, Archive oder Export erscheinen. Entscheidend ist die erste verwertbare Fehlermeldung im Log beziehungsweise im xcresult. Erst Begriffe wie Compilerfehler, Linkerfehler, fehlendes Profil oder nicht verfügbare Destination erlauben eine belastbare Zuordnung.

Was tun, wenn ein Remote Mac das Scheme nicht findet?

Prüfen Sie zuerst, ob der Befehl eine .xcodeproj- oder .xcworkspace-Datei verwendet. Danach muss das Scheme im Projekt vorhanden und für gemeinsame Nutzung freigegeben sein. Lassen Sie sich die Schemes in derselben SSH- oder CI-Sitzung anzeigen, in der der Build läuft. Stimmen Arbeitsverzeichnis oder Dateieingang nicht, wird häufig ein formal korrektes, aber falsches Projekt geladen.

Wie bleiben vollständige Logs und xcresult in CI erhalten?

Lassen Sie die Standardausgabe in eine Datei schreiben und vergeben Sie für Build, Test und Archive jeweils einen eigenen Ergebnis-Pfad. Speichern Sie Logdatei und xcresult als CI-Artefakte, auch wenn der Job fehlschlägt. Entfernen Sie vor dem Upload Geheimnisse, Team-IDs, Bundle-IDs, Benutzerpfade und Zertifikatsnamen. Die Auswertung sollte mit dem ersten Fehler beginnen, nicht mit der letzten Statuszeile.