Wie prüfen Sie eine Mac-App vor der Notarisierung für macOS 27? Checkliste 2026

Für eine direkte Verteilung auf macOS 27 sollte eine Mac-App erst freigegeben werden, wenn Developer-ID-Signatur, Notarisierung des tatsächlich ausgelieferten Objekts und Starttest im Zielsystem zusammenpassen. Diese Abnahme gilt für Apps außerhalb des Mac App Store; für den Store ist Apples eigener Verteilungsweg maßgeblich.

Für wen dieser Leitfaden gedacht ist: Für unabhängige Entwickler, die eine Mac-App direkt an Nutzer ausliefern und Signatur, Notarisierung und Download vor der Veröffentlichung prüfen möchten.
Für Teams mit DMG oder PKG, die Paket- und App-Prüfung nicht verwechseln wollen.
Auch für Entwickler ohne eigenen Mac, die eine wiederholbare entfernte Veröffentlichungsumgebung erwägen.

Zuletzt aktualisiert am 06.11.2026; geprüft anhand von Apples Dokumentation zur Notarisierung, zum App-Vertrieb und zu den macOS-27-Veröffentlichungshinweisen.

Zuerst den Verteilungsweg festlegen

Die erste Abnahmefrage lautet nicht, welcher Befehl in der CI ausgeführt wurde. Entscheidend ist, was Nutzer tatsächlich erhalten und über welchen Weg es verteilt wird. Apple unterscheidet direkte Verteilung von der Bereitstellung über den Mac App Store. Die Apple-Dokumentation zu den Verteilungswegen für Apps beschreibt diese Unterscheidung. Eine App, die außerhalb des Stores verteilt wird, muss nach Apples Anleitung für macOS-Software notariert werden. Die Notarisierungsanleitung für macOS-Software ist dafür die maßgebliche Referenz.

Damit wird die Abnahme in klar getrennte Prüfpunkte aufgeteilt:

• Direkte App-Verteilung: Die signierte App, ihr Notarisierungsergebnis und die heruntergeladene finale App prüfen.
• DMG: Zusätzlich das Disk-Image als Auslieferungsobjekt berücksichtigen und die darin enthaltene App nach dem Einhängen starten.
• PKG: Das Installationspaket und die nach der Installation vorhandene App getrennt prüfen.
• Mac App Store: Den Store-Einreichungs- und Freigabeweg kontrollieren, nicht ungeprüft die Developer-ID-Schritte für eine direkte Verteilung übernehmen.

Der häufige Abnahmefehler liegt darin, dass ein Team ein internes App-Bundle erfolgreich einreicht und danach eine andere Datei erzeugt, beispielsweise ein neues DMG. Das frühere Ergebnis belegt dann nicht automatisch den Zustand der später ausgelieferten Datei. Apple beschreibt in der Dokumentation zum Verpacken und Verteilen von Mac-Software die verschiedenen Verpackungsformen. Für die Freigabe ist deshalb eine nachvollziehbare Zuordnung zwischen Build, eingereichtem Objekt und Download erforderlich.

Welche Abnahmekriterien unterscheiden die Szenarien?

Die folgende Gegenüberstellung ist als Projektentscheidungshilfe gedacht. Die Bewertung „vollständig“ bedeutet hier: Das Team kann den relevanten Zustand anhand eines konkreten Artefakts und gespeicherter Prüfergebnisse belegen. Sie ersetzt keine Prüfung der aktuellen Apple-Vorgaben.

Die Notarisierung ist eine Sicherheitsprüfung des eingereichten Softwareobjekts. Sie ist kein Kompatibilitätstest und keine Garantie, dass jede Nutzerkonfiguration einen fehlerfreien Start erlaubt. Apple beschreibt die Voraussetzungen für die Hardened Runtime sowie die Rolle der Code-Signing-Dienste. Daraus folgt für die Abnahme: Signaturidentität und Runtime-Einstellungen müssen geprüft werden, aber ein erfolgreiches Prüfergebnis darf nicht als Ersatz für einen realen Starttest behandelt werden.

Entscheidung nach Auslieferungsform

• Wenn eine signierte App direkt verteilt wird, prüfen Sie genau diese App nach der Notarisierung und testen Sie den finalen Download. Ein Test des Build-Verzeichnisses allein reicht für die Release-Freigabe nicht.
• Wenn Nutzer ein DMG laden, behandeln Sie das Image als Teil der Auslieferung. Prüfen Sie das eingereichte Objekt und starten Sie die App aus einem gemounteten Image, nicht nur aus dem Entwicklungsordner.
• Wenn ein PKG installiert, speichern Sie den Zustand des Pakets und prüfen Sie danach die installierte App. Das Paket kann korrekt signiert sein, während eine fehlerhafte Installations- oder Ablagesituation den Nutzer dennoch blockiert.
• Wenn die App über den Mac App Store erscheint, folgen Sie dem Store-Prozess und dokumentieren Sie Einreichung, Freigabe und veröffentlichte Version. Nutzen Sie den Developer-ID-Ablauf nicht als vermeintliche Abkürzung für Store-Abnahmen.
• Wenn ein ausgeliefertes Objekt nach der Prüfung verändert wird, starten Sie die Abnahme für das geänderte Objekt erneut. Ändert sich nur ein interner Build, der nicht Teil des Releases ist, muss das Team trotzdem belegen, dass der Download unverändert dem geprüften Artefakt entspricht.

So entsteht eine nachvollziehbare Freigabe

Ein reproduzierbarer Ablauf verhindert, dass Signierung, Upload und Test auf unterschiedliche Builds bezogen sind. Die folgenden Schritte passen in eine lokale Pipeline ebenso wie in eine kontrollierte CI-Umgebung.

Erster Schritt: Ziel und Artefakt festhalten

Legen Sie vor dem Build fest, ob die Veröffentlichung direkt, als DMG, als PKG oder über den Mac App Store erfolgt. Notieren Sie den Namen und die Version des vorgesehenen Releases sowie, welches Objekt eingereicht und welches an Nutzer ausgeliefert wird. Das ist keine Formalität: Bei einem DMG oder PKG reicht es nicht, nur den Namen des App-Bundles festzuhalten.

Zweiter Schritt: Build-Umgebung und Zielsystem abgleichen

Prüfen Sie, auf welchem macOS die App gebaut wird und auf welchen Systemen sie starten soll. Apples macOS-27-Veröffentlichungshinweise nennen die maßgebliche Plattforminformation: macOS 27 unterstützt ausschließlich Apple-Silicon-Macs. Daraus folgt nicht, dass ein erfolgreicher Build automatisch mit jeder gewünschten macOS-Version oder jeder Nutzerumgebung kompatibel ist. Halten Sie die eingesetzte Xcode- und macOS-Umgebung, die Zielarchitektur und die tatsächlich getestete Laufzeit getrennt fest.

Die Plattformgrenze ist außerdem nicht mit der Notarisierungsentscheidung gleichzusetzen. Eine App kann die Sicherheitsprüfung bestehen und dennoch wegen einer nicht unterstützten Architektur oder eines Laufzeitfehlers nicht wie erwartet starten. Umgekehrt ersetzt ein erfolgreicher lokaler Start nicht die Sicherheits- und Signaturprüfung.

Dritter Schritt: Signatur und Runtime-Einstellungen kontrollieren

Vergewissern Sie sich, dass die für die direkte Verteilung vorgesehene Developer-ID-Signatur verwendet wurde und die Hardened Runtime den Projektanforderungen entspricht. Prüfen Sie die signierte Release-App und nicht nur ein früheres Zwischenprodukt. Notieren Sie außerdem, welche Entitlements tatsächlich benötigt werden und ob sie zum vorgesehenen Verhalten passen. Unnötige Ausnahmen sollten nicht unkommentiert aus einer Entwicklungs- oder Debug-Konfiguration übernommen werden.

Apple bietet einen eigenen Leitfaden zum Anpassen des Xcode-Archivierungsprozesses. Er ist hilfreich, wenn Archivierung und anschließende Verpackung automatisiert sind. Die konkrete Abnahme sollte dennoch die finale Exportdatei erfassen, nicht allein den Erfolg eines Archivierungsschritts.

Vierter Schritt: Das richtige Objekt mit notarytool einreichen

Verwenden Sie notarytool für den vorgesehenen Notarisierungsablauf und halten Sie Submission-ID, Status und zugehörige Datei zusammen. Apples Beschreibung anpassbarer Notarisierungsabläufe erläutert, wie sich der Prozess in eigene Arbeitsabläufe integrieren lässt. Bei Fehlern oder Rückfragen ist das zugehörige Protokoll aussagekräftiger als eine isolierte Erfolgsmeldung in der Build-Konsole.

Ordnen Sie das Resultat ausdrücklich der Datei zu, die später ausgeliefert wird. Bei einem DMG bedeutet das: Nicht aus der erfolgreichen Prüfung eines darin enthaltenen App-Bundles ableiten, dass das finale Disk-Image damit ebenfalls vollständig abgenommen ist. Bei einem PKG ist das Installationspaket der zusätzliche Prüfkandidat.

Fünfter Schritt: Ticket und Prüfstatus am finalen Objekt verifizieren

Wenn der Workflow das Anheften eines Tickets vorsieht, prüfen Sie es am finalen Objekt und bewahren Sie das Ergebnis auf. Die Freigabeakte sollte nachvollziehbar machen, welches Objekt geprüft wurde und welcher Status zurückkam. Verlassen Sie sich nicht ausschließlich auf eine Statusanzeige, deren Bezug zur lokalen Release-Datei nicht dokumentiert ist.

Wichtig: Eine erfolgreiche Notarisierung bestätigt nicht, dass die App in der vorgesehenen Nutzerumgebung startet. Die Sicherheitsprüfung und der funktionale Starttest beantworten unterschiedliche Fragen und müssen getrennt protokolliert werden.

Sechster Schritt: Die Nutzerstrecke testen

Laden Sie das Release so herunter, wie es ein Nutzer erhalten würde. Öffnen Sie ein DMG, wenn das Image der Download ist; führen Sie bei einem PKG die Installation aus. Prüfen Sie danach die installierte oder enthaltene App auf Signatur und tatsächlichen Start. Halten Sie fest, welches System und welche Architektur für diesen Test verwendet wurden. Für die Abnahme genügt keine bloße Aussage „auf dem Build-Mac gestartet“, wenn die Zielumgebung davon abweicht.

Das Ergebnis sollte außerdem einen eindeutigen Bezug zur veröffentlichten Version haben: etwa über den abgelegten Release-Dateinamen, die Build-Informationen und den unveränderten Download. Gibt es nach dem Test eine neue Verpackung, einen Austausch des Installationsprogramms oder einen anderen finalen Build, wird die Abnahme für das neue Objekt wiederholt.

Welche Belege gehören in das Release-Protokoll?

Ein gutes Protokoll erlaubt einer zweiten Person, ohne Rückgriff auf die ursprüngliche CI-Sitzung nachzuvollziehen, was geprüft wurde. Es sollte mindestens enthalten:

• Build-Umgebung: macOS- und Xcode-Version sowie Zielarchitektur.
• Signatur: verwendete Developer-ID-Identität und Status der finalen App-Signatur.
• Notarisierung: eingereichtes Objekt, Submission-ID, Ergebnis und gegebenenfalls das zugehörige Protokoll.
• Ticketprüfung: Ergebnis, wenn im gewählten Ablauf ein Ticket angeheftet wird.
• Auslieferungsform: finale App, DMG oder PKG und Zuordnung zur eingereichten Datei.
• Nutzertest: verwendetes Zielsystem, Installations- oder Öffnungsschritt und dokumentiertes Startverhalten.
• Store-Verteilung: bei einer App-Store-Veröffentlichung Einreichungs- und Freigabestatus sowie die abgeglichene Release-Version.

Bewahren Sie diese Belege so auf, dass sie nicht versehentlich mit Entwicklerzertifikaten, privaten Schlüsseln oder Zugangsdaten vermischt werden. Zugriffsrechte auf Build-Logs und Release-Artefakte sollten sich am tatsächlichen Veröffentlichungsbedarf orientieren. Wer dafür einen entfernten Mac einsetzt, sollte zusätzlich prüfen, welche Personen auf die Umgebung zugreifen können und wie sensible Daten gespeichert werden. Die Datenschutzhinweise von OrbVPS helfen bei der Prüfung des Dienstkontexts; sie ersetzen keine projektinterne Datenschutzbewertung.

Häufige Fragen zur Abnahme

Was bedeutet ein erfolgreiches Ergebnis von notarytool?
Es belegt das Ergebnis der Notarisierung für das zugehörige eingereichte Objekt. Daraus folgt nicht, dass ein verändertes DMG, ein neu erzeugtes PKG oder ein anderer Download ebenfalls geprüft wurde. Auch der Start der App ist damit nicht bestätigt. Ordnen Sie Submission-ID und Ergebnis dem konkreten Artefakt zu und führen Sie danach den Nutzer- beziehungsweise Installationstest aus.

Muss eine App für den Mac App Store separat nach dem Developer-ID-Verfahren notariert werden?
Nicht automatisch. Die Store-Verteilung ist ein eigener Pfad, den Apples Verteilungsdokumentation von der direkten Verteilung abgrenzt. Die Abnahme sollte daher beim tatsächlich eingereichten Store-Produkt und dessen Veröffentlichungsstatus ansetzen. Für direkte Downloads ist dagegen die Developer-ID-Notarisierungsanleitung einschlägig. Vermischen Sie die beiden Prozessnachweise nicht in einem einzigen Freigabeschritt.

Warum muss ein DMG separat betrachtet werden, wenn die App darin bereits geprüft wurde?
Weil Nutzer das Image erhalten und daraus die App öffnen. Die Prüfung des App-Bundles beantwortet nicht automatisch, ob genau das finale Image dem geprüften Release entspricht oder ob die enthaltene App nach dem Einhängen erwartungsgemäß startet. Protokollieren Sie deshalb Image und App als verbundene, aber unterschiedliche Prüfpunkte.

Reicht beim PKG die Prüfung der Installationsdatei aus?
Nein. Das PKG ist der Installationsgegenstand. Für die Nutzerabnahme zählt zusätzlich der Zustand der installierten App. Führen Sie die Installation in einer geeigneten Testumgebung durch, prüfen Sie dort die App-Signatur und starten Sie die Anwendung. Das Ergebnis sollte auf die konkrete Paketdatei und den tatsächlich installierten Release zurückführbar sein.

Kann eine entfernte macOS-Umgebung wiederkehrende Veröffentlichungen abdecken?
Ja, wenn sie für Build, Signierung und Notarisierung kontrolliert eingerichtet ist und die benötigten Entwicklerzugänge sicher verwaltet werden. Entscheidend sind reproduzierbare Artefakte, nachvollziehbare Logs und ein Starttest der finalen Datei. Für eine einmalige Veröffentlichung kann ein verfügbarer eigener Mac einfacher sein; bei wiederkehrenden Releases kann eine feste entfernte Umgebung die gleiche Prüfstrecke bereitstellen.

Wann ist ein entfernter Mac für die Veröffentlichung sinnvoll?

Ein vorhandener Mac ist häufig die einfachste Wahl, wenn Releases selten sind, die lokale Umgebung stabil läuft und ausreichend Speicherplatz vorhanden ist. Ein selbst betriebener Mac bietet außerdem direkte Kontrolle über Hardware und Zugänge. Dafür bleiben Wartung, Updates, Verfügbarkeit und die sichere Verwaltung von Zertifikaten Aufgabe des Teams. Ein Windows- oder Linux-Rechner kann viele Entwicklungsarbeiten übernehmen, ersetzt aber nicht die macOS-Umgebung, die für Xcode-basierte Veröffentlichungs- und Signierungsschritte benötigt wird.

Ein gemieteter Mac kann passen, wenn das Team wiederholt eine fest verfügbare macOS-Umgebung für Build, Signierung und Abnahme benötigt, aber keine eigene Hardware bereitstellen möchte. Bei OrbVPS lässt sich eine entfernte echte Mac-Umgebung über VNC, SSH oder eine Webkonsole nutzen. Vor einer Buchung sollte das Team prüfen, ob die vorgesehene Umgebung die benötigte Apple-Silicon-Plattform, den passenden macOS- und Xcode-Stand sowie einen kontrollierten Umgang mit Entwicklerzugängen ermöglicht. Details zum verfügbaren Angebot sind auf der deutschsprachigen OrbVPS-Seite aufgeführt.

Die Abwägung fällt anders aus, wenn dauerhaft hohe lokale Last, physische Anschlüsse oder vollständige Kontrolle über die Hardware erforderlich sind: Dann kann ein eigener Mac die passendere Lösung sein. Wer zunächst nur eine einzelne App veröffentlicht, sollte nicht allein wegen der Notarisierung eine Mietumgebung einrichten. Für wiederkehrende Releases kann eine feste Umgebung dagegen lokale Rechner entlasten und den Ablauf zwischen Build, Notarisierung und finalem Starttest konsistenter machen.

Vor der Entscheidung sollte das Team eine Testveröffentlichung durchspielen und festhalten, ob jeder Beleg ohne manuelle Nacharbeit dem finalen Download zugeordnet werden kann. Erst wenn Signatur, Notarisierungsergebnis und Nutzerstart durchgängig dokumentiert sind, ist die Freigabe für die direkte Verteilung belastbar.

Häufig gestellte Fragen