Wie werden Xcode Cloud-Build-Artefakte automatisch archiviert? Leitfaden 2026

Ein Build ist abgeschlossen, aber das benötigte Protokoll oder Testergebnis ist später nicht mehr greifbar.

Schnellste Lösung: Archivieren Sie benötigte Xcode Cloud-Build-Artefakte zeitnah nach dem Build. Laden Sie sie manuell über Xcode oder App Store Connect herunter oder automatisieren Sie den Abruf mit der App Store Connect API. Prüfen Sie jede Datei und speichern Sie sie mit einer nachvollziehbaren Build-Zuordnung. Ein API-Downloadlink ist kein dauerhafter Speicherort.

Dieser Ablauf ist für kleine Teams gedacht, die fehlgeschlagene Builds später reproduzieren oder Testergebnisse als Nachweis aufbewahren müssen.
Auch CI-Verantwortliche profitieren, wenn Protokolle und Archive nach einem einheitlichen Schema abgelegt werden.
Wenn Ihr Team keine historischen Build-Daten benötigt und kurzfristig auf die Cloud-Oberfläche zugreifen kann, reicht zunächst eine dokumentierte manuelle Ablage.

Vor dem Build-Abschluss den nötigen Archivumfang festlegen

Nicht jedes Artefakt hat für jedes Team denselben Wert. Wir beginnen mit dem Zweck der Aufbewahrung, nicht mit dem Download sämtlicher angebotener Dateien. Für eine Release-Rückverfolgung kann das App-Archiv entscheidend sein. Bei einem reproduzierbaren Testfehler sind dagegen Testbericht und Build-Protokoll oft hilfreicher.

Xcode Cloud stellt im Zusammenhang mit Builds unter anderem Protokolle, Archive beziehungsweise Build-Dateien, Symbolinformationen und Testergebnisse bereit. Welche Artefakte bei einem konkreten Build verfügbar sind, hängt vom Build und den bereitgestellten Ressourcen ab. Apple beschreibt die verfügbaren Build-Informationen und die Möglichkeiten zum Herunterladen und Archivieren in der Dokumentation zu Xcode Cloud und Build-Artefakten.

Aufbewahrungsziel	Was wir sichern	Wofür es später hilft
Release-Rückverfolgung	Archiv oder bereitgestellte Build-Datei sowie Build- und Commit-Zuordnung	Nachvollziehen, welcher Build zu einem Release gehört
Fehleranalyse	Build-Protokolle und relevante Symbolinformationen	Build- oder Absturzprobleme untersuchen
Testnachweis	Testergebnisse und zugehörige Build-Informationen	Testergebnisse einem konkreten Lauf zuordnen
Interne Prüfung	Nur die für den Prüfzweck erforderlichen Artefakte	Zugriff und gespeicherte Daten begrenzen

Wie lange bleiben Xcode-Cloud-Build-Artefakte verfügbar? Apple gibt an, dass Build-Informationen und Artefakte höchstens 30 Tage zugänglich sind. Das ist die von Apple dokumentierte Zugriffsfrist, keine Aufbewahrungsregel für Ihr Team. Wenn Sie Dateien länger benötigen, müssen Sie sie rechtzeitig selbst herunterladen und nach Ihrer eigenen Richtlinie speichern. Maßgeblich ist Apples Beschreibung der Xcode-Cloud-Konfiguration und Archivierung.

Für die Auswahl helfen drei Fragen: Müssen wir einen Release später einem konkreten Commit zuordnen? Müssen wir einen fehlgeschlagenen Testlauf nachvollziehen? Enthalten die Dateien interne Informationen, die nur ein kleiner Personenkreis sehen darf? Die Antworten bestimmen, welche Dateien wir abrufen, wer sie verwaltet und wohin sie gehören.

Beim Build-Bericht zuerst manuell prüfen und sichern

Der manuelle Weg eignet sich, wenn selten archiviert wird, ein Mensch die Auswahl prüfen soll oder die API-Automatisierung noch nicht freigegeben ist. Er ist außerdem eine gute Referenz für den späteren automatisierten Ablauf: Wir sehen zuerst, welche Artefakte bei einem echten Build vorhanden sind und wie sie sich öffnen lassen.

Gehen Sie in dieser Reihenfolge vor:

Öffnen Sie den betreffenden Build über Xcode oder App Store Connect.
Prüfen Sie Build-Informationen, Aktionen und die dort angebotenen Artefakte.
Wählen Sie Dateien anhand des zuvor festgelegten Zwecks aus. Laden Sie nicht nur ein Archiv herunter, wenn die Fehleranalyse zusätzlich das Protokoll oder den Testbericht erfordert.
Speichern Sie die Dateien in einem kontrollierten Team-Speicherort. Ordnen Sie sie dem Build und dem zugehörigen Commit oder Workflow zu.
Öffnen Sie die heruntergeladenen Dateien oder lesen Sie sie mit dem vorgesehenen Werkzeug ein. Ein erfolgreicher Download allein belegt noch nicht, dass die Datei vollständig und verwendbar ist.
Halten Sie fest, wer die Ablage geprüft hat und wer sie später bereinigt.

Wie lassen sich Testergebnisse und Build-Protokolle aufbewahren? Öffnen Sie den Build-Bericht und sichern Sie die für den jeweiligen Zweck relevanten Ergebnisse zusammen mit der Build-Zuordnung. Der lokale oder teamweite Ablageort sollte nicht nur den Dateinamen enthalten: Ergänzen Sie eine maschinenlesbare Zuordnung zu Build, Commit und Workflow, damit das Team den Kontext später wiederfindet.

Manuelles Speichern hat Grenzen. Es hängt davon ab, dass eine verantwortliche Person den Vorgang rechtzeitig ausführt. Die Auswahl kann zwischen Mitarbeitenden variieren. Außerdem ist ein Download in einen persönlichen Ordner keine belastbare Teamarchivierung. Legen Sie daher fest, wer die Ablage übernimmt und wie eine erfolgreiche Prüfung dokumentiert wird. Die metalvnc-Hilfeseiten können bei Fragen zum Zugang und zur Nutzung einer gemieteten Mac-Umgebung helfen; sie ersetzen jedoch nicht die teaminterne Festlegung des Archivspeichers.

Hinweis: Verwenden Sie einen manuellen Build zunächst als Referenzlauf. Notieren Sie, welche Dateien tatsächlich verfügbar sind und wie sie sich öffnen lassen. Erst danach sollte die Automatisierung dieselbe Auswahl reproduzieren.

Für wiederholbare Abrufe die API-Ressourcen richtig verknüpfen

Die App Store Connect API eignet sich, wenn Ihr Team Artefakte regelmäßig und ohne manuelle Auswahl abrufen muss. Der Ablauf beginnt nicht mit einem fest angenommenen Dateinamen. Er beginnt mit dem Build und den Ressourcen, die Apple dafür bereitstellt.

Die API-Übersicht zu Xcode-Cloud-Workflows und Builds beschreibt die zugehörigen Ressourcen. Für die Artefakte einer Build-Aktion dokumentiert Apple einen Abruf über Artefakte einer Build-Aktion. Die genaue Struktur der zurückgegebenen Artefaktattribute ist in Apples Attributbeschreibung für CIArtifact festgelegt. Ein einzelnes Artefakt lässt sich anschließend über die dokumentierte CIArtifact-Ressource abfragen.

Das gibt dem Abruf eine nachvollziehbare Kette:

Build bestimmen: Ermitteln Sie den Ziel-Build anhand der von Ihrem Workflow gespeicherten Build-Informationen.
Aktionen auflösen: Lesen Sie die zugehörigen Build-Aktionen aus der API-Ressource aus.
Artefakte auflisten: Rufen Sie die für die Aktion dokumentierten Artefakt-Ressourcen ab.
Attribute prüfen: Lesen Sie die von der API gelieferten Angaben, etwa Dateiname, Dateityp und Downloadadresse, anhand des aktuellen Schemas.
Datei abrufen: Laden Sie die Datei unmittelbar aus der zurückgegebenen Adresse herunter und speichern Sie sie in Ihrem Archiv.

Wie laden wir Xcode-Cloud-Artefakte mit der App Store Connect API herunter? Authentifizieren Sie zuerst die API-Anfrage gemäß Apples Vorgaben. Ermitteln Sie danach die passende Build-Aktion, lesen Sie deren Artefakte aus und verwenden Sie die gelieferten Attribute für den Download. Speichern Sie die Build- und Artefaktkennungen mit der Datei, damit der Download später auf die ursprüngliche Ressource zurückgeführt werden kann.

Die API-Automatisierung setzt eine gültige Authentifizierung und passend berechtigte Zugangsdaten voraus. Apple beschreibt das Erstellen von API-Schlüsseln für App Store Connect und die JWT-Erzeugung für API-Anfragen. Verwenden Sie für den Produktionsablauf nur die notwendigen Berechtigungen. Speichern Sie private Schlüssel in einem dafür vorgesehenen Geheimnisspeicher, nicht im Quellcode, in Build-Protokollen oder in einem Artefaktverzeichnis.

Prüfen Sie vor der Umsetzung außerdem, welche Rollen und Berechtigungen Ihr Team für die verwendeten API-Schlüssel vergeben kann. Die Schlüsselverwaltung ist ein organisatorischer Teil der Automatisierung: Verantwortliche müssen feststehen, Schlüssel müssen widerrufbar bleiben und der Zugriff darf nicht unnötig breit sein. Apple dokumentiert die Erstellung und Verwendung der Schlüssel; die konkrete Freigabe innerhalb Ihres Teams sollte zusätzlich mit dessen Sicherheitsvorgaben übereinstimmen.

Den Download nach dem Build zeitnah ausführen

Ein robuster Ablauf behandelt den Download als eigene Phase nach dem Build. Er sollte weder voraussetzen, dass eine bestimmte automatische Archivierungsaktion von Apple garantiert ausgelöst wird, noch einen temporären API-Wert als dauerhaften Speicherort betrachten.

Richten Sie den Ablauf so ein:

Auslöser definieren. Verwenden Sie den Abschluss oder die nachgelagerte Prüfung Ihres bestehenden Workflows als Anlass, den Build über die API zu ermitteln. Planen Sie keine Funktion ein, die in der Apple-Dokumentation nicht zugesichert ist.
Build eindeutig zuordnen. Halten Sie die verfügbaren Build- und Workflow-Informationen fest. Verknüpfen Sie sie, soweit vorhanden, mit Commit oder Release.
Aktionen und Artefakte auslesen. Folgen Sie den dokumentierten API-Beziehungen, statt Kennungen oder Dateinamen fest einzubauen.
Downloadadresse sofort verwenden. Apple weist darauf hin, dass Artefakt-Downloadadressen nur begrenzte Zeit gültig sind. Behandeln Sie sie daher als kurzfristige Abrufinformation und nicht als Link, den Sie in einem dauerhaften Index ablegen. Die Einschränkung ist in der API-Dokumentation zur CIArtifact-Ressource zu berücksichtigen.
Datei und Metadaten gemeinsam ablegen. Speichern Sie die geladene Datei zusammen mit der Build-Zuordnung und den für spätere Prüfungen notwendigen Metadaten.
Ergebnis melden. Markieren Sie den Lauf erst als abgeschlossen, wenn die Datei lokal beziehungsweise im vorgesehenen Archiv vorliegt und die nachgelagerte Prüfung erfolgreich war.

Bei einem fehlgeschlagenen Download sollte der Prozess nicht stillschweigend Erfolg melden. Protokollieren Sie eine verständliche Fehlerursache und die betroffene Build- oder Artefaktkennung. Speichern Sie dabei keine JWTs, privaten Schlüssel oder vollständigen, kurzfristig gültigen Downloadadressen in frei zugänglichen Logs. Eine Wiederholung kann sinnvoll sein, muss aber erneut die aktuelle API-Antwort verwenden, statt eine alte Downloadadresse wiederzuverwenden.

Die Ablage verifizieren und Zugriffe begrenzen

Ein Archiv ist erst dann nützlich, wenn Dateien später auffindbar und lesbar sind. Wir prüfen deshalb sowohl den Inhalt als auch die Zuordnung. Für das Team ist außerdem wichtig, dass gespeicherte Protokolle und Artefakte nicht automatisch für alle Mitarbeitenden sichtbar werden.

Verwenden Sie diese abhakbare Freigabe vor dem produktiven Einsatz:

[ ] Der Build ist über stabile Team-Metadaten wie Build- und Workflow-Zuordnung identifizierbar.
[ ] Die zu archivierenden Artefakttypen sind für Release-Prüfung, Fehleranalyse oder Testnachweis begründet.
[ ] Der Download wurde aus der aktuellen API-Antwort gestartet; ein alter Link wurde nicht wiederverwendet.
[ ] Die Datei liegt im vorgesehenen Team-Speicher und lässt sich mit dem passenden Werkzeug öffnen oder einlesen.
[ ] Dateiname und Typ stimmen mit den erwarteten Artefaktattributen überein.
[ ] Ein fehlender oder ungültiger Download wird als Fehler gemeldet und nicht als erfolgreicher Archivlauf verbucht.
[ ] API-Schlüssel und JWT-Material sind nicht in Quellcode, Artefaktordnern oder allgemein zugänglichen Logs enthalten.
[ ] Zugriffsrechte auf Protokolle, Archive und Testergebnisse sind auf den benötigten Personenkreis begrenzt.
[ ] Es gibt eine verantwortliche Stelle für die Aufbewahrungsentscheidung und die spätere Bereinigung.

Für die Integritätsprüfung können Sie zusätzlich einen lokal berechneten Datei-Hash mit den Archivmetadaten speichern. Das hilft, eine später veränderte oder versehentlich ersetzte Datei zu erkennen. Stellen Sie dabei nicht ohne Prüfung eine Gleichheit mit einem von Apple gelieferten Hashwert in Aussicht: Entscheidend ist, welche Angaben die jeweils aktuelle API-Antwort tatsächlich enthält.

Bei Logs und Testdaten gilt das Prinzip der Datenminimierung. Speichern Sie, was Sie für Diagnose, Rückverfolgung oder Nachweis brauchen, nicht automatisch jede verfügbare Datei. Wenn Artefakte interne Quelltextinformationen, Testdaten oder andere sensible Inhalte enthalten können, begrenzen Sie Lese- und Löschrechte und berücksichtigen Sie die Datenschutzvorgaben Ihres Unternehmens sowie die DSGVO.

Aufbewahrung als Teamregel statt als Cloud-Versprechen festlegen

Apples dokumentierte Zugriffsfrist und Ihre interne Aufbewahrung sind zwei verschiedene Dinge. Die von Apple angegebene Höchstdauer für den Zugriff auf Xcode-Cloud-Build-Informationen und Artefakte legt nicht fest, wie lange Ihr Team eine bereits heruntergeladene Datei speichern soll. Diese Entscheidung muss zu Release-Prozessen, Fehleranalyse und internen Nachweispflichten passen.

Legen Sie daher pro Artefaktklasse fest, wann sie archiviert wird, wer Zugriff erhält und wer die Bereinigung verantwortet. Definieren Sie außerdem, welche Zuordnungsinformationen gemeinsam mit der Datei erhalten bleiben müssen. Ohne Build- und Commit-Kontext bleibt selbst ein technisch lesbares Archiv für spätere Untersuchungen oft nur eingeschränkt hilfreich.

Testen Sie die Regel an einem echten Projektlauf. Prüfen Sie, ob die API-Antwort vollständig verarbeitet wird, ob die Datei im Team-Speicher ankommt und ob eine andere berechtigte Person den Build-Kontext wiederherstellen kann. Kontrollieren Sie auch den Fehlerfall: Ein nicht erreichbarer Download, eine unerwartete Dateityp-Angabe oder fehlende Berechtigung darf nicht unbemerkt zum vermeintlich erfolgreichen Archiv führen.

Für macOS-Nacharbeiten die passende Umgebung wählen

Xcode Cloud bleibt für die dort ausgeführten Builds zuständig. Ein zusätzlicher Mac ist nicht automatisch nötig, nur weil Artefakte archiviert werden. Er wird interessant, wenn Ihr Ablauf nach dem Download macOS-Werkzeuge für Prüfung, Signierung, Konvertierung oder andere projektspezifische Nacharbeiten benötigt oder ein Team eine separate Mac-Umgebung für wiederholbare Tests betreiben möchte.

Eine lokale Mac-Umgebung bietet direkte Kontrolle über Hardware und Schnittstellen, bindet aber Kapital und muss vom Team gewartet werden. Eine gemietete Remote-Mac-Umgebung vermeidet den Hardwarekauf und kann für zeitlich begrenzte Prüf- oder Nachbearbeitungsaufgaben passen. Dafür hängen Bedienung und Zugriff von Netzwerkverbindung und Berechtigungsverwaltung ab; sie ersetzt keine durchdachte Archivierung und ist nicht die richtige Wahl, wenn ein dauerhaft hoher lokaler Rechenbedarf oder physische Geräteanschlüsse zwingend sind.

Wenn für Ihre Abnahme tatsächlich ein macOS-Werkzeug außerhalb von Xcode Cloud benötigt wird, können Sie die Angebote von metalvnc mit dem Umfang Ihres Workflows vergleichen. Für reine API-Abrufe und eine dateibasierte Ablage ist ein zusätzlicher Mac nicht zwingend erforderlich. Wenn Sie jedoch eine echte Mac-Umgebung für die wiederholbare Prüfung oder Nachbearbeitung brauchen, finden Sie den Einstieg über die metalvnc-Übersicht. Entscheidend bleibt: Erst den Archivablauf mit einem realen Build verifizieren, dann die zusätzliche Umgebung nach dem tatsächlichen Bedarf auswählen.