Für die Xcode-Notarisierung benötigen Sie nicht zwingend einen Mac, wenn es ausschließlich um die Einreichung bei Apples Notarisierungsdienst und die Abfrage des Bearbeitungsstands geht: Dafür kann die Notary API die macOS-Abhängigkeit aufheben. Für Build, Signierung, Ticket-Anheftung und eine verlässliche Abnahme bleibt ein passender macOS-Arbeitsplatz jedoch häufig Teil der Veröffentlichungskette. Wenn Sie bereits mit Xcode auf dem Mac veröffentlichen, behalten Sie zunächst notarytool bei und wechseln Sie nur dann zur API, wenn Ihre Pipeline die Einreichung ausdrücklich plattformübergreifend ausführen muss.
Dieser Beitrag richtet sich an Sie, wenn Sie macOS-Apps außerhalb des Mac App Store verteilen und dafür eine Notarisierung einplanen.
Er hilft Ihnen, eine Windows- oder Linux-Pipeline von einer vollständigen Mac-Veröffentlichungsumgebung abzugrenzen.
Auch für kleine Teams, die Signierungszugänge und die finale Abnahme verantworten, ist diese Unterscheidung entscheidend.
Diese Woche: Ordnen Sie Ihre bestehenden Schritte den Stationen Build, Signierung, Einreichung, Ergebnisprüfung, Ticket-Anheftung und Abnahme zu. Markieren Sie nur die Einreichung und die Statusabfrage als mögliche Kandidaten für einen plattformneutralen Ablauf; prüfen Sie die übrigen Schritte mit dem tatsächlich auszuliefernden Paket.
SECTION 01 Welcher Weg passt zu Ihrer aktuellen Veröffentlichungsumgebung?
Die Wahl hängt weniger davon ab, ob eine Notary API verfügbar ist, als davon, welche Arbeit Ihre Pipeline bereits erledigt und wo sie ausgeführt wird. Die API ist eine Schnittstelle zur Interaktion mit dem Notarisierungsdienst, kein Ersatz für Xcode, eine macOS-Buildumgebung oder jedes Werkzeug nach der Freigabe.
| Ihre Ausgangslage | Naheliegender Weg | Was dadurch nicht automatisch erledigt ist |
|---|---|---|
| Xcode erstellt und signiert das Programm auf einem Mac | notarytool in den vorhandenen Ablauf aufnehmen | Ticket-Anheftung und Prüfung des ausgelieferten Pakets bleiben eigene Abnahmepunkte |
| Windows- oder Linux-System soll nur ein bereits vorbereitetes Programm einreichen und den Status prüfen | Notary API erwägen | Erstellung und Signierung des Programms werden dadurch nicht bereitgestellt |
| Externes Build-System erzeugt das Artefakt; der Release-Ablauf soll die Kommunikation mit Apples Dienst integrieren | notarytool und Notary API anhand der vorhandenen Laufzeit vergleichen | Sie müssen Upload, Statusbehandlung, Logs, Zugangsdaten und spätere macOS-Schritte weiterhin verantworten |
Apple dokumentiert sowohl notarytool als auch die Notary API als Wege, mit dem Notarisierungsdienst zu kommunizieren. Die API ist laut Apples Beschreibung gerade dafür vorgesehen, die Interaktion mit dem Dienst ohne macOS auszuführen. Daraus folgt aber nicht, dass ein beliebiges Windows- oder Linux-System Xcode ausführen oder ein fertiges Programm automatisch korrekt signieren kann. Die Apple-Dokumentation zur Notary API beschreibt den Dienstzugriff; für die Vorbereitung und Verteilung eines Programms gelten daneben die Anforderungen aus Apples Dokumentation zur App-Verteilung.
Kann die Notary API notarytool vollständig ersetzen?
Sie kann den Dienstkontakt für bestimmte Abläufe ersetzen, etwa wenn Ihre Pipeline Einreichung, Statusabfrage und den Abruf der zugehörigen Informationen selbst über die API abwickelt. Das bedeutet nicht, dass die API dieselbe Bedienoberfläche wie das Kommandozeilenwerkzeug bereitstellt oder alle nachgelagerten Aufgaben erledigt. Wenn Ihr Team bereits einen funktionierenden Xcode- und macOS-Ablauf mit notarytool hat, rechtfertigt ein Wechsel allein durch die Existenz der API meist nicht die zusätzliche Integrations- und Wartungsarbeit.
Für bestehende Xcode-Veröffentlichungen: Warum notarytool oft genügt
Wenn Sie Xcode und macOS bereits für Build und Signierung verwenden, ist notarytool meist der kleinere Eingriff. Sie behalten die vorhandene Umgebung und ergänzen den Notarisierungsschritt im selben Ablauf, statt zusätzlich eine eigene HTTP-Integration, Fehlerbehandlung und Auswertung der API-Antworten zu pflegen. Apple beschreibt notarytool als Werkzeug für die Interaktion mit dem Notarisierungsdienst; es gehört zum Werkzeugumfeld, das mit den Xcode Command Line Tools bereitgestellt wird. Die Apple-Anleitung zu den Command Line Tools erläutert deren Installation und Einordnung.
Die entscheidende Einschränkung ist der Ausführungsort: Wenn der Job notarytool aufruft, muss die entsprechende Apple-Werkzeugumgebung verfügbar sein. Daher sollten Sie nicht voraussetzen, dass Sie das macOS-Kommandozeilenwerkzeug einfach auf einem Linux- oder Windows-Runner ausführen können. Kann notarytool unter Windows oder Linux laufen? Planen Sie den direkten Aufruf als macOS-Schritt ein; wenn Ihr nicht-macOS-System selbst mit dem Notarisierungsdienst sprechen soll, prüfen Sie die Notary API statt den Werkzeugaufruf auf eine nicht vorgesehene Umgebung zu übertragen.
Für ein vorhandenes Xcode-Projekt zählt außerdem, ob die API einen konkreten Engpass beseitigt. Müssen Sie nur ein Programm notarisieren, das ohnehin auf einem Mac gebaut und signiert wird, kann ein Wechsel die Zuständigkeiten zerlegen: Ein System erzeugt das Artefakt, ein anderes reicht es ein, und ein weiterer Schritt muss Ergebnisse und Logs wieder dem Build zuordnen. Das kann sinnvoll sein, wenn Ihre Infrastruktur einen plattformneutralen Release-Dienst verlangt. Ohne diesen Bedarf entsteht jedoch eine zusätzliche Schnittstelle, die Sie bei Änderungen an Authentifizierung, Upload oder Fehlerauswertung beobachten müssen.
SECTION 02 Was ändert sich, wenn Windows oder Linux die Pipeline steuert?
Für ein Team, dessen zentrale CI/CD-Steuerung auf Windows oder Linux läuft, ist die Notary API eine echte Möglichkeit, den Kontakt zum Notarisierungsdienst von einem Mac zu entkoppeln. Apple beschreibt einen Web-Ablauf, in dem die Software eingereicht und anschließend der Status abgefragt werden kann. Die Anleitung zur Einreichung über das Web ist die maßgebliche Grundlage für diese Aufgaben. Sie sollten daraus aber nur die Fähigkeit zur Kommunikation mit dem Dienst ableiten, nicht eine plattformübergreifende Xcode-Toolchain.
| Aufgabe in der Veröffentlichung | Ohne Mac möglich? | Worauf Sie die Entscheidung stützen sollten |
|---|---|---|
| Build einer macOS-App mit Xcode | Nicht durch die Notary API ermöglicht | Prüfen Sie, wo Xcode tatsächlich ausgeführt wird und wie das signierte Artefakt entsteht |
| Signierung für die Verteilung | Nicht durch die Notary API ersetzt | Verifizieren Sie, dass Signatur und Verteilungskonfiguration zum konkreten Paket passen |
| Einreichung und Statusabfrage | Ja, über die Notary API | Planen Sie API-Authentifizierung, Upload-Ablauf, Wiederholungen und Ergebniszuordnung |
| Lesen der Notarisierungsprotokolle | Über den API-Ablauf integrierbar | Legen Sie fest, wie Logs gesichert und Fehler dem Build zugeordnet werden |
| Ticket-Anheftung und Endabnahme | Nicht als automatisch erledigt annehmen | Prüfen Sie die erforderlichen macOS-Werkzeuge und testen Sie das konkrete Lieferartefakt |
Ein API-Aufruf macht die Pipeline also nicht zu einer vollständigen macOS-Veröffentlichungsumgebung. Build und Signierung müssen weiterhin dort stattfinden, wo Ihre Werkzeuge und Ihre verantwortete Signierung eingerichtet sind. Ebenso darf ein erfolgreicher Einreichungsaufruf nicht als Nachweis gelten, dass das Ergebnis bereits für die Auslieferung geprüft und vorbereitet ist. Trennen Sie in Ihren Build-Ergebnissen den Zustand „an den Dienst übermittelt“ von „Notarisierung abgeschlossen“ und von „auszulieferndes Paket abgenommen“.
Für externe Build-Systeme: Nur den austauschbaren Abschnitt auslagern
Wenn ein externes Build-System ein macOS-Programm produziert, entscheiden Sie zunächst, welche Teile dieses Systems tatsächlich macOS voraussetzen. Danach vergleichen Sie nicht „Mac gegen API“, sondern zwei Wege für die Kommunikation mit dem Notarisierungsdienst: notarytool in einer macOS-Umgebung oder eine eigene Integration der Notary API in den bestehenden Pipeline-Dienst.
| Vergleichspunkt | notarytool | Notary API |
|---|---|---|
| Einbindung | Kommandozeilenwerkzeug in einer passenden Apple-Werkzeugumgebung | Direkte Integration der Dienstaufrufe in die eigene Pipeline |
| Plattformabhängigkeit des Dienstkontakts | an die macOS-Werkzeugumgebung gebunden | Dienstinteraktion kann ohne macOS erfolgen |
| Verantwortlichkeit für Antworten und Fehler | Der Aufruf bleibt in einem Werkzeugablauf; die Pipeline muss Ergebnisse dennoch auswerten | Das Team implementiert und betreibt die Antwort-, Status- und Fehlerbehandlung selbst |
| Zugangsdaten | Zugangsdaten müssen geschützt und dem Auftrag zugeordnet werden | API-Schlüssel, JWT-Erzeugung und kurzlebige Upload-Zugangsdaten müssen sicher behandelt werden |
| Nachgelagerte macOS-Arbeit | Bleibt erforderlich, sofern Ihre Abnahme sie voraussetzt | Wird nicht durch die API übernommen |
Die API lohnt sich eher, wenn Ihre vorhandene Pipeline ohnehin direkte Dienstintegrationen betreibt, die Plattform des ausführenden Runners bewusst unabhängig von macOS bleiben soll und Ihr Team die dafür nötige Betriebsverantwortung übernehmen kann. notarytool ist meist passender, wenn Ihr Release-Schritt bereits auf dem Mac liegt und die Umstellung keine messbare Vereinfachung bringt.
Wann ist bei einem bestehenden Xcode-Build der Wechsel zur Notary API sinnvoll?
Dann, wenn Sie einen klaren technischen Grund haben: etwa wenn ein zentraler Windows- oder Linux-Runner den Notarisierungsdienst ansprechen soll, ohne dafür einen macOS-Runner für diesen Teil bereitzustellen. Bleiben Build, Signierung und weitere Veröffentlichungsschritte ohnehin auf dem Mac, ist es häufig einfacher, die Interaktion mit notarytool in diesem Ablauf zu belassen und API-Code nur dann einzuführen, wenn eine konkrete Systemanforderung es verlangt.
SECTION 03 Wie prüfen Sie Zugangsdaten, Ergebnis und ausgeliefertes Paket?
Die API-Variante verlagert Arbeit: Sie beseitigt die Abhängigkeit vom Mac für den Dienstkontakt, überträgt dem Team aber mehr Verantwortung für Authentifizierung, Transport und Auswertung. Apple beschreibt im Web-Ablauf die Verwendung eines JWT und temporärer Upload-Zugangsdaten. Behandeln Sie diese Daten deshalb als Geheimnisse Ihrer Pipeline: Speichern Sie private Schlüssel nicht in Quelltexten oder frei lesbaren Build-Protokollen, begrenzen Sie den Zugriff auf CI/CD-Geheimnisse und vermeiden Sie, wiederverwendbare Authentifizierungsdaten in Diagnoseausgaben zu kopieren. Die Apple-Beschreibung der Web-Einreichung erläutert den Authentifizierungs- und Upload-Ablauf.
Bei notarytool entfällt Ihre eigene Implementierung der API-Aufrufe nicht jede Zugangsdatenverantwortung. Auch hier müssen Sie festlegen, wo Anmeldedaten gespeichert, welchen Aufträgen sie verfügbar gemacht und wie Ausgaben protokolliert werden. Lassen Sie fehlgeschlagene Aufträge nicht einfach erneut mit unkontrolliert kopierten Zugangsdaten starten. Erstellen Sie stattdessen eine klare Trennung zwischen geschützten Geheimnissen, nicht vertraulichen Statusinformationen und den Logs, die Sie zur Fehlersuche aufbewahren dürfen.
Ein erfolgreicher Upload ist noch keine Freigabe für die Auslieferung. Behandeln Sie Einreichung, abgeschlossene Notarisierung, Ticket-Anheftung und Abnahme des endgültigen Pakets als getrennte Prüfpunkte.
Auch nach einer erfolgreichen Notarisierung müssen Sie den Auslieferungsweg abschließen. Brauchen Sie nach einer Einreichung ohne Mac noch stapler? Wenn Sie ein Ticket an das ausgelieferte Programm anheften möchten, müssen Sie diesen Schritt gesondert einplanen und prüfen, ob dafür die passende macOS-Umgebung und das Apple-Werkzeug stapler verfügbar sind. Die Notary API sollte nicht als Funktion missverstanden werden, die das Ticket automatisch an jedes Paket heftet. Apples Dokumentation zum Anpassen des Notarisierungsablaufs unterscheidet die Interaktion mit dem Notarisierungsdienst von den weiteren Schritten eines benutzerdefinierten Ablaufs.
Wenn ein Auftrag abgelehnt wird oder das Ergebnis nicht zu Ihrer Erwartung passt, prüfen Sie die konkreten Angaben im Notarisierungsprotokoll und ordnen Sie sie dem eingereichten Artefakt zu. Ein „erfolgreich eingereicht“ im Pipeline-Log belegt nicht, dass das Paket freigegeben wurde. Apple führt in der Fehlerbehebung für häufige Notarisierungsprobleme typische Ursachen und Prüfwege auf. Verknüpfen Sie daher Einreichungskennung, Build-Ausgabe und Protokoll so, dass die zuständige Person genau das betroffene Artefakt untersuchen kann.
Fünf Prüfschritte vor einer Umstellung
-
Verfolgen Sie den tatsächlichen Artefaktweg. Notieren Sie, welches System das Programm baut, welches es signiert und welches Paket tatsächlich an den Notarisierungsdienst übermittelt. Verlassen Sie sich nicht nur auf die Bezeichnung des CI-Jobs; prüfen Sie dessen Eingabe und Ausgabe.
-
Grenzen Sie die plattformunabhängige Arbeit ab. Markieren Sie Einreichung, Statusabfrage und Protokollabruf als mögliche API-Aufgaben. Kennzeichnen Sie Build, Signierung und Ticket-Anheftung separat, statt sie in einem Sammelschritt „Release“ zu verstecken.
-
Bewerten Sie den Integrationsaufwand. Bei notarytool prüfen Sie, ob die bestehende macOS-Umgebung das Werkzeug bereitstellt. Bei der API kalkulieren Sie die Wartung für Authentifizierung, Upload, Statusabfrage, Fehlerbehandlung und Protokollzuordnung mit ein. Die Entscheidung betrifft damit nicht nur den Start eines Auftrags, sondern auch dessen Betrieb.
-
Testen Sie Geheimnisverwaltung und Fehlerpfade. Kontrollieren Sie, wer auf private Schlüssel und temporäre Upload-Daten zugreifen kann und welche Inhalte in Build-Logs landen. Führen Sie außerdem einen kontrollierten Fehlerfall durch, damit Ihr Team weiß, wie eine abgelehnte oder unvollständige Einreichung erkannt und diagnostiziert wird.
-
Nehmen Sie das fertige Lieferartefakt ab. Prüfen Sie das Paket nach Abschluss des Dienstschritts, führen Sie erforderliche macOS-Arbeiten wie die Ticket-Anheftung aus und verifizieren Sie anschließend genau die Datei, die an Nutzer verteilt werden soll. Bewahren Sie nachvollziehbar auf, welches Ergebnis und welches Protokoll zu diesem Paket gehören.
SECTION 04 Welche Entscheidung sollten Sie jetzt treffen?
Nutzen Sie die folgenden Bedingungen als Entscheidungsliste. Sie ersetzen keine Prüfung Ihrer konkreten Apple-Werkzeuge, verhindern aber, dass „ohne Mac einreichen“ fälschlich als „ohne Mac veröffentlichen“ ausgelegt wird.
- Wenn Xcode auf einem Mac baut und signiert, Ihre Pipeline dort läuft und kein Dienstkontakt außerhalb dieser Umgebung verlangt wird, wählen Sie zunächst notarytool. Sie halten den Ablauf zusammen und vermeiden eine eigens zu betreibende API-Integration.
- Wenn Ihr Release-Dienst auf Windows oder Linux laufen muss und nur Einreichung, Statusabfrage sowie Protokollabruf plattformneutral ausgeführt werden sollen, prüfen Sie die Notary API. Planen Sie getrennt, wo Build, Signierung und Ticket-Anheftung stattfinden.
- Wenn Ihr externes Build-System zwar ein fertiges Artefakt erzeugt, aber weder Signierung noch macOS-Abnahme verlässlich abdeckt, lösen Sie zuerst diese Lücke. Ein API-Wechsel allein macht das Paket nicht auslieferungsbereit.
- Wenn Ihre Organisation die Schlüsselverwaltung, Fehlerauswertung und Pflege einer eigenen Dienstintegration nicht übernehmen kann, bleiben Sie bei einem kontrollierten macOS-Ablauf mit notarytool, statt die Plattformabhängigkeit nur in eine neue Betriebsverantwortung umzuwandeln.
| Ergebnis Ihrer Prüfung | Konsequenz für die Pipeline |
|---|---|
| Mac vorhanden und Xcode-Werkzeugkette etabliert | notarytool im bestehenden Veröffentlichungsablauf verwenden |
| Mac nur für den Dienstkontakt vorgesehen, Ausführung muss plattformneutral sein | Notary API für den begrenzten Interaktionsabschnitt bewerten |
| Kein klarer Ort für Signierung, Ticket-Anheftung oder Paketprüfung | Vor der Werkzeugwahl die Zuständigkeiten und Abnahmeschritte festlegen |
Die praktische Grenze verläuft also nicht zwischen „Mac“ und „kein Mac“, sondern zwischen dem Austausch mit Apples Notarisierungsdienst und den übrigen Aufgaben, die Ihr Veröffentlichungsprozess erfüllen muss. Die API kann den ersten Teil von macOS lösen; sie ersetzt nicht automatisch die Werkzeuge und Prüfungen, von denen die Integrität Ihres ausgelieferten macOS-App-Pakets abhängt.
Wenn Ihre aktuelle Windows- oder Linux-Pipeline für Build und Signierung gut funktioniert, aber für Ticket-Anheftung oder abschließende Prüfung einen Mac benötigt, vergleichen Sie zunächst den Aufwand eines gezielten Mac-Schritts mit dem Betrieb einer eigenen API-Integration. Ein dauerhaft bereitgestellter eigener Mac ist nicht für jedes unabhängige Projekt sinnvoll; umgekehrt bringt eine API keinen Vorteil, wenn Ihre restliche Veröffentlichung ohnehin auf macOS angewiesen ist. Für einen zeitlich begrenzten Release-Test oder eine Mac-Umgebung, die Sie für diese konkreten Schritte erreichbar halten möchten, können Sie die Nutzungsinformationen von VPSNIX und die Mietoptionen prüfen. Entscheiden Sie nach Ihrem tatsächlichen Ablauf: Die Notary API ist eine Option für den Dienstkontakt, kein Ersatz für eine abgenommene Mac-Veröffentlichungskette.