Fehlerbild: Claude Code meldet einen erfolgreichen Release-Schritt, aber Sie können nicht belegen, ob das verteilte Paket korrekt signiert und notarisiert ist.
Schnellste Lösung: Lassen Sie Claude Code Werkzeuge ausführen, aber bestätigen Sie Signatur, Notarisierung und Freigabe anhand ihrer tatsächlichen Ausgaben. Apple-Zugangsdaten gehören in eine kontrollierte, nach dem Auftrag bereinigbare macOS-Umgebung.
Dieser Leitfaden richtet sich an Sie, wenn Sie als unabhängiger Entwickler ohne ständig verfügbaren Mac einen Veröffentlichungsablauf vorbereiten, als Release-Verantwortlicher Claude Code in eine überprüfbare Pipeline aufnehmen oder als Plattformadministrator Signaturgeheimnisse und den Fernzugriff verwalten. Wenn Sie nur eine App im Store einreichen möchten, überspringen Sie nicht die Unterscheidung zwischen Store-Verteilung und direkter Verteilung.
Wählen Sie zuerst den passenden Veröffentlichungsweg
macOS-App-Signierung und Notarisierung sind nicht einfach zwei Häkchen in einem universellen Release-Schritt. Ihr Veröffentlichungsweg bestimmt, welche Art von Signatur, Verpackung und Übergabe Sie brauchen. Die beiden Wege dürfen Sie in Ihrer Pipeline nicht vermischen.
Für den Mac App Store erstellen und signieren Sie ein für die Store-Übermittlung vorgesehenes Build-Artefakt und laden es gemäß Apples Verfahren zu App Store Connect hoch. Die anschließende Store-Prüfung und Bereitstellung ist nicht mit der Verteilung einer Developer-ID-App außerhalb des Stores gleichzusetzen. Apples Anleitung zum Hochladen von Builds zu App Store Connect beschreibt den Store-Weg.
Bei einer Verteilung außerhalb des Mac App Store signieren Sie die App für diesen Vertriebsweg mit einer passenden Apple Developer ID und bereiten sie für die Notarisierung vor. Apple beschreibt die Anforderungen für distributionssignierten Mac-Code. Die Notarisierung ist Apples automatisierte Prüfung eingereichter Software; sie ersetzt weder Ihre Tests noch die Verantwortung, das tatsächlich ausgelieferte Paket zu kontrollieren. Die Apple-Dokumentation zur Notarisierung von macOS-Software erläutert diesen Ablauf.
| Entscheidungspunkt | Mac App Store | Verteilung außerhalb des Stores |
|---|---|---|
| Ziel | Bereitstellung über den Mac App Store | Eigene Verteilung eines signierten Pakets |
| Zentrale Übergabe | Upload des Store-Builds zu App Store Connect | Einreichung des geeigneten Pakets zur Notarisierung |
| Welche Prüfung zählt? | Build-Zuordnung und Status in App Store Connect sowie Ihre Release-Kontrollen | Signaturprüfung, Notarisierungsergebnis, Ticket und Kontrolle des finalen Pakets |
| Rolle von Claude Code | Kann freigegebene Build- und Upload-Schritte unterstützen | Kann Signatur- und Notarisierungsbefehle vorbereiten oder ausführen |
| Freigabeentscheidung | Bleibt bei der verantwortlichen Person | Bleibt bei der verantwortlichen Person |
Claude Code kann auf Ihrem Auftrag Shell-Befehle ausführen; daraus folgt aber nicht, dass es eine passende Signieridentität auswählen oder eine Veröffentlichung eigenständig verantworten sollte. Die Berechtigungsoptionen der Claude-Code-CLI-Dokumentation helfen Ihnen, Zugriffe und Freigaben zu steuern. Legen Sie den Agenten nicht so aus, als wäre seine Textantwort ein vertrauenswürdiger Nachweis für den Status von Apple-Werkzeugen.
Erstes Release-Szenario: einen reproduzierbaren Build bereitstellen
Der erste Nachweis entsteht beim Build, nicht bei der Notarisierung. Bevor Claude Code einen Release-Auftrag erhält, müssen Sie wissen, was gebaut werden soll und woran Sie das Ergebnis erkennen. Halten Sie deshalb die Build-Anweisung, den erwarteten Ausgabepfad und die Versionskennung in Ihrem Projekt fest. Der Agent kann diese Informationen verwenden, sollte sie aber nicht aus Vermutungen ergänzen.
Prüfen Sie im Repository insbesondere:
- Welches Projekt oder welches Schema ist für die Release-Konfiguration vorgesehen?
- Baut Xcode das Projekt, oder erzeugt ein externes Build-System die App?
- Welche Abhängigkeiten werden während des Builds aufgelöst, und sind ihre Versionen nachvollziehbar festgelegt?
- Welche Zielarchitekturen sind vorgesehen, und enthalten eingebettete Komponenten dieselben benötigten Architekturen?
- Welcher Pfad enthält nach erfolgreichem Build die zu prüfende App oder das Archiv?
Diese Angaben sind projektspezifisch; sie lassen sich nicht seriös durch eine pauschale Xcode-Anleitung ersetzen. Apples Hinweise zum Packen von Mac-Software für die Verteilung sind für den erwarteten Ausgabetyp und die anschließende Übergabe relevant. Wenn Sie ein Xcode-Projekt nutzen, führen Sie den vorgesehenen Build-Auftrag aus und kontrollieren Sie die erzeugte Datei. Ein möglicher Einstieg ist:
xcodebuild -scheme "IhreApp" -configuration Release -archivePath "$PWD/build/IhreApp.xcarchive" archive
Das Beispiel ist keine Garantie, dass dieses Schema für Ihr Projekt passt. Ersetzen Sie den Namen durch die tatsächliche Projektkonfiguration und prüfen Sie den Exit-Status, den vollständigen Konsolenauszug sowie das Vorhandensein des Archivs am festgelegten Pfad. Speichern Sie den Log als Release-Nachweis. Ein von Claude Code formulierter Satz wie „Build erfolgreich“ ist kein Ersatz für einen erfolgreichen Prozessstatus und das überprüfte Artefakt.
Wenn Sie ein externes Build-System einsetzen, gilt derselbe Grundsatz: Der dokumentierte Projektbefehl muss wiederholbar sein; das Ergebnis und sein Herkunftsnachweis müssen zur nachfolgenden Signaturprüfung passen. Lassen Sie den Agenten nicht stillschweigend zu einem anderen Schema, einer anderen Konfiguration oder einem lokalen Zwischenprodukt wechseln. Ein falscher Ausgabepfad kann einen scheinbar erfolgreichen Release erzeugen, bei dem die spätere Prüfung ein anderes Artefakt betrachtet als das, das Sie verteilen wollen.
Zweites Release-Szenario: Signaturidentität und Geheimnisse kontrollieren
Bei der Signierung treffen technische Entscheidung und Berechtigungsentscheidung aufeinander. Prüfen Sie vor der Ausführung, welche Signieridentität zum gewählten Vertriebsweg gehört und wer den Zugriff darauf freigibt. Apple beschreibt die Anforderungen an signierten Code für die Verteilung in der Dokumentation zur Mac-Code-Signierung. Verlassen Sie sich nicht auf den Anzeigenamen, den ein Agent in seiner Erklärung nennt: Die lokale Werkzeugausgabe muss die tatsächlich verwendete Identität belegen.
Speichern Sie Zertifikat, privaten Schlüssel, API-Schlüssel oder andere Authentifizierungsdaten nicht im Repository, in einer Prompt-Nachricht oder in einem dauerhaft aufbewahrten Arbeitsverzeichnis. Geben Sie die erforderlichen Geheimnisse nur über einen kontrollierten Schlüsselbund- oder Geheimnisverwaltungsmechanismus frei. Legen Sie fest, welche Sitzung darauf zugreifen darf, ob eine menschliche Bestätigung erforderlich ist und wie der Zugriff nach Abschluss des Jobs entfernt oder widerrufen wird. Achten Sie außerdem darauf, dass Shell-Ausgaben und CI-Protokolle keine Geheimnisse offenlegen.
Das betrifft auch Datenschutz und Aufbewahrung: Ein Cloud-Mac ist Teil Ihrer Verarbeitungsumgebung, deshalb sollten Sie festlegen, welche Quelltexte, Logs und Schlüssel dort landen und wie sie nach dem Auftrag behandelt werden. Prüfen Sie Ihre internen Vorgaben und die Datenschutzhinweise von Kvmkit, bevor Sie vertrauliche Projektinhalte in eine entfernte Umgebung übertragen.
Signieren Sie das für die Verteilung vorgesehene App-Bundle mit der vorher bestätigten Identität. Lassen Sie Claude Code den Befehl ausführen, wenn die Berechtigungen dafür passend begrenzt sind, und sichern Sie anschließend die tatsächliche Ausgabe. Für die Prüfung können Sie beispielsweise ausführen:
codesign --verify --deep --strict --verbose=2 "/Pfad/IhreApp.app"
codesign -dv --verbose=4 "/Pfad/IhreApp.app"
Diese Befehle prüfen nicht automatisch, ob Ihre komplette Release-Entscheidung richtig war. Kontrollieren Sie zusätzlich eingebettete Hilfsprogramme, Frameworks und weitere signierte Bestandteile, die zu Ihrem Produkt gehören. Wenn ein verschachteltes Objekt fehlschlägt, beheben Sie zuerst die Ursache und signieren Sie das vorgesehene Artefakt erneut. Eine oberflächliche Prüfung des äußeren App-Bundles reicht nicht als Beleg dafür, dass alle enthaltenen ausführbaren Komponenten korrekt sind.
Apple dokumentiert für bestimmte Verteilungsfälle die Anforderungen an die Hardened Runtime. Prüfen Sie diese Vorgaben für Ihren konkreten Vertriebsweg, statt eine pauschale Einstellung aus einem anderen Projekt zu übernehmen. Die benötigten Entitlements müssen begründet und auf die App zugeschnitten sein. Eine großzügige Ausnahme, nur damit ein Release-Befehl ohne Fehlermeldung endet, ist keine sichere Fehlerbehebung.
Wichtig: Lassen Sie Claude Code keine Zugangsdaten in die Befehlszeile, den Quellcode oder ein dauerhaft gespeichertes Chat-Protokoll schreiben. Wenn Sie nicht sicher nachweisen können, wo ein Schlüssel verfügbar war und wie Sie den Zugriff anschließend beenden, halten Sie den Release an.
Drittes Release-Szenario: Notarisierung als Folge prüfbarer Ergebnisse
Bei einer Developer-ID-Verteilung besteht „Notarisierung erfolgreich“ aus mehreren überprüfbaren Zuständen. Eine angenommene Einreichung ist nicht automatisch ein abgeschlossenes Notarisierungsergebnis; ein abgeschlossenes Ergebnis beweist noch nicht, dass das Ticket am richtigen finalen Artefakt angebracht wurde. Apple beschreibt die werkzeuggestützte und die angepasste Notarisierungs-Arbeitsweise. Prüfen Sie dort die aktuell dokumentierte Werkzeugführung, bevor Sie einen bestehenden Pipeline-Befehl übernehmen.
Ein möglicher Ablauf mit notarytool sieht so aus:
xcrun notarytool submit "IhreApp.zip" --keychain-profile "ReleaseProfil" --wait
Verwenden Sie den Profilnamen nur, wenn er auf dem verwendeten Mac eingerichtet und der Zugriff dafür genehmigt ist. Bewahren Sie die Kennung der Einreichung, die Rückmeldung des Werkzeugs und das zugehörige Protokoll als Release-Nachweis auf. Wird die Einreichung abgelehnt oder mit Warnungen beendet, lesen Sie das Notarisierungsprotokoll, bevor Sie den nächsten Versuch starten. Die Fehlermeldung im Terminal kann auf den betroffenen Bestandteil hinweisen; sie ersetzt aber nicht die vollständige Auswertung des Apple-Protokolls.
Nach einem akzeptierten Ergebnis können Sie das Ticket mit stapler an den dafür geeigneten Verteilungsgegenstand anheften. Prüfen Sie danach sowohl das Ticket als auch das finale Paket:
xcrun stapler staple "IhreApp.dmg"
xcrun stapler validate "IhreApp.dmg"
spctl --assess --type execute --verbose "/Pfad/IhreApp.app"
Diese Beispielbefehle sind an Pakettyp und Ablauf anzupassen. Ein gültiger Test des DMG belegt nicht automatisch, dass ein anderes, später erzeugtes ZIP dieselbe App enthält. Dokumentieren Sie deshalb, welche Datei eingereicht, an welche Datei das Ticket geheftet und welche Datei tatsächlich zur Veröffentlichung freigegeben wurde. Wenn Ihr Workflow ein Paket nach der Prüfung neu erstellt oder austauscht, muss die Kontrolle am neuen Release-Artefakt wiederholt werden.
Die Reihenfolge ist für die Nachvollziehbarkeit entscheidend: Erzeugen Sie das vorgesehene Release-Artefakt, signieren Sie die App samt relevanten Bestandteilen, verpacken Sie sie in der für den Distributionsweg vorgesehenen Form, reichen Sie das geeignete Paket ein und werten Sie Ergebnis und Protokoll aus. Heften Sie das Ticket an, sofern es für das verwendete Paket vorgesehen ist. Kontrollieren Sie schließlich die tatsächliche Datei, die Sie ausliefern. Verwenden Sie keine neue Verpackung nach erfolgreicher Prüfung, ohne diese ebenfalls zu validieren.
Release-Abnahme: nachweisen, bereinigen und erst dann freigeben
Ein sauberer Release braucht mehr als eine grüne Build-Anzeige. Die Person, die veröffentlicht, sollte die Quelle des Artefakts, seine Versionskennung und die Ergebnisse jeder relevanten Prüfung zusammenführen können. Trennen Sie dabei die Rolle des Agenten von der menschlichen Freigabe: Claude Code kann Befehle vorbereiten und ausführen, aber die verantwortliche Person bestätigt die Belege und entscheidet, ob das Produkt ausgeliefert wird.
| Abnahmepunkt | Nachweis, den Sie aufbewahren | Release stoppen, wenn … |
|---|---|---|
| Herkunft | Repository-Stand, Build-Befehl und Pfad des erzeugten Artefakts | der geprüfte Build nicht eindeutig dem freizugebenden Stand zugeordnet ist |
| Signierung | Werkzeugausgabe zur Identität und erfolgreiche Verifikation der App-Bestandteile | die Identität nicht bestätigt ist oder eine relevante Komponente die Prüfung nicht besteht |
| Notarisierung | Status, Einreichungsprotokoll und gegebenenfalls validiertes Ticket | das Ergebnis fehlt, abgelehnt wurde oder zum falschen Paket gehört |
| Verpackung | Kontrollierte finale Datei mit Version und Verteilungspfad | die ausgelieferte Datei nach der Prüfung verändert oder ersetzt wurde |
| Zugang und Freigabe | Bestätigung der Berechtigungen, Bereinigung und menschliche Freigabe | Zugangsdaten weiter verfügbar sind oder eine Freigabeentscheidung nicht dokumentiert ist |
Legen Sie fest, wer die Ergebnisse prüft und wer den Release tatsächlich freigibt. Diese Rollen können in einem kleinen Team bei derselben Person liegen; die Prüfung muss trotzdem stattfinden. Wenn die App signiert ist, die Notarisierung aber noch aussteht, behandeln Sie sie nicht als freigegeben. Wenn die Notarisierung erfolgreich war, aber das Endpaket nicht validiert wurde, halten Sie ebenfalls an. Fehlt eine dieser Belegketten, ist „Agent sagt erfolgreich“ kein Ersatz.
Nach Abschluss des Auftrags entfernen Sie temporäre Dateien, nicht mehr benötigte Schlüsselbundprofile und den Zugriff auf die für den Job bereitgestellten Geheimnisse. Prüfen Sie die gespeicherten Protokolle auf versehentlich ausgegebene Tokens oder private Daten. Bei einem Verdacht auf Offenlegung widerrufen Sie betroffene Zugangsdaten und behandeln Sie den Vorfall nach Ihrem Sicherheitsprozess, statt lediglich die Logdatei zu löschen.
| Einsatzoption | Passt besonders, wenn … | Grenzen, die Sie einplanen sollten |
|---|---|---|
| Eigener Mac | Sie häufig veröffentlichen, lokale Kontrolle brauchen und Hardware dauerhaft verfügbar halten möchten | Anschaffung, Wartung, Updates und sichere Schlüsselverwaltung bleiben bei Ihnen |
| Cloud-Mac | Sie eine kontrollierte entfernte macOS-Umgebung für einen begrenzten Release-Auftrag brauchen | Netzwerkzugriff, Sitzungsberechtigungen, Datenaufbewahrung und Geheimnisbereinigung müssen geklärt sein |
| Allgemeine CI-Umgebung ohne macOS | Ihre Schritte keine Apple-spezifische Signierung oder Notarisierung voraussetzen | Sie ersetzt den benötigten macOS-Werkzeuglauf für die hier beschriebenen Release-Prüfungen nicht |
Wenn Sie noch kein geeignetes Fernsystem haben, vergleichen Sie vorab Übergabe, Zugriffsschutz und Löschablauf. Für die regionale Auswahl können Sie beispielsweise die Seiten zu Mac mini mieten in Japan und Mac mini mieten in Hongkong prüfen; entscheiden Sie anhand Ihrer Anforderungen und nicht allein anhand des Standorts. Eine Mietumgebung ist kein Ersatz für einen klaren Freigabeprozess.
Häufige Fragen zur Claude-Code-Signierung auf dem Cloud-Mac
Kann Claude Code die App samt Zertifikat veröffentlichen?
Claude Code kann von Ihnen freigegebene Werkzeuge anstoßen und Arbeitsschritte automatisieren. Es kann dadurch jedoch weder die Eigentümerschaft an einer Signieridentität übernehmen noch eine menschliche Freigabe ersetzen. Begrenzen Sie den Zugriff auf Geheimnisse, prüfen Sie die Werkzeugausgaben unabhängig und lassen Sie die zuständige Person entscheiden, ob die geprüfte Datei veröffentlicht wird.
Was muss ich nach einer angenommenen Einreichung aufbewahren?
Sichern Sie die Kennung und das Ergebnis der Einreichung, das Notarisierungsprotokoll, die Ausgabe der Ticketprüfung sowie den Pfad und die Versionskennung des finalen Pakets. Diese Informationen helfen Ihnen, eine Ablehnung oder spätere Rückfrage dem richtigen Artefakt zuzuordnen. Ein einzelner Terminal-Screenshot ohne Dateibezug reicht dafür nicht aus.
Kann ich Store-Upload und Developer-ID-Notarisierung in einer Pipeline zusammenfassen?
Sie können gemeinsame Vorarbeiten wie Build und Tests automatisieren, sollten aber die Freigabepfade als getrennte Ziele modellieren. Der Store-Upload folgt dem Verfahren von App Store Connect; die direkte Verteilung benötigt die dafür passende Signierung und den Notarisierungsnachweis. Vermischen Sie Berechtigungen, Paketformate und Abnahmekriterien nicht bloß, um weniger Pipeline-Schritte zu pflegen.
Wenn Sie den Ablauf zuerst ohne echte Signiergeheimnisse erproben, können Sie Build-Pfade, Protokollaufbewahrung und Freigabesperren prüfen, bevor ein produktiver Schlüssel zugänglich wird. Für eine zeitlich begrenzte Release-Umgebung kann ein Cloud-Mac sinnvoll sein; ein eigener Mac ist oft die bessere Wahl, wenn Sie dauerhaft hohe Auslastung, lokale Geräteanschlüsse oder vollständige Kontrolle über die Hardware benötigen. Entscheiden Sie erst nach einem erfolgreichen End-to-End-Test mit einem ungefährlichen Testprojekt, ob ein gemieteter Mac von Kvmkit zu Ihrem Release-Betrieb passt.
FAQ
Kann Claude Code eine macOS-App selbstständig signieren?
Claude Code kann freigegebene Kommandozeilenwerkzeuge auf dem Mac aufrufen und damit Arbeitsschritte unterstützen. Ob eine Signierung tatsächlich erfolgreich ist, belegt jedoch nicht die textliche Rückmeldung des Agenten, sondern die Prüfung der konkreten App mit den macOS-Werkzeugen. Sie bestimmen außerdem, welche Identität verwendet wird, welche Geheimnisse zugänglich sind und ob das Ergebnis veröffentlicht werden darf.
Wie bleiben Signatur-Zugangsdaten auf einem Cloud-Mac geschützt?
Hinterlegen Sie Zertifikate, private Schlüssel und Zugangstoken nicht im Quellcode, in Prompts oder in einem dauerhaft gespeicherten Projektordner. Geben Sie sie der Sitzung nur über einen kontrollierten Geheimnis- oder Schlüsselbund-Mechanismus frei, beschränken Sie Berechtigungen auf den nötigen Umfang und entfernen oder widerrufen Sie den Zugriff nach dem Auftrag. Prüfen Sie auch, ob Protokolle Geheimnisse ausgeben.
Was ist nach einer erfolgreichen macOS-Notarisierung noch zu prüfen?
Prüfen Sie den Status der Einreichung und lesen Sie das zugehörige Protokoll auf Warnungen oder abgelehnte Bestandteile. Kontrollieren Sie anschließend, ob das Ticket an der vorgesehenen Verteilungsdatei angebracht wurde und ob das fertige Paket die erwartete Signatur trägt. Eine erfolgreiche Einreichung allein weist weder die korrekte Verpackung noch die Eignung des endgültigen Downloads nach.
In welcher Reihenfolge erfolgen Signierung, Notarisierung und Verpackung?
Erstellen Sie zunächst das freizugebende Build-Artefakt und signieren Sie die App samt relevanter eingebetteter Komponenten. Reichen Sie anschließend das für die Verteilung geeignete Paket bei Apple zur Notarisierung ein, werten Sie das Ergebnis aus und heften Sie das Ticket an, sofern der gewählte Pakettyp und Ablauf dies vorsehen. Prüfen Sie zuletzt genau das Artefakt, das Sie verteilen wollen.
CI/CD auf M4 Mac mini — am unkompliziertesten
Xcode, Fastlane, CocoaPods, and SPM are first-class on macOS. Mac mini M4 unified memory keeps signing and archiving smooth; ~4W standby power suits 24/7 build nodes.