CodePush React Native: OTA updates
CodePush permette di aggiornare il bundle JavaScript di un'app React Native senza passare dagli store. E utile per correggere bug velocemente o per rilasciare modifiche minori. Con la deprecazione di App Center previsto per inizio 2025, le alternative come Expo Updates e self-hosted stanno crescendo.
Come funziona
L'app scarica al lancio (o periodicamente) un nuovo bundle JS firmato. Solo il codice JS e gli asset cambiano: codice nativo, permessi e binari rimangono come pubblicati sullo store. L'update e silenzioso e l'utente vede il nuovo codice al prossimo lancio.
Limiti delle store policy
Apple e Google permettono OTA solo per modifiche che non cambiano il comportamento principale dichiarato nella review. Cambiare radicalmente la UX o aggiungere feature non recensite e violazione. Apple in particolare vieta OTA che ridiretta a contenuti non recensiti.
Alternative
Expo Updates: integrazione nativa con il Managed/Bare workflow, hosting su Expo. Self-hosted: distribuisci il bundle dal tuo server con firma e verifica. EAS Update: gestione semplificata per progetti Expo. Per progetti enterprise valuta le soluzioni con audit log e rollback.
Limitazioni Apple
Apple permette OTA solo per cambiamenti che non alterano "scope, functionality, or features" dichiarati nella App Store review. Esempi accettabili: bug fix, copy update, styling. Esempi NON accettabili: aggiungere screen nuova, cambiare flusso onboarding, monetization changes. Violazione: rimozione dell'app.
Expo Updates e EAS
Expo Updates e l'evoluzione open-source di CodePush. EAS Update e il servizio managed di Expo: distribuzione globale via CDN, gestione canali (preview, production), rollback con un click. Free tier copre la maggior parte dei progetti, piani enterprise per scale grandi.
Self-hosted
Per controllo totale, puoi self-hostare gli OTA: file server con manifest JSON e bundle JS firmato. Vantaggi: no dipendenza da terzi, controllo privacy. Svantaggi: gestione CDN, integrita, rollback. Stack tipico: S3 + CloudFront + signing tramite Sigstore o chiavi proprietarie.
Strategia di rollout
Mai 100% direttamente. Inizia con 5%, monitora crash-free rate per 24 ore, scala a 25%, 50%, 100%. Implementa kill switch lato server: in caso di issue, disabilita l'update e gli utenti tornano al bundle bundled. Combina con feature flags per disattivare singole feature problematiche senza rollback completo.
Bundle signing
Firma i bundle JS con chiave privata, verifica con chiave pubblica nel client. Previene injection attack via MITM. EAS Update e Expo Updates lo fanno automaticamente. Per self-hosted, implementa con node-forge o tweetnacl. Conserva la chiave privata in HSM, mai in repository.
Native dependency mismatch
Errore comune: aggiornamenti OTA con dipendenze native modificate. Esempio: aggiorni react-native-reanimated via OTA, ma la versione nativa nel binary e vecchia. App crasha. Imposta versionate compatibilità server-side: il bundle JS dichiara native version richiesta, il server serve solo a client compatibili.
Procedura passo-passo
- Scegli la piattaforma OTA (Expo Updates, EAS, self-hosted).
- Integra l'SDK e configura le chiavi.
- Crea canali separati (staging, production).
- Imposta versioning con runtime version o appVersion.
- Distribuisci a percentuali (10%, 50%, 100%) per minimizzare rischi.
- Implementa rollback rapido in caso di problemi.
- Documenta la policy interna di rilascio OTA.
Monitoraggio OTA
Tracking metriche OTA: install rate del bundle, crash rate post-update, time-to-update per percentile, rollback effettuati. Strumenti: EAS Update dashboard, custom analytics su event "ota_update_applied". Imposta alert per spike di crash subito dopo rollout. Pattern: rollback automatico se crash-free rate scende sotto threshold nelle prime 6 ore.
Errori comuni e come risolverli
- OTA contro le policy: rejection o rimozione app.
- Bundle non firmato: rischio MITM e iniezione codice.
- Versioning non gestito: app con codice nuovo ma asset vecchi.
- Mancato rollback: gli utenti restano bloccati su bug.
- Caching aggressivo: gli utenti non vedono mai gli update.
Domande frequenti
D: OTA e legale?
R: Si, se rispetta le policy degli store. Per cambi rilevanti devi sempre passare dalla review.
D: Funziona anche con Flutter?
R: Per Flutter esiste Shorebird che fornisce funzionalita simili.
D: Quanto pesa il bundle medio?
R: Tipicamente 1-5 MB per modifiche standard di app React Native.
D: Posso forzare un'update obbligatorio?
R: Si tramite mandatory flag, ma user experience deve essere chiara. Force update senza opzione disinstalla app.
Best practice operative
Documenta policy OTA: cosa puo essere shippato OTA (bug fix, copy), cosa richiede app store review (nuove feature, UI changes). Forma il team su queste regole. Audit OTA mensile per verificare compliance. Misurare adoption rate e crash rate per release. Strumento potente se usato responsabilmente.
OTA puo introdurre complessita di debug: quale bundle e in esecuzione? La versione native e compatibile? Implementa logging che riporti versione bundle in ogni crash report. Combine con feature flag per testing fine-grained. Per app critiche, OTA con percentage rollout e rollback automatico sono best practice obbligatorie.
Considera anche Shorebird per Flutter, che offre simile capability per code push Dart. Ecosystem in evoluzione: valuta options ogni 6-12 mesi.
Hai bisogno di aiuto?
Se vuoi sviluppare la tua app con G Tech Group, scrivici tramite il modulo di contatto.