Xcode Cloud-Build-Artefakte nur 30 Tage aufbewahrt? Sicherungsanleitung 2026

Die Sicherung von Xcode-Cloud-Build-Artefakten sollte am Tag eines erfolgreichen Builds beginnen: Xcode Cloud ist kein langfristiges Archiv. Apple dokumentiert, dass Build-Informationen und Artefakte höchstens 30 Tage zugänglich sein können; gelegentliche Veröffentlichungen laden Sie manuell herunter, laufende Projekte archivieren automatisch über die App Store Connect API und prüfen die Wiederherstellung in einem getrennten Speicher.

Diese Anleitung ist für Sie gedacht, wenn Sie iOS- oder macOS-Apps mit Xcode Cloud bauen, aber bisher keine eigenständige Kopie von Archiven und Symbolinformationen besitzen. Sie richtet sich außerdem an kleine Teams, die ältere Abstürze untersuchen oder xcarchive und xcresult regelmäßig auf einem entfernten Mac öffnen müssen.

Der erste Meilenstein: Was vor Ablauf der 30 Tage wirklich erhalten bleiben muss

Nicht jedes erzeugte Paket verdient dieselbe Aufbewahrungsregel. Die 30-Tage-Angabe beschreibt eine maximale Zugriffsfrist für Build-Informationen und Artefakte, nicht eine Empfehlung, sämtliche Dateien dauerhaft zu speichern. Die offizielle Anleitung für den ersten Xcode-Cloud-Workflow ist der Ausgangspunkt für die Zuordnung von Workflow und Build.

Ordnen Sie die Dateien nach ihrem späteren Zweck:

Ein App-Store-Connect-Build ist dabei nicht automatisch dasselbe wie jedes von Xcode Cloud erzeugte Arbeitsartefakt. Unterscheiden Sie mindestens zwischen der Build-Identität, dem Workflow, der Build-Aktion, dem xcarchive, dem xcresult und selbst hochgeladenen Zusatzdateien. Diese Trennung verhindert, dass Sie später zwar eine ZIP-Datei finden, aber nicht mehr wissen, zu welcher App-Version sie gehört.

Für die Absturzanalyse sind Symboldateien kein optionaler Anhang. Ohne passende Symbolinformationen bleiben viele Adressen im Bericht schwer interpretierbar. Apple beschreibt die Zuordnung von Absturzberichten und Gerätesprotokollen in der Dokumentation zur Diagnose mit Crash Reports und Device Logs.

Der Veröffentlichungstag: Manuell laden und eine belastbare Archivspur anlegen

Am Tag eines erfolgreichen Release-Builds ist der Download noch überschaubar. Sie können in Xcode oder App Store Connect zum passenden Build navigieren und die verfügbaren Artefakte laden. Entscheidend ist nicht nur der Download selbst, sondern die nachvollziehbare Ablage.

Verwenden Sie beispielsweise eine Ordnerstruktur wie diese, wobei Platzhalter statt echter Kontodaten stehen:

<app-id>/
  <version>/
    <build-number>/
      <workflow>/
        <build-date>/
          archive/
          symbols/
          test-results/
          logs/
          manifest.json
          checksums.txt

Die Angaben <app-id>, <version>, <build-number>, <workflow> und <build-date> müssen aus dem konkreten Build übernommen werden. Schreiben Sie keine API-Schlüssel, Team-IDs oder Kundendaten in öffentlich zugängliche Protokolle. Für eine DSGVO-konforme Ablage sollten Sie außerdem prüfen, ob Testanhänge Gerätekennungen, E-Mail-Adressen oder andere personenbezogene Daten enthalten.

Erstellen Sie beim ersten manuellen Lauf eine Referenz. Listen Sie die tatsächlich angebotenen Dateien auf, entpacken Sie die Archive in einem temporären Verzeichnis und notieren Sie, welche Inhalte lesbar sind. Diese Baseline ist später der Vergleich für das Automatisierungsskript. Ein Skript, das nur „Download erfolgreich“ meldet, kann eine unvollständige oder beschädigte Kopie unbemerkt durchwinken.

Die erste Automatisierung: App Store Connect API statt wiederholter Handarbeit

Sobald Sie regelmäßig veröffentlichen, sollte die Sicherung von Xcode-Cloud-Build-Artefakten nicht von einer manuellen Erinnerung abhängen. Die App Store Connect API bietet Ressourcen für Build-Runs, Build-Aktionen und Artefakte. Die Dokumentation zu Build-Runs hilft bei der zeitlichen und workflowbezogenen Zuordnung; die Artefakt-Ressource einer Build-Aktion beschreibt den Zugriff auf die zugehörigen Dateien.

Schreiben Sie den Ablauf nicht als starre Liste einzelner Endpunkte, sondern als Prüfstrecke:

1. Erfolgreiche Builds suchen: Filtern Sie nach App, Workflow, Ergebnisstatus und Veröffentlichungsrelevanz. Ein fehlgeschlagener Testlauf sollte nicht als fertiges Release-Archiv behandelt werden.
2. Build-Aktion zuordnen: Ermitteln Sie, welche Aktion das Archiv, Testergebnis oder die Symboldatei erzeugt hat. Speichern Sie die externe Kennung des Builds und der Aktion.
3. Artefaktinformationen lesen: Übernehmen Sie Dateityp, Download-Information, Namen und die Beziehung zum Build. Die verfügbaren Artefakte sind in der API-Übersicht zu Artifacts beschrieben.
4. Datei in getrennten Speicher laden: Schreiben Sie zunächst in eine temporäre Datei. Benennen und verschieben Sie sie erst nach erfolgreicher Integritäts- und Lesbarkeitsprüfung in den endgültigen Ordner.
5. Status protokollieren: Speichern Sie Build-ID, Workflow, Ergebnis, Download-Zeitpunkt, Dateiliste und Fehlertext. So kann ein späterer Lauf erkennen, ob derselbe Build bereits verarbeitet wurde.
6. Fehler nachbearbeiten: Bei abgelaufenen URLs, fehlenden Artefakten oder Netzwerkfehlern muss der Job sichtbar fehlschlagen. Eine leere Antwort darf nicht als erfolgreiche Sicherung gelten.

Trennen Sie die Berechtigungen strikt. Die Zugangsdaten für die App Store Connect API dienen der API-Kommunikation. Code-Signaturmaterial wie Zertifikate und private Schlüssel gehört in eine eigene, geschützte Verwaltung. Der Zugriff per SSH oder VNC auf einen entfernten Mac ist wiederum eine dritte Berechtigungsebene. Verwenden Sie in Beispielen nur Platzhalter:

export ASC_KEY_ID="<api-key-id>"
export ASC_ISSUER_ID="<issuer-id>"
export ASC_PRIVATE_KEY="<path-to-private-key>"
export ARCHIVE_ROOT="<private-storage-path>"

Legen Sie niemals echte Schlüssel, App-IDs oder interne Pfade in ein öffentliches Repository. Die vollständige API-Nutzung und ihre Ressourcen finden Sie in der offiziellen App-Store-Connect-API-Dokumentation.

Ereignisgesteuert oder zeitgesteuert: Der richtige Sicherungspunkt

Ein Xcode-Cloud-Webhook meldet ein Build-Ereignis an einen externen Dienst. Er ist aber kein Speicherort für das Artefakt. Die Apple-Dokumentation zur Konfiguration von Xcode-Cloud-Webhooks sollte deshalb zusammen mit einem eigenen Download- und Archivdienst gelesen werden.

Für die Auswahl zählt Ihr Veröffentlichungsrhythmus:

Bei einem seltenen Release genügt ein geplanter Lauf, sofern Sie den Erfolg kontrollieren. Bei häufigen Veröffentlichungen ist ein Webhook der schnellere Auslöser. Ersetzen Sie den periodischen Abgleich trotzdem nicht vollständig: Netzwerkfehler, nicht erreichbare Empfänger oder ein falsch behandelter Status können sonst zu einer stillen Lücke führen.

Die wichtigste technische Eigenschaft ist Idempotenz. Der Sicherungsdienst muss denselben Build mehrfach erhalten können, ohne jedes Mal eine zweite unklare Kopie zu erzeugen. Verwenden Sie dafür die Build-ID, die Build-Aktion und den Workflow als eindeutige Zuordnung. Speichern Sie auch negative Ergebnisse, etwa „Artefakt noch nicht verfügbar“ oder „Download abgebrochen“. Ein späterer Lauf kann dann gezielt erneut versuchen, statt den Vorgang als unbekannt zu behandeln.

Achtung: Ein Webhook bestätigt nur, dass ein Ereignis versendet wurde. Erst die erfolgreiche Abfrage der Artefaktinformationen, der vollständige Download und die Lesbarkeitsprüfung machen daraus eine verwertbare Sicherung.

FAQ: Aufbewahrung, Download und Wiederherstellung richtig einordnen

Wie lange bleiben Xcode-Cloud-Builds und Artefakte verfügbar?

Apple nennt für Build-Informationen und Artefakte eine maximale Zugänglichkeit von 30 Tagen. Behandeln Sie diese Frist als Ablaufgrenze für Ihren Download, nicht als Archivstrategie. Die tatsächliche Arbeitsregel lautet: Release-Artefakte unmittelbar nach dem erfolgreichen Build sichern und erst danach über Bereinigung entscheiden.

Wie laden Sie ein xcarchive und Symboldateien herunter?

Öffnen Sie den erfolgreichen Build in Xcode oder App Store Connect und prüfen Sie die angebotenen Artefakte. Laden Sie das xcarchive und die zugehörigen Symboldateien gemeinsam herunter. Ergänzen Sie anschließend Versionsnummer, Build-Nummer und Workflow in der Ablage. Ohne diese Zuordnung kann ein später gefundener Absturzbericht nicht zuverlässig mit dem richtigen Paket verbunden werden.

Kann die App Store Connect API automatisch sichern?

Ja, sofern Ihr Dienst die passenden Build-Runs und Build-Aktionen filtert, Artefakte abfragt und den Downloadstatus speichert. Das ist eine Automatisierung des Zugriffs, aber noch keine vollständige Archivlösung. Sie benötigen zusätzlich geschützte Zugangsdaten, Fehlerbehandlung, doppelte Verarbeitungsschutz und eine Prüfung, ob das gespeicherte Paket wirklich entpackt und gelesen werden kann.

Sind gelöschte Xcode-Cloud-Artefakte wiederherstellbar?

Verlassen Sie sich nicht darauf. Ist das Artefakt nach der Zugriffsfrist nicht mehr verfügbar und existiert keine externe Kopie, fehlt Ihnen möglicherweise die Grundlage für eine spätere Analyse. Die sichere Annahme lautet daher: Nach erfolgreichem Build selbst sichern. Ein Webhook oder ein späterer API-Aufruf ersetzt keine bereits abgelaufene oder entfernte Kopie.

Welche Artefakte benötigen Sie für die Absturzanalyse?

Für einen veröffentlichten Build sind das passende App-Archiv, die Symboldateien und die eindeutige Version-Build-Zuordnung besonders wichtig. xcresult-Dateien und Protokolle ergänzen die Nachvollziehbarkeit von Tests und Fehlern. Speichern Sie nur, was Sie für Support, Prüfung und Wiederholung benötigen, und trennen Sie Signaturgeheimnisse von normalen Build-Artefakten.

Der Release-Meilenstein: Download ist erst der Anfang der Abnahme

Markieren Sie einen Build nicht als archiviert, nur weil der HTTP-Download ohne Fehlermeldung beendet wurde. Führen Sie eine Wiederherstellungsprüfung in einer sauberen Arbeitsumgebung durch:

• [ ] Die Datei lässt sich vollständig entpacken, ohne Archiv- oder Prüfsummenfehler.
• [ ] Das xcarchive enthält die erwartete App-Version und Build-Nummer.
• [ ] Die App-Zuordnung stimmt mit dem Eintrag in App Store Connect überein.
• [ ] Die Symboldateien lassen sich dem gleichen Release-Build zuordnen.
• [ ] Das xcresult lässt sich öffnen und enthält die erwarteten Testinformationen.
• [ ] Die Build-ID, Workflow-Bezeichnung und Build-Aktion stehen im Archivprotokoll.
• [ ] Personenbezogene Testdaten wurden vor einer Weitergabe entfernt oder geschützt.
• [ ] Zertifikate und private Schlüssel liegen nicht im gewöhnlichen Artefaktordner.
• [ ] Ein zweiter Lauf erzeugt keine unkontrollierte Dublette.
• [ ] Ein absichtlich fehlerhafter Download führt zu einer sichtbaren Warnung.

Für Testresultate beschreibt Apple das Ausführen und Interpretieren von Tests. Nutzen Sie diese Prüfung nicht nur für die Entwicklerzweige. Ein Release-Kandidat sollte mindestens einmal aus der archivierten Kopie geöffnet oder analysiert werden. Für die Absturzsuche empfiehlt sich außerdem eine getrennte, anonymisierte Wiederherstellungsprobe mit einem historischen Bericht.

Der laufende Betrieb: Aufbewahrung, Bereinigung und Wiederanlauf

Legen Sie keine einheitliche Dauer fest, wenn Ihr Supportbedarf noch nicht geklärt ist. Interne Builds können nach einer kurzen Entwicklungsphase bereinigt werden, während Release-Kandidaten länger für Vergleich und Fehleranalyse relevant bleiben. Veröffentlichte Versionen sollten nach Ihren Anforderungen an Support, Prüfungen und Rückfragen aufbewahrt werden.

Trennen Sie dabei die Aufgaben der Speicherorte:

• Lokaler Rechner: geeignet für den ersten Download und die schnelle Sichtprüfung, aber anfällig für versehentliches Löschen, Festplattenausfall und unklare Zugriffsrechte.
• Getrennter Objektspeicher: geeignet für skalierbare Ablage und Versionierung; Verschlüsselung, Lebenszyklusregeln und DSGVO-Zugriffskontrollen müssen Sie selbst festlegen.
• Dauerhaft verfügbarer Remote Mac: sinnvoll, wenn Sie historische xcarchive- oder xcresult-Dateien regelmäßig mit Xcode öffnen, Symbolisierung ausführen oder Wiederherstellungsskripte betreiben.

Prüfen Sie nach jeder Veröffentlichung, ob der Archivjob abgeschlossen wurde. Führen Sie zusätzlich regelmäßige Stichproben durch: Datei lokalisieren, entpacken, Build-Zuordnung kontrollieren und mindestens ein relevantes Ergebnis lesen. Die Prüfung sollte einen Fehler melden, wenn das erwartete Archiv fehlt, statt stillschweigend nur den Ordner anzulegen.

Wenn Sie diese Aufgaben auf einem iOS-Paketierungsserver oder einem dauerhaft laufenden Remote Mac bündeln möchten, vergleichen Sie zunächst Zugriffsschutz, Speichertrennung und Wiederherstellungsablauf. Für eine Übersicht zur Auswahl zwischen Xcode Cloud und einem eigenen Paketierungsserver können Sie die passende Entscheidungshilfe für iOS-Paketierungsserver heranziehen. Ein produktiver Archivdienst braucht außerdem getrennte Konten, eingeschränkte SSH-Rechte und nachvollziehbare Protokolle; ein Administratorzugang sollte nicht automatisch jedem Build-Skript offenstehen.

Aktueller Aufbau oder Remote Mac: Welche Lösung passt zur Archivpflicht?

Xcode Cloud bleibt für viele Projekte ein bequemer Build- und Testdienst. Als alleiniger Langzeitspeicher hat der Aufbau jedoch klare Grenzen: Artefakte sind nur begrenzt zugänglich, die Wiederherstellung hängt vom rechtzeitigen externen Download ab, und die dauerhafte Analyse historischer Archive gehört nicht automatisch zum Build-Ablauf.

Ein selbst verwalteter Mac kann dagegen mehr Kontrolle über Verzeichnisse, Skripte und Wiederherstellung geben. Dafür tragen Sie Betriebssystempflege, Zugriffsschutz, Speicherüberwachung und Fehlerbehebung selbst. Wenn Sie nur gelegentlich veröffentlichen und keine historischen Pakete öffnen müssen, ist ein eigener Dauerbetrieb möglicherweise unnötig. Wenn Sie jedoch regelmäßig symbolisieren, alte Archive prüfen oder Downloadjobs dauerhaft ausführen, ist ein verfügbarer Remote Mac organisatorisch einfacher als ein Notebook, das nur sporadisch eingeschaltet wird.

Für diesen zweiten Fall können Sie die VMSPIN-Angebote für gemietete Macs prüfen. Der Vorteil gegenüber Ihrem bisherigen Aufbau liegt nicht in einer pauschalen Leistungsbehauptung, sondern in der Trennung der Aufgaben: Xcode Cloud erzeugt den Build, ein eigener Speicher bewahrt die Kopie, und der Remote Mac führt bei Bedarf Download-, Entpack- und Wiederherstellungsschritte aus. Prüfen Sie vor einer Anmietung dennoch, ob Sie physische Geräte, lokale USB-Zugriffe oder eine dauerhaft unveränderte Hochlastumgebung benötigen; dann kann ein eigener Mac langfristig besser passen.

Beginnen Sie diese Woche mit einem erfolgreichen Release-Build: Laden Sie xcarchive, Symboldateien, xcresult und relevante Protokolle herunter, dokumentieren Sie die Zuordnung und führen Sie eine Wiederherstellungsprobe durch. Erst wenn diese Baseline funktioniert, lohnt sich die Automatisierung mit API, Webhook und regelmäßiger Kontrollprüfung.