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

# Criar as contas de lançamento de desktop

Credenciais de assinatura e notarização Apple, opções de assinatura de código no Windows e o backend alojado de que um shell publicado precisa.

## Quando precisa delas

O trabalho de desktop local não precisa de nada desta página — `corepack pnpm --filter @supastack/desktop dev` executa o shell, e `tauri build` produz instaladores não assinados que funcionam perfeitamente na sua própria máquina.

Estas contas só importam antes de uma release pública: a assinatura de código e a notarização Apple são o que remove os avisos de segurança que os computadores das outras pessoas mostram para uma app desconhecida. Crie-as quando uma release estiver próxima, não no primeiro dia.

[Configurar Amazon SES com SDK AWS ou IAM SMTP](https://supastack.dev/pt/docs/web/aws-ses.md)


## Apple: certificado + chave de notarização

1. Inscreva-se no [Apple Developer Program](https://developer.apple.com) — 99 $ por ano. A mesma adesão que submete apps iOS cobre a assinatura de macOS; não paga duas vezes.

2. Crie um certificado Developer ID Application num Mac: Xcode → Settings → Accounts → a sua conta → Manage Certificates → + → Developer ID Application (o fluxo certificate-assistant do Acesso a Chaves é a alternativa).

3. A notarização — a verificação do lado do servidor da Apple em que o Gatekeeper confia — usa uma chave de API do App Store Connect: abra [appstoreconnect.apple.com](https://appstoreconnect.apple.com) → Users and Access → Integrations → App Store Connect API → gere uma chave, descarregue o ficheiro `.p8` de imediato (só é oferecido uma vez) e anote o Key ID e o Issuer ID.

Essas credenciais alimentam os nomes de ambiente `APPLE_*` documentados em Code signing — o certificado, a sua palavra-passe, a identidade de assinatura e o par chave de API/emissor. Guarde cada uma num cofre de segredos, nunca no repositório.

[Ligar as credenciais à build](https://supastack.dev/pt/docs/desktop/signing.md)


## Assinatura de código no Windows

Existem duas opções: comprar um certificado de assinatura de código OV ou EV a uma autoridade de certificação — EV remove os avisos de SmartScreen mais depressa enquanto OV constrói reputação com o tempo — ou usar o serviço Azure Trusted Signing da Microsoft com uma conta Azure, a via de subscrição mais recente.

Os instaladores não assinados instalam e executam na mesma; disparam avisos de SmartScreen para quem os descarrega. Aceitável para testes privados, inaceitável para uma release pública.

A impressão digital do certificado ou um comando `signtool` personalizado vai na configuração do bundle Windows — os detalhes estão em Code signing; esta página só cobre a conta.

[Configurar a assinatura no Windows](https://supastack.dev/pt/docs/desktop/signing.md)


## Um URL de backend público

O shell de desktop é uma webview, não uma app autónoma: uma build de release tem de carregar um backend HTTPS público, que fornece incluindo `SUPASTACK_APP_URL` na build. Um shell que aponta para `localhost` é uma ferramenta local, não um produto.

Implemente a app web primeiro — o caminho Google Cloud produz o URL HTTPS, e a lista de verificação de implementação é a referência mais curta. Defina `SUPASTACK_APP_URL` a apontar para ele ao construir a release.

[Implementar o backend no Google Cloud](https://supastack.dev/pt/docs/web/deploy-google-cloud.md)

[Checklist de deployment](https://supastack.dev/pt/docs/web/deployment.md)


## Um endpoint de atualização

O updater do Tauri consulta um manifesto HTTPS `latest.json` para saber das novas versões. Qualquer host estático serve — uma release do GitHub Releases ou um ficheiro num bucket S3/R2 — por isso uma conta GitHub existente chega para começar; não é necessário serviço separado.

Isso é apenas preparação ao nível da conta: a ligação do updater em si é assunto do trabalho Bundle e release no momento da release, não algo a configurar agora.


## O que significa «concluído»

Verifique cada item antes do trabalho de release: a Apple mostra uma adesão ativa ao Developer Program, um certificado Developer ID Application está no Acesso a Chaves, e o `.p8` do App Store Connect está guardado com o Key ID e o Issuer ID anotados. No Windows há um caminho de certificado escolhido — compra a uma AC ou Trusted Signing — ou decidiu explicitamente lançar sem assinatura por agora.

A verificação do backend: existe uma implementação HTTPS pública e `SUPASTACK_APP_URL` para builds de release aponta para ela. A verificação de atualizações: está escolhido um host para `latest.json` — GitHub Releases ou um bucket.

Depois continue pela ordem:

[Empacote e publique](https://supastack.dev/pt/docs/desktop/release.md)

[Assinatura de código](https://supastack.dev/pt/docs/desktop/signing.md)

[Implementar o backend partilhado](https://supastack.dev/pt/docs/web/deployment.md)


Para continuar a configuração, leia [Empacote e publique](https://supastack.dev/pt/docs/desktop/release.md).


## Seguinte

[Empacote e publique](https://supastack.dev/pt/docs/desktop/release.md)