Siete felici di aver chiesto.
Non sto dando consigli legali. Sto condividendo cosa è pratico e largamente utilizzato tra i team che distribuiscono Capacitor app in modo sicuro.
L'importante distinzione è questa:
- La sottoscrizione nativa è ancora richiesta per nuove funzionalità native e capacità principali.
- Aggiornamenti in tempo reale Sono destinati a correzioni e aggiustamenti JavaScript/web all'interno dello scope dell'app esistente.
Both iOS e Android possono utilizzare questo modello, ma dovete trattarlo come un flusso di lavoro sicuronon è un'eccezione.
Cosa Apple e Google consentono in termini semplici
Puoi considerare Apple e Google come condividere un confine simile:
- Puoi distribuire il contenuto code interpretato dal layer web integrato (HTML/CSS/JS) senza doverlo risubmettere.
- Non dovresti utilizzare quel canale per aggiungere funzionalità principali che cambiano lo scopo dell'app.
- Non dovresti alterare i controlli di sicurezza o di distribuzione critici attraverso JavaScript da solo.
Apple’s official guidance around WebKit/JavaScript updates is the core of this model. Google is typically less restrictive for web-based updates, but the same principle applies: keep native changes in a native release.
Cosa Capgo è buono per
Capgo è per:
- risolvere i bug web,
- correzioni sicure per la copia UI / stile / flusso.
- 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 passare attraverso la revisione,
- modificare il comportamento di firma, crittografia o identità del pacchetto.
Strategia di rilascio consigliata
Pensa in due tracce:
Traccia 1: traccia nativa (revisione del negozio)
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.
Questi richiedono:
bun run build
bunx cap sync
# then App Store / Google Play submission flow
Track 2: Tracciato JS (Capgo)
Per cambiamenti di runtime sicuri e piccoli:
bun run build
bunx @capgo/cli deploy --channel staging
bunx @capgo/cli deploy --channel production
Questo ti consente di iterare velocemente senza dover caricare nuovi file binari, mantenendo stabile il binario stesso.
Come evitare “oops, questo richiedeva un rilascio nativo”
Prima di ogni rilascio (Capgo), esegui questa rapida verifica:
- La modifica richiede una nuova dipendenza nativa o una autorizzazione?
- Cambia le capacità pubblicizzate dell'app?
- Alterano i confini di autenticazione e sicurezza?
- 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à
- Mantieni la banda di revisione dell'app per modifiche significative.
- Preservi il controllo del rollback e il patching veloce.
- Riduci 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, revisione nativa solo per i binari reali.
Se desideri approfondire, abbinare questo con una strategia di ambiente rigorosa basata sui canali in modo che la QA non riceva errori di produzione. È il modo Capgo-nativo per mantenere puliti lo staging, la beta e la produzione.
Continua da Come aggiornare le app Capacitor JS senza revisione di store ripetuta
Se stai utilizzando How to aggiornare Capacitor app JS senza revisione di store ripetuta per pianificare l'approvazione e la distribuzione del store, connettilo con @capgo/capacitor-revisioni-in-app per i dettagli di implementazione in @capgo/capacitor-revisioni-in-app, Utilizzare @capgo/capacitor-revisioni-in-app per la capacità nativa in Utilizzare @capgo/capacitor-revisioni-in-app, @capgo/capacitor-mercato-nativo per i dettagli di implementazione in @capgo/capacitor-mercato-nativo, Utilizzare @capgo/capacitor-mercato-nativo per la capacità nativa in Utilizzare @capgo/capacitor-mercato-nativo, e Capacitor Aggiornamenti OTA: Guida all'approvazione del store per il contesto pratico in Capacitor Aggiornamenti OTA: Guida all'approvazione del store.