Invia fix Capacitor senza i ritardi degli store
Immagina: la tua pagina di checkout ha un problema di allineamento CSS alle 8 del mattino. Inizia il panico: serve un rilascio iOS, uno Android, Native Build e giorni di revisione. Non più.
Crea un nuovo web bundle, caricalo su un canale Capgo controllato e i dispositivi compatibili lo scaricheranno senza passare per la coda di revisione degli store. Fix di CSS, JavaScript, file e asset possono raggiungere gli utenti in pochi minuti, mentre le modifiche native seguono il consueto percorso di rilascio binario.
Indice dei contenuti
Quando ha senso un Live File Update
Un live update funziona quando il tuo native shell è a posto ma il web layer va sistemato. Quel problema di allineamento CSS? Correggi il foglio di stile, ricostruisci i web assets e pubblica un bundle firmato. Entro le 9 del mattino — un'ora dopo la comparsa del bug — i tuoi utenti ricevono la fix al prossimo avvio dell'app. Capgo applica il bundle tramite il suo updater senza toccare minimamente il binario nativo.
Ecco come decido quale strada intraprendere:
- Usa un live update per il comportamento JavaScript, CSS, testo, configurazione e asset compatibili.
- Usa un rilascio nativo per modifiche ai plugin, permessi, dipendenze native o funzionalità a livello OS.
- Testa tramite un channel prima di sottoporre una correzione a tutti i clienti.
| Tipo di rilascio | Uso tipico | Impatto utente |
|---|---|---|
| Pacchetto nativo | Nuova funzionalità nativa | Download e revisione dello Store |
| Bundle web live | Fix urgente compatibile | Update all'avvio dell'app |
Mantieni compatibili i layer nativi e web. Un bundle live non può introdurre in sicurezza API native non presenti nel binario installato. Se aggiungi un nuovo plugin o cambi i permessi, serve una Native Build: non ci sono alternative.
Per una sequenza di deployment passo dopo passo, ti consiglio di leggere questa guida al deployment degli hotfix Capgo. Ti spiegherà come passare da una correzione testata a un rilascio controllato, senza usare gli utenti in produzione come team di QA.
Prima di pushare gli aggiornamenti in produzione, assicurati che i tuoi build locali siano stabili. Installa Capgo’s open-source updater plugin, then add its TypeScript package so your editor actually recognizes the updater methods instead of throwing missing type errors. For Capacitor projects, their guida alla configurazione di un ambiente Capacitor locale vale la pena salvarlo tra i preferiti: ti guida nella preparazione di un workspace pulito.
Mantieni prevedibili i Web Assets
Il tuo bundle live contiene solo i web asset compilati, non i file sorgente che potresti modificare. Configura il progetto in modo che il comando di build generi sempre JavaScript, CSS, HTML e asset compatibili nella stessa www o public directory a cui fa riferimento la shell nativa.
Ecco come funziona in pratica: dopo aver modificato uno stylesheet di checkout, esegui il tuo normale web build, poi ispeziona la directory di output e conferma che i file generati abbiano effettivamente sostituito le versioni precedenti. Non modificare manualmente i file compilati: il prossimo build li sovrascriverà silenziosamente, facendoti perdere le modifiche senza che tu te ne accorga.
Un live update può distribuire solo ciò che è incluso nel tuo web build. Se la correzione manca da
wwwopublic, il dispositivo semplicemente non può riceverla.
Configura canali separati per development, staging e production. Un build di sviluppo non dovrebbe mai puntare al canale di production, specialmente quando più membri del team stanno testando bundle incompleti contemporaneamente.
- Sviluppo intercetta import corrotti e asset mancanti prima che vadano oltre.
- Staging verifica il comportamento su dispositivi reali con impostazioni simili alla release.
- Produzione distribuisce solo bundle approvati e testati — niente di sperimentale.
Verifica il Bundle prima del rilascio
Run a short integrity check before uploading anything. This catches most issues that would otherwise reach users:
- Elimina l'output della build precedente, quindi crea una nuova build.
- Conferma che il file corretto esista effettivamente nella directory di output.
- Testa la navigazione, il login, il comportamento offline e le chiamate ai plugin nativi — non solo la nuova funzionalità.
- Installa il bundle su dispositivi di test sia iOS che Android.
- Registra il canale e la versione del bundle usati durante i test per poter riprodurre eventuali problemi in seguito.
I team Electron possono applicare la stessa disciplina: builda gli asset del renderer separatamente, poi conferma che l'applicazione pacchettizzata faccia riferimento alla directory di output corretta. Le API tipizzate e i controlli sui canali di Capgo rendono questo workflow più facile da ripetere con costanza, ma non sostituiscono i test di compatibilità reali. Se una modifica richiede un nuovo plugin nativo o un nuovo permesso, pubblica un nuovo binario invece di provare a distribuirlo come live web bundle — l'updater non può modificare autonomamente i code nativi.
Gestire correttamente gli aggiornamenti dei file in Capacitor e nelle app Electron si riduce a una cosa: un artifact di rilascio solido. Builda il tuo layer web dall'esatto commit che hai già testato, poi verifica che tutto il tuo JavaScript, CSS, HTML e gli asset si trovino in www o public come previsto. Se stai lavorando con Electron, builda il renderer separatamente e verifica che la shell pacchettizzata punti a quell'output.
Creazione di un Bundle Verificabile
Prima ancora di pensare all'upload, elimina qualsiasi vecchio output di build ed esegui da zero la build di produzione. Annota l'hash del commit, la versione del bundle, il canale di destinazione e la versione dell'app nativa. Questi dettagli ti risparmieranno ore di grattacapi quando più avanti qualcosa non corrisponderà.
Controlla sempre il bundle su dispositivi reali: iPhone reali, telefoni Android o installazioni Electron. Verifica login, navigazione, modalità offline e ogni plugin nativo che interagisce con i file appena aggiornati. Caricare con successo il bundle sul server di aggiornamento non serve a nulla se il dispositivo non riesce davvero a eseguire ciò che hai inviato.
La firma conferisce al tuo artifact un'impronta crittografica. L'updater si basa su quella firma per confermare che il bundle sia passato intatto dalla tua release pipeline. Conserva le credenziali di firma completamente fuori dal repo, limita chi può accedervi e ruotale con la cadenza richiesta dalla tua policy di sicurezza.
Un bundle firmato non sostituisce i test. La firma dimostra da dove viene l'artifact e che non è stato manomesso, ma non dice nulla sul fatto che l'app funzionerà davvero con esso.
Per un quadro completo, ti consiglio di leggere la guida di Capgo alla sicurezza end-to-end e alla firma code.
Pubblicazione tramite canali controllati
Una volta pronto il bundle firmato, caricalo su Capgo e assegnalo a un canale adatto alla tua strategia di rollout. Quelli più utili con cui lavorerai più spesso:
- Beta — per il team interno e tester selezionati
- Staging — per validare in un ambiente simile alla produzione prima del rilascio agli utenti
- Produzione — per il pubblico approvato
- Canali specifici per cliente — quando diversi tenant necessitano di tempi di aggiornamento indipendenti
Ecco uno scenario comune: un team fintech nota un errore in un'etichetta di pagamento in produzione. Caricano il web bundle corretto su un canale interno, verificano il checkout su alcuni dispositivi e poi promuovono lo stesso identico artefatto testato a un piccolo segmento di produzione prima del roll-out globale. Questi guardrail dei canali impediscono che una correzione frettolosa si trasformi in un incidente critico.
Dopo il rilascio, analizza i log per singolo dispositivo invece di affidarti solo allo stato aggregato della dashboard. Devi confermare che la versione corretta dell'app abbia scaricato il bundle, che la firma sia valida, che l'installazione sia andata a buon fine e che il successivo avvio abbia effettivamente caricato i nuovi file.
Se i dispositivi segnalano discrepanze, metti in pausa immediatamente quel canale e confronta versione del bundle, compatibilità nativa, chiave di firma e assegnazione del canale. Espandi la distribuzione solo quando i log sono puliti per tutto il gruppo di test, e tieni sempre disponibile il bundle precedente per un eventuale rollback.
Una volta che i build locali funzionano correttamente, è il momento di integrare il publishing nella tua pipeline CI/CD. L'obiettivo è semplice: buildare gli asset web, firmare il bundle e pubblicarlo automaticamente dopo il superamento dei test. Niente più upload manuali. Niente più dubbi su come aggiornare i file dopo una merge: il processo lo gestisce in automatico.
Ecco come appare una pipeline pratica nel mondo reale:
- Avvia il job quando un ramo di release viene mergiato nel branch di destinazione.
- Installa le dipendenze e genera un
wwwopublicbuild pulito. - Esegui l'intera suite di test: unit test, integration test e smoke test sui dispositivi.
- Firma il bundle usando le credenziali salvate nel secret manager della tua CI.
- Push verso un canale beta o staging tramite la API pubblica di Capgo.
- Dopo il superamento dei controlli di validazione, promuovi esattamente lo stesso artifact. Non ricostruirlo.
Una cosa da ripetere: non committare mai chiavi di firma o token API nel tuo repo. Salvali come variabili d'ambiente protette, limita il publishing in produzione solo ai branch approvati e logga ogni release con versione del bundle, commit hash, versione dell'app nativa e canale di destinazione. Di Capgo Guida all'integrazione con GitHub Actions ti guida nella configurazione completa, passo dopo passo.
Il punto fondamentale è che la validazione rimane parte integrante del processo di delivery. La pubblicazione non è il traguardo. La tua pipeline deve confermare che i dispositivi target abbiano effettivamente ricevuto e accettato il bundle.
Riduci i costi di trasferimento con update differenziali
Inviare bundle completi ogni volta è uno spreco, specialmente quando un rilascio cambia solo un foglio di stile o un paio di moduli JavaScript. Attiva la delivery differenziale per far scaricare ai dispositivi solo i file modificati. Assicurati solo di testare come vengono gestiti gli asset rimossi o rinominati, altrimenti avrai una brutta sorpresa in produzione.
Un'agenzia che ho visto affrontare questo problema ha ridotto i costi medi di banda del 47% dopo essere passata dai re-bundle completi alla delivery incrementale. Il vero vantaggio è stato per gli utenti con connessioni più lente, dove download più piccoli hanno anche comportato tempi di installazione sensibilmente più rapidi.
Consiglio anche di usare canali separati per controllare l'esposizione:
- Beta gestisce le build interne e raccoglie il feedback dei tester.
- Staging replica le impostazioni di produzione senza impattare i clienti.
- Produzione inizia su piccola scala con un pubblico limitato prima di espanderti.
- Canali per i clienti mantengono isolate le release specifiche per ogni tenant.
Promuovi un artifact testato: non ricostruirlo tra le varie fasi. Ricostruire per ogni ambiente introduce drift, e all'improvviso ti ritrovi a debuggare differenze che non dovrebbero esistere.
Per un'app fintech, il flusso potrebbe essere questo: pubblica prima per i dipendenti, poi rilascia al 5% degli utenti idonei, ispeziona i log per singolo dispositivo e amplia solo quando l'adozione è stabile e i tassi di errore rimangono bassi. E tieni sempre pronto il bundle precedente. Se qualcosa va storto, devi poter mettere in pausa o fare il rollback in pochi minuti, non ore.
Pubblicare un bundle è solo metà dell'opera. Per confermare che gli utenti ricevano davvero l'update, apri i log per singolo dispositivo di Capgo e controlla la versione nativa, il channel, la versione del bundle, la validazione della firma, lo stato del download e l'esito dell'installazione.
Un rollout sano deve mostrare avvii riusciti dopo l'installazione, non solo download completati. Per un fix al checkout, testa un flusso di acquisto reale su diversi dispositivi, poi confronta i risultati con i report degli utenti su connessioni lente o versioni dell'app più vecchie.
Analizza i segnali di Update con chiarezza
Combina metriche di adozione e di fallimento. Un alto tasso di download con continui errori all'avvio indica un bundle corrotto, mentre una bassa adozione potrebbe dipendere dal targeting del canale, dai dispositivi offline o da un errore nella configurazione dell'updater.
| Segnale | Cosa significa solitamente |
|---|---|
| Scaricato | Il dispositivo ha scaricato il bundle |
| Installato | File superati i controlli di installazione |
| Avviato con successo | L'app si è aperta con i nuovi file |
| Rollback effettuato | È stato ripristinato il precedente bundle funzionante |
Monitora i lanci riusciti, non solo i download. Un aggiornamento è operativo solo quando gli utenti possono aprire e usare l'app normalmente.
La protezione automatico rollback di Capgo offre una rete di sicurezza se un nuovo bundle causa crash o impedisce l'avvio. Mantieni disponibile la versione precedente, metti in pausa il canale interessato e analizza i log prima di promuovere un altro artifact.
Il controllo versione dei video condivide concetti con il monitoraggio degli aggiornamenti file e la gestione dei rollback nelle pipeline di distribuzione live, quindi i team potrebbero trovare utili queste idee anche quando gestiscono le versioni dei video di training.
Verifica il rilascio
Usa questa breve checklist post-rilascio:
- Conferma l'adozione per canale e versione dell'app.
- Controlla download falliti, errori di firma e fallimenti di avvio.
- Testa il nuovo workflow su dispositivi fisici.
- Confronta il timing degli errori con il timestamp del rilascio.
- Interrompi la distribuzione se i fallimenti aumentano inaspettatamente.
- Registra il bundle finale, il commit e la decisione di rollback.
Per approfondire, leggi come monitorare gli aggiornamenti OTA nelle app Capacitor. Questo trasforma l'aggiornamento dei file da un semplice task di pubblicazione a un processo operativo controllato.
I Live Updates rispettano le regole degli Store?
I Live Updates sono ideali per modifiche a JavaScript, CSS, testi, configurazioni e asset compatibili. Non sono una backdoor per aggiungere funzionalità native, cambiare permessi o aggirare la revisione degli store. Controlla sempre le policy di Apple e Google per la tua categoria di app prima di pubblicare.
Come fanno gli aggiornamenti differenziali a ridurre i download?
La consegna differenziale invia solo i file effettivamente modificati invece dell'intero web bundle. Se modifichi un foglio di stile nella pagina di checkout, non c'è motivo di ritrasmettere ogni altro asset non correlato. Risultato: trasferimenti più veloci e meno consumo di banda.
Attenzione però ai file rinominati o eliminati. Asset obsoleti rimasti dalle versioni precedenti possono causare bug strani e difficili da tracciare.
Anche le piccole patch richiedono comunque test di compatibilità completi. Un download più piccolo non elimina la necessità di verificare l'intero user flow.
Cosa succede quando un dispositivo è offline?
Un dispositivo offline continua a eseguire il bundle installato. Una volta ripristinata la connessione, l'updater controlla il canale assegnato e scarica l'ultima release compatibile. Non dare per scontato che ogni dispositivo si aggiorni subito: i team sul campo con connessione instabile potrebbero restare indietro per un po'.
Come gestire i breaking changes?
Considera il binario nativo e il web bundle come una coppia coordinata. Se i tuoi file web aggiornati chiamano un metodo nativo assente nel binario attualmente installato, devi prima rilasciare una nuova release nativa, poi pubblicare l'aggiornamento web sopra di essa.
Usa canali separati per beta, staging e produzione. Verifica che ogni dispositivo riceva effettivamente il canale previsto. Quando compaiono signature mismatch, di solito indicano artefatti alterati, credenziali errate o problemi di configurazione. Metti in pausa la distribuzione, confronta quanto pubblicato con quanto testato e analizza i log del dispositivo prima di riprovare.
Per un workflow di deployment pratico, esplora Capgo — ti offre release firmate, controllo dei canali, delivery differenziale e protezione dal rollback per aggiornare i file senza mal di testa.
