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 /es/docs/desktop/external-accounts.md (or send Accept: text/markdown).
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.
Apple: certificado + clave de notarización
1. Inscríbete en el Apple Developer Program — 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 → 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.
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.
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.
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:
Si quieres continuar la configuración, lee Empaqueta y publica.