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 /it/docs/desktop/external-accounts.md (or send Accept: text/markdown).
Crea gli account di rilascio desktop
Credenziali di firma e notarizzazione Apple, opzioni di firma del codice su Windows e il backend ospitato di cui una shell pubblicata ha bisogno.
Quando servono
Il lavoro desktop in locale non richiede nulla di questa pagina — corepack pnpm --filter @supastack/desktop dev esegue la shell, e tauri build produce installer non firmati che funzionano benissimo sulla tua macchina.
Questi account contano solo prima di una release pubblica: la firma del codice e la notarizzazione di Apple sono ciò che elimina gli avvisi di sicurezza che i computer altrui mostrano per un'app sconosciuta. Creali quando una release si avvicina, non il primo giorno.
Apple: certificato + chiave di notarizzazione
1. Iscriviti al programma Apple Developer — 99 $ all'anno. La stessa iscrizione che invia app iOS copre la firma di macOS; non paghi due volte.
2. Crea un certificato Developer ID Application su un Mac: Xcode → Settings → Accounts → il tuo account → Manage Certificates → + → Developer ID Application (il flusso certificate-assistant di Accesso Portachiavi è l'alternativa).
3. La notarizzazione — il controllo lato server di Apple di cui Gatekeeper si fida — usa una chiave API di App Store Connect: apri appstoreconnect.apple.com → Users and Access → Integrations → App Store Connect API → genera una chiave, scarica subito il file .p8 (viene offerto una sola volta) e annota il Key ID e l'Issuer ID.
Queste credenziali alimentano i nomi di ambiente APPLE_* documentati in Code signing — il certificato, la sua password, l'identità di firma e la coppia chiave API/emittente. Conserva ciascuna in un archivio dei segreti, mai nel repo.
Firma del codice su Windows
Esistono due opzioni: acquistare un certificato di firma del codice OV o EV da un'autorità di certificazione — EV rimuove gli avvisi SmartScreen più in fretta mentre OV costruisce reputazione nel tempo — oppure usare il servizio Azure Trusted Signing di Microsoft con un account Azure, la via in abbonamento più recente.
Gli installer non firmati si installano ed eseguono comunque; attivano avvisi SmartScreen per chiunque li scarichi. Accettabile per test privati, inaccettabile per una release pubblica.
L'impronta del certificato o un comando signtool personalizzato va nella configurazione del bundle Windows — i dettagli sono in Code signing; questa pagina copre solo l'account.
Un URL di backend pubblico
La shell desktop è una webview, non un'app autonoma: una build di release deve caricare un backend HTTPS pubblico, che fornisci incorporando SUPASTACK_APP_URL nella build. Una shell che punta a localhost è uno strumento locale, non un prodotto.
Distribuisci prima l'app web — il percorso Google Cloud produce l'URL HTTPS, e la checklist di distribuzione è il riferimento più breve. Imposta SUPASTACK_APP_URL su di esso quando costruisci la release.
Un endpoint di aggiornamento
L'updater di Tauri interroga un manifesto HTTPS latest.json per sapere le nuove versioni. Qualsiasi host statico va bene — una release di GitHub Releases o un file in un bucket S3/R2 — quindi un account GitHub esistente basta per iniziare; non serve un servizio separato.
È solo preparazione a livello di account: il cablaggio dell'updater vero e proprio riguarda il lavoro Bundle e release al momento dell'uscita, non qualcosa da configurare ora.
Cosa significa «finito»
Controlla ogni voce prima del lavoro di release: Apple mostra un'iscrizione Developer Program attiva, un certificato Developer ID Application è nel Portachiavi, e la .p8 di App Store Connect è salvata con il suo Key ID e l'Issuer ID annotati. Su Windows è stato scelto un percorso di certificato — acquisto da una CA o Trusted Signing — oppure hai deciso esplicitamente di distribuire senza firma per ora.
Il controllo del backend: esiste una distribuzione HTTPS pubblica e SUPASTACK_APP_URL per le build di release punta a essa. Il controllo degli aggiornamenti: è stato scelto un host per latest.json — GitHub Releases o un bucket.
Poi prosegui nell'ordine: