For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /de/docs/desktop/external-accounts.md (or send Accept: text/markdown).
Desktop-Release-Konten einrichten
Apple-Signierungs- und Notarisierungs-Zugangsdaten, Windows-Code-Signing-Optionen und das gehostete Backend, das eine veröffentlichte Shell braucht.
Wann Sie sie brauchen
Lokale Desktop-Arbeit braucht nichts von dieser Seite — corepack pnpm --filter @supastack/desktop dev startet die Shell, und tauri build erzeugt unsignierte Installer, die auf Ihrem eigenen Rechner problemlos laufen.
Diese Konten werden erst vor einer öffentlichen Veröffentlichung wichtig: Code-Signierung und Apple-Notarisierung entfernen die Sicherheitswarnungen, die die Rechner anderer Leute für eine unbekannte App zeigen. Legen Sie sie an, wenn ein Release nah ist — nicht am ersten Tag.
Apple: Zertifikat + Notarisierungs-Key
1. Nehmen Sie am Apple Developer Program teil — 99 $ pro Jahr. Dieselbe Mitgliedschaft, die iOS-Apps einreicht, deckt die macOS-Signierung; Sie zahlen nicht doppelt.
2. Erstellen Sie ein Developer-ID-Application-Zertifikat auf einem Mac: Xcode → Settings → Accounts → Ihr Konto → Manage Certificates → + → Developer ID Application (der Certificate-Assistant-Flow von Keychain Access ist die Alternative).
3. Die Notarisierung — Apples serverseitige Prüfung, der Gatekeeper vertraut — nutzt einen App-Store-Connect-API-Key: Öffnen Sie appstoreconnect.apple.com → Users and Access → Integrations → App Store Connect API → generieren Sie einen Key, laden Sie die .p8-Datei sofort herunter (sie wird nur einmal angeboten) und notieren Sie Key ID und Issuer ID.
Diese Zugangsdaten speisen die APPLE_*-Umgebungsnamen aus Code signing — das Zertifikat, sein Passwort, die Signing-Identität und das API-Key/Issuer-Paar. Bewahren Sie jedes davon in einem Secret Store auf, nie im Repo.
Windows-Code-Signierung
Es gibt zwei Optionen: ein OV- oder EV-Code-Signing-Zertifikat von einer Zertifizierungsstelle kaufen — EV baut SmartScreen-Warnungen am schnellsten ab, während OV mit der Zeit Reputation aufbaut — oder Microsofts Azure-Trusted-Signing-Dienst mit einem Azure-Konto nutzen, der neuere Abo-Weg.
Unsignierte Installer installieren und laufen trotzdem; sie lösen SmartScreen-Warnungen bei jedem aus, der sie herunterlädt. Für private Tests akzeptabel, für eine öffentliche Veröffentlichung nicht.
Der Zertifikats-Fingerprint oder ein eigener signtool-Befehl kommt in die Windows-Bundle-Konfiguration — die Details stehen in Code signing; diese Seite deckt nur das Konto ab.
Eine öffentliche Backend-URL
Die Desktop-Shell ist ein Webview, keine eigenständige App: Ein Release-Build muss ein öffentliches HTTPS-Backend laden, das Sie bereitstellen, indem Sie SUPASTACK_APP_URL in den Build backen. Eine Shell, die auf localhost zeigt, ist ein lokales Werkzeug, kein Produkt.
Deployen Sie die Web-App zuerst — die Google-Cloud-Anleitung erzeugt die HTTPS-URL, und die Deployment-Checkliste ist die kürzere Referenz. Setzen Sie SUPASTACK_APP_URL beim Bauen des Release darauf.
Ein Update-Endpunkt
Tauris Updater prüft ein HTTPS-latest.json-Manifest, um von neuen Versionen zu erfahren. Jeder statische Host reicht — ein GitHub-Releases-Release oder eine Datei in einem S3/R2-Bucket — ein bestehendes GitHub-Konto reicht also zum Start; kein separater Dienst nötig.
Das ist nur Konto-Vorbereitung: Die Updater-Verkabelung selbst ist eine Release-Aufgabe für die Bundle- und Release-Arbeit, nichts, was Sie jetzt konfigurieren.
Was „fertig“ bedeutet
Prüfen Sie jeden Punkt vor der Release-Arbeit: Apple zeigt eine aktive Developer-Program-Mitgliedschaft, ein Developer-ID-Application-Zertifikat liegt im Schlüsselbund, und die App-Store-Connect-.p8 ist gespeichert, mit Key ID und Issuer ID notiert. Auf Windows ist ein Zertifikatsweg gewählt — CA-Kauf oder Trusted Signing — oder Sie haben ausdrücklich beschlossen, vorerst unsigniert auszuliefern.
Die Backend-Prüfung: Ein öffentliches HTTPS-Deployment existiert, und SUPASTACK_APP_URL für Release-Builds zeigt darauf. Die Update-Prüfung: Ein Host für latest.json ist gewählt — GitHub Releases oder ein Bucket.
Dann in Reihenfolge weiter: