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

# Crear las cuentas de lanzamiento de escritorio

Credenciales de firma y notarización de Apple, opciones de firma de código en Windows y el backend alojado que necesita un shell publicado.

## Cuándo las necesitas

El trabajo de escritorio local no necesita nada de esta página — `corepack pnpm --filter @supastack/desktop dev` ejecuta el shell, y `tauri build` produce instaladores sin firmar que funcionan perfectamente en tu propia máquina.

Estas cuentas solo importan antes de una release pública: la firma de código y la notarización de Apple son lo que quita los avisos de seguridad que los ordenadores de otras personas muestran para una app desconocida. Créalas cuando una release esté cerca, no el primer día.

[Configurar Amazon SES con AWS SDK o IAM SMTP](https://supastack.dev/es/docs/web/aws-ses.md)


## Apple: certificado + clave de notarización

1. Inscríbete en el [Apple Developer Program](https://developer.apple.com) — 99 $ al año. La misma membresía que envía apps iOS cubre la firma de macOS; no pagas dos veces.

2. Crea un certificado Developer ID Application en un Mac: Xcode → Settings → Accounts → tu cuenta → Manage Certificates → + → Developer ID Application (el flujo del asistente de certificados de Keychain Access es la alternativa).

3. La notarización — la comprobación del lado servidor de Apple en la que Gatekeeper confía — usa una clave de API de App Store Connect: abre [appstoreconnect.apple.com](https://appstoreconnect.apple.com) → Users and Access → Integrations → App Store Connect API → genera una clave, descarga el archivo `.p8` inmediatamente (solo se ofrece una vez) y anota el Key ID y el Issuer ID.

Esas credenciales alimentan los nombres de entorno `APPLE_*` documentados en Code signing — el certificado, su contraseña, la identidad de firma y el par clave API/emisor. Guarda cada una en un almacén de secretos, nunca en el repo.

[Conectar las credenciales al build](https://supastack.dev/es/docs/desktop/signing.md)


## Firma de código en Windows

Hay dos opciones: comprar un certificado de firma de código OV o EV a una autoridad de certificación — EV quita los avisos de SmartScreen más rápido mientras que OV construye reputación con el tiempo — o usar el servicio Azure Trusted Signing de Microsoft con una cuenta de Azure, la vía de suscripción más reciente.

Los instaladores sin firmar igual se instalan y ejecutan; disparan avisos de SmartScreen para cualquiera que los descargue. Aceptable para pruebas privadas, inaceptable para una release pública.

La huella del certificado o un comando `signtool` personalizado va en la configuración del bundle de Windows — los detalles están en Code signing; esta página solo cubre la cuenta.

[Configurar la firma en Windows](https://supastack.dev/es/docs/desktop/signing.md)


## Una URL de backend pública

El shell de escritorio es una webview, no una app independiente: un build de release debe cargar un backend HTTPS público, que proporcionas horneando `SUPASTACK_APP_URL` en el build. Un shell que apunta a `localhost` es una herramienta local, no un producto.

Despliega primero la app web — la guía de Google Cloud produce la URL HTTPS, y la lista de comprobación de despliegue es la referencia más corta. Define `SUPASTACK_APP_URL` apuntando a ella al construir la release.

[Desplegar el backend en Google Cloud](https://supastack.dev/es/docs/web/deploy-google-cloud.md)

[Lista de comprobación de despliegue](https://supastack.dev/es/docs/web/deployment.md)


## Un endpoint de actualización

El updater de Tauri consulta un manifiesto HTTPS `latest.json` para enterarse de nuevas versiones. Cualquier host estático sirve — una release de GitHub Releases o un archivo en un bucket S3/R2 — así que una cuenta de GitHub existente basta para empezar; no se requiere servicio aparte.

Eso es solo preparación a nivel de cuenta: el cableado del updater en sí es un asunto del momento de la release para el trabajo de Bundle y release, no algo que configurar ahora.


## Qué significa «terminado»

Revisa cada elemento antes del trabajo de release: Apple muestra una membresía del Developer Program activa, un certificado Developer ID Application está en el Llavero, y la `.p8` de App Store Connect está guardada con su Key ID e Issuer ID anotados. En Windows hay un camino de certificado elegido — compra a una CA o Trusted Signing — o has decidido explícitamente lanzar sin firmar por ahora.

La comprobación del backend: existe un despliegue HTTPS público y `SUPASTACK_APP_URL` para builds de release apunta a él. La comprobación de actualizaciones: hay un host elegido para `latest.json` — GitHub Releases o un bucket.

Luego continúa en orden:

[Empaqueta y publica](https://supastack.dev/es/docs/desktop/release.md)

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

[Desplegar el backend compartido](https://supastack.dev/es/docs/web/deployment.md)


Si quieres continuar la configuración, lee [Empaqueta y publica](https://supastack.dev/es/docs/desktop/release.md).


## Siguiente

[Empaqueta y publica](https://supastack.dev/es/docs/desktop/release.md)
