Packaging und Distribution von Electron-Apps

Das Ausliefern einer Electron-App an echte Nutzer ist eine vierstufige Pipeline: Die App wird in einen plattformnativenInstaller gepackt, signiert und notarisiert, damit Betriebssysteme ihr vertrauen, über einen für Nutzer erreichbaren Kanal verteilt, und mit Auto-Update versehen, damit sie stets aktuell bleibt. Die Wahl des Tools für diese Pipeline ist die erste Entscheidung – und 2026 läuft sie auf zwei Optionen hinaus: Electron Forge oder electron-builder. Dieser Leitfaden beschreibt den gesamten Weg mit direkt verwendbarer Konfiguration, den seit 2023 und 2024 geänderten Code-Signing-Regeln und einer funktionierenden GitHub-Actions-Matrix, die alle drei Plattformen parallel baut – denn plattformübergreifendes Bauen ist von einer einzigen Maschine aus nicht vollständig möglich.

Electron Forge vs. electron-builder im Jahr 2026

Wählen Sie Electron Forge, wenn Sie eine offiziell unterstützte All-in-one-Pipeline möchten; wählen Sie electron-builder, wenn Sie den ausgereiftesten integrierten Auto-Updater und die größte Community-Präsenz bevorzugen. Beide erzeugen signierte, aktualisierbare Installer für macOS, Windows und Linux. Der Unterschied liegt im Support-Modell und der Philosophie, nicht in den Fähigkeiten.

Electron Forge ist das vom Projekt empfohlene Tool. Es ist ein All-in-one-Tool zum Packaging und zur Distribution von Electron-Anwendungen, das viele Einzelpakete zu einer vollständigen Build-Pipeline kombiniert, die sofort einsatzbereit ist – inklusive Code-Signing, Installern und Artifact-Publishing. Forge hat die älteren Utilities @electron/packager und @electron/osx-sign in sein Makers-und-Publishers-System integriert. Entscheidend ist: Wer Electron Forge nicht verwenden möchte, muss wissen, dass andere Drittanbieter-Tools von Mitgliedern der Electron-Community gepflegt werden und keinen offiziellen Support vom Electron-Projekt erhalten.

electron-builder ist diese Community-Alternative – und die meistgeladene, mit 2–3 Millionen wöchentlichen Installationen, je nach verwendetem Zähler. Stand Juni 2026 ist die aktuelle stabile Version 26.15.3; neue Versionen erscheinen mehrmals im Monat, daher sollte die Version fixiert und vor jedem Release-Zyklus überprüft werden. Die nächste Hauptversion, v27, befindet sich Stand Juni 2026 in der Alpha-Phase (die 27.0.0-alpha-Linie): Sie migriert electron-builder zu nativen ES-Modulen, erhöht die Mindestlaufzeit auf Node.js 22.12 und entfernt lange veraltete APIs. Vor der Übernahme sollte daher eine Node- und Konfigurationsprüfung eingeplant werden – der stabile Kanal ist vorerst noch 26.x. Viele Teams greifen auf electron-builder zurück, weil es einen integrierten Updater mitbringt: electron-builder ist eine vollständige Lösung, die eine einzige Abhängigkeit hinzufügt, weitere Anforderungen intern verwaltet und von den Electron-Maintainern genutzte Features – wie den Auto-Updater – durch eigene Implementierungen ersetzt.

Dieser Artikel verwendet electron-builder für seine Konfigurationsbeispiele, da sein deklarativer package.json-Block sauber auf alle Plattformziele abbildet und sein Begleiter electron-updater der De-facto-Standard für selbst gehostete Updates ist. Die Konzepte lassen sich auf Forge übertragen, wenn der offizielle Weg bevorzugt wird.

Was ist mit Tauri?

Tauri 2.x ist die glaubwürdige, schlankere Alternative zu Electron, wenn ein Bundle von ~100 MB ein Ausschlusskriterium ist. Die UI wird über die native WebView des Betriebssystems ausgeliefert, anstatt eine vollständige Chromium-Laufzeitumgebung zu bündeln, was zu deutlich kleineren Binärdateien führt (Größenordnung, nicht exakt). Der Kompromiss ist real: Man gibt Electrons konsistentes Rendering über verschiedene Maschinen hinweg und sein umfangreiches npm- und Native-Module-Ökosystem auf und akzeptiert WebView-Versionsfragmentierung über verschiedene Nutzer-Betriebssysteme hinweg. Tauri ist die richtige Wahl für ein kleines, sicherheitskritisches Utility; Electron behält die Nase vorn, wenn UI-Konsistenz und Ökosystemtiefe wichtiger sind als der Speicherplatzbedarf.

Plattformspezifisches Packaging mit electron-builder

electron-builder erzeugt native Installer aus einem einzigen build-Block in package.json. Definieren Sie eine übergeordnete Konfiguration sowie plattformspezifische mac-, win- und linux-Schlüssel, die die gewünschten Targets benennen. Eine minimale Multi-Plattform-Konfiguration sieht so aus:

{
  "build": {
    "appId": "com.example.myapp",
    "productName": "MyApp",
    "directories": { "output": "dist" },
    "files": ["dist-app/**/*", "package.json"],
    "mac": {
      "category": "public.app-category.productivity",
      "target": ["dmg", "zip"],
      "hardenedRuntime": true,
      "notarize": true
    },
    "win": {
      "target": ["nsis"]
    },
    "linux": {
      "target": ["AppImage", "deb", "rpm"],
      "category": "Utility"
    },
    "publish": [{ "provider": "github" }]
  }
}

Jedes Target entspricht einem realen Installer-Format:

Zwei Details zu electron-builder-Targets bereiten häufig Probleme. Das zip-Target unter macOS ist beim Auto-Update nicht optional: Das zip-Target für macOS ist für Squirrel.Mac erforderlich, andernfalls kann latest-mac.yml nicht erstellt werden, was zu einem autoUpdater-Fehler führt – da das Standard-macOS-Target jedoch dmg+zip ist, muss es in der Regel nicht explizit angegeben werden. Für Auto-Updates gilt außerdem: Die macOS-Anwendung muss für automatische Updates signiert sein, und die unterstützten Standard-Targets sind DMG (macOS), AppImage/DEB/Pacman/RPM (Linux) und NSIS (Windows). Ein Build wird mit npx electron-builder --mac --win --linux gestartet, allerdings können signierte Installer für eine bestimmte Plattform nur auf (oder für) dieser Plattform vollständig gebaut werden – weshalb CI später eine entscheidende Rolle spielt.

Zur Sicherheitsgrundlage: Dieser Artikel setzt voraus, dass Ihre App bereits mit der empfohlenen Electron-Sicherheitskonfiguration läuft – einem Preload-Skript mit aktiviertem contextIsolation und deaktiviertem nodeIntegration. Liefern Sie niemals das Gegenteil aus; Packaging behebt keine unsichere Renderer-Konfiguration.

Code-Signing und Notarisierung: die Abhängigkeitskette

Hier ist die Regel, die mehr macOS-Releases scheitern lässt als alles andere: Eine unsignierte macOS-App kann einen Nutzer zwar über ein verfügbares Update benachrichtigen, es aber nicht automatisch installieren. Code-Signing ist eine Voraussetzung für die Notarisierung, und die Notarisierung ist eine Voraussetzung für ein funktionierendes macOS-Auto-Update. Die Anwendung muss für automatische Updates unter macOS signiert sein – dies ist eine Anforderung von Squirrel.Mac. Wird das Signing übersprungen, bricht die gesamte nachgelagerte Kette zusammen.

macOS: signieren, dann notarisieren

Sie benötigen ein Apple Developer ID-Zertifikat, das eine Mitgliedschaft voraussetzt. Das Apple Developer Program kostet 99 USD pro Mitgliedschaftsjahr, mit Preisen in lokaler Währung während der Registrierung – nicht „EUR 99” – und die Notarisierung ist inklusive: Als Mitglied des Apple Developer Program können Sie Mac-Apps ohne zusätzliche Kosten notarisieren. Die Notarisierung (Apples automatisierter Malware-Scan) ist seit macOS 10.15 Catalina für Developer-ID-Apps, die außerhalb des Mac App Store vertrieben werden, verpflichtend.

Setzen Sie in electron-builder hardenedRuntime: true und notarize: true im mac-Block (wie oben gezeigt) und übergeben Sie Anmeldedaten zur Build-Zeit über Umgebungsvariablen – niemals im Repository:

# macOS-Signing-Zertifikat (base64-kodiertes .p12) und sein Passwort
export CSC_LINK="$(base64 -i developer-id.p12)"
export CSC_KEY_PASSWORD="••••••"
# Notarisierungs-Anmeldedaten (App Store Connect API oder Apple ID App-spezifisches Passwort)
export APPLE_ID="you@example.com"
export APPLE_APP_SPECIFIC_PASSWORD="abcd-efgh-ijkl-mnop"
export APPLE_TEAM_ID="XXXXXXXXXX"

Windows: die SmartScreen-Änderung von 2024

Beginnen Sie Ihre Windows-Entscheidung mit der Änderung, die fast jeder ältere Leitfaden übersieht. EV-Zertifikate umgehen SmartScreen nicht mehr: Früher erzeugte das Signieren mit einem Extended-Validation-Zertifikat standardmäßig eine positive SmartScreen-Reputation, aber dieses Verhalten existiert nicht mehr, und der EV-Aufpreis allein zur Vermeidung von SmartScreen-Warnungen ist nicht mehr gerechtfertigt. Ein EV-signierter Installer baut Download-Reputation nun genauso auf wie ein günstigeres Organization-Validated-Zertifikat (OV).

Die andere Änderung betrifft den Speicherort von Schlüsseln. Seit dem 1. Juni 2023 müssen private Code-Signing-Schlüssel auf zertifizierter Hardware gespeichert werden – genau deshalb funktioniert ein USB-Token-OV-Zertifikat nicht mit headless CI. Tauris Windows-Signing-Dokumentation markiert dieselbe Grenze: Ihr Standardleitfaden gilt nur für OV-Zertifikate, die vor dem 1. Juni 2023 erworben wurden; für danach ausgestellte Zertifikate wird auf den Hardware-Token-Prozess des Ausstellers verwiesen.

Der sauberste Standard für 2026 umgeht den Token vollständig. Azure Artifact Signing – früher Trusted Signing – ist ein vollständig verwalteter, durchgängiger Code-Signing-Dienst, der in Azure integriert ist. Er signiert aus der Cloud ohne USB-Token, läuft nativ in CI/CD-Pipelines und speichert Schlüssel in von Microsoft verwalteten HSMs. Empfohlene Entscheidungsreihenfolge:

1. Azure Artifact Signing zuerst. Es ist CI-nativ und kostengünstig (Microsoft dokumentiert verbrauchsbasierte Pläne im Bereich von ~10 USD/Monat für kleine Projekte). Die Verfügbarkeit ist auf Organisationen in den USA, Kanada, der EU und dem Vereinigten Königreich beschränkt; Einzelpersonen sind derzeit auf die USA und Kanada beschränkt.
2. OV-Zertifikat von DigiCert, Sectigo oder GlobalSign, wenn Sie außerhalb dieser Regionen tätig sind. OV-Zertifikate sind für SmartScreen-Zwecke funktional gleichwertig mit Azure Artifact Signing.
3. Behalten Sie ein vorhandenes EV-Zertifikat bis zu seinem Ablauf – aber wenn Sie bereits ein EV-Zertifikat besitzen, ist es weiterhin gültig und funktionsfähig zum Signieren, obwohl der EV-Aufpreis allein zur Vermeidung von SmartScreen-Warnungen nicht mehr gerechtfertigt ist. Kaufen Sie aus diesem Grund kein neues.

Signiert vs. unsigniert

Unsignierte Builds sind für ein Entwicklerpublikum akzeptabel, das mit den Umgehungsschritten vertraut ist. Für nicht-technische Nutzer – und für jede App, die unter macOS automatisch aktualisiert wird – ist Signing nicht verhandelbar.

Auto-Updates mit electron-updater

electron-updater (der Begleiter von electron-builder) bietet plattformübergreifende, selbst gehostete Updates mit minimalem Code. Es unterstützt GitHub Releases, Amazon S3, DigitalOcean Spaces, Keygen und einen generischen HTTP(S)-Server von Haus aus und benötigt nur zwei Codezeilen, um zu funktionieren. Der häufigste Anwendungsfall:

const { autoUpdater } = require("electron-updater");

app.whenReady().then(() => {
  createWindow();
  autoUpdater.checkForUpdatesAndNotify();
});

Rufen Sie autoUpdater.checkForUpdatesAndNotify() auf – und rufen Sie setFeedURL nicht auf, da electron-builder beim Build automatisch eine interne app-update.yml-Datei erstellt. Der Hosting-Ort für Releases wird durch den publish-Block in Ihrer Build-Konfiguration festgelegt; bei Verwendung von { "provider": "github" } löst ein gepushter Tag CI aus, lädt Artifacts in ein GitHub Release hoch, und der Updater findet sie automatisch. Unter macOS bewirkt dieser Einzeiler nichts Nützliches, solange der Build nicht signiert und notarisiert ist – dieselbe Kette wie im vorherigen Abschnitt. Linux verfügt über keinen universellen Auto-Update-Mechanismus; AppImage-Updates funktionieren über electron-updater, aber deb/rpm-Nutzer aktualisieren über ihren Paketmanager.

Distributionskanäle

Wählen Sie Kanäle nach Reichweite beim Zielpublikum und danach, wie viel Umsatz und Vertrauen Sie behalten möchten:

• Eigene Website. Volle Kontrolle, signiert oder unsigniert, keine Provision, und direkt mit electron-updater über GitHub Releases oder S3 kombinierbar.
• GitHub Releases. Kostenloses Hosting, Versionsverlauf und der Weg des geringsten Widerstands für die Auto-Update-Integration.
• Mac App Store. Erhöht die Auffindbarkeit, erfordert aber Sandboxing und Review und beinhaltet Apples Standard-Provision von 30 % – reduziert auf 15 % im Rahmen des App Store Small Business Program für Entwickler mit weniger als 1 Mio. USD Jahresumsatz.
• Microsoft Store. Allein wegen des SmartScreen-Vorteils lohnenswert: Die Veröffentlichung eines MSIX-Pakets über den Microsoft Store bedeutet, dass Microsoft Ihr Paket automatisch neu signiert, sodass Nutzer keine SmartScreen-Warnung sehen und Sie kein Zertifikat kaufen oder erneuern müssen.
• Homebrew Cask. Kostenlose, entwicklerfreundliche Distribution für macOS über einen Pull Request an das Casks-Repository – ideal, um technische Nutzer über brew install zu erreichen.

Ein praktischer Hinweis: Da ein Electron-Renderer ein Chromium-Fenster ist, läuft Browser-Session-Replay-Instrumentierung unverändert in einem gepackten Desktop-Build. Dies ist eine der wenigen praktischen Möglichkeiten, UI-Regressionen zu beobachten, die erst nach dem Packaging oder Auto-Update auf dem Gerät eines Nutzers auftreten – etwa bei nativen Menü- und Tray-Pfaden, Dateidialog-Abläufen oder signierten Build-CSP-Unterschieden – und die während der Entwicklung mit electron . nie sichtbar werden.

Alle drei Plattformen in CI mit GitHub Actions bauen

Plattformübergreifendes Bauen ist lokal nicht vollständig möglich: DMG-Notarisierung benötigt macOS-Tooling, und signierte Windows-Installer benötigen Windows-Tooling. Der realistische Weg für 2026 ist eine GitHub-Actions-Matrix, die macos-latest, windows-latest und ubuntu-latest parallel ausführt, wobei Signing-Secrets als verschlüsselte Umgebungsvariablen eingebunden werden. Eine vollständige release.yml, die bei einem Tag baut und veröffentlicht:

name: Release
on:
  push:
    tags: ["v*"]

jobs:
  release:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [macos-latest, windows-latest, ubuntu-latest]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - name: Build, sign, and publish
        run: npx electron-builder --publish always
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # macOS-Signing + Notarisierung (wird nur auf macos-latest gelesen)
          CSC_LINK: ${{ secrets.MAC_CSC_LINK }}
          CSC_KEY_PASSWORD: ${{ secrets.MAC_CSC_KEY_PASSWORD }}
          APPLE_ID: ${{ secrets.APPLE_ID }}
          APPLE_APP_SPECIFIC_PASSWORD: ${{ secrets.APPLE_APP_PASSWORD }}
          APPLE_TEAM_ID: ${{ secrets.APPLE_TEAM_ID }}
          # Windows: Azure Artifact Signing-Anmeldedaten (wird nur auf windows-latest gelesen)
          AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
          AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
          AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}

Jeder Runner baut nur die Targets seiner eigenen Plattform, electron-builder signiert mit den in der Umgebung des jeweiligen Runners vorhandenen Anmeldedaten, und --publish always lädt alle Artifacts sowie die latest*.yml-Update-Metadaten in ein einzelnes GitHub Release hoch. Speichern Sie alle Secrets in Repository- oder Umgebungs-Secrets – niemals in der Workflow-Datei. Da Azure Artifact Signing mit GitHub Actions und Azure DevOps über einfache Umgebungsvariablen funktioniert, benötigt der Windows-Job weder USB-Token noch einen selbst gehosteten Runner.

Das Ausliefern einer Electron-App dreht sich weniger um einen magischen Einzelbefehl als darum, die Kette zu respektieren: signieren, um notarisieren zu können; notarisieren, damit macOS-Auto-Update funktioniert; und das Ganze in einer CI-Matrix ausführen, weil keine einzelne Maschine alle drei Plattformen bauen kann. Richten Sie den build-Block ein, fügen Sie electron-updater hinzu, committen Sie eine release.yml, und Ihr nächstes git tag v1.0.0 && git push --tags erzeugt signierte, aktualisierbare Installer für alle Plattformen auf einmal.

Häufig gestellte Fragen

Kann ich signierte Installer für macOS, Windows und Linux auf einer einzigen Maschine bauen?

Nein. DMG-Notarisierung erfordert macOS-Tooling und signierte Windows-Installer erfordern Windows-Tooling, sodass keine einzelne Maschine signierte Builds für alle drei Plattformen erzeugen kann. Sie können für die Plattform bauen, auf der Sie sich befinden, und electron-builder unterstützt eingeschränktes Cross-Targeting, aber Signing und Notarisierung sind plattformgebunden. Der realistische Ansatz für 2026 ist eine GitHub-Actions-Matrix mit macos-latest, windows-latest und ubuntu-latest parallel, wobei jeder Runner nur die Targets seiner eigenen Plattform baut und signiert.

Entfernt der Microsoft Store SmartScreen-Warnungen ohne Code-Signing-Zertifikat?

Ja. Die Veröffentlichung eines MSIX-Pakets über den Microsoft Store bedeutet, dass Microsoft Ihr Paket automatisch neu signiert, sodass Nutzer keine SmartScreen-Warnung sehen und Sie kein Zertifikat kaufen oder erneuern müssen. Dies macht den Microsoft Store zu einem effektiven Weg, sowohl Zertifikatskosten als auch den Reputationsaufbau vollständig zu umgehen. Der Kompromiss besteht in der Store-Einreichung, dem Review-Prozess und der Notwendigkeit, Ihre App als MSIX zu paketieren, anstatt einen eigenständigen NSIS- oder MSI-Installer direkt von Ihrer eigenen Website zu vertreiben.

Warum benachrichtigt meine macOS-App Nutzer über Updates, installiert sie aber nie automatisch?

Der Build ist höchstwahrscheinlich unsigniert. Unter macOS muss eine Anwendung signiert sein, damit automatische Updates funktionieren, da Squirrel.Mac dies voraussetzt. Eine unsignierte App kann erkennen und den Nutzer benachrichtigen, dass eine neue Version verfügbar ist, kann die Binärdatei jedoch nicht lautlos ersetzen. Die Lösung ist die vollständige Kette: ein Apple Developer ID-Zertifikat beschaffen, die App signieren und dann notarisieren. Code-Signing ist eine Voraussetzung für die Notarisierung, und die Notarisierung ist eine Voraussetzung für funktionierende stille macOS-Auto-Updates.

Lohnt es sich noch, für ein EV-Zertifikat zu zahlen, um SmartScreen-Warnungen unter Windows zu vermeiden?

Nein. EV-Zertifikate haben SmartScreen früher beim ersten Download vollständig umgangen, aber Microsoft hat dieses Sofort-Reputationsverhalten 2024 abgeschafft. Ein EV-signierter Installer baut Download-Reputation nun genauso auf wie ein günstigeres Organization-Validated-Zertifikat, sodass der EV-Aufpreis allein zur Vermeidung von SmartScreen nicht mehr gerechtfertigt ist. Für die meisten Teams ist 2026 der sauberere Standard Azure Artifact Signing, das aus der Cloud ohne USB-Token signiert, oder ein OV-Zertifikat, wenn Sie außerhalb der berechtigten Regionen tätig sind.