Come mantenere gli aggiornamenti di Capgo leggeri e veloci

Il miglior live update è quello che gli utenti quasi non notano.

Di solito, questo significa tre cose:

1. Il download è piccolo.
2. Il rollout è controllato.
3. Il ripristino è istantaneo se qualcosa va storto.

Lo stesso consiglio di "mantenere l'OTA leggero" che vale per React Native si applica anche a Capgo. La differenza è che Capgo offre ai team Capacitor alcuni strumenti extra: Aggiornamenti delta, canali, rollback automatici, targeting delle versioni, e opzionali la crittografia end-to-end.

Usandoli insieme, otterrai payload più piccoli, installazioni più veloci e molta meno confusione operativa.

L'efficienza conta anche se gli MAU rimangono invariati

Un dettaglio utile specifico per Capgo: Capgo MAU è essenzialmente il numero di dispositivi attivi mensili che hanno contattato il servizio di update negli ultimi 30 giorni.

Quindi, snellire un bundle non è solo un trucco per ridurre il conteggio degli MAU. È importante perché migliora ciò che utenti e team percepiscono realmente:

• Download più veloci su rete cellulare o Wi-Fi debole
• Esperienza migliore con gli update diretti
• Meno banda sprecata per release fallite o rollback
• Raggio d'impatto ridotto durante test o staging di una release

Gli update lean riguardano davvero velocità, sicurezza e disciplina operativa.

1. Usa gli update Delta di default

Se devi fare una sola cosa, fai questa.

di Capgo Aggiornamenti delta invia solo i file modificati tra le versioni invece di riscaricare l'intero web bundle. È il più grande vantaggio per le performance OTA di routine.

bun run build
bunx @capgo/cli@latest bundle upload --channel staging --delta

Quando il QA è terminato:

bunx @capgo/cli@latest bundle upload --channel production --delta

Se vuoi mantenere la CI rigorosa, usa --delta-only così nessuno tornerà accidentalmente agli upload di bundle completi:

bunx @capgo/cli@latest bundle upload --channel production --delta-only

Usa solo --delta-only quando il tuo parco dispositivi supporta i Delta updates. Con versioni di plugin miste, i dispositivi più vecchi che non supportano la consegna delta basata su manifest non potranno scaricare quell'update.

Questo è ancora più importante se usi directUpdate, perché il tempo tra “update trovato” e “app ricaricata” diventa visibile all'utente.

2. Tratta gli asset come asset, non come baggage di JavaScript

Gli asset pesanti sono la causa principale del bloating dei bundle OTA.

Alcune regole pratiche:

• Non includere immagini o media pesanti direttamente nel JavaScript se puoi usare un normale file asset.
• Tieni i contenuti che cambiano spesso sul tuo CDN o su API se non devono stare nel bundle dell'app.
• Fai attenzione alle immagini di marketing, ai video di onboarding e agli asset per campagne temporanee che vengono sostituiti a ogni release.
• Mantieni gli asset stabili. Con gli aggiornamenti Delta, i file invariati vengono riutilizzati invece di essere scaricati di nuovo.

È uno dei modi più semplici per mantenere Capgo veloce mentre l'app cresce. Il pattern peggiore è una piccola correzione UI che costringe gli utenti a scaricare un sacco di media non correlati.

3. Usa le release native per i veri cambiamenti nativi

Capgo aggiorna il web layer: HTML, CSS, JavaScript e gli asset caricati a runtime.

Non è il canale adatto per:

• nuovi plugin nativi,
• cambiamenti ai permessi,
• capacitor.config.ts modifiche,
• qualsiasi cosa che modifichi lo stato del progetto nativo iOS o Android.

Quella distinzione è fondamentale anche per le performance. Se continui a inserire grandi cambiamenti strutturali nel canale OTA, la tua strategia di update diventerà sempre più pesante e rischiosa.

Usa intenzionalmente due canali di rilascio:

Canale Native

Per modifiche ai plugin, ai permessi e alla configurazione nativa:

bun run build
bunx cap sync

Poi pubblica un normale rilascio sugli store.

Canale Capgo

Per iterazioni sicure sul web-layer:

bun run build
bunx @capgo/cli@latest bundle upload --channel production --delta

Aggiorna regolarmente anche la tua baseline nativa se hai aggiunto molti asset a lungo termine. Una nuova build sugli store incorpora quella baseline, mantenendo i futuri diff di Capgo più piccoli.

4. Usa i canali per limitare la dimensione del rollout

Un update "lean" non riguarda solo i megabyte. Riguarda anche quanti dispositivi ricevono l'update prima che tu possa confermarne la stabilità.

di Capgo sistema di canali è il modo più pulito per gestirlo:

• staging per il QA
• beta per i tester invitati
• production per tutti
• hotfix per il ripristino di emergenza

Un flusso semplice è questo:

1. Upload su staging.
2. Valida su dispositivi reali.
3. Distribuisci gradualmente, tramite canali controllati o rollout basato su percentuali.
4. Esegui il rollback immediato se le performance calano.

Se la tua app ha più baseline native attive, associa i canali a targeting delle versioni. Così eviti di inviare bundle incompatibili o troppo pesanti a vecchi binari.

Per i team che cercano cicli di revisione ancora più rapidi, Capgo funziona bene con PR preview. Questo permette a product, QA e stakeholder di testare modifiche JS senza aspettare nuovi build di TestFlight o Play internal.

5. Se abiliti gli update diretti, ottimizza il comportamento di

Più velocemente vuoi applicare un update, più deve essere disciplinato il tuo startup path.

di Capgo comportamento degli update docs explicitly recommend pairing directUpdate agli update Delta. È la scelta migliore di default.

Il secondo guardrail è notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

Se la tua app non segnala lo stato ready entro i 10 secondi notifyAppReady() predefiniti, o entro il tempo che appReadyTimeout hai impostato nella tua config Capacitor, Capgo può marcare quel bundle come non valido e ripristinare la versione valida precedente. Questo comportamento di rollback è quello che vuoi in produzione, ma significa anche che devi mantenere l'avvio pulito:

• Chiama notifyAppReady() nel posto giusto
• Evita operazioni lente all'avvio nel critical path
• Salva e ripristina lo stato dell'app con cura se ricarichi subito
• Testa scenari con rete instabile e device low-end prima del rollout

Se non l'hai letta di recente, la guida notifyAppReady merita una rilettura.

6. Usa canali di update interni invece di inutili Native Build

Molti team mobile perdono tempo a buildare binari per modifiche che sono chiaramente solo web.

Se la modifica riguarda:

• il copy,
• UI polish,
• il flusso di onboarding,
• la logica della schermata di pricing,
• l'integrazione dell'analytics,
• i feature flag,
• rendering del prompt o della risposta API,

spesso un aggiornamento Capgo è l'artefatto più rapido da revisionare.

Ciò significa meno rebuild nativi, meno churn su TestFlight e un feedback loop più stretto per il team. È uno dei vantaggi più sottovalutati di Capgo: puoi spostare più lavoro di revisione e QA sul canale OTA senza rompere il confine nativo/web.

La nostra guida su lo staging con un solo ID app mobile spiega un modo pratico per mantenere tutto pulito nel tempo.

7. Tieni separato lean da secret

Bundle piccoli e bundle sicuri risolvono problemi diversi.

I canali controllano l'idoneità. Di per sé non rendono riservato un bundle.

Se hai bisogno di garanzie di distribuzione più forti:

• abilita la crittografia Live Update,
• usa lo storage personalizzato o la distribuzione self-hosted,
• e tieni le chiavi private solo in CI o in workflow operativi sicuri.

Questo non rende la dimensione dell'update irrilevante. Significa solo che devi ottimizzare entrambe le dimensioni:

• leggero per la velocità,
• criptato per il controllo della distribuzione,
• canali per il controllo del rollout,
• rollback per il ripristino.

Un workflow pratico “lean Capgo”

Se vuoi un modello operativo semplice di default, usa questo:

1. Mantieni separati i flussi di rilascio native e OTA.
2. Carica le modifiche JS con --delta di default.
3. Usa staging e beta canali prima di production.
4. Guarda statistiche e log degli update dopo il rollout, non solo prima.
5. Trasforma le PR in preview installabili quando non serve una build nativa.
6. Evita di includere nel bundle media pesanti o che cambiano spesso.
7. Aggiorna la baseline nativa dopo grandi aumenti di asset o modifiche native.
8. Gestisci notifyAppReady() e il rollback come parte del release engineering, non come dettagli di setup.

Questa combinazione resta veloce molto più a lungo dell'approccio comune "carica tutto ciò che è cambiato".

Considerazione finale

Per i team Capgo, "lean and fast" non è solo una questione di dimensione del bundle.

È un problema di design del rilascio.

Usa i Delta update per la dimensione del payload, i channel per la portata del rollout e i rollback per gestire i fallimenti. Pensando agli OTA in questo modo, i tuoi update rimarranno veloci anche con l'aumentare dell'app, del team e della base utenti.

Continua da Come mantenere gli update di Capgo snelli e veloci

Se stai usando Come mantenere gli aggiornamenti di Capgo leggeri e veloci per pianificare il routing dei canali e il rollout graduale, connettilo a Canali per i dettagli di implementazione nei Channels, Canali per i dettagli di implementazione nei Channels, Canali per i dettagli di implementazione nei Channels, Soluzione Beta Testing per il workflow di prodotto nella Soluzione Beta Testing, e Soluzione Version Targeting per il workflow di prodotto nella Soluzione Version Targeting.