Salta al contenuto principale

Targeting delle versioni

Invia a ogni versione nativa solo i bundle che può eseguire

Gli utenti aggiornano l'app dallo store con i propri tempi, quindi diverse versioni native della tua app sono attive contemporaneamente. Capgo controlla le dipendenze native di ogni bundle, blocca gli aggiornamenti in base a regole di versione e può instradare ogni versione nativa verso il proprio canale.

Verifica la compatibilità nativa prima dell'upload

La compatibilità del bundle confronta i pacchetti nativi del tuo progetto con il bundle attivo sul canale. Aggiungi --fail-on-incompatible in CI per bloccare un upload che richiede un nuovo binario.

Docs sulla compatibilità nativa

Imposta una versione nativa minima per ogni bundle

Imposta il canale sulla strategia metadata e fai l'upload con --auto-min-update-version. I dispositivi con versione nativa sotto la soglia del bundle lo saltano e mantengono il bundle attuale.

Documentazione sul version targeting

Blocca gli update tra linee semver

--disable-auto-update major, minor o patch impedisce a un dispositivo di ricevere un bundle fuori dalla sua linea di versione nativa. Queste regole confrontano solo i numeri di versione: non ispezionano i code nativi.

Tipi di update e blocco versioni

Un canale per ogni versione nativa

Imposta il defaultChannel nella config Capacitor di ogni Native Build, ad esempio v2 o v3. Ogni versione avrà i suoi bundle, e una versione più vecchia potrà restare sul suo ultimo bundle funzionante.

Documentazione sul version targeting

Come funziona

Come i team con più versioni native usano Capgo

Una configurazione CI che permette alla lane live update e alla lane dello store di lavorare insieme. Ogni comando qui sotto proviene dalla documentazione Capgo CLI.

  1. Verifica se il commit richiede un Native Build

    build needed confronta i tuoi pacchetti nativi con il canale. Restituisce 'yes' ed esce con code 1 quando è necessario un rilascio sullo store, e 'no' quando basta un live update.

    npx @capgo/cli@latest build needed com.example.app --channel production
    Riferimento build needed

  2. Passa alla strategia basata sui metadati

    Fallo una sola volta. Da quel momento, ogni bundle includerà una versione nativa minima e i dispositivi inferiori salteranno il bundle.

    npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update metadata
    Documentazione sul version targeting

  3. Carica live update ogni giorno

    Mantieni --auto-min-update-version su ogni upload. --fail-on-incompatible blocca il job se il bundle richiede code nativi che il canale non ha.

    npx @capgo/cli@latest bundle upload --channel production \
  --auto-min-update-version \
  --fail-on-incompatible
    Docs sulla compatibilità nativa

  4. Carica il bundle per un nuovo rilascio nativo

    Quando esce il nuovo binario, carica il suo bundle senza --fail-on-incompatible. Capgo alza la soglia minima così i build più vecchi vengono saltati, e i controlli successivi confrontano con i nuovi pacchetti nativi.

    npx @capgo/cli@latest bundle upload --channel production \
  --auto-min-update-version
    Workflow dei canali native e OTA

Migrazione da Appflow

Vieni da Ionic Appflow?

Appflow associava i live updates alle versioni native per te. Con Capgo ottieni lo stesso risultato con canali e regole di versione:

  1. Crea un canale per ogni linea nativa, ad esempio v1 e v2.
  2. Imposta defaultChannel nella config Capacitor di ogni build nativa sul relativo canale.
  3. Fai l'upload di ogni bundle sul canale della linea nativa per cui è stato buildato.
  4. Mantieni --auto-min-update-version durante gli upload, così un bundle che richiede un code nativo più recente viene saltato sulle build più vecchie.
Guida alla migrazione Appflow
Canale per linea nativa 
// capacitor.config.ts in your 2.x native builds
plugins: {
  CapacitorUpdater: {
    defaultChannel: 'v2',
  },
},

# ship a fix to 2.x users only
npx @capgo/cli@latest bundle upload --channel v2 \
  --auto-min-update-version

# 1.x devices stay on their channel's current bundle

Casi d'uso comuni

Nuovo plugin nativo

Il tuo binario 2.0 aggiunge un plugin camera. Carica con --auto-min-update-version il bundle che lo usa: i dispositivi 1.x lo salteranno finché gli utenti non installano la 2.0.

Docs sulla compatibilità nativa

Rilascio graduale

Invia un bundle a una parte di un canale con --rollout, monitora i dati di install e fallimenti, poi promuovilo o fai rollback.

Docs sui rollout progressivi

Dismettere una vecchia versione

Smetti di caricare sul canale v1. I dispositivi su quel canale mantengono l'ultimo bundle funzionante, mentre la v2 continua a ricevere update.

Documentazione sul version targeting

Ogni linea nativa punta al proprio canale

Un esempio di layout con tre versioni native attive.

  • Native 3.x
    v3
    Nuovi bundle
  • Native 2.x
    v2
    Solo fix
  • Native 1.x
    v1
    Nessun nuovo bundle

Rilascia feature su v3, fix su v2 e nulla su v1. I dispositivi su v1 mantengono l'ultimo bundle funzionante.

App buildate con Capacitor

Le app pubbliche devono supportare vecchie e nuove versioni native

App civiche, sanitarie o di previsioni possono supportare versioni Android datate e diverse generazioni di dispositivi. Il version targeting permette di mantenere ogni Native Build sul web bundle più recente e compatibile, senza imporre un unico percorso di aggiornamento a tutti.

Icona dell'app e-Título SOCIAL

e-Título

App di identità civica con ampie necessità di compatibilità su dispositivi pubblici.

Installazioni Google Play
54,9M
Valutazione store
4.8
Icona dell'app Conecte SUS MEDICINA

Connetti SUS

App di salute in cui shell native vecchie e nuove potrebbero richiedere web bundle differenti.

Installazioni Google Play
27,7M
Valutazione store
4.6
Icona dell'app Windy.com - Previsioni meteo METEO

Windy.com - Previsioni Meteo

App meteo in cui le capacità del dispositivo e le performance della mappa possono variare in base alla versione.

Installazioni Google Play
32,9M
Valutazione store
4.7

Cosa dicono i clienti

Cosa dicono i team che rilasciano con Capgo

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

no-tone @ Webincode

Sviluppatore, Webincode

“Poter aggiungere i Device ID a determinati gruppi e inviare le modifiche solo a quei gruppi è una manna.”

Nate van Jole

CTO, Privato

“Il setup ha richiesto meno di un giorno. I rollout basati su channel mi permettono di testare sul mio dispositivo prima che qualsiasi cosa arrivi agli utenti in produzione.”

Ritratto di Sergiu S

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.”

FAQ

Domande sulle versioni in circolazione

Per i team che supportano utenti che aggiornano l'app dallo store in momenti diversi.

Cosa succede agli utenti che non aggiornano mai l'app nativa?

Continueranno a ricevere bundle compatibili con la loro versione nativa. Con la strategia metadata, un bundle la cui versione nativa minima è superiore alla loro viene saltato e restano sul bundle attuale.

Documentazione sul version targeting

--disable-auto-update è abbastanza incisivo da prevenire i crash?

No. Le regole di versione confrontano solo i numeri di versione, quindi una modifica nativa rilasciata in una minor o patch viene comunque distribuita. Usa --fail-on-incompatible o --auto-min-update-version, che controllano i tuoi pacchetti nativi.

Docs sulla compatibilità nativa

Come fa la CI a sapere se una modifica richiede un rilascio sullo store?

Esegui build needed o bundle releaseType sul channel. Entrambi confrontano i metadati dei pacchetti nativi. Non vedono ogni modifica in ios/, android/ o capacitor.config, quindi aggiungi controlli anche su quei percorsi in git.

Scegli OTA o Native Build in CI

Stiamo passando da Ionic Appflow. Possiamo mantenere gli update abbinati alla versione?

Sì. Usa un canale per ogni versione native con defaultChannel, oppure la strategia metadata con --auto-min-update-version. La guida alla migrazione di Appflow ti accompagnerà nella configurazione.

Guida alla migrazione Appflow

E se un bundle incompatibile è già stato rilasciato?

Riporta il channel all'ultimo bundle compatibile nella sua cronologia, oppure forza il bundle integrato e rilascia la build nativa. notifyAppReady() effettua il rollback di un bundle che non parte, ma non sostituisce code nativi compatibili.

Docs sui rollback

Associa ogni versione nativa a un bundle compatibile

Configura la strategia metadata e un controllo di compatibilità in CI durante la prova gratuita di 14 giorni. Nessuna carta di credito richiesta.