Was muss bei der Migration einer iOS-Build-Maschine gesichert werden? Xcode 27-Checkliste 2026

Der Projektordner ist bereits auf dem neuen Mac, aber das erste Release scheitert an einer fehlenden Signieridentität.

Die schnellste Lösung ist keine weitere Xcode-Neuinstallation: Bei einer Xcode-27-iOS-Build-Maschinenmigration müssen Quellcode, Werkzeugkette, Signierung, Veröffentlichungszugänge, Archive und CI/CD-Dienste getrennt abgenommen werden. Die alte Maschine darf erst nach einem echten Archive-, Upload- und Wiederherstellungstest offline gehen.

Für wen diese Checkliste gedacht ist: Für unabhängige Entwickler, die einen Remote Mac zurückgeben und nicht wissen, welche Dateien und Zugangsdaten erhalten bleiben müssen. Für CI/CD-Verantwortliche, die Xcode-27-Builds auf einen anderen Mac verschieben. Und für kleine Teams, die eine übernommene oder beschädigte Build-Maschine so neu aufsetzen müssen, dass der nächste Release nicht von alten Verzeichnissen abhängt.

Zuletzt aktualisiert am 08.09.2026. Die Aussagen zu Xcode 27, Archive, Signierung, API Keys, Profilen und Runner-Verwaltung wurden gegen die unten verlinkten Apple- und Plattformdokumente geprüft. Nicht offiziell bestätigte Zukunftsannahmen werden nicht als Migrationsgrundlage verwendet.

Der eigentliche Abnahmetest: Veröffentlichung statt Dateikopie

Eine Migration ist nicht erfolgreich, wenn der Projektordner auf dem Zielsystem sichtbar ist. Sie ist erfolgreich, wenn der neue Mac den Release-Prozess ohne versteckte Abhängigkeit vom alten Host ausführen kann.

Dazu gehören mindestens diese Prüfpunkte:

• Ein sauberer Checkout kann die Abhängigkeiten anhand der vorhandenen Sperrdateien auflösen.
• Das vorgesehene Xcode-27-Projekt, Scheme und Build-Konfiguration sind eindeutig dokumentiert.
• Ein Archive wird mit der vorgesehenen Signieridentität erzeugt.
• Das Archive kann in das gewünschte Distributionsziel exportiert werden.
• Der Upload zu App Store Connect funktioniert mit dem vorgesehenen Zugang.
• Ein CI/CD-Job kann auf dem neuen Runner ausgeführt werden.
• Der alte Mac kann während eines Wiederholungstests abgeschaltet bleiben.

Die letzte erfolgreiche Veröffentlichung dient als Vergleichsbasis. Notiert werden sollten der Commit, die Bundle ID, die Versions- und Buildnummer, das verwendete Scheme, die Exportkonfiguration, das Distributionsziel und die zugehörige Archive-UUID. Die Apple-Dokumentation zur Archive- und Distributionskette beschreibt, wie Xcode ein Archive für Beta- und Release-Verteilung verwendet.

Für die Abnahme ist ein kurzer Protokolleintrag sinnvoll:

Commit: <COMMIT_HASH>
Scheme: <SCHEME_NAME>
Bundle ID: <BUNDLE_ID>
Team ID: <TEAM_ID>
Distribution: <DISTRIBUTION_TARGET>
Archive UUID: <ARCHIVE_UUID>
Upload: bestanden / fehlgeschlagen
Alter Host während Test: offline / aktiv

Die Platzhalter bleiben absichtlich anonymisiert. Zugangsdaten, Runner-Tokens, Key IDs und interne Repository-Namen gehören nicht in ein öffentliches Migrationsprotokoll.

Xcode-27-iOS-Build-Maschine migrieren: Welche Eingaben sind wirklich reproduzierbar?

Die erste Messgröße ist die Quellcode-Reproduzierbarkeit. Sie beantwortet nicht die Frage, ob Dateien kopiert wurden, sondern ob das Projekt aus einer kontrollierten Quelle neu entstehen kann.

Gesichert oder nachvollziehbar vorhanden sein müssen:

1. Das Repository oder ein belastbarer Export des relevanten Commits.
2. Git-Submodule und deren festgelegte Revisionen.
3. Sperrdateien für Swift Package Manager, CocoaPods oder andere verwendete Abhängigkeiten.
4. Private Paketquellen einschließlich der erlaubten Zugriffsmethode.
5. Build-Skripte, fastlane-Dateien und Konfigurationsvorlagen.
6. Nicht versionierte Dateien, die für den Build zwingend erforderlich sind.
7. Umgebungsvariablen, allerdings nur als dokumentierte Namen und nicht als ungeschützte Klartextwerte.

Nicht jede Datei auf dem alten Mac besitzt denselben Wiederherstellungswert. Der Projektquellcode, ein privates Zertifikat und ein temporärer Build-Cache sind drei unterschiedliche Kategorien. Ein Cache kann Zeit sparen, ersetzt aber keine sauber dokumentierte Umgebung. DerivedData sollte daher nicht als Beweis dienen, dass der neue Host korrekt eingerichtet ist.

Die Prüfung beginnt mit einem isolierten Verzeichnis:

git clone <REPOSITORY_URL> migration-check
cd migration-check
git checkout <COMMIT_HASH>

xcodebuild -version
xcodebuild -list -project <PROJECT_FILE>

Die Ausgabe wird zusammen mit dem Commit und dem gewählten Scheme gespeichert. Anschließend werden die Abhängigkeiten in einem frischen Arbeitsverzeichnis aufgelöst. Ein Build, der nur funktioniert, weil ein altes ~/Library/Developer-Verzeichnis kopiert wurde, ist noch kein bestandener Migrationstest.

Die Xcode-27-Systemanforderungen sollten unmittelbar vor der Einrichtung anhand der offiziellen Apple-Übersicht zu Xcode 27 kontrolliert werden. Das ist wichtiger als eine allgemeine Aussage wie „Xcode läuft auf jedem aktuellen Mac“. Betriebssystem, SDK-Bereich und unterstützte Werkzeugkombination können sich zwischen Versionen ändern. Für eine belastbare Übergabe werden deshalb die konkrete Xcode-Version und der macOS-Stand im Prüfprotokoll festgehalten.

Was nicht einfach kopiert werden sollte

Ein vollständiger Benutzerordner wirkt zunächst bequem, vergrößert aber die Unsicherheit:

• Alte Schlüsselbund-Einträge können unbemerkt weiterverwendet werden.
• Shell-Historien können Zugangsdaten oder temporäre Tokens enthalten.
• Veraltete Profile können einen scheinbar erfolgreichen lokalen Build vortäuschen.
• Hintergrunddienste können auf Pfade zeigen, die es auf dem neuen Host nicht gibt.
• Caches können eine fehlende oder falsche Abhängigkeit verdecken.

Eine selektive Sicherung ist deshalb überprüfbarer als das blinde Kopieren des gesamten Home-Verzeichnisses.

Signierung, Apple Distribution und Veröffentlichungszugänge getrennt prüfen

Die zweite Messgröße ist die Signierbarkeit. Eine Apple-Distribution-Identität besteht nicht bloß aus einer sichtbaren Zertifikatsdatei. Der zugehörige private Schlüssel ist für die tatsächliche Signatur entscheidend. Ohne ihn kann das Zertifikat zwar im Schlüsselbund erscheinen, aber kein verwendbarer Release-Prozess entstehen.

Zu unterscheiden sind:

• Zertifikat der Apple Distribution-Identität.
• Zugehöriger privater Schlüssel.
• Provisioning Profile für die jeweilige Bundle ID und Verteilung.
• Schlüsselbund und dessen Zugriffsschutz.
• Automatische oder manuelle Signierung im Projekt.
• App Store Connect API Key für automatisierte Uploads.

Für den Export einer Identität wird eine geschützte PKCS#12-Datei verwendet. Apple beschreibt im Dokument zum Import einer Identität, wie Zertifikat und privater Schlüssel zusammen importiert werden. Das Exportkennwort wird getrennt vom Dateiarchiv verwahrt. Eine PKCS#12-Datei ohne bekanntes Kennwort ist keine verlässliche Sicherung.

Der Import sollte nicht direkt in den produktiven Standard-Schlüsselbund erfolgen. Besser ist ein isolierter Test-Schlüsselbund mit dokumentierter Zugriffskontrolle:

security create-keychain -p '<TEST_KEYCHAIN_PASSWORD>' migration-test.keychain-db
security import <IDENTITY_FILE>.p12 \
  -k migration-test.keychain-db \
  -P '<P12_PASSWORD>' \
  -T /usr/bin/codesign

security find-identity -v -p codesigning migration-test.keychain-db

Die Werte sind Platzhalter und dürfen nicht durch echte Kennwörter in Dokumentationen ersetzt werden. Das Ergebnis „Identität gefunden“ reicht allein nicht aus. Erst ein Archive mit dem vorgesehenen Exportweg zeigt, ob Zertifikat, privater Schlüssel, Profile, Team-Zuordnung und Projektkonfiguration zusammenpassen.

Provisioning Profiles werden separat verwaltet. Ihre Sicherung sollte die Zuordnung zu Bundle ID, Team und Distributionszweck dokumentieren. Die Apple-Hilfe zum Bearbeiten, Herunterladen oder Löschen von Provisioning Profiles ist dabei die maßgebliche Referenz. Ein Profil darf nicht als Ersatz für einen privaten Schlüssel behandelt werden.

Für automatisierte Uploads gilt eine weitere Trennung. Ein App Store Connect API Key besteht aus einer Key ID, einer Issuer ID und einer privaten Schlüsseldatei. Diese Werte gehören nicht in Git, nicht in Shell-Historien und nicht in unverschlüsselte Runner-Logs. Die Regeln für Verwaltung und Download stehen in der offiziellen Dokumentation zu App Store Connect API Keys.

Die folgende Tabelle trennt Bestandteile, Nachweis und Rückfallentscheidung:

Jede riskante Aktion braucht vorher einen Rückfallplan. Vor dem Widerruf eines Zertifikats wird dokumentiert, welche Builds, Runner und Entwicklerkonten es verwenden. Vor einer Schlüsselrotation wird der neue Schlüssel getestet. Vor dem Löschen eines alten Profiles wird geprüft, ob noch ein aktiver Workflow darauf verweist.

Archive, dSYM und IPA nach Wiederherstellungswert sortieren

Die dritte Messgröße ist die Produktions- und Diagnosefähigkeit. Nicht jedes Build-Ergebnis muss gleich lange aufbewahrt werden.

Das xcarchive ist nicht dasselbe wie eine IPA-Datei. Es enthält zusätzliche Informationen für spätere Prüfungen und Exporte. Die dSYM-Datei ist wiederum für die Symbolisierung relevant. Apple erläutert in der Anleitung zum Auffinden fehlender Debug-Symbol-Dateien, wie die Zuordnung geprüft wird.

Ein brauchbarer Dateiname oder ein separates Manifest verbindet Artefakte eindeutig:

<AppName>-<VERSION>-<BUILD>-<ARCHIVE_UUID>.xcarchive
<AppName>-<VERSION>-<BUILD>-<ARCHIVE_UUID>.dSYM.zip
<AppName>-<VERSION>-<BUILD>-<ARCHIVE_UUID>.xcresult
<AppName>-<VERSION>-<BUILD>-ExportOptions.plist

Versionsnummer und Buildnummer müssen aus dem tatsächlichen Projekt oder Archive übernommen werden. Sie werden nicht geraten. Die Archive-UUID wird aus dem erzeugten Artefakt ausgelesen und mit dem Manifest gespeichert.

Nach dem Kopieren wird mindestens ein Archive geöffnet oder exportiert. Eine Datei, die sich lediglich auf dem Backup-Speicher auflisten lässt, ist noch nicht als intakt bewiesen. Bei dSYM-Dateien wird die UUID mit dem erwarteten Binary abgeglichen. Bei einem IPA wird geprüft, ob es tatsächlich aus dem vorgesehenen Archive stammt und nicht nur zufällig denselben Dateinamen trägt.

Preis, Betriebsrisiko und Rückfall: drei Wege im Vergleich

Die Migrationsentscheidung hängt nicht nur vom Speicherort ab. Entscheidend sind Wiederholbarkeit, Zugriffskontrolle und die Frage, wie lange die alte Umgebung parallel erhalten bleiben muss.

Für eine Auswahl sollten nicht nur Mietkosten oder Anschaffungspreise verglichen werden. Relevant sind auch Root- beziehungsweise Administrationsrechte, Zugriff über SSH oder VNC, Datenlöschung nach der Rückgabe, Backup-Möglichkeiten, Erreichbarkeit der Maschine und die Frage, ob ein Runner dauerhaft laufen kann. Einen Überblick über die SFTPMAC-Angebotsbedingungen für Remote Macs und die verfügbaren Mac-Mietpreise kann ein Team für die Kostenplanung heranziehen; die konkrete Eignung muss anhand des eigenen Xcode- und CI/CD-Ablaufs geprüft werden.

Ein Remote Mac ist nicht automatisch eine vollständige Backup-Strategie. Auch bei einer gemieteten Maschine bleiben private Schlüssel, Archive und API-Zugänge in der Verantwortung des Teams. Für DSGVO-relevante Projekte werden Speicherort, Zugriffspfade, Protokollierung und Löschprozess vor der Übergabe dokumentiert.

FAQ: Dateien, Schlüssel, Archive und Runner

Die folgenden Antworten decken die häufigsten Entscheidungen bei einer vollständigen iOS-Build-Maschinenmigration ab.

Welche Dateien gehören beim Wechsel einer iOS-Build-Maschine in die Sicherung?

Gesichert werden sollten nicht nur Projektordner, sondern auch Git-Submodule, Sperrdateien, private Abhängigkeiten, Build-Skripte und notwendige Konfigurationsdateien. DerivedData und andere Caches sind dagegen normalerweise keine belastbare Migrationsgrundlage. Entscheidend ist ein sauberer Checkout auf dem neuen Mac, bei dem Abhängigkeiten erneut aufgelöst und anschließend Build, Archive und Signierung ohne alte Verzeichnisse ausgeführt werden.

Wie lassen sich Signierzertifikat und privater Schlüssel vor der Rückgabe eines Remote Mac sichern?

Eine Apple-Distribution-Identität besteht aus Zertifikat und zugehörigem privaten Schlüssel. Das Zertifikat allein reicht nicht. Exportieren Sie die Identität aus dem Schlüsselbund als geschützte PKCS#12-Datei, bewahren Sie das Kennwort getrennt auf und importieren Sie beides testweise in einen isolierten Schlüsselbund auf dem neuen Mac. Profile, Team-Zuordnung und Signiermodus müssen anschließend zu einem echten Archive passen.

Müssen xcarchive und dSYM dauerhaft aufgehoben werden?

Für veröffentlichte Versionen sind xcarchive und dSYM wertvoller als ein einzelnes IPA. Das Archive kann bei einer späteren Prüfung oder einem erneuten Export helfen; dSYM-Dateien werden für die Symbolisierung von Abstürzen benötigt. Bewahren Sie beide mit Bundle ID, Versionsnummer, Buildnummer und Archive-UUID auf. Eine reine IPA-Sicherung lässt wichtige Diagnose- und Wiederherstellungsinformationen aus.

Wie wird ein selbst gehosteter Runner auf einen neuen Mac übernommen?

Registrieren Sie den neuen Runner zunächst mit einem neuen, minimal berechtigten Token und führen Sie eine isolierte Testaufgabe aus. Prüfen Sie Repository-Zugriff, Runner-Labels, Umgebungsvariablen, fastlane-Konfiguration und Signierung, bevor der alte Runner keine Aufgaben mehr annimmt. Erst danach wird der alte Runner nach der offiziellen Plattformprozedur entfernt. So vermeiden Sie doppelte Uploads und konkurrierende Release-Jobs.

Wann darf die alte Build-Maschine sicher gelöscht oder zurückgegeben werden?

Eine Rückgabe ist erst vertretbar, wenn der neue Mac einen echten Archive- und Upload-Ablauf abgeschlossen hat, die Wiederherstellung ohne alte Pfade funktioniert und der alte Runner keine Aufgaben mehr annimmt. Danach sollten Dienste gestoppt, temporäre Zugangsdaten rotiert oder widerrufen und freigegebene Dateien, Shell-Historien sowie gemeinsam genutzte Verzeichnisse kontrolliert bereinigt werden. Bei einem fehlenden privaten Schlüssel bleibt die alte Maschine vorerst erhalten.

Runner-Übernahme erst nach isoliertem Test aktivieren

Die vierte Messgröße ist die automatisierte Übernahmefähigkeit. Ein neuer Mac kann manuell erfolgreich archivieren und trotzdem im CI/CD-System scheitern. Häufig fehlen dort Umgebungsvariablen, Schlüsselbund-Berechtigungen, private Paketquellen oder die richtige Runner-Kennzeichnung.

Vor dem Wechsel werden diese Bereiche getrennt inventarisiert:

• Repository- und Organisationsrechte.
• Runner-Name und Labels.
• Registrierungstoken.
• fastlane- und Exportkonfiguration.
• Umgebungsvariablen für Team ID, Bundle ID und Distributionsziel.
• App Store Connect API Key.
• Pfade zu Zertifikaten, Profilen und temporären Dateien.
• Benachrichtigungs- und Protokollierungsziele.
• Hintergrunddienste und geplante Aufgaben.

Die Zugangsdaten selbst gehören nicht in die Inventarliste. Dort stehen nur Zweck, Besitzer, Speicherort und Rotationsstatus. Für ein anonymisiertes Übergabedokument genügt beispielsweise:

Runner: <RUNNER_NAME>
Labels: <LABEL_A>, <LABEL_B>
Repository: <REPOSITORY_PLACEHOLDER>
Team ID: <TEAM_ID>
Key ID: <KEY_ID>
Token: <nicht im Dokument>
Logziel: <LOG_ENDPOINT_PLACEHOLDER>

Der neue Runner wird zunächst registriert und mit einem Testlabel isoliert. Der Testjob sollte aus einem sauberen Checkout eine Abhängigkeit auflösen, ein Archive erstellen und – sofern vorgesehen – einen kontrollierten Upload ausführen. Erst wenn die Ausgabe keine alten Hostpfade enthält, wird der Runner für produktive Jobs freigeschaltet.

Der alte Runner bleibt während dieser Phase entweder vollständig deaktiviert oder erhält keine produktiven Aufgaben. Zwei aktive Runner mit gleichem Label können sonst denselben Release-Prozess konkurrierend bearbeiten. Die offizielle Anleitung zum Entfernen selbst gehosteter Runner ist für diesen Schritt maßgeblich. Das Entfernen wird erst nach erfolgreicher Übernahme durchgeführt.

Alte Build-Maschine kontrolliert bereinigen und erst dann zurückgeben

Die letzte Messgröße ist die Bereinigungssicherheit. Sie wird nicht durch das Ende des Dateikopierens erreicht, sondern durch einen Test unter erschwerten Bedingungen: Der alte Mac bleibt offline, während der neue Host den entscheidenden Ablauf wiederholt.

Eine sinnvolle Reihenfolge lautet:

1. Migrationsmanifest und letzte erfolgreiche Veröffentlichung sichern.
2. Repository, Sperrdateien und private Abhängigkeiten auf dem neuen Mac prüfen.
3. Xcode-27-Version, macOS-Version, SDKs, Scheme und Exportkonfiguration dokumentieren.
4. Apple Distribution, privaten Schlüssel und Profiles isoliert importieren.
5. App Store Connect API-Zugang und CI/CD-Umgebungsvariablen kontrolliert hinterlegen.
6. Einen echten Archive-Lauf aus einem sauberen Checkout ausführen.
7. Export und vorgesehenen Upload testen.
8. dSYM, xcarchive und xcresult mit UUID und Builddaten ablegen.
9. Den alten Host offline nehmen und den kritischen Ablauf wiederholen.
10. Runner entfernen, Dienste stoppen und temporäre Zugangsdaten rotieren oder widerrufen.
11. Gemeinsame Verzeichnisse, Shell-Historien und lokale Geheimnisse prüfen.
12. Erst danach Rückgabe, Löschung oder Beendigung der alten Maschine freigeben.

Die Prüfung von Shell-Historien ist besonders wichtig, weil Entwickler bei manuellen Tests gelegentlich Kennwörter, Tokens oder vollständige Exportbefehle eingeben. Auch gemeinsam genutzte temporäre Verzeichnisse dürfen nicht ungeprüft übernommen werden. Bei sensiblen Projekten wird die Bereinigung protokolliert, ohne geheime Inhalte in das Protokoll zu kopieren.

Die abschließende Entscheidungskarte

Für das endgültige Abnahmeprotokoll reichen fünf klare Statuswerte: Quellcode reproduzierbar, Signierung verwendbar, Artefakte wiederherstellbar, Automation übernehmbar und alter Host bereinigt. Ein „unbekannt“ bei einem dieser Punkte ist kein bestandenes Ergebnis.

Wenn die vorhandene Umgebung kurz vor der Rückgabe steht, ist ein neuer Remote Mac oft der kontrolliertere Übergang als eine hektische Reparatur auf einem bereits auslaufenden Host. Ein lokaler Mac bindet Kapital und muss dauerhaft gewartet werden; eine beschädigte oder gemeinsam genutzte Cloud-Umgebung erschwert dagegen Schlüsselkontrolle, Pfadbereinigung und reproduzierbare CI/CD-Läufe. SFTPMAC kann deshalb als neue, getrennt geprüfte Umgebung sinnvoll sein, sofern der Zugriff, die Datenlöschung und die benötigten Xcode-27-Buildaufgaben vorab bestätigt werden. Entscheidend bleibt: Erst die reale Veröffentlichung auf dem neuen System, dann die Rückgabe des alten.