Ionic App Deployment: Una Guida Completa per il 2026

Hai completato l'app. Eseguita correttamente nel browser, l'interfaccia utente si sente giusta e i flussi di base sono stabili. Poi la distribuzione compare e trasforma un progetto Ionic semplice in tre diverse tracce di rilascio, ognuna con le sue regole di firma, processo di revisione e strategia di aggiornamento.

È lì che spesso si perde molto tempo. Non nel scrivere funzionalità, ma nel cucire insieme costruzioni native, hosting web, automazione di rilascio e correzioni post-lancio in un processo che le persone possono ripetere senza indovinare. Distribuzione dell'app Ionic funziona meglio quando smetti di considerare iOS, Android e PWA come progetti separati e inizi a considerarli come un sistema di rilascio unico con output diversi.

Indice

• Il tuo app Ionic è stata creata, ora cosa fare?
• Preparare il tuo progetto per la produzione
  • Inizia con i controlli di ambiente
  • Blocca la configurazione Capacitor
  • Genera gli asset una volta sola
• Distribuzione nativa per iOS e Android
  • Costruisci la layer web per prima
  • Flusso di lavoro di rilascio per Android
  • Flusso di lavoro di rilascio per iOS
• Distribuisci la tua App Ionic come PWA
  • Costruisci per il web con intenzione
  • Abilita il comportamento offline con cura
  • Scegli l'hosting in base al flusso di lavoro
• Automazione dei Build con Pipeline CI/CD
  • Cosa deve essere presente nella pipeline
  • Una forma pratica di GitHub Actions
  • Igiene per le chiavi segrete e la firma
• Invia Aggiornamenti istantaneamente con Capgo
  • Cosa dovrebbero gestire gli aggiornamenti OTA
  • Configura i canali prima del tuo primo incidente
  • Invia piccoli fix senza toccare il codice nativo code
• Pratiche e Problemi di Distribuzione Comune
  • I problemi che si ripetono
  • Il tuo abito di rilascio che prevenire il lavoro di rilascio

La tua App Ionic è stata costruita. Ora cosa fare?

La maggior parte dei sviluppatori incontra lo stesso punto. ionic serve Sembra tutto a posto, le chiamate locali API funzionano, e l'app sembra completa. Non è completa. È solo testata nel browser, non firmata e non collegata alle restrizioni di App Store review, Play signing, e hosting web di produzione.

Il cambio di produzione cambia le domande che si fanno. Si smette di chiedere se l'app si rende e si inizia a chiedere se il bundle è riproducibile, se i progetti nativi sono sincronizzati, se le variabili di ambiente sono separate in modo pulito, e se si può risolvere un bug non-nativo dopo il rilascio senza creare uno scompiglio di rilascio per la store.

Questo cambio è importante perché Ionic si trova in una corsia ibrida. La tua app ha un layer web, ma le conchiglie native decidono ancora come si installa, si firma, si valuta e si aggiorna. Le squadre che trattano la distribuzione come un dopo pensiero finiscono spesso con una deriva di configurazione tra piattaforme, progetti nativi obsoleti, e passaggi di rilascio manuali fragili. Le squadre che lo fanno bene definiscono un percorso di rilascio unico per tutti i target e rendono esplicito ogni passo specifico per piattaforma.

Un ciclo di rilascio pulito solitamente assomiglia a questo:

• Prepara il progetto così Capacitor config, gli identificatori dell'applicazione, gli icona, i valori di ambiente e le versioni di produzione sono coerenti.
• Crea artefatti di rilascio nativi per Android e iOS utilizzando gli strumenti di piattaforma, non solo comandi Ionic.
• Invia un build PWA per gli utenti che hanno bisogno di un accesso immediato al browser.
• Automatizza le parti routine così i build non dipendono da un solo sviluppatore che ricorda un elenco di controllo.
• Pianifica aggiornamenti post-lancio così le correzioni degli asset web non aspettano la revisione della store quando non è necessario.

Se la tua applicazione attuale ancora sembra “un'app web che accade a caso di aprire in un guscio di telefono,” risolvi questo problema per primo. Una utile guida per quella transizione è questo manuale su trasformare un'app web in un'app mobile con Capacitor.

Il tuo primo invio di store di successo solitamente proviene dalla disciplina, non dalla astuzia.

Preparazione del Progetto per la Produzione

Prima di generare qualsiasi build, trattare il progetto come un candidato di rilascio. La maggior parte delle distribuzioni rotte deriva da piccoli disallineamenti che erano innocui nel development locale e costosi in produzione.

Inizia con le verifiche dell'ambiente

Esegui le basi prima:

ionic doctor
npm ci
npx cap doctor

ionic doctor rileva comuni CLI e problemi di ambiente. npm ci è meglio di npm install per il lavoro di rilascio perché installa dal file di lock esattamente come commesso. npx cap doctor aiuta a portare alla luce le disallineamenti dei plugin e delle piattaforme prima che Xcode o Android Studio le trasformino in errori più difficili da leggere.

Utilizza i build di rilascio da uno stato pulito ogni volta che è possibile. Se l'app si costruisce solo dopo la patch locale, le cartelle cancellate o i file nativi modificati a mano, il tuo processo di distribuzione non è ancora stabile.

Alcune verifiche sono utili da fare ogni volta:

• Verifica l'ID dell'app. Modificare in ritardo può creare confusione sullo store e la firma. appId Conferma lo stato del plugin.
• . Le modifiche ai plugin nativi richiedono spesso una sincronizzazione fresca, e a volte un riavvio della piattaforma.Recensisci l'iniezione dell'ambiente.
• . I punti di fine __CAPGO_KEEP_0__, le chiavi e le bandiere di feature dovrebbero provenire da una configurazione specifica dell'ambiente, non da costanti inline.. API endpoints, keys, and feature flags should come from environment-specific config, not inline constants.

differenze tra sviluppo e produzione in __CAPGO_KEEP_0__ app development vs production differences in Capacitor apps Blocca la configurazione __CAPGO_KEEP_0__.

Lock down Capacitor config

e recensiscila come l'infrastruttura di produzione, non come metadati dell'applicazione. capacitor.config.ts Conferma

A un file tipico assomiglia questo:

import type { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  appId: 'com.example.myapp',
  appName: 'My App',
  webDir: 'www',
  bundledWebRuntime: false,
};

export default config;

Il campo che conta subito è:

Se utilizzi un server di sviluppo locale durante lo sviluppo, assicurati che la configurazione di produzione non punti i costruzioni native verso di esso. Quel singolo errore causa molti casi di ‘funziona in dev, schermo bianco in release’

Regola pratica: Se un costrutto di rilascio dipende da un server locale attivo, non è un costrutto di rilascio

Genera gli asset una volta sola

Non ridimensionare gli icon e le schermate di splash a mano. Utilizza un unico asset di alta qualità come fonte e generare gli output per piattaforma

Nelle attuali workflow di Capacitor, molti team utilizzano gli strumenti di asset ufficiali attraverso l'ecosistema CLI. Il pacchetto esatto può variare in base alla versione della pila, ma la disciplina è la stessa: mantenere un'icona canonica e una schermata di splash canonica sotto controllo di versione, generare gli output, poi esaminare i risultati all'interno di Xcode e Android Studio prima della sottoscrizione

Ciò evita un modo di fallimento familiare in cui l'icona PWA è attuale, Android utilizza ancora un asset di foreground più vecchio e iOS mostra un'immagine di avvio datata perché una cartella non è mai stata aggiornata

Una buona passata di produzione include anche:

1. Costruisci i tuoi asset web in modalità di produzione
2. Sincronizza i progetti nativi
3. Apri ogni IDE nativo e controlla manualmente nome dell'app, icone, autorizzazioni e impostazioni di firma.
4. Testa l'app su un dispositivo fisico prima di pacchettizzare qualcosa per i negozi.

Deployamento Nativo per iOS e Android

Il deployamento nativo è dove la tua app Ionic smette di essere “solo web” e inizia a rispondere alle regole della piattaforma. Il bundle web può essere condiviso, ma Android e iOS divergono rapidamente non appena entrano in gioco le firme, la confezione e le richieste dei negozi.

Costruisci la layer web per prima

Produce sempre asset web freschi prima di toccare la confezione nativa:

ionic build
npx cap sync

Alcune squadre dicono ancora ionic build --prod per abitudine. In progetti moderni, il comportamento di produzione esatto dipende dalle tue tooling del framework, ma il principio non è cambiato: genera un build di rilascio ottimizzato, poi sincralo nei piattaforme native.

Dopo la sincronizzazione, apri i progetti nativi direttamente:

npx cap open android
npx cap open ios

Questo è anche un buon momento per revisionare Configurazione per Android degli app Capacitor If il tuo progetto ancora ha una configurazione nativa incerta.

Flusso di rilascio Android

La strada di rilascio di Android è di solito più prevedibile di iOS, ma ancora si rompe quando la firma è configurata in modo casuale.

Genera un keystore di caricamento una volta e memoralo in modo sicuro:

keytool -genkeypair -v -keystore upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias upload

Conserva il file del keystore, l'alias e le password in un archivio segreto sicuro. Non li commetti. Non li lasciare in un chat di squadra. Non assumere che qualcun altro li abbia salvati.

Poi collega la firma a Gradle. Le squadre configurano questo in build.gradle file o utilizzano l'interfaccia utente di firma di Android Studio, a seconda di quanto del processo vogliono scriptare. Una configurazione tipica include un signingConfigs blocco e un tipo di costruzione di rilascio che punti a esso.

L'artefatto di rilascio che si desidera di solito per la sottoscrizione di Play Store è un AAB, non un APK di debug. In Android Studio, utilizza il percorso di menu per generare un bundle firmato, scegli la variante di rilascio e esporta il bundle dell'app. Se preferisci gli edifici a linea di comando, Gradle può gestirlo una volta configurata la firma.

Il trappoloni comuni di Android si manifestano in modi familiari:

• Password di keystore sbagliato produce fallimenti di firma che sembrano più drammatici di quanto siano.
• Debugare residui di firma crea build che installano localmente ma non sono validi per la rilascio nel negozio.
• Plugin desincronizzato si verifica quando qualcuno modifica una dipendenza di plugin nativo e salta npx cap sync.
• Nome di pacchetto non corrispondente causa problemi se l'ingresso dell'app di Console Play è stato creato con un identificatore diverso.

Un pattern che funziona bene è questo: commit web code, costruisci il layer web, sincronizza nativo, costruisci l'artefatto di rilascio dal progetto nativo, e archivia l'hash di commit esatto accanto al bundle generato.

Flusso di rilascio iOS

L'iOS è più rigoroso, e la maggior parte dei problemi di distribuzione derivano dalla confusione dell'identità di firma piuttosto che code problemi.

Apre il progetto in Xcode e vai direttamente a Autenticazione & Capacità. Assicurati che il team selezionato sia corretto, l'identificatore del pacchetto corrisponda al record dell'applicazione che intendi distribuire, e l'autenticazione automatica sia funzionante come previsto o sostituita intenzionalmente con la configurazione manuale.

Di solito si hanno a che fare con questi elementi in movimento:

Per il lavoro di rilascio locale, compila l'app in Xcode, seleziona un dispositivo fisico o un dispositivo iOS generico come destinazione, quindi scegli Archivia. Una volta completata l'archiviazione, utilizza la finestra dell'Organizzatore per validare e distribuire su App Store Connect.

Se Xcode dice che la firma è rotta, leggi l'ID del bundle esatto, il team e i nomi dei profili prima di modificare qualcosa. La generazione casuale di certificati spesso peggiora il problema.

Se non hai un Mac, ancora hai bisogno di un ambiente macOS per produrre un artefatto di rilascio iOS reale. In pratica, le squadre risolvono questo problema con un Mac locale, un Mac in affitto nel cloud o un servizio di CI/CD mobile che esegue costruzioni macOS per loro.

Questa guida passo passo è un utile prerequisito prima della tua prima archiviazione e sottoscrizione:

Un'altra lezione dura imparata: non editare i file nativi generati casualmente se puoi evitarlo. Inserisci la configurazione ripetibile nelle impostazioni del progetto giuste, nella configurazione del plugin o nei script di costruzione. Le modifiche manuali non documentate sono il motivo per cui un rilascio ha successo una volta e poi fallisce la volta successiva quando un altro sviluppatore sincronizza il progetto.

La distribuzione della tua app Ionic come PWA

Un percorso PWA dà alla tua app Ionic la strada più veloce per gli utenti. Nessuna revisione della store. Nessuna cerimonia di firma. Nessuna frizione di installazione per le persone che hanno bisogno di accedere immediatamente dal browser.

That velocità è utile anche quando le app native rimangono il tuo canale principale. Molte squadre utilizzano la PWA come superficie di distribuzione parallela per strumenti interni, esperienze pre-accesso, pannelli amministrativi o mercati dove l'installazione del negozio aggiunge una resistenza inutile.

Costruisci per il web con intenzione

La tua PWA inizia con una costruzione web di produzione:

ionic build

La parte importante non è il comando stesso. È assicurarsi che l'output sia ottimizzato, punti ai servizi di produzione e contenga gli asset finali e il manifesto che intendi distribuire.

Controlla questi file prima di distribuire:

• index.html deve fare riferimento agli asset compilati corretti.
• manifest.webmanifest deve avere il nome, gli icon e le impostazioni di visualizzazione che desideri.
• File del servizio di lavoro devono esistere solo se intendi utilizzare la cache offline.
• Output dell'ambiente deve fare riferimento a endpoint live, non a servizi locali o di staging.

Abilita il comportamento offline con cura

If il tuo stack Ionic utilizza Angular, il servizio di lavoro Angular è il percorso usuale per il supporto offline e la cache. È potente, ma è anche facile da sbagliare.

Cache troppo aggressivamente e gli utenti rimangono bloccati su dati obsoleti. Cache troppo poco e l'app non si sente resiliente quando le connessioni diventano flaccide. La configurazione giusta dipende dall'app. Una shell orientata al marketing può cache pesantemente. Una dashboard con dati operativi in rapida evoluzione ha bisogno di una strategia più conservativa.

Trattare il supporto offline come una decisione di prodotto, non come un casellario. Alcune schermate dovrebbero cache. Altre dovrebbero sempre recuperare dati freschi.

Testare scenari reali, non solo ipotesi di tipo Lighthouse. Apri l'app una volta, disconnetti il dispositivo, rilancia l'app e ispeziona cosa funziona ancora. Poi riconnetti e conferma che il servizio di lavoro aggiorni senza intrappolare gli utenti in UI obsoleti.

Scegliere l'hosting in base al flusso di lavoro

Per le PWAs Ionic, le piattaforme di hosting statico sono abbastanza. Le principali opzioni che le squadre raggiungono sono Netlify, Vercel e Firebase Hosting.

Ecco la visione pratica della scelta tra le opzioni:

Un flusso di deployment diretto su qualsiasi di loro sembra simile: collega il repository, imposta il comando di build, imposta la directory di output, aggiungi le variabili di ambiente, e verifica le regole di rewrite per evitare che la routing client-side si rompa alla ricarica.

Per le app Ionic che utilizzano la navigazione basata su router, lo setup di hosting deve inviare le rotte non corrispondenti al punto di ingresso dell'app. Se non è configurata la rewrite, la pagina di home funziona e i collegamenti profondi falliscono. È uno dei più comuni errori di deployment per le app PWA.

L'automazione dei build con le pipeline di CI/CD

Lavoro di rilascio manuale è accettabile una volta. Dopo di che, diventa un carico. Qualcuno dimentica un passo di sincronizzazione, qualcuno costruisce da una branca sporca, qualcuno firma con la configurazione sbagliata, e improvvisamente l'artefatto generato non può essere più fidato.

Il CI/CD risolve questo problema trasformando la sequenza di rilascio in code. Invece di affidarsi alla memoria, si definisce esattamente come l'app viene costruita, sincronizzata, testata e pacchettizzata ogni volta.

Cosa appartiene alla pipeline

Per i progetti Ionic, una pipeline utile solitamente esegue questi compiti in ordine:

1. Installa le dipendenze dal file di lock.
2. Costruisci l'app web.
3. Sincronizza le Capacitor piattaforme.
4. Esegui i test o almeno una basic validation.
5. Produce gli artefatti nativi per la piattaforma di destinazione.
6. Mantieni o pubblica l'output di costruzione.

Quel flusso è anche dove le buone abitudini di infrastruttura contano. Se i tuoi esecutori di build, il repository degli artefatti o i passaggi di distribuzione sembrano fragili, questa guida all'ottimizzazione cloud essenziale per le piccole imprese è da leggere perché la stessa disciplina operativa si applica alle pipeline di consegna mobile. è da leggere perché la stessa disciplina operativa si applica alle pipeline di consegna mobile.

Azione pratica GitHub

GitHub Azioni è una buona impostazione predefinita perché molte squadre Ionic già ospitano code su GitHub. La seguente workflow mostra la forma generale per un rilascio di build Android.

name: Android Release Build

on:
  push:
    branches:
      - main

jobs:
  build-android:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm ci

      - name: Build web assets
        run: npm run build

      - name: Sync Capacitor
        run: npx cap sync android

      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17

      - name: Build Android bundle
        run: cd android && ./gradlew bundleRelease

Questo non firmerebbe un rilascio da solo a meno che non fornisca anche materiali di keystore e configurazione di firma Gradle. Ciò è intenzionale. La firma dovrebbe rimanere separata dal file di workflow pubblico.

Se desidera un percorso di implementazione focalizzato su mobile, questo post su impostazione della CI/CD per le app Capacitor è direttamente rilevante.

Segreti e igiene di firma

La parte più difficile della CI/CD per i dispositivi mobili non è scrivere YAML. È gestire i segreti senza creare un incidente futuro.

Utilizzare segreti di repository o organizzazione per:

• Password di keystore
• Alias di chiave
• File di keystore codificati
• API token utilizzati durante la rilascio
• Valori di costruzione specifici dell'ambiente

Un modello Android comune è quello di codificare in base64 il keystore, memorizzare la stringa codificata in un segreto, ricostruire durante il workflow e puntare Gradle al file ricostruito. Lo stesso principio si applica a qualsiasi materiale di firma: iniettalo durante la costruzione, non memorizzarlo nel repository.

La CI/CD dovrebbe eliminare l'errore umano, non centralizzare il sapere tribale nascosto. Se solo un sviluppatore comprende come i segreti di rilascio si combinano, il pipeline è ancora fragile.

Una raccomandazione pratica: separare la validazione dal rilascio. Lascia che le richieste di pull eseguano l'installazione, lint, test e costruzioni web. Lascia che un ramo protetto o l'approvazione manuale attivi gli artefatti di produzione firmati. Ciò mantiene il pipeline veloce per lo sviluppo normale e controllato per la distribuzione reale.

Aggiornamenti di spedizione istantanei con Capgo

Gli archivi di rilascio sono necessari per le modifiche native code, le modifiche di autorizzazione e qualsiasi cosa modifichi il binario dell'applicazione. Non sono un buon veicolo per ogni correzione di testo, correzione di stile o bug JavaScript che vive interamente nella layer web.

È per questo Aggiornamenti OTA importano nei progetti Ionic e Capacitor. Consentono alle squadre di spedire asset web aggiornati agli app installati senza dover attendere la revisione del negozio, fintanto che la modifica rimane entro i limiti di cosa il shell nativo già supporta.

Quali aggiornamenti OTA dovrebbero gestire

Utilizza gli aggiornamenti OTA per modifiche come:

• Correzioni dei logici JavaScript che non richiedono un nuovo plugin nativo.
• Adattamenti CSS per layout rotti o aggiornamenti del marchio.
• Modifiche della copia come testo, etichette e testo legale.
• Sostituzioni di asset statici ove l'app già sappia come caricarli.

Non utilizzarli come workaround per vere modifiche native. Se aggiungi una nuova dipendenza nativa, cambi i permessi o alteri qualcosa che il binario approvato dalla store deve contenere, invia una rilascio normale della store.

Quel confine conta perché l'intero scopo degli OTA è la velocità con controllo, non bypassare le regole della piattaforma con disinvoltura.

Configura i canali prima del tuo primo incidente

I migliori workflow OTA utilizzano canali. Un canale di produzione fornisce aggiornamenti stabili agli utenti. Un canale di staging o beta riceve gli aggiornamenti per primi, in modo che i tester interni possano validarli su applicazioni installate in rete.

Quel pattern ti aiuta a evitare il peggiore errore OTA, che è quello di inviare direttamente a tutti perché un fix sembra urgente. Le correzioni urgenti ancora hanno bisogno di barriere di sicurezza.

Una configurazione tipica inizia con l'installazione del plugin e l'inizializzazione dell'applicazione secondo le istruzioni del documento della piattaforma, quindi l'assegnazione del canale in base all'ambiente. L'articolo su aggiornamenti OTA sicuri per l'app store è un punto di riferimento utile per impostare correttamente quei confini.

Invia piccole correzioni senza toccare il code nativo

Una volta integrato l'aggiornatore, il workflow pratico diventa semplice. Costruisci gli asset web aggiornati, pubblicali sul canale destinato, quindi lascia che l'applicazione recuperi e applichi gli aggiornamenti al lancio secondo la tua politica di aggiornamento.

Un esempio reale è un hotfix per una regressione di layout mobile:

1. Regola il CSS nell'app Ionic.
2. Esegui la costruzione web di produzione.
3. Pubblica il bundle risultante sul canale di staging.
4. Testa le versioni installate.
5. Promuovi o pubblica la stessa correzione per la produzione.

Quell'approccio cambia la risposta agli incidenti. Senza OTA, un bug del layer web può lasciarti in attesa della revisione della store e dell'adozione da parte degli utenti della nuova versione binaria. Con OTA, puoi correggere i file interessati, inviarli al pubblico giusto e osservare il rollout in modo controllato.

Aggiornamenti veloci sono utili solo se puoi mirarli in modo sicuro e annullarli quando necessario.

Gli team che traggono maggior beneficio da OTA non sono team temerari. Sono team disciplinati con confini di rilascio chiari, canali denominati e l'abitudine di trattare le correzioni del layer web come un flusso separato dalle rilasci native.

Problemi di distribuzione comuni e migliori pratiche

La maggior parte dei problemi di distribuzione non è unica. Si ripetono tra gli team perché gli stessi errori continuano a verificarsi sotto pressione di scadenza.

Fallimenti che si ripetono

Gli errori di firma Android solitamente si riducono al password sbagliato, alias sbagliato o file keystore sbagliato utilizzato nella configurazione di rilascio. Quando succede, smetti di girare le credenziali a casaccio. Verifica il file, l'alias e i valori segreti prima.

Gli errori di costruzione iOS spesso si risolvono con una disallineamento tra identificatore di bundle, selezione del team, certificato e profilo di provisioning. I messaggi di errore di Xcode possono sembrare densi, ma il disallineamento è spesso letterale. Uno di quei valori non si allinea con gli altri.

Schermate bianche dopo l'installazione sono un classico. Le cause comuni includono:

• Applicazione di produzione che punta a un server di sviluppo al posto di risorse bundle
• Risorse web non ricostruite prima npx cap sync
• Modifiche del plugin non sincronizzate in progetti nativi
• Valori di ambiente mancanti al runtime in costruzione di rilascio effettiva

Abitudini di rilascio che prevenire il lavoro di ripetizione

Le migliori pratiche sono noiose, e questo è il motivo per cui funzionano.

Conserva un unico punto di verità per la configurazione dell'ambiente. Costruisci da rami puliti. Etichetta i commit di rilascio. Conserva il materiale di firma al di fuori del repository. Testa le costruzioni installate su dispositivi reali, non solo simulatori e schede del browser. Prepara i metadati della store in anticipo per evitare che la distribuzione si blocchi sui screenshot, sulle risposte sulla privacy o sulla mancanza di copia.

Un'altra abitudine salva molto dolore: conserva un elenco scritto di rilascio anche dopo l'automazione è in atto. Le pipeline costruiscono artefatti. Non confermano che la descrizione dell'app è aggiornata, il tuo URL di supporto è corretto o la tua stringa di autorizzazione nativa più recente ancora corrisponde al comportamento dell'app.

Se il tuo team distribuisce Capacitor app e vuole una via più sicura per inviare aggiornamenti del layer web dopo il lancio, Capgo è degno di essere valutato. Gli fornisce un flusso di lavoro OTA strutturato con canali, roll-out controllati e supporto per il rollback, in modo che tu possa distribuire aggiornamenti di JavaScript, CSS, copia e asset senza trasformare ogni piccolo fix in un'altra presentazione dell'app store.