CI/CD 8. September 2026 ca. 13 Min. macOS-Notarisierung Remote Mac CI

Braucht die macOS-App-Notarisierung einen Mac? CI-Entscheidung 2026

Diese Anleitung zeigt, welche Teile einer macOS-Veröffentlichung auf einem echten Mac ausgeführt werden sollten und welche Aufgaben ein Linux-CI-Knoten übernehmen kann. Sie erhalten eine zeitliche Prüfkette für Erstellung, Developer-ID-Signatur, Einreichung, Ticket-Verknüpfung und abschließende Validierung sowie eine Entscheidung zwischen reinem Remote-Mac-, Hybrid- und bedarfsgesteuertem Betrieb.

Apple dokumentiert drei offizielle Wege, mit dem Notarisierungsdienst zu arbeiten: Xcode, notarytool und die Notary API. Diese Aufteilung beantwortet die Frage „Braucht die macOS-App-Notarisierung einen Mac?“ bereits weitgehend: Für das Einreichen und Abfragen kann ein nicht macOS-basiertes System geeignet sein; für Erstellung, Developer-ID-Signatur, Ticket-Verknüpfung und lokale Endprüfung sollte weiterhin ein echter Mac eingeplant werden. Die grundlegende Einordnung finden Sie in Apples Dokumentation zur Notarisierung von macOS-Software.

Symptom: Ein Linux-Job meldet eine erfolgreiche Einreichung, aber das ausgelieferte Paket ist nicht signiert, nicht abschließend validiert oder ohne erforderliches Ticket.

Schnellste Lösung: Linux übernimmt Orchestrierung und Statusabfrage; ein isolierter Remote Mac übernimmt die macOS-spezifische Erstellung, Signatur, Ticket-Verknüpfung und Abschlussprüfung.

Diese Analyse richtet sich an Plattformingenieure, die aus einer Linux-CI heraus macOS-Software veröffentlichen wollen. Sie hilft außerdem macOS-Entwicklern und technischen Verantwortlichen, zwischen einem dauerhaft gemieteten Remote Mac, einem gemeinsam genutzten Knoten und einem nur bei Releases gestarteten Mac zu entscheiden.

Die Veröffentlichung ist eine Zeitkette, kein einzelner Upload

Eine erfolgreiche Notarisierung bestätigt nicht automatisch eine vollständige Auslieferung. In einer belastbaren Pipeline müssen mindestens diese Stationen getrennt behandelt werden:

Quellcode und Build-Konfiguration werden reproduzierbar verarbeitet.
Das macOS-Artefakt wird in ein geeignetes Distributionsformat gebracht.
Eingebettete Komponenten, Berechtigungen und Signaturen werden geprüft.
Die Developer-ID-Signatur wird auf einem geeigneten Ausführungssystem erzeugt oder verifiziert.
Das signierte Artefakt wird eingereicht.
Status und Fehlerbericht werden abgefragt.
Das Ergebnis wird, falls für das Format erforderlich, mit dem Ticket verknüpft und erneut validiert.

Apple beschreibt die Notarisierung als anpassbaren Workflow und nicht als bloßen Upload. Die Dokumentation zum Anpassen des Notarisierungs-Workflows ist deshalb für die Architektur wichtiger als die verkürzte Annahme, ein Dienststatus sei gleichbedeutend mit einer fertigen Veröffentlichung.

Der Linux-Knoten kann der zentrale Orchestrator bleiben. Er kann Quellcode auschecken, Artefakte übertragen, Statusabfragen koordinieren und Protokolle sammeln. Daraus folgt aber nicht, dass er jedes macOS-Werkzeug ersetzt. Ein Dienst kann eine Datei annehmen, ohne die lokale Signatur-, Packaging- und Validierungsumgebung des Zielsystems bereitzustellen.

Phase 1: Ein reproduzierbares Artefakt vor der Notarisierung erzeugen

Der erste Prüfpunkt ist nicht der Notarisierungsdienst, sondern das Eingangsartefakt. Die Pipeline muss festlegen, ob sie mit einer bereits erzeugten Anwendung, einem Archiv, einem Installationspaket oder einem Disk-Image arbeitet. Diese Formate sind nicht austauschbar, weil spätere Prüf- und Ticket-Schritte vom tatsächlichen Auslieferungsformat abhängen.

Beginnt der Prozess mit einem Xcode-Projekt, gehört der relevante Build- und Archivierungsschritt auf einen echten Mac. Das gilt besonders dann, wenn Xcode-Projekte, Apple-spezifische SDKs, native Abhängigkeiten oder macOS-eigene Packaging-Werkzeuge beteiligt sind. Die Apple-Anleitung zur Paketierung von Mac-Software beschreibt den erwarteten Übergabepunkt für die Distribution.

Beginnt der Prozess dagegen mit einem bereits erstellten, unveränderten Artefakt, kann ein Linux-Controller die nachfolgenden Übergaben und Statusabfragen koordinieren. Er sollte die Datei jedoch nicht stillschweigend neu packen oder verändern. Jede Änderung nach der Signatur kann die Integrität des Ergebnisses brechen.

Als Abnahme für diese Phase empfehlen wir:

Das Eingangsartefakt erhält eine unveränderliche Build-ID und eine Prüfsumme.
Die Pipeline speichert, aus welchem Commit und welcher Build-Konfiguration es entstanden ist.
Das Format wird vor dem Signieren ausdrücklich dokumentiert.
Ein zweiter Lauf mit identischen Eingaben erzeugt ein erwartbares Übergabeobjekt.
Bei einer fehlenden oder beschädigten Datei endet der Lauf vor der Signatur und nicht erst nach der Einreichung.

Der Fehlerausstieg ist wichtig: Wenn ein Linux-Job nur ein Archiv weiterreicht, aber keine verlässliche Aussage über dessen Herkunft oder Inhalt machen kann, sollte die Notarisierung nicht gestartet werden. Ein erfolgreicher Dienststatus würde diesen Mangel nicht beheben.

Phase 2: Signatur und Berechtigungen auf dem Ausführungsknoten isolieren

Die Notarisierung ersetzt keine Developer-ID-Signatur. Vor der Einreichung muss die Pipeline klären, welche ausführbaren Bestandteile, Frameworks, Helper, Plug-ins und verschachtelten Codeobjekte zum Paket gehören. Außerdem müssen Entitlements und Signaturhierarchie zum vorgesehenen Auslieferungsweg passen.

Die offizielle Dokumentation zur Erstellung von distributionssigniertem Mac-Code behandelt die Signatur als Teil der Apple-Entwicklungs- und Distributionswerkzeuge. Ein Linux-Runner kann den Ablauf anstoßen und das Ergebnis archivieren; er stellt aber nicht automatisch die passende lokale Schlüsselbundumgebung bereit.

Wir trennen deshalb drei Betriebsmodelle:

Dedizierter Remote Mac: Der Knoten gehört einer Pipeline oder einem klar abgegrenzten Team. Schlüsselbundzugriff, Ausführungskonto und temporäre Arbeitsverzeichnisse lassen sich am saubersten kontrollieren. Dieses Modell ist für regelmäßige Veröffentlichungen und strenge Wiederholbarkeit geeignet.
Geteilter Mac-Knoten: Mehrere Jobs verwenden dieselbe Maschine. Das kann Leerlauf reduzieren, verlangt aber Queue-Isolation, Bereinigung nach jedem Job, getrennte Schlüsselbundkontexte und eine nachweisbare Sperre gegen parallele Signaturvorgänge.
Externer Signaturschritt: Die Signatur wird aus dem normalen Build herausgelöst. Das kann die Schlüsselverwaltung zentralisieren, erhöht aber die Komplexität beim Artefakttransport und bei der Fehlerdiagnose. Die Pipeline muss beweisen, dass genau das erwartete Artefakt signiert zurückkommt.

Die Abnahme darf sich nicht auf die Meldung „codesign erfolgreich“ beschränken. Wir erfassen mindestens das Ergebnis der Signaturprüfung, das ausführende Konto, den verwendeten Schlüsselbundkontext und die geprüften verschachtelten Komponenten. Konkrete Zertifikatsnamen, Team-IDs und Geheimnisse gehören nicht in Logs; dafür verwenden wir Platzhalter wie <TEAM_ID>, <SIGNING_IDENTITY> und <KEYCHAIN_CONTEXT>.

Bei fehlendem Schlüsselbundzugriff, unklarer Identität oder einer abweichenden Prüfsumme wird der Job vor der Einreichung abgebrochen. Ein automatischer Wiederholungsversuch auf demselben möglicherweise verunreinigten Knoten wäre hier keine Stabilitätsmaßnahme, sondern eine Verschleierung der Ursache.

Phase 3: Einreichung mit notarytool oder Apple Notary API

Für die Kommunikation mit dem Notarisierungsdienst existieren zwei relevante Integrationsrichtungen. notarytool passt zu einem Mac-zentrierten Ablauf: Das signierte Artefakt bleibt auf dem Mac, die Pipeline führt das offizielle Kommandozeilenwerkzeug aus und übernimmt Status- sowie Protokollschritte im lokalen Job.

Die Apple-Dokumentation zu notarytool sollte die maßgebliche Grundlage für Syntax, Authentifizierung und Verhalten sein. Da Apple Parameter und Authentifizierungswege verändern kann, gehören sie nicht als unveränderliche Annahmen in einen internen Standard. Wir prüfen sie beim Aufbau des Knotens und bei jeder relevanten Toolchain-Änderung.

Die Apple Notary API ist dagegen für eine stärker entkoppelte Architektur interessant. Ein Linux-Orchestrator kann Einreichung und Statusabfrage als API-Aufgaben behandeln, ohne dass der gesamte Steuerungsprozess auf dem Mac laufen muss. Die offiziellen Schnittstellen für Software-Einreichungen und für den Abruf des Einreichungsprotokolls müssen dabei getrennt betrachtet werden.

Der Vergleich fällt in der Praxis so aus:

Wählen Sie notarytool, wenn bereits ein vertrauenswürdiger Mac-Knoten existiert, das Artefakt dort signiert wird und ein lokaler Ablauf mit Kommandozeilenprotokollen einfacher zu betreiben ist.
Wählen Sie die Notary API, wenn ein Linux-CI-System Einreichungen zentral koordinieren, mehrere Statusläufe verwalten und die Mac-Ausführung auf klar definierte lokale Schritte begrenzen soll.
Kombinieren Sie beide Wege nur mit einer eindeutigen Zuständigkeit. Eine Pipeline, die teilweise über notarytool und teilweise über API-Aufrufe arbeitet, braucht eine feste Quelle für Submission-ID, Status und Fehlerprotokoll.

Für beide Varianten gelten dieselben Sicherheitsanforderungen. Authentifizierungsdaten werden nicht in Quelltext, Artefaktnamen oder frei lesbare Job-Ausgaben geschrieben. API-Aufrufe benötigen eine Wiederholungsstrategie, die zwischen einem Netzwerkfehler, einer bereits angenommenen Einreichung und einer tatsächlich abgelehnten Datei unterscheidet. Ein blinder Neuversuch kann sonst doppelte oder schwer zuzuordnende Einträge erzeugen.

Wir nennen bewusst keine allgemeine Bearbeitungsdauer und keine Erfolgsquote. Apple kann Dienstverhalten, akzeptierte Eingaben und Authentifizierungsanforderungen ändern; außerdem hängt die Wiederholung von Netzwerk, Artefakt und Fehlerart ab. Entscheidend sind Submission-ID, Status und das vollständige Protokoll.

FAQ zur Linux- und Remote-Mac-Aufteilung

Kann eine macOS-App aus einer Linux-CI heraus notariert werden?

Ja, Einreichung und Statusabfrage können über die Notary API von einem nicht macOS-basierten Controller aus orchestriert werden. Das beantwortet jedoch nur einen Teil der Veröffentlichungsfrage. Wenn Build, Developer-ID-Signatur, formatabhängiges Packaging, Ticket-Verknüpfung oder lokale Validierung fehlen, ist das Endprodukt noch nicht abgenommen. Linux kann also den Dienst steuern, aber nicht automatisch jede macOS-Aufgabe ersetzen.

Wann ist notarytool gegenüber der Notary API die bessere Wahl?

notarytool ist meist der kürzere Weg, wenn der Remote Mac bereits signiert und das Artefakt lokal weiterverarbeitet. Die API ist sinnvoll, wenn ein Linux-CI-System Einreichungen, Statusabfragen und Protokolle zentral verwalten soll. Für die Entscheidung zählen nicht nur der Upload, sondern auch Geheimnisverwaltung, Wiederholungen, Ausfallverhalten und die Frage, wo das endgültige Artefakt geprüft wird.

Welche Aufgaben müssen auf einem Mac laufen?

Der Bedarf entsteht nicht allein durch die Notarisierung. Xcode-basierte Builds, macOS-spezifische Paketierung, Developer-ID-Signatur und lokale Werkzeuge für Ticket-Verknüpfung oder Validierung sprechen für einen echten Mac. Eine vorhandene signierte Datei kann dagegen von einem Linux-Controller übertragen und über die API eingereicht werden. Jede Pipeline muss die konkreten Formate und ihre Abschlussaktionen einzeln testen.

Wie wird ein Remote Mac in die Pipeline eingebunden?

Der Mac erhält eine begrenzte Runner-Rolle mit definierten Eingaben und Ausgaben. Linux erstellt oder koordiniert den Build, überträgt die unveränderliche Datei und ruft den Mac für Signatur, Einreichung, Ticket-Verknüpfung und Endprüfung auf. Nach jedem Job werden Arbeitsverzeichnisse bereinigt und Protokolle zentral gesichert. Ein Neustarttest zeigt, ob Schlüsselbund, Runner und Netzwerkpfade tatsächlich wieder funktionieren.

Phase 4: Ticket-Verknüpfung und Endprüfung nicht überspringen

Ein erfolgreicher Notarisierungsstatus bedeutet nicht zwangsläufig, dass die veröffentlichte Datei alle letzten Schritte durchlaufen hat. Die Pipeline muss unterscheiden zwischen dem vom Dienst akzeptierten Artefakt, dem Einreichungsprotokoll und dem konkreten Objekt, das an Kunden oder interne Tester verteilt wird.

Je nach Format kann ein Ticket-Schritt mit stapler erforderlich sein. Dieser Schritt ist lokal an der Auslieferungsdatei zu prüfen und gehört deshalb in vielen Designs auf den Remote Mac. Die nachfolgende Validierung muss ebenfalls am finalen Distributionsobjekt stattfinden, nicht nur an einem früheren Archiv.

Eine belastbare Abschlussprüfung umfasst:

Die Prüfsumme des finalen Files wird mit dem signierten Übergabeobjekt verglichen.
Die Signatur wird am finalen Objekt erneut validiert.
Die Ticket-Verknüpfung wird geprüft, sofern der gewählte Distributionsweg sie verlangt.
Dienstantwort und Einreichungsprotokoll werden unter der Submission-ID archiviert.
Ein Testlauf verwendet genau die Datei, die später veröffentlicht würde.
Bei einem negativen Status wird kein nachgelagerter Veröffentlichungsjob ausgelöst.

Dieser Ansatz schützt vor einem häufigen organisatorischen Fehler: Das CI-System markiert den Upload als erfolgreich und veröffentlicht anschließend automatisch ein anderes, nachträglich verpacktes Artefakt. Für die Abnahme zählt nur die Datei am Ende der Kette.

Der Remote Mac braucht eine definierte Sicherheits- und Wiederherstellungsgrenze

Bei Signatur- und Notarisierungsjobs sind nicht nur Rechenleistung und Erreichbarkeit relevant. Ein Entwicklerteam muss auch klären, wer auf den Schlüsselbund zugreifen darf, wie lange temporäre Dateien liegen bleiben und welche Logs vertrauliche Daten enthalten. Für Teams mit europäischen Kunden gehören DSGVO-Prüfung, Datenstandort, Zugriffsprotokollierung und Löschfristen in die Betriebsentscheidung.

Ein geteilter Mac ist nur dann vertretbar, wenn parallele Jobs nicht auf denselben Schlüsselbund, dieselben Exportverzeichnisse oder dieselben temporären Artefakte zugreifen. Ein dedizierter Knoten reduziert diese Überschneidungen, ersetzt aber keine Bereinigung. Auch nach einem Neustart müssen Runner-Registrierung, Dateirechte, Schlüsselbundzugriff und Netzwerkpfade erneut geprüft werden.

Für eine externe Betriebsumgebung kann ein Remote-Mac-Mietmodell interessant sein, wenn ein Team keinen eigenen Mac beschaffen und dauerhaft administrieren möchte. Die Entscheidung sollte aber erst nach einem echten End-to-End-Test fallen; eine erreichbare Maschine ist noch kein abgenommener Release-Knoten.

Entscheidungswerkzeug: CI-Topologie mit Bedingungen auswählen

Die folgende Checkliste ist für eine Architekturentscheidung gedacht. Sie wird nicht nach dem Upload, sondern nach einem vollständigen Testlauf ausgefüllt.

1. Mac-Pflicht für die Lieferkette

Der Build verwendet Xcode, Apple-SDKs oder macOS-spezifische native Abhängigkeiten.
Wenn ja: Build und Archivierung auf einem echten Mac ausführen. Wenn nein: Linux darf den Build koordinieren, sofern das Eingangsartefakt anschließend unverändert bleibt.
Das Paket enthält verschachtelten Code, Helper, Plug-ins oder besondere Entitlements.
Wenn ja: Signatur und lokale Prüfung auf einem kontrollierten Mac abnehmen. Wenn nein: Trotzdem die Signatur des finalen Artefakts prüfen; ein Linux-Upload allein genügt nicht als Nachweis.
Das finale Format benötigt Ticket-Verknüpfung oder macOS-spezifische Validierung.
Wenn ja: Einen Mac als letzte Veröffentlichungsstation einplanen. Wenn nein: API-basierte Einreichung kann weiter entkoppelt werden, aber die Formatannahme muss dokumentiert sein.

2. Auswahl des Einreichungswegs

Das Artefakt liegt bereits auf dem signierenden Remote Mac und soll dort weiterverarbeitet werden.
Dann: notarytool zuerst bewerten, weil der Ablauf nahe an Signatur und lokaler Prüfung bleibt.
Ein Linux-Orchestrator soll Einreichung, Statusabfrage und Protokolle zentral verwalten.
Dann: Die Notary API bewerten und Submission-ID sowie Fehlerprotokoll als dauerhafte Pipeline-Ausgaben definieren.
Das Team benötigt beide Wege für unterschiedliche Produkte.
Dann: Pro Produkt einen verbindlichen Weg festlegen; nicht ohne Grund zwischen notarytool und API wechseln.

3. Auswahl des Betriebsmodells

Es gibt häufige Releases und einen dauerhaft benötigten Signaturkontext.
Dann: Dedizierten oder klar reservierten Remote Mac einsetzen.
Releases sind selten, aber Build, Signatur und Abschlussprüfung müssen real auf macOS getestet werden.
Dann: Bedarfsgesteuerten Mac-Knoten verwenden und ihn vor dem Release vollständig abnehmen.
Mehrere Teams sollen denselben Mac nutzen.
Dann: Nur mit Queue-Isolation, getrennter Schlüsselbundverwaltung, Bereinigung, Protokollierung und Neustarttest fortfahren. Fehlt eine dieser Kontrollen, auf einen dedizierten Knoten zurückfallen.
Die Pipeline benötigt ausschließlich Einreichung und Statusabfrage für bereits geprüfte Artefakte.
Dann: Linux-zentrierte Orchestrierung kann ausreichen; sie darf aber nicht als vollständiger Ersatz für macOS-Build und -Release dokumentiert werden.

Aus dieser Checkliste entstehen drei belastbare Zielbilder:

Nur Remote Mac: sinnvoll, wenn Build, Signatur, Packaging und Prüfung eng gekoppelt sind.
Hybrid-CI: meist die ausgewogene Variante: Linux orchestriert, der Remote Mac erledigt die macOS-spezifische Lieferkette.
Bedarfsgesteuerter Mac-Knoten: geeignet, wenn Releases selten sind, die Ausführungsumgebung aber trotzdem real getestet und reproduzierbar bleiben muss.

Fünf Schritte für einen belastbaren Probelauf

Artefaktvertrag festlegen: Definieren Sie Eingangsformat, Ausgangsformat, Prüfsumme, Build-ID und erlaubte Übergaben zwischen Linux und Mac.
Minimalen Mac-Job erstellen: Lassen Sie zunächst ein bekanntes Testartefakt signieren und lokal validieren. Geheimnisse und Identitäten bleiben in der Dokumentation durch Platzhalter ersetzt.
Einreichungsweg auswählen: Testen Sie entweder notarytool auf dem Mac oder die Notary API vom Linux-Orchestrator. Speichern Sie Submission-ID, Status und Protokoll getrennt.
Finales Auslieferungsobjekt prüfen: Führen Sie Ticket-Verknüpfung und Endvalidierung am tatsächlichen Distributionsfile aus, nicht am Zwischenarchiv.
Fehler und Neustart erzwingen: Unterbrechen Sie das Netzwerk, starten Sie den Runner neu und wiederholen Sie einen bereits eingereichten Lauf. Die Pipeline muss zwischen Wiederaufnahme, neuem Lauf und endgültiger Ablehnung unterscheiden.
Berechtigungen dokumentieren: Prüfen Sie Ausführungskonto, Schlüsselbundzugriff, Log-Inhalte, temporäre Dateien und Löschverhalten unter DSGVO-Gesichtspunkten.
Produktionsentscheidung treffen: Erst wenn die vollständige Kette wiederholbar durchläuft, entscheiden Sie über Mietdauer, Knotenanzahl und gemeinsame Nutzung.

Linux allein, eigener Mac oder Remote Mac

Ein Linux-CI-System ist als Orchestrator attraktiv: Es kann bestehende Jobs, Artefaktspeicher und Berechtigungsmodelle weiterverwenden. Als alleiniger Produktionsknoten stößt es jedoch an Grenzen, sobald Xcode, Developer-ID-Signatur, macOS-Packaging, stapler oder lokale Endprüfung benötigt werden. Die typische Schwäche ist nicht die Netzwerkverbindung zum Notarisierungsdienst, sondern die fehlende macOS-Ausführungsumgebung.

Ein eigener Mac bietet die höchste physische Kontrolle, verursacht aber Anschaffung, Wartung, Betriebssystempflege, Ausfallplanung und die sichere Verwaltung von Signaturmaterial. Für Teams mit seltenen Releases kann ein dauerhaft bereitgehaltener Rechner dadurch unnötig gebunden sein.

Ein Remote Mac vermeidet diese Hardwarebindung, bringt aber eigene Prüfpflichten mit: Zugriffsschutz, Stabilität der Verbindung, Datenstandort, Wiederanlauf, Schlüsselbundisolation und die Frage, ob ein geteiltes System zulässig ist. Gerade bei kurzen Releasefenstern ist ein vorher getesteter, reservierter Knoten oft sinnvoller als ein spontan eingerichteter Runner. Für regionale Anforderungen können Sie beispielsweise die deutschen Remote-Mac-Optionen prüfen und anschließend mit einem realen Testartefakt abnehmen.

Für das eigentliche Ziel — eine reproduzierbare macOS-Veröffentlichung — ist die Mischform häufig die sauberste Grenze: Linux bleibt der zentrale Planer, während ein echter Mac alle Schritte übernimmt, bei denen Apple-Werkzeuge, Schlüsselbund oder lokale Validierung maßgeblich sind.

Wenn die aktuelle Lösung ausschließlich auf Linux basiert, bleiben mindestens drei reale Nachteile: Signatur- und Packaging-Schritte werden künstlich ausgelagert, Ticket-Verknüpfung und Endprüfung können auseinanderfallen, und Fehler zwischen Dienststatus und tatsächlich ausgelieferter Datei sind schwerer einzugrenzen. Ein eigener Mac beseitigt diese Lücke, bindet aber Kapital und Wartungszeit. Für einen kontrollierten Probelauf oder ein Release-Team ohne dauerhaft benötigte Hardware ist es deshalb vernünftig, zunächst einen isolierten Remote Mac von VNCMac zu mieten, die vollständige Pipeline mit echten Artefakten zu prüfen und erst danach über einen langfristigen Mietzeitraum oder einen eigenen Rechner zu entscheiden.

FAQ (Häufige Fragen)

Das reine Einreichen und Abfragen eines Artefakts kann über die Apple Notary API auch von einem nicht-macOS-Controller aus geplant werden. Damit ist jedoch nicht automatisch die gesamte Veröffentlichung abgedeckt: Erstellung, Developer-ID-Signatur, Ticket-Verknüpfung mit stapler und die lokale Endprüfung müssen separat bewertet werden. Für eine reproduzierbare Release-Kette bleibt ein echter Mac meist die verlässlichere Abschlussstation.

notarytool passt besonders gut, wenn bereits ein abgesicherter Mac-Knoten vorhanden ist und das Team den offiziellen Kommandozeilenablauf mit Wartefunktion, Protokollabruf und lokaler Fehlerbehandlung nutzen möchte. Die Apple Notary API ist interessanter, wenn ein Linux-Orchestrator Einreichungen und Statusabfragen zentral steuern soll. Die Wahl sollte sich an Geheimnisverwaltung, Wiederholbarkeit und dem anschließenden Mac-Schritt orientieren.

Die Antwort hängt vom Artefakt und vom gewünschten Release ab. Xcode-basierte Erstellung, macOS-spezifisches Packaging, Developer-ID-Signatur, die Prüfung der lokalen Codesignatur und das Verknüpfen eines Tickets mit bestimmten Auslieferungsformaten benötigen typischerweise macOS-Werkzeuge. Die Kommunikation mit dem Notarisierungsdienst kann dagegen über notarytool oder die Notary API erfolgen. Jede Stufe sollte einzeln abgenommen werden.

Der Remote Mac wird als isolierter Ausführungsknoten mit klar definiertem Eingangs- und Ausgangsartefakt registriert. Der Linux-CI-Knoten erstellt oder koordiniert den Build, übergibt ein unveränderliches Paket und startet auf dem Mac die Signatur-, Einreichungs- und Validierungsschritte. Zertifikate, Schlüsselbundzugriff, temporäre Dateien und Protokolle müssen getrennt verwaltet werden. Nach Neustart und Wiederholung ist der Knoten erst produktionsreif.

Weiterführende Artikel