fastlane match auf dem Remote-Mac konfigurieren? 2026 Checkliste für die CI-Signaturmigration

Für die Migration gilt: Ein neues Projekt kann fastlane match direkt verwenden; bei bestehender Produktionssignierung werden die vorhandenen Identitäten zuerst importiert und parallel geprüft. Ein match nuke ist kein Standard-Schritt. Der Remote-Mac synchronisiert in CI-Jobs über eine temporäre Schlüsselbund-Umgebung und standardmäßig im readonly-Modus. Apple beschreibt eine Signieridentität als Kombination aus Zertifikat und zugehörigem privaten Schlüssel – nur ein erfolgreich heruntergeladenes Zertifikat beweist daher noch keinen funktionierenden Build.

Diese Anleitung ist für Sie relevant, wenn Sie iOS- oder macOS-Builds von einem persönlichen Mac lösen möchten, eine CI/CD-Signierung betreuen oder Zertifikate, private Schlüssel und Beschreibungsprofile verwalten. Sie eignet sich außerdem für Verantwortliche, die einen Remote-Mac als dauerhaft verfügbaren Build- oder Veröffentlichungs-Node einsetzen wollen.

Entscheidungsrahmen für die Migration

Der wichtigste Unterschied liegt nicht zwischen „lokal“ und „remote“, sondern zwischen einer verwalteten Signierquelle und einer nicht dokumentierten Einzelmaschine. Ein persönlicher Mac kann funktionieren, obwohl dort private Schlüssel, Profile, Benutzerfreigaben und manuelle Xcode-Einstellungen vermischt sind. Beim Umzug auf einen Remote-Mac wird diese Unsicherheit sichtbar.

Für die Auswahl des Vorgehens hilft folgende Gegenüberstellung:

Apple weist darauf hin, dass die Identität ohne den passenden privaten Schlüssel nicht vollständig synchronisiert ist. Die Apple-Dokumentation zur gemeinsamen Nutzung von Signierzertifikaten sollte deshalb neben der fastlane-Konfiguration als Prüfgrundlage dienen.

Neues Projekt und erste Signierquelle

Bei einem neuen Projekt darf fastlane match früh eingesetzt werden, weil noch keine produktive Identität geschützt werden muss. Trotzdem sollte die Initialisierung nicht mit dem Nachweis enden, dass Dateien im Repository liegen. Die erste belastbare Basis ist ein sauberer Remote-Mac, der aus einem definierten Commit einen signierten Build erzeugt.

Vor der Initialisierung werden diese Werte festgelegt:

• APP_IDENTIFIER: com.example.app
• TEAM_IDENTIFIER: TEAMID1234
• SIGNING_REPOSITORY: git@example.invalid:signing-repo.git
• SIGNING_BRANCH: team-placeholder
• MATCH_PASSWORD: ausschließlich als Secret der CI oder des Verwaltungsprozesses
• Ziel-Targets: Haupt-App, Extensions, Widget, Watch App oder macOS-App, sofern vorhanden

Bundle Identifier und Target-Namen dürfen nicht nur aus dem Hauptprojekt übernommen werden. Ein Widget mit einer eigenen App-ID benötigt häufig ein eigenes Beschreibungsprofil. Für macOS-Ziele gelten außerdem eigene Verteilungsbedingungen; die Apple-Anleitung für distribution-signierten macOS-Code ist dafür die maßgebliche Referenz.

Die Signierarten sollten vorab schriftlich zugeordnet werden. Development, Ad Hoc, App Store und macOS Distribution sind keine austauschbaren Varianten. Entscheidend ist, welcher Build-Typ später installiert oder verteilt wird. Die Apple-Beschreibung zur Verteilung auf registrierte Geräte hilft bei der Abgrenzung von Entwicklungs- und Verteilungsprofilen.

Initialisierung ohne versteckte Abhängigkeiten

Ein kontrollierter Erstlauf folgt dieser Reihenfolge:

1. Ein neues oder bereinigtes Arbeitsverzeichnis auf dem Remote-Mac anlegen.
2. Das Repository mit dem Anwendungscode und die vorgesehenen Platzhaltervariablen bereitstellen.
3. match nur für die benötigte Signierart und das definierte Target initialisieren.
4. Die synchronisierten Dateien und die Teamzuordnung im Log prüfen, ohne Geheimnisse auszugeben.
5. Mit demselben Commit einen signierten Build oder ein Archiv erzeugen.
6. Signatur, Profilzuordnung und Installierbarkeit prüfen.
7. Erst danach weitere Targets, Distributionswege oder Veröffentlichungsschritte ergänzen.

Das Ergebnis gilt nur dann als Basis, wenn die private Schlüsselkomponente tatsächlich in der temporären Keychain verfügbar ist. Ein Repository mit .cer- oder Profil-Dateien ist kein Ersatz für eine erfolgreiche Signierung.

Bestehende Produktion kontrolliert übernehmen

Bei einer vorhandenen Produktionspipeline beginnt die Arbeit mit einer Bestandsaufnahme, nicht mit dem Löschen alter Ressourcen. Zu erfassen sind verwendete Zertifikate, zugehörige private Schlüssel, Beschreibungsprofile, Bundle Identifier, Distribution-Ziele und die Person oder Rolle, die bisher die Veröffentlichung freigibt.

match import ist für diesen Übergang der vorsichtige erste Schritt. Die offizielle match-Dokumentation beschreibt den Import vorhandener Signierressourcen. Das Repository sollte zunächst isoliert betrieben werden, damit ein Fehler nicht automatisch die bisherige Produktionskette verändert.

Wichtig: match nuke, der Widerruf eines Zertifikats oder das Löschen einer Keychain verändert die Wiederherstellbarkeit. Vor einem solchen Schritt müssen Auswirkung, Backup, verantwortliche Freigabe und Rückkehr zur alten Veröffentlichung dokumentiert sein.

Die Migrationsprüfung sollte dieselbe Anwendung, denselben Commit und denselben vorgesehenen Verteilungsweg verwenden. Nur so lässt sich unterscheiden, ob eine Abweichung aus dem Quellcode, aus Xcode, aus dem Profil oder aus der neuen Schlüsselbund-Umgebung stammt.

Die Apple-Hilfe zum Bearbeiten, Herunterladen oder Löschen von Provisioning Profiles ist besonders relevant, wenn ein Profil nach einer Änderung an App-ID, Geräteliste oder Berechtigungen neu erzeugt werden muss. Eine Profiländerung sollte nicht mit einer Zertifikatsrotation verwechselt werden.

Mehrere Targets und Teams isolieren

Ein gemeinsames Repository kann für mehrere Anwendungen sinnvoll sein, wenn Zertifikate, Profile und Verantwortlichkeiten sauber unterschieden werden. Das bedeutet jedoch nicht, dass jede Anwendung dieselben Zugangsdaten oder dieselbe Apple-Teamzuordnung verwenden sollte.

Die fastlane-Dokumentation zum Appfile beschreibt die Zuordnung von App- und Teaminformationen. Für die Konfiguration sollten Platzhalter statt echter Kontodaten verwendet werden:

app_identifier("APP_IDENTIFIER")
team_id("TEAM_IDENTIFIER")
git_branch("SIGNING_BRANCH")

Die tatsächlichen Werte kommen erst zur Laufzeit aus einer geschützten CI-Konfiguration. Niemals gehören reale Passwörter, Repository-Token oder persönliche Apple-Zugangsdaten in das Anwendungrepository.

Die Abnahme muss mindestens das Haupt-Target und jedes signierrelevante Zusatz-Target abdecken. Ein grüner Build der Haupt-App sagt nichts über Widget, Watch App oder Extension aus, wenn diese andere App-IDs oder Berechtigungen besitzen.

Unbeaufsichtigte CI auf dem Remote-Mac

Ein CI-Job darf nicht davon abhängen, dass eine grafische Sitzung geöffnet ist oder eine Person eine Sicherheitsabfrage bestätigt. setup_ci ist dafür relevant, weil es eine CI-orientierte Umgebung mit temporärem Schlüsselbund vorbereiten kann. Die offizielle Dokumentation zu setup_ci sollte für die verwendeten Parameter und das Verhalten der eingesetzten fastlane-Version direkt geprüft werden.

Die Reihenfolge ist entscheidend:

1. CI-Job startet mit einem frischen Arbeitsbereich.
2. setup_ci richtet den temporären Schlüsselbund ein.
3. Der Signierspeicher wird entschlüsselt und synchronisiert.
4. match läuft im readonly-Modus.
5. Erst danach startet Xcode den Build oder die Archivierung.
6. Signatur und Profil werden geprüft.
7. Logs und Status werden als Build-Artefakte gesichert.
8. Der Job beendet die Sitzung, ohne Secrets oder Signiermaterial in den Arbeitsbereich zu übernehmen.

Für reguläre Builds sollte die Konfiguration sinngemäß auf readonly gestellt werden:

match(
  type: "appstore",
  app_identifier: "APP_IDENTIFIER",
  readonly: true
)

Der konkrete Typ und die Parameter müssen zu Target und Verteilungsweg passen. Der Zweck von readonly ist nicht, jeden Schreibvorgang technisch unmöglich zu machen, sondern die normale CI davon abzuhalten, Zertifikate oder Profile eigenständig zu erzeugen, zu erneuern oder zu ersetzen.

Die Berechtigungen sind getrennt zu behandeln:

Ein einzelner hoch privilegierter Schlüssel widerspricht dieser Trennung. Wenn ein Build-Job sowohl den Signierspeicher verändern als auch veröffentlichen darf, kann ein Fehler in einem gewöhnlichen Testlauf die Produktionskette beeinflussen.

Gemeinsamer Node und Restzustände

Ein geteilter Remote-Mac braucht nicht nur getrennte CI-Variablen, sondern auch getrennte Arbeitsbereiche, Benutzerkontexte und Schlüsselbund-Lebenszyklen. Ein Neustart, eine abgelaufene Sitzung oder ein parallel laufender Job kann sonst dazu führen, dass ein Prozess eine bereits vorhandene Keychain oder ein fremdes Profil vorfindet.

Die wichtigste Prüfung besteht aus zwei getrennten Jobs:

• Job A verwendet ein nicht-produktives Signierprofil und baut nur die Testanwendung.
• Job B verwendet einen anderen Arbeitsbereich und eine andere Berechtigungsgruppe.
• Beide Jobs laufen nacheinander oder – falls der Node das unterstützt – parallel.
• Danach wird geprüft, ob Job B keine Identität, Datei oder Umgebungsvariable aus Job A übernommen hat.
• Nach einem Neustart wird der Ablauf wiederholt.

Dabei sollten Dateipfade, Keychain-Liste, Umgebungsvariablen und Build-Logs auf unbeabsichtigte Übernahme geprüft werden. Logs dürfen Zertifikatsnamen zur Diagnose enthalten, aber keine Passwörter, Repository-Token oder privaten Schlüsselmaterialien.

Für Teams, die zunächst einen kontrollierten Remote-Mac ohne sofortige Produktionsumstellung benötigen, kann ein verwalteter Remote-Mac-Zugang von RUVCLOUD als Testumgebung dienen. Die Entscheidung sollte an der Möglichkeit hängen, den Node neu zu starten, administrativ zu verwalten und einen vollständigen Signier- und Wiederherstellungstest auszuführen – nicht allein an der Verfügbarkeit einer grafischen macOS-Sitzung.

Rotation, Ausfall und Rückkehr

Eine belastbare Signiermigration definiert vor dem ersten produktiven Lauf, wer bei einem ablaufenden Zertifikat, einem veränderten Profil, einem verlorenen Repository-Zugriff oder einem nicht verfügbaren Remote-Mac handelt. Die Zuständigkeit sollte pro Ressource dokumentiert werden:

• Zertifikat und privater Schlüssel: Signieradministrator
• Beschreibungsprofile und App-ID: Apple-Teamverantwortlicher
• Signierspeicher und Verschlüsselungs-Passwort: getrennte technische Verwaltung
• Veröffentlichungs-Token: Release-Verantwortlicher
• CI-Job und Wiederherstellung des Nodes: DevOps-Verantwortlicher

Bei einer Rotation wird nicht zuerst die alte Identität gelöscht. Zunächst wird die neue Ressource in einem isolierten Verwaltungsjob erzeugt oder importiert, anschließend auf einem frischen Remote-Mac synchronisiert und mit einem nicht-produktiven Lauf geprüft. Erst wenn Archiv und Zielkanal akzeptiert werden, wird die neue Identität in den Release-Prozess übernommen.

Die endgültige Entscheidung sollte eine von drei Formen annehmen:

1. Direkte Migration: Der Remote-Mac erfüllt Signatur-, Archivierungs-, Installations- und Wiederherstellungstests; der alte Prozess bleibt zunächst als Rückfall erhalten.
2. Weiterer Parallelbetrieb: Der neue Node baut erfolgreich, aber ein Target, eine Freigabe oder ein Wiederanlauf ist noch nicht ausreichend geprüft.
3. Verschiebung: Private Schlüssel, Teamrechte, Profile oder Wiederherstellung sind nicht belastbar dokumentiert; die Produktionskette bleibt unverändert.

Ein einzelner erfolgreicher Build ist keine Produktionsfreigabe. Erst die Kombination aus identischem Commit, vollständiger Target-Abdeckung, nicht-interaktiver Ausführung, kontrollierter Keychain und geprüftem Rückfall rechtfertigt die Umstellung.

Häufige Fragen zur Signaturmigration

Kann fastlane match vorhandene Produktionszertifikate importieren?

Ja, aber der Import ersetzt keine Bestandsaufnahme. Zertifikat, privater Schlüssel, Profil, Bundle Identifier und Teamzuordnung müssen zusammen geprüft werden. Der sichere Weg besteht aus einem isolierten Import, einem parallelen Build und einer dokumentierten Wiederherstellung. Das Widerrufen bestehender Produktionsidentitäten ist dafür nicht erforderlich und sollte nicht als automatischer Vorbereitungsschritt behandelt werden.

Weshalb ist die temporäre Keychain auf einem Remote-Mac wichtig?

Auf einem gemeinsam genutzten oder dauerhaft laufenden Node kann eine dauerhaft geöffnete Benutzer-Keychain alte Identitäten und persönliche Zugriffsrechte enthalten. Eine temporäre Umgebung begrenzt den Job und macht fehlende Schlüssel sichtbar. Sie verhindert nicht jede Fehlkonfiguration, erleichtert aber die Prüfung, ob der Build ohne grafische Bestätigung und ohne fremde Restdaten funktioniert.

In welchen Jobs ist readonly richtig?

readonly passt zu Build-, Test-, Archivierungs- und normalen Release-Jobs, sofern die benötigten Ressourcen bereits freigegeben wurden. Import, Erneuerung, Rotation und Profiländerung benötigen dagegen einen gesonderten Verwaltungsprozess. Dieser Prozess sollte nicht parallel zu gewöhnlichen Builds laufen und muss nachvollziehbar festhalten, welche Identität geändert wurde und wie der alte Stand wiederhergestellt wird.

Wie werden mehrere Teams voneinander getrennt?

Die Trennung erfolgt durch eigene Speicherbereiche oder Branches, unterschiedliche Zugangsdaten und klar zugeordnete Team- und App-Variablen. Ein gemeinsames Repository ist nur dann vertretbar, wenn die Zugriffsgrenzen tatsächlich durchgesetzt und alle Targets geprüft werden. Für unterschiedliche Apple-Teams ist eine unabhängige Verwaltung in der Regel leichter zu auditieren als ein gemeinsames, breit berechtigtes Secret.

Nächster Schritt für einen kontrollierten Test

Nach der Bestandsaufnahme sollte zunächst ein Remote-Mac mit vollständigen Verwaltungsrechten und reproduzierbarem Neustart bereitstehen. Darauf wird ein nicht-produktiver match-Lauf mit temporärer Keychain ausgeführt, anschließend ein Archiv erzeugt und der Wiederanlauf nach einer frischen Sitzung geprüft. Erst wenn diese Kette stabil ist, sollte die formelle Migration der Veröffentlichung beginnen. Für eine konkrete Mietdauer und die verfügbaren Umgebungen können Sie die RUVCLOUD-Tarife für Remote-Macs anhand des benötigten Test- und Betriebsmodells vergleichen.

Ein persönlicher Mac bleibt für kleine, dauerhaft manuelle Projekte bequem, bindet die Signierung jedoch an eine einzelne Sitzung und erschwert die reproduzierbare Übergabe. Ein Linux- oder Windows-Server kann CI-Aufgaben übernehmen, ersetzt aber weder Xcode noch die macOS-Signierumgebung. Ein Remote-Mac von RUVCLOUD ist deshalb besonders dann sinnvoll, wenn vor einer endgültigen Hardwareentscheidung ein isolierter Build- und Wiederherstellungsprozess benötigt wird; für dauerhaft hohe Last, lokale Geräteanschlüsse oder eine langfristig wirtschaftlichere Eigeninstallation kann der Kauf und Betrieb eigener Hardware weiterhin die passendere Lösung sein.