macOS-App-Notarisierung lässt sich in Remote-Mac-CI integrieren: Bereiten Sie zuerst eine korrekt mit Developer ID signierte Anwendung und das vorgesehene Verteilungspaket vor, reichen Sie es mit notarytool ein und prüfen Sie Ergebnis, Ticket und endgültiges Paket getrennt. Das gilt für die Verteilung außerhalb des Mac App Store; eine erfolgreiche Einreichung allein bestätigt noch nicht, dass die ausgelieferte Anwendung vollständig geprüft ist.

Dieser Leitfaden richtet sich an unabhängige macOS-Entwickler, die eine reproduzierbare Veröffentlichung statt manueller Notarisierung benötigen.
Er unterstützt Build-Verantwortliche beim Trennen von Archive, Export und Lieferartefakt.
DevOps-Teams erhalten einen Ablauf für beschränkte Zugangsdaten, nachvollziehbare Protokolle und eine belastbare Freigabeentscheidung.

Ablauf: Eingabe und Signierung vorbereiten, Zugangsdaten sicher bereitstellen, Einreichung ausführen, Ergebnis prüfen, gegebenenfalls ein Ticket anheften und die Auslieferung testen.
Aktion für diese Woche: Lassen Sie einen isolierten Release-Auftrag ein Testartefakt durch die gesamte Kette führen und sichern Sie dabei die Verbindung zwischen Quellstand, Einreichung und ausgelieferter Datei.

01

Verteilungsweg und Eingabe vor dem CI-Auftrag festlegen

Die Notarisierung ist ein Teil der Developer-ID-Verteilung und keine App-Review. Sie sollte daher nicht mit einem Upload in den Mac App Store vermischt werden: Der Release-Auftrag muss ausdrücklich festlegen, welche außerhalb des Stores verteilte Anwendung geprüft und welches Paket anschließend ausgeliefert wird. Apples Anleitung zur Notarisierung von macOS-Software vor der Verteilung beschreibt diesen Verteilungszweck. Die Dokumentation zur signierten Mac-Distribution erläutert die getrennte Signierungsstufe.

Vor dem Einrichten eines Remote-Mac-Auftrags sollten Verantwortliche drei Dinge klären:

  • Was ist die Eingabe? Ein Xcode-Archive, eine exportierte Anwendung und ein fertiges Installations- oder Downloadpaket sind unterschiedliche Zustände. Die Notarisierungsstufe muss ein definiertes Artefakt erhalten, nicht irgendeine Datei aus einem Build-Verzeichnis.
  • Was ist das Lieferartefakt? Legen Sie fest, ob Nutzer eine App, ein komprimiertes Archiv, ein Disk-Image oder ein Installationspaket erhalten. Davon hängt ab, welche Ticketverarbeitung und welche abschließende Prüfung sinnvoll sind. Apple beschreibt die Paketierung in der Dokumentation zur Verteilung von Mac-Software.
  • Wie wird die Herkunft belegt? Verknüpfen Sie den Quellstand mit dem erzeugten Artefakt und den späteren Notarisierungsdaten. Ein Dateiname allein ist keine belastbare Zuordnung: Ein neu gepacktes oder ersetztes Objekt kann unter demselben Namen erscheinen.

Die Voraussetzungen für Developer-ID-Code-Signierung, Hardened Runtime, Zeitstempel und eingebettete Komponenten sind vor dem Upload zu prüfen. Verwenden Sie dafür die Vorgaben der Apple-Dokumentation zur Notarisierung und Signierung, statt pauschale Einstellungen aus einem anderen Projekt zu übernehmen. Welche Identität, Entitlements und Exportoptionen passen, hängt von der Anwendung und ihrem tatsächlichen Inhalt ab.

Der technische Ablauf sollte die Zwischenstände kenntlich machen: Archive, Export und finales Verteilungspaket werden mit getrennten Pfaden oder eindeutigen Artefaktkennungen abgelegt. Sichern Sie zu jeder Stufe die relevanten Build-Protokolle und das Ergebnis der Signaturprüfung. So lässt sich später feststellen, ob ein Fehler bereits vor der Notarisierung bestand oder erst beim Verpacken für die Auslieferung entstand.

02

Zugangsdaten begrenzt bereitstellen und notarytool anbinden

Auf dem Remote-Mac muss die gewählte Xcode- oder Command-Line-Tools-Installation notarytool für den CI-Auftrag bereitstellen. Prüfen Sie das in einem isolierten Lauf, bevor Sie den Schritt in einen Produktions-Release übernehmen. Apples Hinweise zur Anpassung des Notarisierungsworkflows behandeln die skriptgesteuerte Einreichung. Für aktuelle Vorgaben zum Werkzeugwechsel ist außerdem Apples Migrationshinweis zur Notarisierung maßgeblich.

Ein dokumentierter Kompatibilitätsrand ist besonders wichtig: Seit dem 01.11.2023 akzeptiert Apple keine Notarisierungs-Uploads mehr, die mit altool oder Xcode 13 und älteren Xcode-Versionen eingereicht werden. Prüfen Sie diese Grenze anhand des Apple-Migrationsdokuments, statt einen alten Schritt lediglich auf einen anderen CI-Knoten zu verschieben. Der praktische Schluss ist eindeutig: Ein Release-Auftrag muss notarytool verwenden und die Werkzeugverfügbarkeit auf dem tatsächlich eingesetzten Mac nachweisen.

Zugangsdaten und Schlüsselmaterial gehören nicht in den Quellcode, in dauerhaft gespeicherte Build-Ausgaben oder in einen Befehl, dessen Shell-Verlauf mitgesichert wird. Trennen Sie zwei Verantwortlichkeiten:

  • Keychain-Profil: Es ermöglicht notarytool, einen eingerichteten Zugang für die Notarisierungsoperation zu verwenden.
  • CI-Geheimnisverwaltung: Sie bestimmt, welcher Auftrag Zugangsdaten beziehen darf, wie sie dem Lauf bereitgestellt werden und wer Rotation oder Sperrung veranlasst.

Apple beschreibt die unterstützten Authentifizierungswege und die Einrichtung des Werkzeugs in der Dokumentation zum benutzerdefinierten Notarisierungsworkflow. Richten Sie die gewählte Methode nach diesen Vorgaben ein. Der Beispielaufruf zeigt nur die Übergabe eines bereits eingerichteten Profils; er enthält keine Kontodaten:

xcrun notarytool submit "$ARTIFACT_PATH" \
  --keychain-profile "$NOTARY_PROFILE" \
  --wait

ARTIFACT_PATH und NOTARY_PROFILE sind Platzhalter. Setzen Sie dort keine Zugangsdaten ein und geben Sie keine Geheimnisse über die Shell-Befehlszeile aus. Sichern Sie stattdessen die CI-Ausgabe so, dass sie den Auftragsverlauf dokumentiert, sensible Werte aber maskiert oder gar nicht protokolliert. Die konkrete Authentifizierung und die verfügbaren Optionen müssen gegen Apples aktuelle notarytool-Dokumentation geprüft werden; dieses Beispiel ist kein Ersatz für die Einrichtung.

Für die Übergabe in der CI bietet sich ein enger Auftragsschnitt an: Der Signierungsauftrag stellt das freigegebene Artefakt bereit, der Notarisierungsauftrag erhält nur die dafür erforderliche Berechtigung, und die Veröffentlichungsstufe verwendet ausschließlich das nachfolgend geprüfte Ergebnis. Dadurch bleiben Diagnose und Wiederherstellung verständlicher, als wenn Build, Zugangsdaten und Veröffentlichungsfreigabe in einem ungeteilten Shell-Skript vermischt werden.

03

Einreichung anhand von Kennung, Status und Protokoll prüfen

Ein erfolgreicher Start von notarytool submit belegt zunächst nur, dass der Auftrag angestoßen wurde. Speichern Sie die von der Einreichung zurückgegebene Kennung zusammen mit dem CI-Lauf und dem Artefaktbezug. Prüfen Sie anschließend den abgeschlossenen Bearbeitungsstatus; wenn der Lauf nicht auf das Ende wartet, fragen Sie den Auftrag mit seiner Kennung gezielt ab. Die genaue Verwendung von submit, info und log ist in Apples Dokumentation zum benutzerdefinierten Workflow beschrieben.

Ein mögliches Muster für einen Folgeauftrag lautet:

xcrun notarytool info "$SUBMISSION_ID" \
  --keychain-profile "$NOTARY_PROFILE"

Bei Ablehnung oder Warnungen sollte der Ablauf das zugehörige Protokoll abrufen und mit dem Release-Lauf ablegen, statt nur eine gekürzte Fehlermeldung in der CI-Oberfläche anzuzeigen:

xcrun notarytool log "$SUBMISSION_ID" \
  --keychain-profile "$NOTARY_PROFILE" \
  "$NOTARY_LOG_PATH"

Verwenden Sie diese Aufrufe nur mit den in der aktuellen Apple-Dokumentation bestätigten Optionen. Die Werte in Anführungszeichen sind Platzhalter für die Kennung, das eingerichtete Profil und einen geschützten Ausgabeort. Das Protokoll soll für die Fehleranalyse zugänglich sein, ohne vertrauliche Inhalte unnötig offenzulegen.

Ordnen Sie die Diagnose nach dem vorliegenden Beleg:

  • Signierung: Prüfen Sie Signatur, Zeitstempel, Laufzeitvorgaben und eingebettete Komponenten. Eine Ablehnung ist nicht automatisch ein Beleg für einen defekten Remote-Mac.
  • Berechtigungen und Paketinhalt: Vergleichen Sie den tatsächlich eingereichten Inhalt mit dem vorgesehenen Export. Stimmen Berechtigungen oder enthaltene Komponenten nicht, sollte die Ursache am Artefakt und an dessen Erstellung untersucht werden.
  • Format und Verpackung: Prüfen Sie, ob die eingereichte Datei der von Apple unterstützten Form und dem vorgesehenen Verteilungsweg entspricht. Die Apple-Dokumentation zur Paketierung hilft, Formatfragen von Signierungsfehlern zu trennen.
  • Dienstantwort oder Verbindungsproblem: Bewahren Sie die konkrete Antwort und die Auftragskennung auf. Erst wenn diese Belege auf ein Problem bei der Erreichbarkeit oder Dienstantwort hindeuten, ist eine Netz- oder Plattformprüfung der passende nächste Schritt.

Apple führt häufige Ursachen und Abhilfen in der Dokumentation zur Fehlerbehebung bei der Notarisierung auf. Nutzen Sie diese Zuordnung, bevor Sie Zugangsdaten austauschen, den Knoten neu aufsetzen oder denselben Upload wiederholt starten. Ein erneuter Versuch ist nur dann aussagekräftig, wenn klar ist, welche Eingabe geändert wurde und welcher Fehler damit geprüft werden soll.

04

Häufige Fragen zu Status, Zugangsdaten und Ticket

Wie wird die macOS-App-Notarisierung in Remote-Mac-CI zu einem reproduzierbaren Schritt?
Trennen Sie signierte Eingabe, Einreichung, Ergebnisprüfung und Paketfreigabe als nachvollziehbare Stationen. So wird ein Upload-Erfolg nicht mit einer vollständigen Veröffentlichung verwechselt. Die folgende Ticketverarbeitung hängt vom Lieferformat ab; ein Auftrag für den Mac App Store gehört nicht in denselben Ablauf.

Welche Belege werden nach einer erfolgreichen notarytool-Einreichung gespeichert?
Mindestens die Auftragskennung, der abgeschlossene Status und die Zuordnung zum eingereichten Artefakt. Bei Warnung oder Ablehnung gehört das zugehörige Protokoll dazu. Erst diese Belege erlauben, zwischen einem Problem in der Anwendung, beim Paketformat und einer Antwort des Dienstes zu unterscheiden.

Wie bleiben Zugangsdaten beim Einsatz eines Remote-Mac geschützt?
Die Zugangsdaten werden kontrolliert durch die Geheimnisverwaltung des CI-Auftrags bereitgestellt und nicht in Repository, Kommandozeilenverlauf oder Build-Protokoll geschrieben. Ein Keychain-Profil unterstützt die Werkzeugnutzung, ersetzt aber weder eine Zugriffsbeschränkung noch einen dokumentierten Prozess für Rotation und Entzug.

Wann ist das Anheften eines Tickets erforderlich?
Entscheidend sind das konkrete Verteilungsartefakt und Apples dafür geltende Formatregeln. Prüfen Sie in der offiziellen Dokumentation, ob für die verwendete App, das Disk-Image oder das Installationspaket ein Stapling-Schritt vorgesehen ist. Validieren Sie anschließend die verarbeitete Datei und testen Sie das tatsächlich bereitgestellte Paket.

05

Ticket und Signatur am endgültigen Verteilungspaket kontrollieren

Ein bearbeiteter Notarisierungsauftrag, ein verfügbares Ticket, eine gültige Signatur und ein funktionierendes Downloadpaket sind unterschiedliche Prüfpunkte. Ein Release-Auftrag sollte sie nicht zu einem einzigen Erfolgssignal zusammenfassen. Erstellen Sie zunächst die Notarisierungsausgabe, prüfen Sie den Status und entscheiden Sie dann anhand des tatsächlichen Lieferformats, ob das Ticket an das Verteilungsobjekt angeheftet werden muss.

Apple dokumentiert Notarisierung, Stapling und Validierung in seiner Anleitung zur Notarisierung von Software. Ein möglicher Aufruf zum Anheften und anschließenden Validieren sieht beispielsweise so aus:

xcrun stapler staple "$DISTRIBUTION_ITEM"
xcrun stapler validate "$DISTRIBUTION_ITEM"

DISTRIBUTION_ITEM ist hier ein Platzhalter für ein Objekt, das nach Apples Vorgaben unterstützt wird. Wenden Sie die Befehle nicht ungeprüft auf beliebige Container an: Welches Objekt verarbeitet wird und welcher Ablauf passt, richtet sich nach Format und Verteilung. Die unterstützten Formate und konkreten Optionen sind unmittelbar vor der Übernahme in die CI anhand der Apple-Anleitung zu verifizieren.

Danach folgen getrennte Abnahmen:

  1. Signatur: Prüfen Sie das exportierte Objekt und seine eingebetteten Komponenten gegen die erwartete Developer-ID-Signierung.
  2. Ticket: Validieren Sie das angeheftete Objekt, sofern Stapling für dieses Format vorgesehen ist.
  3. Paketidentität: Vergleichen Sie das getestete und das veröffentlichte Artefakt, damit nicht versehentlich eine andere Datei hochgeladen wird.
  4. Nutzerpfad: Laden Sie das endgültige Paket in einer kontrollierten Testumgebung herunter und prüfen Sie Installation oder Start. So wird auch Verpackung und Transport in die Abnahme einbezogen.

Diese Prüfpunkte beantworten unterschiedliche Fragen. Eine valide Signatur ersetzt nicht die Kontrolle des Tickets; ein erfolgreiches Stapling beweist nicht, dass der Download die geprüfte Datei enthält. Der Test des Nutzerpfads ist deshalb besonders wichtig, wenn der CI-Auftrag nach der Notarisierung noch kopiert, umbenennt, komprimiert oder anderweitig paketiert.

06

Veröffentlichung anhand überprüfbarer Bedingungen freigeben

Vor der Automatisierung einer echten Veröffentlichung sollte ein isolierter Release-Auftrag die Kette von der signierten Anwendung bis zum finalen Paket durchlaufen. Er muss nachvollziehbar zeigen, welches Artefakt eingereicht wurde, welche Einreichungskennung dazu gehört, welches Ergebnis zurückkam und welches Objekt anschließend geprüft wurde. Ist eine dieser Zuordnungen nicht rekonstruierbar, bleibt die Veröffentlichung zunächst unter manueller Kontrolle.

Entscheidungswerkzeug: Wählen Sie den Freigabemodus anhand der Prüfergebnisse. Gehen Sie die Punkte in Reihenfolge durch; sobald eine Bedingung für „Pausieren“ zutrifft, wird nicht veröffentlicht.

  • [ ] Automatisch freigeben: Quellstand, signiertes Artefakt, Einreichungskennung und finales Paket sind eindeutig miteinander verknüpft. Signatur- und Notarisierungsprüfung sind erfolgreich; ein erforderliches Ticket wurde validiert. Wenn zusätzlich die Veröffentlichungs- und Wiederherstellungsverantwortung dokumentiert ist, kann die CI den Release automatisch veröffentlichen.
  • [ ] Manuell bestätigen: Die technischen Prüfungen sind erfolgreich und das Artefakt ist nachvollziehbar, aber die Freigabe- oder Wiederherstellungsverantwortung ist noch nicht ausreichend dokumentiert. In diesem Fall darf die CI vorbereiten und prüfen; eine zuständige Person bestätigt den letzten Veröffentlichungsschritt.
  • [ ] Veröffentlichung pausieren: Signatur, Notarisierungsergebnis oder Ticketprüfung ist fehlgeschlagen, nicht abgeschlossen oder passt nicht zum auszuliefernden Artefakt. Pausieren Sie ebenfalls, wenn Protokolle die Einreichung nicht mit dem Quellstand verbinden. Untersuchen Sie die Ursache und dokumentieren Sie die Korrektur, bevor ein neuer Versuch gestartet wird.
  • [ ] Erst die Nachvollziehbarkeit reparieren: Der Auftrag erzeugt keine belastbaren Protokolle oder kann das geprüfte Artefakt nicht eindeutig identifizieren. Zusätzliche Wiederholungen lösen dieses Problem nicht. Korrigieren Sie zuerst Protokollierung und Artefaktverknüpfung; danach wird ein neuer isolierter Testlauf aussagekräftig.

Ergänzen Sie den Betrieb um klare Zuständigkeiten: Wer rotiert Zugangsdaten, wer untersucht eine fehlgeschlagene Einreichung und wer gibt einen Release nach einer Korrektur erneut frei? Definieren Sie außerdem, welche Protokolle für die Diagnose aufbewahrt werden und wie der Zugriff begrenzt ist. Diese Festlegungen verhindern, dass ein erfolgreicher technischer Lauf ohne verantwortliche Freigabe zur Veröffentlichung führt.

Für Teams, die zunächst die Xcode-Build-Stufe auf einem Remote-Mac etablieren müssen, ist die NodeMini-Übersicht zu Remote-Mac-Umgebungen ein passender nächster Orientierungspunkt.

Ein eigener CI-Mac kann sinnvoll sein, wenn dauerhaft ein kontrollierter Knoten samt Wartung, Zugriffsschutz und Wiederherstellungsverantwortung verfügbar ist. Fehlt dieser Rechner oder wird die Umgebung zunächst für einen begrenzten Veröffentlichungsversuch benötigt, kann eine gemietete Mac-Umgebung den Test ermöglichen, ohne sofort ein Gerät anzuschaffen. Sie ersetzt jedoch keine Prüfung von Xcode-Verfügbarkeit, Signierungsrechten, Geheimnisverwaltung und Pipeline-Kontrolle. Wer diese Voraussetzungen vergleichen möchte, kann die NodeMini-Informationen zur Mac-Miete heranziehen und anhand einer echten Release-Aufgabe prüfen, ob die Umgebung zum eigenen Ablauf passt.