Saltare al contenuto principale
Aggiornamenti diretti

Mostra la versione più recente quando gli utenti aprono la tua app

Di default, un live update esegue una sessione dopo aver scaricato. I modi di aggiornamento diretto lo applicano al lancio invece, dietro lo schermo di splash, quindi la prima schermata che gli utenti vedono è già la nuova versione.

Aggiornamento automatico: a installazione, a avvio o sempre
Schermo di benvenuto tenuto fino a quando l'aggiornamento è pronto
I download delta mantengono la pausa breve

Il problema

Background updates arrive one session late

Cosa succede nel modello predefinito

1

Il problema del background

L'applicazione parte dal bundle che già possiede. L'aggiornatore controlla se esiste una nuova versione e la scarica in background.

2

Il problema del background

Per il resto della sessione, l'utente esegue il code installato prima della tua correzione.

3

La patch si applica alla prossima ripresa

Quando l'utente lascia l'app, l'aggiornatore installa il nuovo pacchetto. Vedono il nuovo pacchetto la prossima volta che aprono l'app.

Per la maggior parte delle rilasci, quella è la scelta giusta. Quando la sessione che inizia dopo il caricamento dei dati deve eseguire il nuovo code, utilizzare un modo di aggiornamento diretto.

Quando la prima sessione conta

Un flusso di pagamento o di accesso rotto

Gli utenti che aprono l'app non dovrebbero passare attraverso la schermata rotta una volta di più prima dell'applicazione della correzione.

Una correzione di sicurezza del layer web

Desideri che il JavaScript aggiornato sia eseguito già alla partenza, non dalla prossima sessione.

Una modifica datata

Termini, avvisi o contenuti degli eventi che devono essere aggiornati sulla prima schermata visibile agli utenti.

La Soluzione

Che cosa cambia con un modo di aggiornamento diretto

L'aggiornatore controlla al lancio mentre lo schermo di benvenuto rimane acceso. Se è disponibile un nuovo pacchetto, lo scarica e lo applica prima che lo schermo di benvenuto si nasconda.

Modalità predefinita (in background)

1
L'utente apre l'app
2
L'app mostra la versione corrente
3
L'aggiornamento scarica in background
4
L'aggiornamento si applica alla prossima ripresa

Nessuna attesa al lancio. Gli utenti vedono l'aggiornamento nella sessione successiva.

Modalità diretta (al lancio)

1
L'utente apre l'app e lo schermo di benvenuto rimane acceso
2
L'aggiornatore controlla e scarica i file modificati
3
The update applies, the splash hides, the new version shows

Gli utenti vedono la nuova versione alla prima schermata. Aspettano allo schermo di benvenuto mentre scarica.

Documentazione comportamento di aggiornamento

Come funziona

Come configurare gli aggiornamenti diretti

Un modo diretto è una configurazione nativa, quindi viene inviato in un build di negozio prima. Dopo di che, ogni live update lo segue. Le istruzioni provengono dalla Capgo documentazione.

  1. Aggiungi il plugin dello schermo di benvenuto e scegli un modo

    Installa @capacitor/splash-screen, quindi imposta autoUpdate, autoSplashscreen e launchAutoHide in capacitor.config.ts.

    npm install @capacitor/splash-screen
npx cap sync

// capacitor.config.ts
plugins: {
  CapacitorUpdater: {
    autoUpdate: 'onLaunch', // or 'atInstall' / 'always'
    autoSplashscreen: true,
    keepUrlPathAfterReload: true,
  },
  SplashScreen: { launchAutoHide: false },
}
    Gestione dello schermo di benvenuto

  2. Invia il config in un build di negozio

    capacitor.config viene compilato nell'app nativa, quindi il nuovo modo raggiunge gli utenti con il tuo prossimo rilascio di negozio. Capgo Build può produrlo in cloud.

    npx @capgo/cli@latest build request --platform ios
npx @capgo/cli@latest build request --platform android
    Capgo Build documentazione

  3. Carica i pacchetti come delta

    Gli utenti attendono il download all'avvio, quindi invia solo i file modificati. Il CLI rileva i modi di applicazione istantanea e richiede un upload delta.

    npx @capgo/cli@latest bundle upload --channel production --delta
    Aggiornamenti delta della documentazione

  4. Mantieni il rollback automatico su

    Chiamare notifyAppReady() una volta che il tuo app è iniziato. Se un nuovo pacchetto fallisce l'avvio, il dispositivo torna al pacchetto lavorante precedente.

    import { CapacitorUpdater } from '@capgo/capacitor-updater'

await CapacitorUpdater.notifyAppReady()
    Documentazione per notifyAppReady()

Scegli il modo che si adatta alla tua app

Il vantaggio diretto è un affare: un breve atteso al lancio in cambio della nuova versione sullo schermo iniziale.

Tre modalità di applicazione istantanea

Imposta autoUpdate in capacitor.config.ts. Ogni modalità decide quando un aggiornamento può applicarsi mentre l'utente attende.

  • Solo all'installazione: solo dopo un installazione fresca o un aggiornamento del store dell'app nativa
  • Solo al lancio: quando l'app si avvia da uno stato ucciso (avvio freddo)
  • Sempre: su ogni controllo in primo piano, anche mentre l'app è aperta
Impostazioni dell'aggiornatore

3

Modalità di applicazione istantanea in autoUpdate

Gestione dello schermo di caricamento

Il vantaggio diretto richiede @capacitor/splash-screen con launchAutoHide impostato su false e autoSplashscreen impostato su true. L'aggiornatore nasconde lo schermo di caricamento una volta applicato l'aggiornamento, o una volta che sa che non è necessario alcun aggiornamento.

  • Non è necessario alcun chiamata manuale SplashScreen.hide()
  • keepUrlPathAfterReload keeps the user on the same route after the reload
  • Listen for appReady if you need extra work after the splash hides
Gestione della schermata di benvenuto

autoSplashscreen

Richiesto per ogni modalità diretta

Compromessi da pianificare

Gli utenti attendono il download all'avvio, e con sempre un aggiornamento possono reload l'applicazione mentre è in uso. Pianifica per entrambi.

  • Carica con --delta in modo che solo i file modificati scaricano
  • Save and restore app state so a reload does not lose user progress
  • Mantieni la modalità predefinita quando una sessione di ritardo è sufficiente
Documentazione aggiornamenti delta

--delta

Consigliato per ogni upload di aggiornamento diretto

Quando utilizzare gli aggiornamenti diretti

Utilizza il modo diretto quando la sessione corrente deve eseguire il nuovo code. Mantieni il valore predefinito per tutto il resto.

Correzioni di bug critici

Bug di pagamento, accesso o dati in cui eseguire l'antico code per un'altra sessione è troppo.

Primo avvio di onboarding

Applica il bundle più recente immediatamente dopo un'installazione fresca o un aggiornamento del negozio, quindi gli utenti nuovi iniziano con la tua onboarding corrente.

Contenuti datati

Pagine di evento, avvisi o termini che devono essere attuali quando gli utenti aprono l'app.

Patch di sicurezza

Aggiornamenti diretti per il layer web che dovrebbero eseguirsi al lancio. Le correzioni native code richiedono comunque una rilascio di store.

Rilasci di routine

Aggiustamenti di stile e piccole funzionalità non giustificano spesso un attesa all'uscita. Il modo predefinito applica gli aggiustamenti nella sessione successiva.

Applicazioni che rimangono aperte per ore

Con controlli periodici (ogni 10 minuti di default) possono essere applicate aggiornamenti mentre l'applicazione è aperta. Salva lo stato prima di affidarti a essa.

Mantenere l'attesa all'uscita breve

L'attesa all'uscita è il controllo dell'aggiornamento più il download. Gli aggiornamenti delta riducono il download ai file modificati.

~50ms

Tipica latenza API

Delta

Sono scaricati solo i file modificati

1B+

Aggiornamenti consegnati al mese

Soluzioni per tipo di team

Trova la soluzione che si adatta alle esigenze del tuo team

Imprese

Deployimenti multi-applicativi e multi-team

Startups

Rilascia velocemente senza sovraccaricare

Sviluppatori Indipendenti

14 giorni di prova gratuita, caricamento CLI

Agenzie

Gestisci applicazioni multiple per i clienti

App costruite con Capacitor

Public information apps need urgent content fixes

Applicazioni di emergenza, sanità e civica non possono attendere giorni per correggere un elenco rotto, un collegamento di risorsa o un avviso specifico per la località. Le aggiornamenti diretti consentono al layer web di muoversi non appena la correzione è stata approvata.

Icona dell'app FEMA METEO

FEMA

Guida di emergenza dove piccoli errori di contenuto possono diventare urgenti.

Installa Google Play
1,6M
Valutazione negli store
4.0
Icona dell'app Conecte SUS MEDICALE

Connetti

Superfici di registrazioni sanitarie e guide dove le modifiche approvate devono essere consegnate velocemente.

Installa Google Play
27,7M
Valutazione negozio
4.6
Icona dell'app e-Título SOCIAL

e-Título

Flussi di identità civica dove la guida sicura per versioni è importante su più dispositivi.

Installazioni Google Play
54,9M
Valutazione negozio
4.8

Prova dei clienti

Ciò che gli team che utilizzano Capgo dicono

5.0/5 valutato dalle squadre di sviluppatori 9,400+ team Leggi le recensioni

Kapil

Fondatore, NuTriQ

"Essere in grado di inviare aggiornamenti OTA in produzione istantaneamente senza dover attendere i cicli di revisione completo dell'App Store è stato un enorme vantaggio operativo."

Ritratto di Sergiu S

Sergiu S

Sergiu S - Responsabile dello sviluppo, drivolino GmbH

The Capgo Capacitor Updater plugin ha completamente rivoluzionato il modo in cui distribuiamo gli aggiornamenti. Ciò che un tempo richiedeva giorni ora richiede solo minuti.

Ritratto di Luis Dominguez

Luis Dominguez

El che paga, Anirol

“Dal momento in cui ho iniziato ad utilizzare Capgo tutto è più veloce, e posso dare ai miei utenti il tempo che meritano senza trascurare la mia vita quotidiana.”

FAQ

Domande sui diretti aggiornamenti

Quando utilizzarli, come configurarli e cosa costano al lancio.

Dovremmo utilizzare gli aggiornamenti diretti o il modo di sfondo predefinito?

Utilizzare il predefinito per la maggior parte delle rilasci: non c'è attesa al lancio, e gli utenti ricevono l'aggiornamento nella sessione successiva. Utilizzare un modo diretto quando la sessione che inizia dopo l'upload deve eseguire il nuovo code, ad esempio un checkout rotto o un fix di sicurezza per il layer web.

Comportamento dell'aggiornamento

Qual è la differenza tra atInstall, onLaunch e sempre?

atInstall applica un aggiornamento immediatamente solo dopo un installazione fresca o un aggiornamento della store dell'app nativa, quindi comporta come il default. onLaunch applica immediatamente quando l'app inizia da uno stato ucciso. sempre controlla ogni volta che l'app è in primo piano e applica non appena il download è completato, anche mentre l'utente è all'interno dell'app.

Impostazioni dell'aggiornatore

Perché il plugin dello schermo di benvenuto è richiesto?

Direct modes apply the update while the user waits. Without @capacitor/splash-screen, autoSplashscreen: true, and launchAutoHide: false, users can see a flicker or the old UI before the reload. With them, the splash stays up until the update is applied or the updater knows none is needed.

Gestione dello schermo di benvenuto

Posiamo attivare gli aggiornamenti diretti con un live update?

No. autoUpdate lives in capacitor.config, which is read into the native app at build time. Ship the new setting in a store release. After that, every live update follows the new mode.

Compatibilità nativa dei documenti

Il nostro config utilizza directUpdate. È ancora supportato?

directUpdate is deprecated but still detected. Its values match the autoUpdate modes atInstall, onLaunch, and always. Move the setting to autoUpdate in your next native release.

Impostazioni dell'aggiornatore

Metti la tua prossima correzione sulla prima schermata

Prova il modo di aggiornamento diretto su una build di test durante la prova e misura il tempo di avvio sul tuo app.

14 giorni di prova gratuita senza carta di credito