Wie lassen sich Xcode-Cloud-Build-Artefakte langfristig speichern? Archivierungsleitfaden 2026

Symptom: Sie finden einen früheren Xcode-Cloud-Build nicht mehr, wenn Sie ihn für eine Diagnose oder Übergabe brauchen.
Schnellste Lösung: Behandeln Sie Xcode Cloud nicht als dauerhaftes Archiv. Wählen Sie zuerst die benötigten Artefakte aus, laden Sie sie im verfügbaren Zugriffsfenster herunter und ordnen Sie sie Build, Workflow und Quellcode-Commit zu. Prüfen Sie anschließend, ob sich die Dateien öffnen und wiederherstellen lassen.

Dieser Ablauf passt zu unabhängigen Entwicklern, die Archive, Symboldateien oder Veröffentlichungsprotokolle für spätere Fehleranalysen brauchen.
Er hilft auch, wenn Sie Testergebnisse oder Screenshots erneut aufrufen müssen.
Kleine Teams erhalten damit eine nachvollziehbare Übergabe statt eines Ordners mit Dateien unbekannter Herkunft.

Xcode-Cloud-Build-Artefakte nach Diagnosezweck auswählen

Ein abgeschlossener Build ist nicht automatisch ein langfristig gesicherter Build. Apple beschreibt den Zugriff auf Xcode-Cloud-Artefakte als befristet und nennt eine maximale Verfügbarkeit von 30 Tagen nach Abschluss des Builds. Laden Sie daher benötigte Unterlagen rechtzeitig herunter. Prüfen Sie die jeweils aktuelle Apple-Dokumentation zum Einrichten eines Xcode-Cloud-Workflows, bevor Sie eine interne Aufbewahrungsregel festlegen.

Entscheidend ist nicht, „alles“ auf Vorrat zu speichern. Entscheidend ist, ob Sie eine spätere Fehlersuche, Testwiederholung oder Veröffentlichung damit tatsächlich unterstützen können. Ein Archive lässt sich nicht durch ein Build-Protokoll ersetzen; Symboldateien wiederum sind nicht dasselbe wie das installierbare oder veröffentlichungsfähige Produkt.

Apple kann für einen Build unterschiedliche Artefaktarten bereitstellen. Die Dokumentation zu Xcode-Cloud-Artefakten in der App Store Connect API beschreibt die über die API verfügbaren Artefaktinformationen. Legen Sie daraus keine pauschale Annahme ab, dass jeder Build dieselben Dateien enthält: Prüfen Sie die tatsächlich aufgeführten Artefakte für den betreffenden Build.

Für die Absturzdiagnose zählen Archive und Symbole gemeinsam

Wenn Sie einen Fehler aus einer bereits ausgelieferten App untersuchen, reicht der Quellcode allein oft nicht aus, um die damalige Build-Ausgabe zuverlässig nachzuvollziehen. Sichern Sie das passende Archive und die Symboldateien, die zu genau diesem Build gehören. Bei einem Archive im Format .xcarchive sollten Sie außerdem notieren, welche App-Version und Build-Kennung es enthält.

Die Symboldateien helfen, Adressen in Absturzberichten lesbar einer Stelle im Programm zuzuordnen. Sie müssen zur betreffenden Binärdatei passen. Eine dSYM-Datei aus einem anderen Build kann für die Diagnose des veröffentlichten Builds ungeeignet sein. Apples Anleitung zum Einbinden von Debugging-Informationen in einen Build erläutert, welche Build-Einstellungen für Debugging-Informationen relevant sind.

Gehen Sie bei einer Release-Sicherung so vor:

1. Rufen Sie den Build Run auf, der zur veröffentlichten App-Version gehört.
2. Vergleichen Sie Version, Build-Kennung und Quellcode-Commit mit den Release-Unterlagen.
3. Laden Sie das Archive und die zugehörigen Symboldateien herunter, sofern sie für diesen Build verfügbar sind.
4. Prüfen Sie, ob das Archive mit Xcode geöffnet werden kann und ob die erwarteten Inhalte enthalten sind.
5. Dokumentieren Sie den Speicherort und die Zuordnung der Dateien, nicht nur ihren ursprünglichen Downloadnamen.

Wollen Sie nur untersuchen, warum ein Build fehlgeschlagen ist, kann das Protokoll wichtiger sein als ein erfolgreich erzeugtes Archive. Speichern Sie für eine spätere Analyse den relevanten Fehlerkontext und die Verbindung zum Build Run. Ein loses Protokoll ohne Commit- oder Workflow-Angabe ist später deutlich schwerer einzuordnen.

Für Testwiederholungen Ergebnisse statt beliebiger Screenshots sichern

Ein Screenshot zeigt einen sichtbaren Zustand, aber nicht zwangsläufig, wie dieser Zustand zustande kam. Wenn Sie einen Fehler reproduzieren oder eine Testentscheidung später nachvollziehen müssen, bewahren Sie nach Möglichkeit das Testergebnis-Paket und die zugehörigen Protokolle auf. Screenshots ergänzen diese Unterlagen dort, wo sie einen konkreten UI-Fehler, eine erwartete Ausgabe oder einen abweichenden Zustand belegen.

Ordnen Sie jede Datei den Informationen zu, mit denen eine andere Person den Test wiederfinden kann: Workflow, Build Run, Quellcode-Commit und Testkonfiguration. Ergänzen Sie bei Screenshots einen aussagekräftigen Namen oder eine kurze Notiz, die Testfall und beobachtetes Problem beschreibt. Vermeiden Sie Sammelordner mit Namen wie „Tests alt“: Sie bewahren Dateien, aber nicht den Weg zurück zu ihrem Ursprung.

Für die Wiederherstellung zählt mehr als ein erfolgreicher Download. Öffnen Sie das Testergebnis-Paket in Xcode und prüfen Sie, ob die erwarteten Testläufe, Fehlerdetails und Anhänge sichtbar sind. Apple verweist bei Fragen zu Xcode-Cloud-Ergebnissen und Feedback auf die Dokumentation zu Xcode Cloud. Verwenden Sie Ihre tatsächliche Xcode-Umgebung für die Abnahme: Ein lokal gespeichertes Paket, das sich nicht mehr sinnvoll öffnen lässt, ist kein belastbarer Wiederherstellungspunkt.

Für eine Teamübergabe Archive nach Build und Commit auffindbar machen

Wenn eine andere Person die Veröffentlichung übernehmen oder einen früheren Fehler untersuchen soll, braucht sie eine Verbindung von der Datei zum Build. Richten Sie Ihre Ablage deshalb nicht ausschließlich nach Datum oder Dateityp aus. Ein praktikables Ordnungsschema kann App, Workflow, Build-Kennung und Commit abbilden; die genaue Ordnerstruktur sollte zu Ihrer vorhandenen Versionsverwaltung und Ablage passen.

Halten Sie pro archiviertem Build mindestens fest:

• den Namen der App und den Workflow,
• die Build-Kennung und den zugehörigen Commit,
• die enthaltenen Dateien, etwa Archive, Symbole, Protokolle oder Testergebnisse,
• den Speicherort und den Zeitpunkt der Ablage,
• offene Lücken sowie die Person, die diese klärt.

Die Apple-Dokumentation zu Workflows und Builds in der App Store Connect API erklärt, wie Workflows und Builds in der API abgebildet werden. Die Build-Run-Ressource hilft dabei, den Lauf zu identifizieren, dessen Artefakte Sie prüfen möchten. Bewahren Sie Kennungen und Herkunftsinformationen zusammen mit den Dateien auf; verlassen Sie sich nicht darauf, dass ein späterer Nutzer den ursprünglichen Build aus dem Dateinamen errät.

Wiederherstellung als Bestandteil der Übergabe prüfen

Führen Sie die Prüfung mit einer Person durch, die nicht selbst die Ablage eingerichtet hat. Sie sollte anhand Ihrer Notiz einen konkreten Build finden, die benötigten Dateien öffnen und ihren Bezug zum Commit bestätigen können. Erfassen Sie fehlende Archive, unlesbare Ergebnis-Pakete oder nicht zuordenbare Symbole als konkrete Abweichungen, statt die Übergabe als abgeschlossen zu markieren.

Diese Kontrolle trennt zwei Zustände, die oft verwechselt werden: „Datei wurde gespeichert“ und „Veröffentlichungsmaterial kann wiedergefunden und verwendet werden“. Nur der zweite Zustand ist ein belastbarer Wiederherstellungsnachweis.

App Store Connect API für wiederholbare Downloads nutzen

Wenn Sie Artefakte regelmäßig sichern müssen, kann die App Store Connect API den Abruf in einen kontrollierten Ablauf einbinden. Das ist keine dauerhafte Speicherung durch Xcode Cloud: Ihre Automatisierung muss Build und Artefakte finden, die Dateien abrufen und anschließend in Ihrer eigenen Ablage verwalten.

Ein typischer Ablauf besteht aus diesen Schritten:

1. Authentifizieren Sie die Automatisierung entsprechend Apples aktueller Vorgaben.
2. Ermitteln Sie den passenden Workflow und Build Run.
3. Fragen Sie die für diesen Build verfügbaren Artefakte ab.
4. Lesen Sie die relevanten Artefaktinformationen und den Download-Einstieg aus.
5. Laden Sie die Datei herunter, prüfen Sie das Ergebnis und speichern Sie den Status.
6. Ordnen Sie Datei und Protokoll Build-Kennung, Workflow und Commit zu.

Die API-Ressource für Build Runs unterstützt die Suche nach einem passenden Lauf. Für das Lesen eines einzelnen Artefakts beschreibt Apple den Abruf eines Artefakts über seine Kennung; zusätzliche Felder sind in der Beschreibung der Artefaktattribute aufgeführt. Welche Felder und Beziehungen verfügbar sind, sollten Sie gegen die aktuelle API-Dokumentation prüfen und nicht aus einem älteren Skript ableiten.

Behandeln Sie die bereitgestellte Download-Adresse nicht wie einen permanenten Link. Die API liefert einen Zugang zum Abruf; Apple beschreibt die Artefaktinformationen und den Download im jeweiligen API-Kontext. Verwenden Sie die Adresse zeitnah und speichern Sie stattdessen die heruntergeladene Datei sowie die zugehörigen Build-Metadaten. Falls ein Download scheitert, protokollieren Sie den betroffenen Build und Artefaktschritt und wiederholen Sie den Abruf über die API, statt eine bereits verwendete Adresse dauerhaft vorauszusetzen.

Schützen Sie außerdem die Zugangsdaten Ihrer Automatisierung. Apple dokumentiert die Erstellung von Tokens in der Anleitung zum Generieren von Tokens für API-Anfragen. Legen Sie geheime Schlüssel nicht in ein öffentliches Repository oder in ein Protokoll, das für das ganze Team zugänglich ist. Begrenzen Sie Berechtigungen auf den erforderlichen Zweck und regeln Sie, wer Schlüssel erneuern und Fehler im Sicherungslauf bearbeiten darf.

FAQ: Frist, API-Abruf und Wiederherstellung

Wie lange können Sie Xcode-Cloud-Build-Artefakte abrufen?

Apple nennt für den Zugriff auf Xcode-Cloud-Build-Artefakte höchstens 30 Tage nach Abschluss des Builds. Diese Frist ist keine Empfehlung, bis zum letzten Tag zu warten. Sichern Sie wichtige Veröffentlichungsmaterialien früh und prüfen Sie in der aktuellen Apple-Dokumentation, welche Artefakte für den betreffenden Build verfügbar sind.

Wie laden Sie Artefakte mit der App Store Connect API herunter?

Finden Sie zunächst den passenden Build Run und lesen Sie anschließend die verfügbaren Artefaktinformationen aus. Die API stellt Angaben zum Artefakt und einen Download-Einstieg bereit. Die konkreten Felder, Beziehungen und Authentifizierungsschritte müssen Sie anhand der aktuellen Apple-Dokumentation umsetzen. Protokollieren Sie Downloadstatus und Build-Zuordnung und behandeln Sie Download-Adressen nicht als dauerhafte Ablage.

Wie sichern Sie ein Xcode Archive und die passenden Symbole?

Sichern Sie das Archive und die dazugehörigen Symboldateien gemeinsam, aber erfassen Sie sie als unterschiedliche Bestandteile. Ordnen Sie beide dem Build, der App-Version und dem Quellcode-Commit zu. Öffnen Sie das Archive zur Prüfung und verifizieren Sie, dass die Symboldateien dem betreffenden Build zugeordnet sind. So sinkt das Risiko, bei einer späteren Absturzanalyse Dateien aus verschiedenen Builds zu verwechseln.

Wie weisen Sie nach, dass archivierte Testergebnisse wiederherstellbar sind?

Laden Sie das Ergebnis-Paket herunter und öffnen Sie es mit einer geeigneten Xcode-Version. Kontrollieren Sie, ob die erwarteten Tests, Fehlerdetails und Anhänge angezeigt werden. Vergleichen Sie die Angaben mit Workflow, Build Run und Commit. Halten Sie fest, was tatsächlich wiederhergestellt wurde und welche Teile fehlen; ein vorhandenes Paket allein belegt noch keine erfolgreiche Prüfung.

Abnahme-Checkliste für Ihre Archivierungsregel

Nutzen Sie diese Liste nach einem Release oder bevor Sie eine automatische Ablage als zuverlässig einstufen:

• [ ] Ist klar festgelegt, ob für diesen Zweck ein Archive, Symboldateien, Protokolle, Testergebnisse oder Screenshots erforderlich sind?
• [ ] Stimmen Build-Kennung, App-Version, Workflow und Quellcode-Commit mit den Release-Unterlagen überein?
• [ ] Wurde der Download abgeschlossen, und wurde die gespeicherte Datei anschließend geöffnet oder anderweitig geprüft?
• [ ] Sind Testergebnis-Pakete in Xcode lesbar und enthalten sie die erwarteten Testinformationen?
• [ ] Sind die Download-Adressen nur für den Abruf verwendet worden, statt als dauerhafte Ablage zu dienen?
• [ ] Kann ein Teammitglied, das die Ablage nicht erstellt hat, die Datei anhand der Notizen wiederfinden?
• [ ] Sind fehlende Dateien, unklare Zuordnungen und zuständige Personen dokumentiert?
• [ ] Ist geklärt, welche Unterlagen dauerhaft gebraucht werden und welche nur für eine begrenzte Fehleranalyse relevant sind?

Bewerten Sie die Archivierung erst als abgeschlossen, wenn die entscheidenden Dateien nicht nur vorhanden, sondern auch zuordenbar und lesbar sind. Wenn eine Prüfung scheitert, beheben Sie zunächst den konkreten Mangel: fehlende Commit-Angabe, falsches Artefakt oder nicht lesbares Paket. Eine pauschale Kopie aller Build-Dateien löst diese Zuordnungsprobleme nicht.

Wann eine dauerhaft verfügbare Mac-Umgebung sinnvoll ist

Für die Ablage kann ein bestehender Speicherort im Team ausreichen, sofern Zugriff, Zuständigkeit und Wiederherstellung geregelt sind. Eine dauerhaft verfügbare Mac-Umgebung kann dann interessant sein, wenn Sie heruntergeladene Dateien zusätzlich in einem macOS-Kontext ordnen, öffnen oder prüfen möchten. Sie ersetzt weder die eigene Archivregel noch den Nachweis, dass ein bestimmtes Artefakt tatsächlich wiederherstellbar ist.

Wägen Sie Alternativen nüchtern ab: Ein eigener Mac verursacht Anschaffungs- und Wartungsaufwand und ist für einen gelegentlichen Sicherungslauf möglicherweise überdimensioniert. Eine bestehende CI- oder Speicherlösung kann besser passen, wenn sie bereits zuverlässig betrieben wird. Ein gemieteter Remote Mac ist dagegen nicht automatisch die richtige Wahl für dauerhaft hohe Lasten oder Arbeitsabläufe, die physische Anschlüsse und lokale Geräte erfordern. Lesen Sie vor einer Umstellung den Vergleich zu Bare Metal und macOS-Virtualisierung und berücksichtigen Sie Zugriffsschutz sowie die DSGVO bei der Ablage von App- oder Testdaten.

Wenn Sie lediglich ein einzelnes Artefakt sichern, richten Sie nicht eigens eine zusätzliche Umgebung ein. Wenn Ihr Team dagegen regelmäßig Veröffentlichungsmaterialien auf einem Mac prüfen und Übergaben nachvollziehbar durchführen muss, können Sie die dafür passende Umgebung anhand Ihrer Arbeitsabläufe bewerten. Informationen zu MacDate und den verfügbaren Remote-Mac-Angeboten sind ein möglicher nächster Schritt; prüfen Sie dabei vor einer Entscheidung selbst, ob Bereitstellung, Zugriff und Speicherablage zu Ihren Anforderungen passen.

Die belastbare Regel bleibt unabhängig von der Umgebung dieselbe: Wählen Sie die benötigten Artefakte aus, laden Sie sie innerhalb des Apple-Zugriffsfensters herunter und testen Sie die Wiederherstellung. Erst wenn Archive, Symbole oder Testergebnisse mit Build und Commit verbunden sind, ist aus einem Download ein verwendbares Release-Archiv geworden.