> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# 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.

[Set up Amazon SES with AWS SDK or IAM SMTP](https://supastack.dev/docs/web/aws-ses.md)


## Apple: certificate + notarization key

1. Enroll in the [Apple Developer Program](https://developer.apple.com) — $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](https://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.

[Wire the credentials into the build](https://supastack.dev/docs/desktop/signing.md)


## 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.

[Configure Windows signing](https://supastack.dev/docs/desktop/signing.md)


## 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.

[Deploy the backend to Google Cloud](https://supastack.dev/docs/web/deploy-google-cloud.md)

[Deployment checklist](https://supastack.dev/docs/web/deployment.md)


## 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:

[Bundle and release](https://supastack.dev/docs/desktop/release.md)

[Code signing](https://supastack.dev/docs/desktop/signing.md)

[Deploy the shared backend](https://supastack.dev/docs/web/deployment.md)


If you want to continue setup, read [Bundle and release](https://supastack.dev/docs/desktop/release.md).


## Next

[Bundle and release](https://supastack.dev/docs/desktop/release.md)