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 /docs/desktop/external-accounts.md (or send Accept: text/markdown).
Create desktop release accounts
Apple signing and notarization credentials, Windows code-signing options, and the hosted backend a released shell needs.
When you need these
Local desktop work needs nothing on this page — corepack pnpm --filter @supastack/desktop dev runs the shell, and tauri build produces unsigned installers that work fine on your own machine.
These accounts matter only before a public release: code signing and Apple notarization are what remove the security warnings other people's computers show for an unknown app. Create them when a release is close, not on day one.
Apple: certificate + notarization key
1. Enroll in the Apple Developer Program — $99 per year. The same membership that submits iOS apps covers macOS signing; you do not pay twice.
2. Create a Developer ID Application certificate on a Mac: Xcode → Settings → Accounts → your account → Manage Certificates → + → Developer ID Application (Keychain Access's certificate-assistant flow is the alternative).
3. Notarization — Apple's server-side check that Gatekeeper trusts — uses an App Store Connect API key: open appstoreconnect.apple.com → Users and Access → Integrations → App Store Connect API → generate a key, download the .p8 file immediately (it is offered once), and note the Key ID and Issuer ID.
Those credentials feed the APPLE_* environment names documented in Code signing — the certificate, its password, the signing identity, and the API key/issuer pair. Keep every one in a secret store, never in the repo.
Windows code signing
Two options exist: buy an OV or EV code-signing certificate from a certificate authority — EV removes SmartScreen warnings fastest while OV builds reputation over time — or use Microsoft's Azure Trusted Signing service with an Azure account, which is the newer subscription route.
Unsigned installers still install and run; they trigger SmartScreen warnings for anyone who downloads them. That is acceptable for private testing and unacceptable for a public release.
The certificate thumbprint or a custom signtool command goes into the Windows bundle configuration — the details live in Code signing, this page only covers the account.
A public backend URL
The desktop shell is a webview, not a standalone app: a release build must load a public HTTPS backend, which you provide by baking SUPASTACK_APP_URL into the build. A shell that points at localhost is a local tool, not a product.
Deploy the web app first — the Google Cloud walkthrough produces the HTTPS URL, and the deployment checklist is the shorter reference. Set SUPASTACK_APP_URL to it when building the release.
An update endpoint
Tauri's updater checks an HTTPS latest.json manifest to learn about new versions. Any static host works — a GitHub Releases release or a file in an S3/R2 bucket — so an existing GitHub account is enough to start; no separate service is required.
That is account-level preparation only: the updater wiring itself is a release-time concern for the Bundle and release work, not something to configure now.
Done means
Check each item before release work: Apple shows an active Developer Program membership, a Developer ID Application certificate sits in Keychain, and the App Store Connect .p8 is saved with its Key ID and Issuer ID recorded. On Windows a certificate path is chosen — CA purchase or Trusted Signing — or you have explicitly decided to ship unsigned for now.
The backend check: a public HTTPS deployment exists and SUPASTACK_APP_URL for release builds points at it. The updates check: a host for latest.json is picked — GitHub Releases or a bucket.
Then continue in order:
If you want to continue setup, read Bundle and release.