Electron 44 macOS-Paketierung braucht einen Mac? CI-Lösung 2026

Ein Electron-Projekt kann unter Windows oder Linux entwickelt werden. Auch ein macOS-Artefakt ohne gültige Signatur lässt sich in vielen Projekten erzeugen. Das beantwortet aber nicht die wichtigere Release-Frage: Kann eine unbeteiligte Person die Anwendung auf macOS installieren, die Sicherheitsprüfung passieren und spätere Updates erhalten?

Electron trennt in seiner Übersicht zur Anwendungsverteilung mehrere Aufgaben:

1. Anwendung und Installer paketieren.
2. Native Komponenten für das Zielsystem bereitstellen.
3. Die Anwendung mit einer passenden Identität signieren.
4. Das Produkt bei Apple zur Notarisierung einreichen.
5. Das Ticket an das Produkt heften.
6. Das finale Paket unter einem sauberen Benutzerkonto installieren und prüfen.

Diese Schritte sind nicht austauschbar. Ein erfolgreicher CI-Job beweist nur, dass die ausgeführten Befehle keinen Fehler zurückgegeben haben. Er beweist nicht automatisch, dass die Signatur vollständig ist, die Notarisierung genehmigt wurde oder die ausgelieferte Datei tatsächlich mit einem frischen macOS-Benutzerkonto funktioniert.

Electron 44 wurde laut offizieller Veröffentlichungsmitteilung vom 25.08.2026 veröffentlicht. Für eine 2026-Pipeline sollten Sie daher die konkrete Electron-44-Version, die verwendete Architektur und die dazugehörigen Abhängigkeiten im Build-Protokoll festhalten.

Kann eine Electron-Anwendung unter Windows ein macOS-Installationspaket erzeugen?
Sie kann je nach Projektstruktur ein nicht signiertes macOS-Artefakt erzeugen. Für ein verteilbares Produkt reicht das nicht als Abnahmekriterium. Sobald native Module, Apple-Zertifikate, Keychain-Zugriff, Entitlements oder Notarisierung relevant werden, sollte der letzte Teil der Kette auf einem echten Mac stattfinden.

Ein reines JavaScript-Projekt ist bei der Zielplattform weniger empfindlich. Viele reale Electron-Anwendungen enthalten jedoch Node-Module mit nativen Erweiterungen, Hilfsprogramme, Dateiüberwacher, Datenbanktreiber oder eigene Binärdateien. Diese Bestandteile müssen zur Zielarchitektur passen.

Die Electron-Installationsdokumentation beschreibt die Bedeutung von Betriebssystem und Prozessorarchitektur für Electron-Abhängigkeiten. Für die Prüfung sollten Sie mindestens unterscheiden:

• darwin-arm64
• darwin-x64
• ein Universal-Build, sofern die jeweilige Abhängigkeit ihn tatsächlich unterstützt

Ein Verzeichnis, das unter Linux korrekt installiert wurde, ist deshalb kein Beweis für eine funktionierende macOS-Anwendung. Kritisch sind insbesondere Postinstall-Skripte, vorgefertigte Binärdateien und Module, die während npm install, pnpm install oder yarn install nach Plattform und Architektur auswählen.

Erste Schritt: Abhängigkeiten reproduzierbar erfassen

Beginnen Sie mit einem festen Commit und einer gesperrten Lock-Datei. Übergeben Sie genau diesen Commit an den Mac-Runner. Lassen Sie den Runner die Abhängigkeiten in einem frischen Arbeitsverzeichnis installieren. Vermeiden Sie eine gemeinsam genutzte node_modules-Struktur zwischen Windows, Linux und macOS.

Prüfen Sie anschließend:

• Wird jedes native Modul für die Zielarchitektur installiert?
• Werden während des Builds zusätzliche Binärdateien heruntergeladen?
• Enthält das gepackte Produkt wirklich alle benötigten Hilfsdateien?
• Lädt die Anwendung die nativen Komponenten nach der Installation?
• Funktioniert der Start auch mit einem Benutzerkonto ohne Entwicklerwerkzeuge?

Der echte Mac hat hier eine andere Aufgabe als ein bloßer Ziel-Runner. Er dient nicht dazu, einen bereits erzeugten Ordner blind zu kopieren. Er soll nachweisen, dass Installation, Neuaufbau und Laden der nativen Komponenten unter der realen Zielumgebung funktionieren.

Achtung: Ein grüner Build auf Linux kann eine falsche Architektur nur deshalb verbergen, weil das betreffende Modul dort aus dem Quellcode kompiliert wurde. Die macOS-Prüfung muss deshalb eine Neuinstallation und einen echten Starttest einschließen.

Für die öffentliche macOS-Verteilung empfiehlt Electron eine Codesignatur. Die Electron-Dokumentation zur Codesignatur erklärt, weshalb unsignierte oder falsch signierte Anwendungen beim Start und bei der Verteilung Probleme verursachen können.

Bei einer typischen Desktop-Anwendung müssen Sie mehrere Ebenen auseinanderhalten:

• die Signatur der Anwendung selbst,
• eingebettete Frameworks,
• Helper-Prozesse,
• native Erweiterungen,
• den Installer oder das Disk-Image,
• Entitlements und Hardened Runtime,
• den privaten Schlüssel im Schlüsselbund.

Electron Forge beschreibt in seiner Anleitung zur macOS-Signierung, wie eine Forge-Pipeline die macOS-Signatur einbindet. Ergänzend dokumentiert @electron/osx-sign relevante Optionen und Konfigurationswerte. Verwenden Sie in Beispielen ausschließlich Platzhalter wie <BUNDLE_ID>, <TEAM_ID>, <ZERTIFIKAT> und <KEYCHAIN_PFAD>.

Warum braucht die Electron-macOS-Codesignatur einen Mac?
Die Signatur hängt an Apples Zertifikats- und Schlüsselbundmodell. Der private Schlüssel muss in einer kontrollierten Keychain verfügbar sein, und die Signatur muss auf den tatsächlich gebauten macOS-Bestandteilen liegen. Ein Windows- oder Linux-Runner kann die Quelltexte vorbereiten, ersetzt aber nicht die macOS-seitige Prüfung des signierten Produkts.

Die entscheidende Sicherheitsfrage ist nicht nur, ob der Mac erreichbar ist. Sie lautet: Welche CI-Aufgabe darf den privaten Schlüssel verwenden?

Empfohlen ist ein eigenes Build-Konto mit:

• einer separaten, nur für Releases bestimmten Keychain,
• minimalen Dateirechten,
• keinem interaktiven Entwicklerprofil,
• einem kurzlebigen Zugriff auf CI-Geheimnisse,
• getrennten Variablen für Zertifikat, Team-ID, Bundle-ID und Notarisierungszugang,
• vollständigen, aber zugriffsgeschützten Logs.

Ein gemeinsamer Mac-Runner für beliebige Pull Requests ist für diesen Zweck ungeeignet, wenn dort dieselbe Signaturidentität liegt. Pull-Request-Builds sollten ohne produktive Zertifikate laufen. Die Signatur gehört in einen geschützten Release-Job mit manueller Freigabe oder einer gleichwertigen Zugriffskontrolle.

Nach der Codesignatur ist das Produkt noch nicht automatisch zur Auslieferung bereit. Apple beschreibt die Notarisierung von macOS-Software als eigenen Verarbeitungsschritt. Für die technische Umsetzung kommen laut Apple unter anderem notarytool und die Notary API infrage.

Die Pipeline muss deshalb mindestens diese Zustände unterscheiden:

Ein erfolgreicher Upload ist kein positives Notarisierungsergebnis. Eine genehmigte Notarisierung ist wiederum kein Beweis, dass das richtige Artefakt angeheftet wurde. Wenn ein Job mehrere Archive erzeugt, muss die Pipeline die konkrete Datei mit Hash, Commit-ID und Submission-ID verbinden.

Wie erledigt Electron Forge die Notarisierung in CI?
Forge kann den Build-Lebenszyklus für Paketierung und Veröffentlichung strukturieren. Die Dokumentation zum Forge-Build-Lebenszyklus hilft dabei, die Stufen voneinander zu trennen. Die Zugangsdaten, <TEAM_ID>, <BUNDLE_ID>, Schlüsseldateien und Submission-Referenzen bleiben dabei CI-Geheimnisse. Sie gehören weder in das Repository noch in frei lesbare Build-Ausgaben.

Apple beschreibt den Notarisierungs-Workflow als Verarbeitung mit Statusabfrage und Ergebnisprüfung. Speichern Sie daher bei jedem Release:

• Commit-ID und Lock-Datei,
• Hash des hochgeladenen Archivs,
• verwendete Bundle-ID,
• Team-ID als geschützte Konfiguration,
• Submission-ID,
• vollständiges Ergebnisprotokoll,
• Ergebnis der Ticket-Prüfung,
• Installations- und Update-Protokoll.

Erfahrung aus der Release-Praxis: Wenn nur „Notarization succeeded“ im CI-Log steht, fehlt für eine spätere Ursachenanalyse meist der Nachweis, welches Archiv eingereicht wurde. Bewahren Sie die Originalantwort und die Artefakt-Prüfung gemeinsam auf.

Die sinnvollste Architektur ist meistens kein vollständiger Umzug auf macOS. Sie teilt die Arbeit nach Plattformabhängigkeit auf:

• Windows oder Linux: Linting, Unit-Tests, statische Analyse, allgemeine Paketprüfungen und plattformunabhängige Builds.
• Echter Mac: macOS-Abhängigkeiten installieren, macOS-Artefakt bauen, signieren, notarisieren, Ticket anheften und auf einem sauberen Konto testen.

Wie veröffentlicht ein Windows-Team eine Electron-Anwendung für Mac?
Es lässt den Quellcode und die allgemeinen Prüfungen auf Windows laufen, übergibt einen eindeutig versionierten Commit an den Mac-Job und erzeugt dort das finale macOS-Artefakt. Danach folgen Signatur, Notarisierung, Ticket-Prüfung, Installation und Update-Test. Der Mac-Job sollte nicht einfach den aktuellen Branch erneut klonen, weil sich dadurch zwischen den Runnern ein anderer Quellstand ergeben kann.

Für einen ersten Produktionslauf kann ein Remote-Mac-Arbeitsplatz von MESHLAUNCH als zeitlich begrenzte Release-Umgebung dienen. Entscheidend ist dabei nicht die Bezeichnung „Cloud“, sondern ob die Umgebung einen echten Mac, kontrollierten Schlüsselbund, reproduzierbare Zugänge und nachvollziehbare Artefakte bietet.

1. Eingabe einfrieren

Starten Sie mit <COMMIT_SHA>, der Lock-Datei und einer dokumentierten Electron-44-Version. Übergeben Sie zusätzlich Prüfsummen der Eingabeartefakte. Der Mac-Job darf nicht stillschweigend eine andere Branch-Spitze verwenden.

2. Abhängigkeiten frisch installieren

Löschen Sie vorhandene Installationsverzeichnisse oder verwenden Sie einen frischen Arbeitsbereich. Installieren Sie die Abhängigkeiten mit dem im Projekt festgelegten Paketmanager. Protokollieren Sie Betriebssystem, Architektur, Node-Version und den Status nativer Module.

3. macOS-Paket erzeugen

Führen Sie die für das Projekt festgelegte Forge- oder Builder-Konfiguration aus. Prüfen Sie danach die erzeugte Bundle-ID, die enthaltenen Helper und die Architektur. Ein erzeugtes .app-Verzeichnis ist zunächst nur ein Zwischenartefakt.

4. Signieren und notarisieren

Laden Sie Zertifikate und Notarisierungszugänge erst im geschützten Release-Job. Signieren Sie die Anwendung mit der vorgesehenen Entitlements-Datei. Reichen Sie genau das archivierte Produkt ein. Warten Sie das Ergebnis ab, heften Sie das Ticket an und speichern Sie alle IDs.

5. Unabhängig installieren

Kopieren Sie das finale Installationspaket in einen sauberen Testbereich. Installieren Sie es mit einem Konto ohne Entwicklerkonfiguration. Starten Sie die Anwendung, prüfen Sie native Funktionen und führen Sie anschließend ein Update von der vorherigen Version aus. Bewahren Sie die vorherige freigegebene Version als Rückfalloption auf.

Die Abnahme sollte nicht mit dem CI-Job enden. Verwenden Sie folgende Checkliste:

• [ ] Neuer Arbeitsbereich aus einem festgehaltenen Commit erstellt
• [ ] Lock-Datei und Installationsprotokoll archiviert
• [ ] Zielarchitektur der nativen Module geprüft
• [ ] Electron-44-Anwendung auf dem echten Mac gebaut
• [ ] Bundle-ID und Signaturidentität kontrolliert
• [ ] Entitlements und Hardened-Runtime-Konfiguration geprüft
• [ ] Notarisierungs-Submission-ID gespeichert
• [ ] Genehmigung und Originalmeldung archiviert
• [ ] Ticket am finalen Artefakt geprüft
• [ ] Installation mit einem sauberen Benutzerkonto durchgeführt
• [ ] Start, Dateizugriff und native Funktionen getestet
• [ ] Update von der vorherigen Version geprüft
• [ ] Neustart des Mac und erneuter Zugriff auf die geschützte Keychain getestet
• [ ] Release-Artefakt und Rückfallversion getrennt gespeichert

Für die Wahl des Betriebsmodells zählen dabei nicht nur Build-Aufgaben. Prüfen Sie auch Wiederanlauf, Schlüsselbund-Zugriff, Konto-Sperren, Geheimnisrotation und die DSGVO-konforme Behandlung von Quellcode und Logs. Wenn der Release-Knoten nach einem Neustart manuell repariert werden muss, ist er kein zuverlässig automatisierter Knoten.

Wer zusätzlich eine physische Alternative kalkuliert, kann die Mac-mini-Optionen für Entwickler als Vergleichspunkt heranziehen. Der Kauf ist nachvollziehbar, wenn ein Team dauerhaft hohe Release-Frequenz, eigene Hardwarekontrolle oder physische Schnittstellen benötigt. Für ein seltenes Release ist gebundenes Kapital dagegen nicht automatisch die bessere technische Entscheidung.

Ein Projekt in der Erprobung sollte nicht sofort einen dauerhaft privilegierten Mac-Runner betreiben. Starten Sie mit einem kurzen, kontrollierten Remote-Mac-Lauf. Bauen Sie aus einem sauberen Arbeitsbereich. Beweisen Sie Signatur, Notarisierung, Ticket, Installation und Update in einem dokumentierten Durchgang.

Bei regelmäßigen Veröffentlichungen verschiebt sich die Entscheidung. Ein dedizierter Mac-Runner kann sinnvoll werden, wenn die Pipeline häufig läuft, die Schlüsselverwaltung automatisiert ist und der Ausfall eines einzelnen Knotens abgefedert wird. Eine zweite Release-Route bleibt trotzdem wertvoll: Ein Backup-Runner oder ein kurzfristig aktivierbarer Remote Mac verhindert, dass ein Hardware- oder Keychain-Problem die Veröffentlichung blockiert.

Die wichtigsten Nachteile der bisherigen Windows-/Linux-only-Lösung sind klar: Sie kann die reale macOS-Installation nicht vollständig abnehmen, sie verdeckt Fehler bei nativen Zielarchitekturen und sie verschiebt Signatur- sowie Notarisierungsprobleme bis kurz vor die Veröffentlichung. Ein Hackintosh oder eine unkontrollierte virtuelle Umgebung fügt zusätzlich Reproduzierbarkeits-, Wartungs- und Compliance-Fragen hinzu. Für einen einzelnen oder seltenen Release ist ein kurzer MESHLAUNCH-Mietzeitraum deshalb oft der sauberere Weg: Sie erhalten einen echten Mac für die kritische Kette, ohne sofort eine dauerhaft betriebene Hardware- und Schlüsselbund-Infrastruktur aufzubauen.

Wenn Ihre Anwendung bereits regelmäßig veröffentlicht wird, sollten Sie die Ergebnisse dieses ersten Laufs als Betriebsdaten verwenden: Welche Schritte benötigen privilegierten Zugriff? Was passiert nach einem Neustart? Welche Artefakte müssen zurückrollbar sein? Erst danach lässt sich begründet entscheiden, ob Miete, Kauf oder ein zweigleisiger Betrieb wirtschaftlich und sicher ist.