Wie signiert und notarisiert man Mac-Forschungssoftware 2026?

Entscheidung vorweg: Apple führt für die externe Verteilung zwei Developer-ID-Zertifikatstypen auf: für Anwendungen und für Installationspakete (Apple-Zertifikatsübersicht). Verteilen Sie über den Mac App Store, folgen Sie dem App-Store-Einreichungsweg; verteilen Sie außerhalb des Stores, planen Sie Developer ID und Notarisierung ein. Bei Tests im Team wählen Sie zuerst eine passende Entwicklungssignierung oder einen Verteilungsweg. Ein entfernter Mac kann fehlende macOS-Arbeitsschritte ermöglichen, aber keine fachliche Forschungsabnahme ersetzen.

Für Sie ist dieser Leitfaden gedacht, wenn Sie als Hochschulangehörige oder Entwicklerin eine Forschungsanwendung an Betreuung, Kooperation oder Testgruppe weitergeben möchten.
Er ist ebenfalls relevant, wenn Sie als Laboradministration Signierung und Auslieferung eines Werkzeugs, Plugins oder Installationspakets organisieren.
Für Projektverantwortliche zeigt er, welche Schritte ohne eigenen Mac gegebenenfalls remote erledigt werden können – und welche Prüfungen trotzdem im Team bleiben.

Vor dem Build: Verteilungsweg und Empfänger festlegen

„Signiert“ und „bereit zur Weitergabe“ bedeuten nicht dasselbe. Die Signatur ordnet Code einem Entwicklerkonto zu und ermöglicht Prüfungen der Codeintegrität. Die Notarisierung ist ein separater Prüf- und Freigabeprozess für geeignete Software, die außerhalb des Mac App Store verteilt wird. Sie ist weder App Review noch Datenschutz- oder Forschungszertifizierung und bestätigt nicht, dass Ihre Analyse fachlich richtige Ergebnisse liefert.

Beginnen Sie deshalb beim Empfänger: Soll die Software öffentlich im Store erscheinen, außerhalb des Stores heruntergeladen werden oder nur im Labor getestet werden? Erst danach legen Sie Zertifikat, Paketierung und Prüfung fest.

Für den Store verwenden Sie den dafür vorgesehenen Übermittlungsprozess; das ist nicht einfach dieselbe Developer-ID-Notarisierung wie bei einem Download außerhalb des Stores. Apple beschreibt das Hochladen eines Builds über App Store Connect. Für externe Verteilung erläutert Apple die Signierung von Mac-Code für die Verteilung. Entscheidend ist, dass Ihr Team die Zielgruppe und den Auslieferungsweg schriftlich festhält, bevor es den Release-Build erstellt.

Achtung: Eine Anwendung, die auf dem Entwicklungsrechner startet, ist noch kein abnahmefähiges Lieferpaket. Lokale Schlüssel, bereits installierte Komponenten oder besondere Zugriffsrechte können Fehler verdecken, die bei Betreuung oder Kooperationspartnern auftreten.

Vor der Signierung: Konto, Zertifikate und Projekt vorbereiten

Legen Sie zuerst fest, wer für das Entwicklerkonto verantwortlich ist und wer Zertifikate verwalten darf. Rollen und Berechtigungen sind nicht automatisch für alle Teammitglieder gleich; prüfen Sie die aktuelle Übersicht der Kontorollen und Zugriffsrechte, statt eine bestimmte Berechtigung für Ihre Hochschule oder Arbeitsgruppe vorauszusetzen.

Für eine Anwendung außerhalb des Stores ist üblicherweise ein Developer-ID-Zertifikat für Anwendungscode relevant. Ein Installationspaket kann zusätzlich eine passende Signierung des Installers benötigen. Apples Dokumentation zu Developer-ID-Zertifikaten beschreibt die Zertifikatstypen. Ein Entwicklungssignaturzertifikat dient einem anderen Zweck und wird dadurch nicht zu einem Distributionszertifikat. Ein fehlendes oder falsch ausgewähltes Zertifikat lässt sich nicht durch eine erfolgreiche lokale Ausführung ausgleichen.

Prüfen Sie anschließend die Projektidentität und die Signiereinstellungen:

• Stimmen App-Kennung und Bundle-ID mit dem vorgesehenen Produkt überein?
• Ist das richtige Teamkonto ausgewählt, und kann die verantwortliche Person das benötigte Zertifikat verwenden?
• Ist die Signierung in der Projektkonfiguration für die ausgewählte Build-Variante gesetzt?
• Sind die benötigten Berechtigungen als Entitlements begründet und auf den tatsächlichen Anwendungsfall beschränkt?
• Ist die Hardened Runtime berücksichtigt, wenn die gewählte externe Verteilung sie voraussetzt?
• Wird beim Signieren ein sicherer Zeitstempel angefordert, und lässt sich dieser im fertigen Artefakt prüfen?

Die Anforderungen hängen vom Paket und Verteilungsweg ab. Apples Vorbereitungshinweise zur Notarisierung von macOS-Software behandeln unter anderem Signierung und Hardened Runtime. Übernehmen Sie Entitlements nicht pauschal aus einer anderen Laboranwendung: Ein nicht benötigter Zugriff kann ein Sicherheitsrisiko schaffen, während ein fehlender erforderlicher Zugriff die Anwendung auf dem Zielsystem beeinträchtigen kann.

Beim Build: alle Bestandteile und die endgültige Hülle signieren

Erstellen Sie einen reproduzierbaren Release-Build und notieren Sie die Versionskennung, den Quellstand sowie die verwendete Build-Konfiguration. Prüfen Sie die App-Bundle-Struktur, bevor Sie signieren. Forschungssoftware enthält häufig neben dem Hauptprogramm Hilfsprozesse, Frameworks, Bibliotheken, Plugins oder Skripte. Diese Bestandteile können eigene Signaturen und eigene Prüfanforderungen haben. Eine sichtbare Signatur am äußeren App-Bundle reicht daher nicht als pauschaler Nachweis für jede enthaltene Datei.

Xcode eignet sich für Projekte, die über den üblichen Xcode-Archiv- und Verteilungsweg gebaut werden. Kommandozeilenwerkzeuge können für automatisierte oder individuell paketierte Abläufe sinnvoll sein. Apple beschreibt die Anpassung des Notarisierungsablaufs; verwenden Sie die dort dokumentierten Werkzeuge passend zu Ihrem Artefakt, statt Befehle aus einem beliebigen App-Beispiel unverändert auf ein Plugin oder Skriptpaket zu übertragen.

Prüfen Sie mit den vorgesehenen Signaturwerkzeugen die Signatur der Hauptanwendung und der eingebetteten Komponenten. Achten Sie darauf, dass keine Änderung nach dem Signieren erfolgt: Wird eine signierte Datei ersetzt oder verändert, muss der betroffene Code erneut geprüft und gegebenenfalls neu signiert werden. Vermerken Sie außerdem, ob Sie eine App, ein Installationspaket, ein Disk-Image oder eine andere Verpackung ausliefern. Der Inhalt und die äußere Hülle können unterschiedliche Signier- und Notarisierungsschritte erfordern.

Beim externen Release: einreichen, Status lesen und Ticket prüfen

Für die öffentliche Verteilung außerhalb des Stores besteht der Ablauf aus mehreren unterscheidbaren Ergebnissen. Ein Upload kann angenommen sein, während die Verarbeitung noch läuft oder eine Prüfung noch nicht erfolgreich abgeschlossen wurde. Behandeln Sie „Upload erfolgreich“ daher nicht als gleichbedeutend mit „Notarisierung erfolgreich“.

Ein belastbarer Ablauf sieht so aus:

1. Finales Artefakt bestimmen. Wählen Sie die Datei, die tatsächlich verteilt werden soll, und prüfen Sie, ob die App und ihre Komponenten vollständig sind.
2. Signierung verifizieren. Kontrollieren Sie Identität, Integrität, Zeitstempel und erforderliche Berechtigungen für die relevanten Codeobjekte.
3. Mit dem unterstützten Verfahren einreichen. Nutzen Sie für einen Xcode-typischen Ablauf den Organizer, sofern er zum Projekt passt. Für einen dokumentierten Kommandozeilenablauf können Sie notarytool verwenden. Wählen Sie nach Artefakt und Automatisierungsbedarf.
4. Abschlussstatus abwarten und lesen. Erst ein abgeschlossener, erfolgreicher Status ist ein Hinweis auf eine akzeptierte Notarisierung. Speichern Sie die Rückmeldung und das zugehörige Protokoll.
5. Protokoll auf konkrete Befunde prüfen. Ein erfolgreicher Gesamtstatus ersetzt nicht die Sichtung der betroffenen Artefakte. Bei Problemen helfen Apples Hinweise zur Behebung häufiger Notarisierungsfehler.
6. Ticket passend zum Format anheften, wenn vorgesehen. Apples Werkzeug stapler kann ein Notarisierungsticket an geeignete Artefakte anheften. Verifizieren Sie danach erneut das Paket, das Sie ausliefern.
7. Die Downloadkopie testen. Entpacken oder installieren Sie genau die veröffentlichte Datei in einer sauberen Testumgebung und starten Sie die Anwendung dort.

Das Protokoll hilft, eine konkrete Einreichung und ihre Rückmeldungen nachzuvollziehen. Das Ticket bezieht sich auf die Notarisierungsfreigabe des passenden Artefakts. Ein erfolgreicher Teststart wiederum zeigt, dass die getestete Kombination aus Betriebssystem, Paket und Umgebung funktioniert. Diese Nachweise sind nicht austauschbar.

Erfahrung für die Release-Abnahme: Bewahren Sie Protokoll und Build-Notizen zusammen mit der Versionskennung auf. Wenn später eine andere Datei verteilt wird, lässt sich der frühere Freigabestatus nicht ungeprüft auf das neue Paket übertragen.

Während der Tests: interne Nutzung nicht mit öffentlicher Verteilung verwechseln

Für interne Tests kommt es darauf an, wer testet und wie die App bereitgestellt wird. Ein enger Entwicklerkreis kann mit einer für Entwicklung und Test geeigneten Signierung arbeiten. Eine größere Testgruppe oder eine externe Kooperation kann dagegen einen geregelten Verteilungsweg erfordern. Prüfen Sie, ob Geräte registriert werden müssen, ob ein Bereitstellungsprofil dazugehört und ob die Teammitglieder die Anwendung wie spätere Nutzer installieren.

Legen Sie außerdem fest, ob interne Tester ein vorläufiges Testartefakt oder bereits den Release-Kandidaten erhalten. Wenn Ihr Team den externen Verteilungsweg prüft, sollten Testpaket und endgültige Paketierung möglichst übereinstimmen. Andernfalls kann die Testabnahme Eigenschaften bestätigen, die in der späteren Auslieferung gar nicht vorhanden sind.

Im Mac App Store ist die Einreichung über App Store Connect der maßgebliche Pfad; eine Developer-ID-Notarisierung ersetzt ihn nicht. Umgekehrt macht die bloße Übergabe einer App-Datei im Labor aus einem Entwicklungsbuild keine externe Veröffentlichung. Dokumentieren Sie deshalb pro Testgruppe: Zweck, Signieridentität, Paketversion, Installationsweg und bekannte Einschränkungen. Bei Forschungsdaten gehören auch die Vorgaben Ihrer Einrichtung zu Zugriff, Speicherung und Datenschutz in den Abnahmeplan.

FAQ: offene Fragen vor der Freigabe

Die häufigsten Verwechslungen betreffen den Unterschied zwischen Signieridentität und Verteilungsweg, den Aussagewert eines Notarisierungsstatus sowie die Grenzen eines entfernten Mac. Klären Sie diese Punkte, bevor Sie eine Anwendung an Personen außerhalb des Build-Teams übergeben.

Abnahmeliste vor der Weitergabe

• [ ] Ist dokumentiert, ob die App in den Store, öffentlich außerhalb des Stores oder nur an eine interne Testgruppe geht?
• [ ] Ist die Signieridentität für diesen Weg vorgesehen und dem richtigen Teamkonto zugeordnet?
• [ ] Sind Bundle-ID, Entitlements und verwendete Berechtigungen geprüft?
• [ ] Wurden Haupt-App und verschachtelte Komponenten in der finalen Fassung geprüft?
• [ ] Bezieht sich das Notarisierungsprotokoll auf genau das auszuliefernde Artefakt?
• [ ] Sind Status, Protokoll und gegebenenfalls angeheftetes Ticket dokumentiert?
• [ ] Wurde die finale Download- oder Installationsdatei in einer sauberen Umgebung getestet?
• [ ] Ist die fachliche Abnahme des Forschungsablaufs unabhängig von der technischen Freigabe erfolgt?

Bei fehlendem Mac: Remote-Build und fachliche Abnahme trennen

Wenn im Labor kein Mac verfügbar ist, kann eine entfernte macOS-Umgebung für Build, Signierung und Installationsprüfung eine Option sein. Voraussetzung ist, dass Sie dort die benötigten Projektdateien und Werkzeuge einsetzen dürfen und die Kontozugriffe sicher geregelt sind. Prüfen Sie vorab, wie sensible Forschungsdaten, Zugangsdaten und nicht veröffentlichter Quellcode behandelt werden. Die DSGVO-Anforderungen Ihrer Einrichtung hängen vom konkreten Datenfluss und den vereinbarten Zuständigkeiten ab; beurteilen Sie diese nicht allein anhand des Standorts eines Rechners.

Ein Remote-Zugang ersetzt nicht automatisch lokale Hardware für alle Aufgaben. Wenn der Test physische Anschlüsse, besondere Messgeräte oder lokale Peripherie erfordert, müssen Sie diese Voraussetzungen separat abdecken. Ebenso sind Fernzugriff, erfolgreiche Notarisierung und fachliche Abnahme drei unterschiedliche Resultate: Der Fernzugriff ermöglicht Arbeit an einer Umgebung, die Notarisierung betrifft ein Softwareartefakt, und die Abnahme klärt, ob das Werkzeug den vorgesehenen Forschungsablauf erfüllt.

Bei GPUMini können Sie sich über Zugang und Nutzung im Hilfe-Center informieren. Prüfen Sie vor der Entscheidung, ob der verfügbare Fernzugriff und die Laufzeit Ihres Vorhabens zu Build und Test passen; bei ungeklärten Anforderungen können Sie eine konkrete Anfrage stellen. Halten Sie für die Abnahme mindestens Build-Version, Signierstatus, Notarisierungsstatus und -protokoll sowie das Ergebnis eines Starts aus einer sauberen Umgebung fest.

Vom Prüfprotokoll zur Entscheidung über Ihre Mac-Umgebung

Der wirtschaftlich passende Weg hängt davon ab, ob Sie nur einmal signieren und veröffentlichen oder wiederholt bauen und testen müssen. Ein eigener Mac bietet unmittelbaren Zugriff und ist sinnvoll, wenn Ihre Arbeit dauerhaft macOS-spezifisch ist oder physische Geräte erfordert. Eine vorhandene Laborumgebung kann genügen, sofern Zugriff, Versionen und Zuständigkeiten verlässlich sind. Eine entfernte Mac-Umgebung lässt sich dagegen prüfen, wenn Ihnen vorübergehend ein geeigneter Build- und Abnahmeplatz fehlt.

Bleiben Sie nicht bei einem Windows- oder Linux-Rechner als vermeintlichem Ersatz für die macOS-Abnahme stehen: Er kann Quellcodeverwaltung und Teile der Entwicklungsarbeit übernehmen, führt aber den abschließenden macOS-Build und den Test der Mac-Installation nicht aus. Ein zusätzlicher Stolperstein bei einer rein lokalen Lösung sind die Beschaffung und Pflege einer passenden Maschine, die Zugriffsverwaltung und die Verfügbarkeit für andere Teammitglieder. Prüfen Sie also zuerst, welche Arbeitsschritte wirklich macOS benötigen und wie oft sie anfallen.

Wenn Ihnen ein Mac nur für einen zeitlich begrenzten Build, eine Signierung oder die Installationsabnahme fehlt, können Sie die verfügbaren GPUMini-Mac-Umgebungen ansehen und die Eignung für Ihr Projekt anhand Ihrer Zugriffs-, Datenschutz- und Geräteanforderungen prüfen. Bei dauerhaftem, regelmäßigem Bedarf oder notwendigen physischen Laboranschlüssen sollten Sie dagegen die passende lokale Ausstattung einplanen.

Häufig gestellte Fragen