> ## 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 # Pubblicazione sugli store Distingui una build funzionante da una release installabile dagli utenti. ## Prepara il tuo primo invio al negozio passo dopo passo Per prima cosa crea e testa una build di sviluppo nativa utilizzando le build per dispositivi mobili. Un invio allo store invia l'app compilata e il relativo elenco a Google o Apple per la revisione; non è la stessa cosa che aprire un'anteprima Expo Go. Hai bisogno del tuo Expo e dei relativi account sviluppatore del negozio, un backend HTTPS testato, nome/icona finale dell'app, screenshot, contatto di supporto e un'informativa sulla privacy pubblica URL. Apri apps/mobile/app.json nell'editor e imposta il nome dell'app, lo slug, ios.bundleIdentifier e android.package per il tuo prodotto prima del primo caricamento. Apri apps/mobile/eas.json e sostituisci gli identificatori dell'app del team di invio iOS con i tuoi dove richiesto. Gli identificatori spediti sono esempi. Leggi le build mobili per i campi esatti e chiedi al tuo agente di codifica di rivedere i due file prima della creazione. Se eas non è installato, esegui npm install --global eas-cli. Dalla root del repository utilizza il comando di accesso riportato di seguito, completa l'autenticazione del browser, quindi seleziona il comando build per una piattaforma in Build, quindi invia. Leggere i registri della dashboard della build; attendere un file .aab o .ipa riuscito prima di tentare l'invio. EAS richiede il collegamento del progetto e le credenziali di firma; questi appartengono ai tuoi account, non a quelli del venditore del kit. Dopo aver caricato il codice binario, apri la tua app in Play Console o App Store Connect, completa l'elenco e i questionari richiesti, aggiungi le istruzioni di accesso per il revisore funzionante, quindi invia per la revisione lì. Il caricamento di una bozza interna non è una versione pubblica. Se la revisione lo rifiuta, apri il collegamento esatto alla politica nel rifiuto e correggi il problema prima di inviarlo nuovamente. [Preparare la build nativa e gli identificatori](https://supastack.dev/it/docs/mobile/builds.md) [Istruzioni attuali per l'invio al negozio di Expo](https://docs.expo.dev/submit/introduction/) [Le attuali linee guida per la revisione delle app di Apple](https://developer.apple.com/app-store/review/guidelines/) [Istruzioni sulla versione di Google Play](https://support.google.com/googleplay/android-developer/answer/9859455) ``` corepack pnpm --filter @supastack/mobile exec eas login ``` ## Configura gli account una volta L'invio allo Store richiede tre account: un account Expo gratuito per EAS Build and Submit, una registrazione per sviluppatori Google Play Console e un'iscrizione all'Apple Developer Program per iOS. Installa EAS CLI ed esegui eas login prima della costruzione; la verifica delle iscrizioni in entrambi i negozi può richiedere giorni, quindi avviale in anticipo. Rinomina gli identificatori dell'applicazione prima del primo caricamento: android.package e ios.bundleIdentifier vengono forniti come com.supastack.app in apps/mobile/app.json. Google Play blocca il nome del pacchetto al primo caricamento, quindi un identificatore errato indica una nuova voce dell'app anziché una ridenominazione. ## Lascia che sia EAS a gestire la firma apps/mobile/eas.json definisce i profili di sviluppo, anteprima e produzione. Il profilo di produzione consente a EAS di generare e conservare l'archivio chiavi Android e il certificato di distribuzione iOS sulla propria infrastruttura: ispezionarli successivamente con eas credentials e mantenere gli archivi chiavi locali fuori dal repository. L'invio della riproduzione automatizzata richiede una chiave JSON dell'account di servizio Google Play collegata in Play Console → Configurazione → Accesso API con autorizzazione di rilascio. Archivialo in apps/mobile/secrets/play-store-service-account.json: il percorso previsto da eas.json e una directory ignorata da git. Il primo caricamento di una nuova app avviene ancora manualmente in Play Console; eas submit subentra alla seconda versione. ## Costruisci, quindi invia Le build vengono eseguite sull'infrastruttura EAS, quindi non è necessaria l'installazione di Android Studio o Xcode per il binario. Il profilo di produzione produce un file .aab pronto per lo store per Play e un file .ipa per l'App Store con numeri di versione gestiti in remoto. Il profilo di anteprima produce uno APK a distribuzione interna per il QA del dispositivo fisico. Il profilo di invio spedito è destinato al percorso interno di Play come bozza di versione: nulla raggiunge i tester finché non lo promuovi all'interno di Play Console dopo aver superato la revisione. ``` corepack pnpm --filter @supastack/mobile build:android corepack pnpm --filter @supastack/mobile submit:android corepack pnpm --filter @supastack/mobile build:ios corepack pnpm --filter @supastack/mobile submit:ios # Internal-testing APK for a physical device: corepack pnpm --filter @supastack/mobile build:android:preview ``` ## Compila i moduli della Play Console Utilizza i controlli di revisione sui contenuti dichiarati tanto quanto sul binario: una politica sulla privacy pubblica URL, il modulo Sicurezza dei dati, il questionario sulla classificazione dei contenuti, il pubblico di destinazione e la categoria. Risposta Sicurezza dei dati dal comportamento reale dell'app: il kit raccoglie le e-mail dell'account per l'autenticazione, archivia i token di sessione nell'archiviazione sicura della piattaforma e comunica solo con il tuo API configurato; aggiungi tutto ciò che il tuo prodotto aggiunge in cima. Per un'app iOS che richiede l'accesso, fornisci ad App Review un account demo funzionante e le istruzioni nelle note di revisione. Rivedi l'attuale regola dei servizi di accesso di Apple e le sue eccezioni prima di scegliere le opzioni di accesso social; i requisiti dipendono dal flusso di accesso effettivo dell'app. Le linee guida ufficiali sono collegate nella sezione relativa alla prima presentazione sopra. ## Prima gli acquisti di Gate dietro RevenueCat Quando la tua app offre acquisti da dispositivo mobile, configura il flusso RevenueCat spedito: imposta `MOBILE_PURCHASES_PROVIDER=revenuecat` e `EXPO_PUBLIC_MOBILE_PURCHASES_PROVIDER=revenuecat`, quindi fornisci la chiave pubblica iOS o Android SDK corrispondente. L'app nativa supporta l'acquisto e il ripristino; dopo entrambe, l'accesso viene aggiornato dal diritto all'area di lavoro verificato dal server. Stripe Checkout non viene utilizzato nel flusso mobile. Mantieni il paywall non disponibile quando gli acquisti sono disattivati ​​o manca la configurazione richiesta. Convalida i prodotti del negozio configurati, acquista, ripristina e aggiorna i diritti in una build di sviluppo EAS con account di prova del negozio. Controlla le indicazioni attuali dello Store per i requisiti applicabili alla tua app e alle tue regioni. ## Lista di controllo pre-invio Prima dell'invio, conferma ogni elemento di seguito utilizzando la tua app di prova e gli account del negozio. - android.package e ios.bundleIdentifier rinominati con un identificatore di tua proprietà - EXPO_PUBLIC_API_URL nell'ambiente di costruzione punta allo API di produzione - Informativa sulla privacy ospitata presso un URL pubblico e collegata alla scheda dello Store - Il modulo di sicurezza dei dati corrisponde alla raccolta reale: email di autenticazione, traffico API, tutto ciò che aggiunge il tuo prodotto - Credenziali dell'account demo funzionante nelle note di revisione dell'App Store - Paywall nascosto o supportato da un diritto RevenueCat verificato - Restituzione del collegamento diretto, ripristino della sessione e disconnessione verificata su un dispositivo fisico - Schermate ed elenco delle risorse preparate per ciascun negozio ## Riprendersi da un rifiuto I rifiuti arrivano con un riferimento politico: correggi la causa dichiarata anziché indovinare il sintomo. Una mancata corrispondenza della sicurezza dei dati di solito significa che il modulo è sbagliato, non l'app. Un rifiuto con richiesta di accesso di solito significa che nelle note di revisione mancava un account demo. Inviare nuovamente con note di rilascio che denominino chiaramente la correzione. La procedura dettagliata completa (comandi delle credenziali, ordine delle operazioni della console e playbook sui rifiuti) si trova in docs/mobile-store-submission.md nel repository. ## Installazione e configurazione La pubblicazione nativa richiede account sviluppatore Apple e/o Google, identificatori app, credenziali di firma e revisione dello store. Il profilo EAS production incrementa i numeri di build; submit.production invia una bozza al canale interno Google Play. Bundle identifier e scheme sono in apps/mobile/app.config.ts. Web e store rilasciano con ritmi diversi: mantieni l’API compatibile con la build supportata più vecchia oppure attiva le nuove funzioni tramite stato gestito dal server. ``` corepack pnpm --filter @supastack/mobile build eas build --profile production --platform ios eas build --profile production --platform android eas submit --profile production --platform ios eas submit --profile production --platform android ``` ## Flusso di implementazione Prima di abilitare gli acquisti nativi, configura progetto RevenueCat, prodotti store ed entitlement. La chiave segreta server e l’Authorization del webhook restano nell’ambiente server; le chiavi SDK iOS e Android sono valori pubblici di build. In produzione il sandbox deve restare disattivato. Prepara i materiali store del prodotto: schermate, descrizione, risposte privacy e informative sugli acquisti. Prima di mostrare l’accesso, l’app verifica acquisti e ripristini rispetto allo stato subscriber corrente sul server. ## Verifica e risoluzione dei problemi Prova su un dispositivo fisico l’esatto artefatto inviato: callback di accesso, ripristino sessione, acquisto e restore, aggiornamento degli entitlement server, cambio workspace, deep link e uso offline. Un export Expo locale non è una build pronta per lo store. Registra numero build, canale store, stato revisione e ambiente API della release. Un rifiuto dello store fa parte del rilascio: correggi metadati o capability invece di attribuirlo senza prove al codice. Prossima superficie: la scheda Desktop mostra lo stesso prodotto nella shell Tauri. ## Successivo [Panoramica desktop](https://supastack.dev/it/docs/desktop.md)