METEO
Windy.com - Previsioni Meteo
App meteo che richiede aggiornamenti accurati per mappe, alert e navigazione.
- Installazioni su Google Play
- 32,9M
- Valutazione store
- 4.7
Update in produzione
Porta ogni utente sull'ultima fix
Fai l'upload di un nuovo web bundle da CLI o CI. I dispositivi lo scaricano in background e lo eseguono al prossimo avvio dell'app. Gestisci il rollout per percentuale, monitoralo con Observe e fai il rollback se necessario.
Prova gratuita illimitata di 14 giorni. Nessuna carta di credito richiesta Garanzia di rimborso di 14 giorni. Annulla quando vuoi.
Esigenze Enterprise? Parla con il nostro team
Nessuna carta di credito richiesta
Rollback automatico integrato
Solo aggiornamenti web-layer
Il Problema
Il rilascio sugli store è un modo lento per distribuire una piccola fix
Il percorso di fix tramite store
1
Trova il bug
Il monitoraggio o il supporto segnalano uno schermo rotto. La fix è di poche righe di JavaScript o CSS.
2
Crea un nuovo binary
Aggiorni la versione, buildi per iOS e Android e prepari due submission per gli store.
3
Attendi la revisione
La revisione dello store richiede spesso 24–48 ore, a volte molto di più. Un rifiuto fa ripartire l'attesa.
4
Attendi l'aggiornamento degli utenti
Dopo l'approvazione, ogni utente deve comunque installare la nuova versione. Fino ad allora, useranno la vecchia code.
Ogni passaggio aggiunge tempo tra la disponibilità della fix e la sua esecuzione sui dispositivi degli utenti.
Perché i fix arrivano lentamente agli utenti
24–48h+
Tempo medio di revisione store
Apple e Google revisionano ogni nuovo binario. La revisione richiede spesso 24–48 ore, a volte molto di più, e un rifiuto implica una nuova sottomissione.
Per utente
Gli aggiornamenti store dipendono dai dispositivi
Un aggiornamento store raggiunge un dispositivo solo quando l'utente, o l'impostazione di auto-update, lo installa. Alcuni dispositivi rimangono su vecchi build per molto tempo.
2 store
Due sottomissioni per ogni fix
Lo stesso fix web deve passare separatamente per App Store e Google Play, ognuno con la propria revisione e rilascio.
La soluzione
Come un live update raggiunge i tuoi utenti
Questo è il comportamento predefinito di Capgo. Nessun prompt di aggiornamento, nessun riavvio forzato e nessuna sottomissione agli store per le modifiche al web-layer.
Flusso di aggiornamento predefinito
-
L'app controlla gli aggiornamenti
Quando l'app torna in foreground, e ogni 10 minuti mentre è aperta, l'updater richiede a Capgo l'ultimo bundle del canale.
Al foreground
-
Scarica in background
Il nuovo bundle viene scaricato mentre l'utente usa la versione attuale. Con i delta updates, vengono scaricati solo i file modificati.
Nessuna interruzione
-
Si applica al prossimo resume
Quando l'utente chiude l'app, l'updater installa il bundle. Al prossimo avvio, verrà eseguita la nuova versione.
Al prossimo foreground
Vuoi che gli utenti vedano la nuova versione appena aprono l'app? Le modalità di direct update la applicano al lancio, durante la splash screen.
Scopri i direct updatesCome funziona
Come i team di produzione rilasciano un fix con Capgo
Un rilascio tipico per un'app Capacitor già presente negli store. Ogni comando qui sotto proviene dalla documentazione Capgo CLI.
-
Configura l'updater una sola volta
Avvia il setup wizard, poi assicurati che la tua app chiami notifyAppReady() all'avvio. Un bundle che non effettua mai quella chiamata viene ripristinato automaticamente.
Docs di notifyAppReady()npx @capgo/cli@latest init # in your app start-up code await CapacitorUpdater.notifyAppReady() -
Carica il fix su una parte della produzione
Usa --delta per far scaricare ai dispositivi solo i file modificati, e --rollout per iniziare con una piccola percentuale di device. Tutti gli altri rimarranno sul bundle stabile.
Docs sui rollout progressivinpx @capgo/cli@latest bundle upload --channel production --delta --rollout 5 -
Lascia che Capgo blocchi un rollout errato
Attiva l'auto-pause con una soglia di tasso di errore (500 basis points è il 5%). Se i fallimenti superano la soglia, Capgo annulla il rollout. Controlla la nuova versione in Observe durante l'esecuzione.
Docs di Observenpx @capgo/cli@latest channel set production \ --auto-pause-enabled \ --auto-pause-failure-rate-bps 500 \ --auto-pause-action rollback -
Promuovi a tutti
Quando i numeri sono corretti, promuovi il bundle su ogni dispositivo del canale. Altrimenti, riporta la cohort di rollout alla versione stable.
Docs sui rollbacknpx @capgo/cli@latest channel set production --rollout-promote # or, if something looks wrong npx @capgo/cli@latest channel set production --rollout-rollback
Progettato per i rilasci in produzione
Il controllo che i team di produzione usano per rilasciare aggiornamenti senza sorprendere gli utenti.
Aggiornamenti delta
Carica con --delta e i dispositivi scaricano solo i file modificati rispetto al bundle attuale. Gli asset pesanti che cambiano raramente vengono scaricati una sola volta.
- Download più leggeri per utenti con reti lente o a consumo
- In modalità default, gli update si applicano tra una sessione e l'altra, non durante l'uso
--delta
Vengono scaricati solo i file modificati
Rollout progressivo con auto-pause
Invia un nuovo bundle a una quota fissa e casuale di un canale, mentre tutti gli altri restano sul bundle stabile. Aumenta la percentuale, promuovilo o fai il rollback da CLI o dalla console.
- L'auto-pause può sospendere o fare il rollback di un rollout se il tasso di errore supera la tua soglia
- Observe confronta la nuova versione con la precedente prima di aumentare l'esposizione
1–5%
Un tipico primo step di rollout
Rollback automatico
Ogni update deve dimostrare di avviarsi correttamente. Se un nuovo bundle non chiama notifyAppReady() in tempo, il dispositivo torna all'ultimo bundle funzionante e segna il nuovo come fallito.
- Il rollback scatta se notifyAppReady() non viene chiamato entro appReadyTimeout (10 secondi di default)
- Fai il rollback di un intero channel a qualsiasi bundle precedente presente nella cronologia
10s
appReadyTimeout di default prima del rollback automatico
Distribuzione consapevole delle review degli store
Capgo distribuisce lo strato web Capacitor: JavaScript, CSS e asset. Non modifica il binario nativo, i plugin, i permessi, gli entitlements o i metadati dell'app store. La revisione dello store è specifica per ogni app, quindi la conformità alle policy e l'approvazione restano di tua responsabilità.
- Usa una release nativa sullo store quando cambiano funzionalità native, plugin, permessi o metadati dell'app store
- Fornisci ai revisori note chiare sulla funzionalità dell'app e sul percorso di aggiornamento del web-layer
- Controlla le attuali policy di Apple e Google prima di ogni submission
Cosa fanno i team di produzione
Gestione quotidiana dei rilasci con le Live Update attive. Ogni card rimanda alla documentazione.
Bug fix critici
Un checkout o una schermata di login non funzionanti ricevono un fix nel web layer. Caricalo e i dispositivi lo scaricheranno al prossimo controllo degli aggiornamenti.
Docs comportamento aggiornamentiModifiche a testi e contenuti
Correggi testi, aggiorna i messaggi di aiuto o sostituisci immagini e altri asset nel bundle senza buildare un nuovo binario.
Documentazione compatibilità nativaMonitora il rilascio con Observe
Confronta un nuovo bundle con il precedente: tasso di errori, tempi di avvio e WebView e marker di deployment per versione.
Documentazione ObserveAggiornamenti più rapidi con le notifiche
Dopo aver cambiato il bundle di un canale, invia una notifica di update silenziosa per far controllare i dispositivi subito, invece di attendere il prossimo avvio in foreground.
Invia notifica di updateProteggi i Native Build più vecchi
Blocca gli update principali su un canale per evitare che un bundle che richiede nuovi code nativi raggiunga un binario più vecchio.
Documentazione version targetingRollback dalla cronologia del canale
Seleziona un bundle precedente nella scheda History del canale per renderlo nuovamente attivo su tutti i dispositivi di quel canale.
Docs sui rollbackInfrastruttura già testata per app in produzione
Capgo distribuisce Live Update ad app in produzione dal 2021.
- Update al mese
- 1B+
- Dispositivi raggiunti
- 90M+
- App che usano Capgo
- 4.7K+
- Latenza tipica di API
- ~50ms
Soluzioni per tipologia di team
Trova la soluzione adatta alle esigenze del tuo team
App sviluppate con Capacitor
Le app ad alto traffico richiedono UI affidabili in produzione
App meteo, sanità e telecomunicazioni dipendono da interfacce, alert e navigazione precisi. Gli update in produzione permettono di rilasciare fix approvate monitorando l'adozione prima di un rollout completo.
METEO
MEDICINA
Connetti SUS
App di sanità pubblica che richiede aggiornamenti rapidi e affidabili per linee guida e servizi.
- Installazioni su Google Play
- 27,7M
- Valutazione store
- 4.6
STRUMENTI
Il mio Orange
App di un account telecom dove avvisi e interfacce cambiano spesso.
- Installazioni su Google Play
- 9,3M
- Valutazione store
- 4.2
Testimonianze dei clienti
Cosa dicono i team che rilasciano con Capgo
Sergiu S
Lead Developer, drivolino GmbH
“Il plugin Capgo Capacitor Updater ha rivoluzionato il nostro modo di rilasciare gli aggiornamenti. Quello che prima richiedeva giorni, ora si fa in pochi minuti.”
Kapil
Fondatore, NuTriQ
“Poter rilasciare aggiornamenti OTA in produzione istantaneamente, senza attendere i cicli di revisione dell'App Store, è stato un enorme vantaggio operativo.”
Michael Haberler
nethead emeritors
“Ottimo lavoro sul plugin updater. Per me funziona alla perfezione e gli aggiornamenti live sono un acceleratore fantastico per ridurre i tempi di test.”
FAQ
Domande dei team di produzione
Come arrivano gli update sui dispositivi e cosa fare in caso di errore.
Quando gli utenti ricevono un live update?
Di default, l'app cerca aggiornamenti quando torna in foreground e ogni 10 minuti mentre è aperta. Scarica il nuovo bundle in background, lo installa quando l'utente chiude l'app e lo avvia al prossimo avvio. L'impostazione autoUpdate modifica questo comportamento.
Docs comportamento aggiornamenti
Can devices pick up an urgent fix faster?
Sì. Dopo aver cambiato il bundle di un channel, invia una notifica di update dalla console o aggiungi --send-update-notification al bundle upload. I dispositivi ricevono un silent push e controllano subito. Richiede Capgo Notifications con credenziali push iOS e Android. La consegna è best effort: un'app offline o forzatamente chiusa controllerà al prossimo avvio.
Invia notifica di update
Cosa succede se un update rompe l'app?
Se un nuovo bundle non chiama notifyAppReady() entro 10 secondi (l'appReadyTimeout di default), il dispositivo torna all'ultimo bundle funzionante e segna il nuovo come fallito. Per bug che non impediscono l'avvio, effettua il rollback del progressive rollout o scegli un bundle precedente dalla cronologia del channel.
Docs sui rollback
Come possiamo rilasciare l'update solo a pochi utenti?
Fai l'upload con --rollout per inviare il bundle a una quota random e persistente del canale, mentre gli altri restano sulla versione stable. Aumenta la percentuale, promuovi o fai il rollback da CLI o dalla console. L'auto-pause può interrompere l'esposizione se il tasso di errore supera una soglia.
Docs sui rollout progressivi
Cosa non può cambiare un live update?
Le Live Update sostituiscono il web layer: JavaScript, HTML, CSS e asset. Plugin nativi, upgrade di Capacitor, modifiche a capacitor.config e i file di progetto iOS o Android richiedono un rilascio sugli store. Capgo verifica la compatibilità nativa dei bundle durante l'upload, e i canali possono bloccare gli update su binari più vecchi.
Documentazione compatibilità nativaRilascia il tuo prossimo fix come live update
Prova l'intero workflow sulla tua app durante la trial: fai l'upload di un bundle, distribuiscilo su pochi dispositivi e fai il rollback.
supporto umano da parte di Martin
Prova gratuita illimitata di 14 giorni. Nessuna carta di credito richiesta Garanzia di rimborso di 14 giorni. Annulla quando vuoi.
Esigenze Enterprise? Parla con il nostro team