How to update Capacitor JS apps without repeat store review

Siete felici di aver chiesto.

Non sto dando consigli legali. Sto condividendo ciò che è pratico e largamente utilizzato tra le squadre che distribuiscono le app Capacitor in modo sicuro.

La distinzione importante è questa:

• Sottoscrizione nativa è ancora richiesta per nuove funzionalità native e capacità principali.
• Aggiornamenti in tempo reale sono per correzioni e aggiustamenti JavaScript/web all'interno dello scope dell'app esistente.

Sia iOS che Android possono utilizzare questo modello, ma dovete trattarlo come un flusso di lavoro sicuro per le politiche, non come un'escamotage. Ciò che Apple e Google consentono in termini sempliciPotete considerare Apple e Google come condividendo un confine simile:

Potete consegnare __CAPGO_KEEP_0__ interpretato dal layer web incorporato (HTML/CSS/JS) senza riassegnare.

Non dovete utilizzare quel canale per aggiunte di funzionalità principali che cambiano lo scopo dell'app.

1. You can deliver code interpreted by the embedded web layer (HTML/CSS/JS) without resubmitting.
2. La guida ufficiale di Apple per aggiornamenti WebKit/JavaScript è il nucleo di questo modello. Google è tipicamente meno restrittivo per aggiornamenti basati su web, ma la stessa regola si applica: mantenete le modifiche native in una versione nativa.
3. You can deliver __CAPGO_KEEP_0__ interpreted by the embedded web layer (HTML/CSS/JS) without resubmitting.

You should not use that channel for major feature additions that change app purpose.

Cosa Capgo è buono per

Capgo è per:

• correzioni di bug web in tempo reale,
• correzioni sicure per copia, stile e flusso dell'interfaccia utente,
• correzioni logiche minori nelle pagine esistenti,
• esperimenti veloci per la QA interna.

Capgo non è per:

• aggiungere autorizzazioni o nuove capacità native,
• invio di nuove capacità core che dovrebbero essere sottoposte a revisione,
• cambiare il comportamento di firma, crittografia o identità del pacchetto.

Strategia di rilascio consigliata

Pensa in due tracce:

Track 1: traccia nativa (recensione dello store)

Use your normal Capacitor release process for:

• aggiornamenti di plugin nuovi,
• modifiche dello shell o del manifesto dell'app,
• aggiornamenti delle autorizzazioni,
• modifiche di funzionalità specifiche per piattaforma.

Queste richiedono:

bun run build
bunx cap sync
# then App Store / Google Play submission flow

Track 2: traccia JS (Capgo)

Per modifiche di runtime sicure e piccole:

bun run build
bunx @capgo/cli deploy --channel staging
bunx @capgo/cli deploy --channel production

Ciò ti consente di iterare velocemente senza dover caricare nuovi file binari, mantenendo stabile il file binario stesso.

Come evitare “oops, questo richiedeva un rilascio nativo”

Prima di ogni rilascio Capgo, esegui questo gate veloce:

1. Richiede la modifica una nuova dipendenza nativa o autorizzazione?
2. Modifica le capacità pubblicizzate dell'app?
3. Alterna i confini di autenticazione/sicurezza?
4. Posso descriverlo come un fix JavaScript non interrompibile?

Se la risposta è sì a (1)-(3), invia una versione nativa. Se sì solo a (4), invia attraverso Capgo.

Cosa significa per i team di conformità

• Riservate la banda di revisione dell'app per modifiche significative.
• Preservate il controllo di rollback e il patching rapido.
• Riducete il rischio di produzione testando gli aggiornamenti nei canali prima di una piena distribuzione.

Questo è lo stesso approccio che le persone utilizzano nei grandi programmi Capacitor in produzione: aggiornamenti veloci per i fix JavaScript solo, revisione nativa solo per i reali binari.

Se desiderate approfondire, associate questo con una strategia di ambiente rigorosa basata sui canali in modo che la QA non riceva mai errori di produzione. Quello è il modo Capgo-nativo per mantenere puliti lo staging, la beta e la produzione.