FAQ

Se hai domande non presenti in questa pagina, chiedi pure! Puoi aprire un issue o scrivere su Discord work.

Che cos'è il “code push”?

Code push, noto anche come "over-the-air updates" (OTA), è un servizio cloud che permette agli sviluppatori Capacitor di distribuire aggiornamenti alle proprie app in produzione. Capgo funziona attualmente su Android, iOS ed Electron.

"Code Push" è un riferimento al nome di una funzionalità di deploy usata dalla community React Native di Microsoft e Expo, nessuno dei quali supporta Capacitor.

Le versioni major di Capgo CLI devono corrispondere al mio plugin o alla Capacitor?

No. Usa sempre l'ultima Capgo CLI (npx @capgo/cli@latest). La console CLI e Capgo seguono il proprio versionamento e rimangono compatibili con qualsiasi major di plugin updater supportato. I plugin Capgo seguono le major di Capacitor; vedi il versionamento Capgo per i tag LTS come @lts-v7.

Qual è la differenza tra un bundle e una release?

Usiamo il termine “release” per indicare la preparazione di un binario per gli app store. Per generare successivamente un bundle, Capgo deve conoscere l'esatto binario inviato agli app store.

Usiamo il termine “bundle” per indicare una patch che può essere applicata a una release per aggiornarla a nuove code. Il npx @capgo/cli@latest bundle upload il comando viene usato per generare un bundle dal tuo nuovo code locale, che viene poi inviato ai tuoi utenti.

Ci sono limitazioni sui file-path degli aggiornamenti Delta?

Sì:

• File da zero byte: I log di CLI Ignoring empty file... ed esclude i file vuoti dai file delta. Non interrompe l'upload, quindi un file vuoto può modificare il bundle risultante senza bloccare il deployment. Non includere file da zero byte nei percorsi del bundle Delta.
• Percorsi con spazi: Gli upload Delta falliscono immediatamente con un errore chiaro se un percorso del bundle contiene uno spazio. Rinomina file o directory per rimuovere gli spazi prima di caricare un aggiornamento Delta.

Vedi Aggiornamenti delta per i dettagli sulla configurazione.

Qual è la roadmap?

Anche le nostre board di progetto sono pubbliche e le trovi qui: https://github.com/orgs/Cap-go/projects

Il nostro team lavora anche in pubblico, così puoi vedere cosa stiamo sviluppando in qualsiasi momento. Saremo felici di rispondere a qualsiasi domanda sulla nostra roadmap o sulle priorità tramite le issue di Github o su Discord.

Posso usare Capgo con il mio team?

Sì! Tutti i piani supportano sviluppatori illimitati. Limitiamo solo le metriche dell'app (MAU, storage e banda) per ogni organizzazione.

Vedi Team per maggiori informazioni.

Capgo memorizza il mio code sorgente?

No. I server di Capgo non vedranno mai il tuo code sorgente. Quando esegui npx @capgo/cli@latest bundle upload, Capgo memorizza un file zip del code minificato/compilato - lo stesso code che un browser riceverebbe, non il tuo code sorgente.

Per una sicurezza extra, hai due opzioni:

• Crittografia end-to-end: Cripta il tuo bundle prima dell'upload per proteggerlo durante lo storage e il transito, impedendo a terzi di generare update criptati validi senza la tua chiave privata. Questo non rende impossibile il reverse engineering degli asset web distribuiti, poiché la chiave pubblica è presente nell'app.
• Upload da URL esterno: Memorizza il bundle sul tuo server e fornisci a Capgo solo il link per il download con l'opzione --external <url>

Consulta anche la nostra privacy policy: https://capgo.app/privacy

I file del bundle sono dati privati?

No. I file del bundle sono asset web pubblici destinati a essere scaricati dagli utenti della tua app. Chiunque conosca l'URL del bundle può scaricare quei file, e Capgo lo comunica agli utenti durante il setup e nella documentazione.

L'accesso ai file del bundle non è considerato un data breach. Non inserire segreti, credenziali, dati personali o dati soggetti a normative nel bundle della tua app. Se ti serve maggiore riservatezza per casi d'uso ad alta sicurezza, usa la crittografia end-to-end, ma considera comunque i code e gli asset dell'app come pubblici ai fini della segnalazione di sicurezza.

Posso usare Capgo dal mio sistema CI?

Sì. Capgo è pensato per essere usato dai sistemi CI. Abbiamo pubblicato una guida per Azioni Android e Github e iOS, e per GitLab. Altri sistemi CI funzionano in modo simile.

Non esitare a contattarci tramite GitHub o Discord se riscontri problemi.

Che relazione c'è con Firebase Remote Config o Launch Darkly?

Il push di Code permette di aggiungere nuovi code o sostituire code sul dispositivo. Firebase Remote Config e Launch Darkly sono sistemi di configurazione. Ti permettono di cambiare la configurazione della tua app senza dover rilasciare una nuova versione. Non sono pensati per sostituire code.

Quanto aumenta il peso delle dipendenze?

Non ho effettuato misurazioni recenti, ma prevedo che la libreria di push di code aggiunga meno di un megabyte alle app Capacitor. Sappiamo come ridurne ulteriormente il peso quando diventerà una priorità. Se la dimensione è un problema per te, faccelo sapere!

Capgo funziona sul simulatore iOS 18.4?

No. A causa di un problema a monte che interessa il simulatore iOS 18.4, Capgo non funziona in modo affidabile. Ti preghiamo di testare su un dispositivo reale o di usare una versione diversa del simulatore iOS.

Vedi i dettagli nell'issue di React Native: facebook/react-native#50510

Il push di code funziona con app di grandi dimensioni?

Sì. Non c'è limite alla dimensione dell'app che può essere aggiornata con un push di code. Come indicato qui sotto, Capgo può modificare qualsiasi code JS nella tua applicazione, indipendentemente dalla dimensione.

Nota bene: una dimensione maggiore rende più difficile il download degli aggiornamenti. Consigliamo di mantenere l'app il più piccola possibile.

Per cosa posso usare il push Capgo code?

Abbiamo visto diversi utilizzi, tra cui:

• Fix d'emergenza per app in produzione.
• Rilasciare bug fix agli utenti con versioni precedenti dell'app.
• Rilasci continui (ad esempio ogni ora).

Nota che la maggior parte degli app store vieta di rilasciare code che modifichi in modo significativo il comportamento dell'app. Consulta qui sotto per maggiori informazioni.

Cosa si intende per “MAU” per Capgo?

Un MAU è un Monthly Active Device. Un dispositivo distinto che contatta Capgo in una finestra scorrevole di 30 giorni conta come un MAU per quell'ID app nativa. Lo stesso dispositivo fisico usato con due ID app native distinti conta una volta per ciascun ID; non viene deduplicato tra i due.

Se i tuoi flavour differiscono solo per il layer web o il routing degli update, usa un unico ID app nativa con canali. Questo tiene i flavour sotto un'unica app Capgo e semplifica i rilasci. Usa ID app native separati quando un flavour richiede un bundle ID, un'identità di firma, un set di entitlement o una scheda dello store distinti.

Su iOS, v7.25.0+ mantiene l'ID dispositivo casuale e specifico dell'app anche con le normali reinstallazioni, tramite Keychain. Su Android, usa v7.50.1+ (o v5.50.1+ e v6.50.1+ su quelle linea di rilascio); l'ID viene ripristinato solo se Android Backup/Restore mantiene le preferenze dell'app. Disabilitare il backup, escludere tali preferenze o cancellare i dati dell'app genera un nuovo device ID. L'aggiornamento dell'app non crea un nuovo device ID.

Per le build di test e sviluppo, disattiva la consegna di development-build ed emulator sui canali di produzione. Questo controlla la distribuzione, non gli MAU: un dispositivo può comunque essere contato quando contatta Capgo. Per evitare l'uso in produzione, disabilita i live updates e non chiamare gli endpoint Capgo di produzione. Vedi Testa le Native Build senza Live Updates per le impostazioni esatte.

Per cosa non possiamo usare la push di Capgo code?

Capgo non può modificare il code nativo, come Java, Kotlin, Objective-C, Swift, plugin nativi o configurazione nativa. Queste modifiche richiedono un nuovo rilascio dell'app nativa. Per l'ambito della revisione degli store, vedi le policy di App Store e Google Play.

Posso aggiornare le modifiche a capacitor.config.ts tramite Capgo?

No. Regola semplice: Capgo può inviare la cartella di build web generata, inclusi HTML, CSS, JavaScript, asset e modifiche ai package puramente JavaScript incluse in quell'output. Le modifiche a capacitor.config.ts, la configurazione dei plugin nativi, l'installazione o l'aggiornamento di pacchetti nativi e qualsiasi modifica che richieda l'aggiornamento del progetto iOS o Android tramite npx cap sync o npx cap copy richiedono un rilascio dell'app nativa.

Il file di configurazione di Capacitor viene letto al momento della build nativa e compilato nel binario dell'app nativa. Se devi modificare la configurazione di Capacitor, devi:

1. Aggiornamento capacitor.config.ts localmente
2. Ricompila la tua app nativa (npx cap sync seguita da una Native Build)
3. Invia il nuovo binario agli store

Capgo invia agli store per me?

Capgo Build può compilare e firmare un progetto nativo iOS o Android preparato e, se configurato, inviare il risultato firmato ad App Store Connect o Google Play. Puoi mantenere la tua CI esistente per dipendenze private, build web, sync di Capacitor e preparazione nativa personalizzata; Capgo riceve il progetto nativo preparato per la fase di Native Build.

Vedi Build Capgo e il riferimento alla configurazione di build per le opzioni di workflow e invio agli store.

Cosa memorizza Capgo su disco e dove?

L'updater di Capgo (incluso nella tua app al momento del build) mette in cache l'ultimo bundle scaricato nell'unica directory che capacitor permette di caricare code. Su Android, si trova in /data/user/0/com.example.app/code_cache/capgo_updater anche se la base di quel percorso è fornita dal sistema Android e può cambiare dinamicamente a runtime. Sui dispositivi iOS, i dati sono salvati in Library/Application Support/capgo.

Gli strumenti da riga di comando di Capgo (es. npx @capgo/cli@latest bundle upload) sono installati su disco nelle cache di npm, i tuoi login sono salvati nella home directory in ~/.capgo.

Che relazione c'è con Capacitor Hot Reload?

L'Hot reload di Capacitor è una funzione solo per lo sviluppo. Il push di Code è per la produzione.

L'Hot reload è una feature di Capacitor che ti permette di modificare code sul dispositivo durante lo sviluppo. Richiede il build dell'app Capacitor con un proxy per connettersi alla tua macchina locale.

Il push di Code è una funzionalità che ti permette di modificare code sul dispositivo in produzione. Utilizzeremo diverse tecniche per renderlo possibile a seconda della piattaforma.

Quali tipi di modifiche supporta il push di Capgo code?

Capgo può modificare qualsiasi code JS nella tua applicazione. Ciò include il code dell'app e i code generati. Puoi anche aggiornare le dipendenze in package.json purché non richiedano modifiche code native.

Non abbiamo in programma di supportare modifiche al code nativo (es. Java/Kotlin su Android o Objective-C/Swift su iOS); lo strumento ti avviserà se rileva modifiche al code nativo, poiché non verranno incluse nel bundle.

Supporta il Web?

Il push di Code non è necessario per il web, poiché funziona già così. Quando un utente apre una web app, scarica l'ultima versione dal server se necessario.

Se hai un caso d'uso per il push di code con il web, faccelo sapere!

Funzionerà su iOS, Android, Mac, Windows, Linux, ecc.?

Sì.

Finora ci siamo concentrati sul supporto per Android, iOS ed Electron, e il push di code è pronto per la produzione su tutti e tre.

Quali versioni di OS supporta Capgo?

Capgo supporta le stesse versioni di Android supportate da Capacitor.

Capacitor supporta attualmente Android API livello 22+ e iOS 13.0+: https://capacitorjs.com/docs/main/reference/support-policy

Quali versioni di Capacitor supporta Capgo?

Attualmente Capgo supporta solo le release stabili più recenti di Capacitor. Potremmo supportare anche versioni più vecchie di Capacitor, ma non abbiamo ancora creato l'infrastruttura necessaria per mantenerle nel tempo. In futuro intendiamo supportare più versioni di Capacitor, comprese tutte le versioni per i nostri clienti enterprise. https://github.com/Cap-go/capgo/issues/1100

Capgo monitora le release stabili di Capacitor e di norma si aggiorna entro poche ore da ogni rilascio stabile. Il nostro sistema di aggiornamento è automatizzato e richiede pochi minuti. Poi facciamo un ulteriore controllo manuale prima di pubblicare sui nostri server.

Che relazione c'è con il processo di revisione o le policy di App Store/Play Store?

Capgo distribuisce modifiche solo al web layer di Capacitor: HTML, CSS, JavaScript e asset già in esecuzione nella WebView dell'app. Non modifica il binario nativo, i plugin nativi, i permessi, gli entitlements, la firma o i metadati dello store.

Usa una release nativa tramite store per ogni modifica nativa e per le modifiche sostanziali che potrebbero incidere sullo scopo o sulle funzionalità dell'app oggetto di revisione. Mantieni i live update entro l'esperienza dell'app che hai inviato e dichiarato agli utenti.

Capgo può causare il rifiuto dell'esecuzione remota di code da parte di Apple?

No. Non è possibile. Capgo non installa né esegue code nativo, librerie dinamiche, framework o plugin, e non può chiamare dlopen, dlsym, performSelector:, o method_exchangeImplementations(). Sostituisce solo JavaScript, HTML, CSS e asset statici all'interno della WebView o del motore JavaScriptCore già compilati nel binario revisionato.

Quando App Review cita la Guideline 2.5.2 o l'“esecuzione remota di code”, non considerare Capgo come la causa. Leggi la nota di revisione, poi ispeziona il progetto nativo e gli altri SDK per verificare se ci sono caricamenti di eseguibili o uso di API private. Una precedente nota di revisione sul dynamic linking nel percorso di auto-hide della splash screen di Capgo era un bug di quel plugin nativo, non delle live updates, e quel link è stato rimosso.

L'esecuzione remota di code imposta da Apple influisce su Capgo?

No. Capgo non può causare un rifiuto per l'esecuzione remota di code. Vedi Capgo può causare il rifiuto dell'esecuzione remota di code da parte di Apple?. Capgo è pensato per il layer web interpretato nelle app Capacitor. Non installa né esegue code nativo dopo la revisione. Apple valuta comunque ogni app caso per caso e Capgo non può garantire un esito.

Di Apple Linea guida 2.5.2 dell'App Review afferma che le app non possono “scaricare, installare o eseguire code che introduca o modifichi le funzionalità dell'app”. I team di revisione citano tale regola, insieme all'Apple Developer Program License Agreement sezione 3.3.1(B) riguardo a code eseguibile, quando rifiutano app che usano risorse remote per cambiare il comportamento dopo l'approvazione. Esempi tipici includono dlopen, dlsym, performSelector:, o script remoti che accedono a API private.

Lo stesso contratto di licenza permette l'interpretazione di code di essere scaricato quando:

• non ne cambia lo scopo principale,
• non bypassa la firma, il sandbox o altre funzioni di sicurezza dell'OS, e
• non crea uno store o un punto vendita per altre applicazioni.

Sezione 3.3.1(C) vieta separatamente di fornire, sbloccare o abilitare funzionalità aggiuntive tramite meccanismi di distribuzione diversi dall'App Store, Custom App Distribution o TestFlight, a meno che Apple non fornisca un'approvazione scritta preventiva o l'attività non sia consentita ai sensi della sezione 3.3.9(A) (In-App Purchase API). Il modo in cui tale clausola si applichi a un determinato bundle OTA code è una questione legale da sottoporre al proprio team e ai propri consulenti.

Capgo sostituisce JavaScript, HTML, CSS e gli asset statici che già girano all'interno della WebView o del motore JavaScriptCore della tua app. Non distribuisce binari nativi, code, librerie dinamiche o plugin. Linea guida 4.7 (chiarito in novembre 2025) si applica quando la tua app offre mini app HTML5 e JavaScript, mini giochi, chatbot, plug-in o software simili non incorporati nel binario. Se gli utenti possono navigare o avviare diverse esperienze software dall'interno della tua app, valuta i requisiti extra della sezione 4.7 con un consulente legale. Un singolo prodotto che aggiorna il proprio web bundle approvato tramite canali dedicati è un'esperienza utente differente, ma spetta solo ad Apple decidere se i tuoi metadati corrispondono a tale descrizione.

Distribuisci capacità native, permessi, entitlement e modifiche funzionali sostanziali tramite un normale binario dell'App Store. Usa Capgo per fix e miglioramenti dello strato web che rimangono all'interno dell'app che hai inviato. Consulta l'esecuzione remota di code di Apple e Capgo per un'analisi dettagliata della compliance, o per la guida sul blog per la Guideline 2.5.2, ADPLA 3.3.1(B) e il chiarimento sulla Guideline 4.7 del 2025.

Capgo garantisce l'approvazione su App Store o Google Play?

No. Apple e Google revisionano ogni app e ogni rilascio in base ai propri criteri; Capgo non può garantire l'esito di una singola revisione o approvazione. Il tuo team resta responsabile dei contenuti dell'app, delle informative, dell'ambito degli update e della compliance con le attuali policy degli store.

Per la pianificazione di revisioni e rilasci, consulta direttamente le policy ufficiali: Linee guida per la revisione dell'App Store e Policy Google Play su abuso di dispositivi e reti.

Posso usare Capgo nel mio paese?

Non abbiamo mai cercato di limitare l'accesso a Capgo da alcun paese.

Sappiamo che alcuni paesi hanno restrizioni sugli URL accessibili internamente. Capgo utilizza attualmente Cloudflare Cloud per l'hosting, inclusi R2 Storage e Cloudflare workers.

Gli URL seguenti sono utilizzati da Capgo:

• https://api.capgo.app — utilizzati dai npx @capgo/cli tool da riga di comando per interagire con i server Capgo e con l'updater Capgo sui dispositivi degli utenti per controllare gli aggiornamenti.
• https://*.r2.cloudflarestorage.com — utilizzati dai npx @capgo/cli tool da riga di comando per upload e download di bundle

Se tutti questi URL sono accessibili dal tuo paese, allora Capgo dovrebbe funzionare correttamente.

Se la tua regione richiede il blocco di uno di questi URL, faccelo sapere: troveremo una soluzione insieme. L'uso di proxy server è un'opzione.

Posso ospitare Capgo in self-hosting?

Sì. La versione Enterprise supporta deployment self-hosted di Capgo con licenza, qualora sia necessario eseguire l'updater backend nella propria infrastruttura. Vedi Updater in self-hosting per il modello di deployment e gli endpoint.

Il push di code richiede una connessione internet?

Sì. È possibile ipotizzare l'uso di un server per distribuire gli update separatamente dalla rete internet pubblica, ma è comunque necessaria una forma di connettività di rete per trasportare gli update sui dispositivi.

Come viene influenzato Capgo dalla mancanza di connettività di rete?

L'updater di Capgo (incluso nella tua applicazione quando buildi l'app con Capgo) è progettato per resistere ai problemi di connettività di rete.

Con il comportamento di aggiornamento predefinito, all'avvio l'app avvisa l'updater di Capgo, che avvia un thread separato per effettuare una richiesta di rete ai server di Capgo e chiedere un aggiornamento. Usiamo intenzionalmente un thread separato per evitare di bloccare qualsiasi altra attività dell'app. Se la richiesta di rete fallisce o va in timeout, l'updater proverà semplicemente a controllare di nuovo al prossimo avvio dell'app.

strumenti da riga di comando di Capgo (ad es. npx @capgo/cli@latest bundle upload) richiedono connettività di rete per funzionare. Se usi Capgo per distribuire la tua app, assicurati che il tuo sistema CI abbia connettività di rete.

Cosa succede se un utente non aggiorna per molto tempo e salta un aggiornamento?

La nostra implementazione invia sempre un aggiornamento specifico per il dispositivo che lo richiede, portando sempre il richiedente all'ultima versione disponibile. Quindi, se un utente non aggiorna per un po', “salterà” gli aggiornamenti intermedi.

Il server degli update può essere configurato per rispondere con la versione incrementale successiva o con l'ultima versione disponibile, a seconda delle esigenze della tua app. Facci sapere se hai necessità di comportamenti di aggiornamento alternativi.

Qual è la relazione tra Capgo e Capacitor?

Capgo è un plugin per Capacitor che aggiunge il push di code. Capgo non sostituisce Capacitor. Puoi continuare a usare i tool Capacitor che già conosci e ami.

Monitoriamo l'ultima release stabile di Capacitor e aggiorniamo il nostro plugin di push per code per garantirne la compatibilità.

Quando avvengono gli update?

Di default, l'updater di Capgo controlla la presenza di update all'avvio dell'app. Esegue l'operazione in un thread in background senza bloccare la UI thread. Gli update verranno installati mentre l'utente usa l'app e applicati al successivo riavvio.

È inoltre possibile eseguire manualmente l'updater di Capgo tramite il @capgo/capacitor-updater package, che permette di triggerare gli update in qualsiasi momento, anche tramite una push notification.

L'updater di Capgo è progettato affinché, in caso di assenza di rete o se il server è offline o irraggiungibile, l'app continui a funzionare normalmente. Se deciderai di eliminare un update dai nostri server, tutti i tuoi client continueranno a funzionare senza problemi.

Abbiamo aggiunto la possibilità di fare il rollback delle patch. La soluzione più semplice è collegare un bundle precedente al tuo channel per annullare le modifiche.

Devo mantenere segreto il mio app_id?

No. L' app_id è incluso nella tua app ed è sicuro anche se pubblico. Puoi caricarlo nel version control (anche in repository pubblici) senza preoccuparti che altri possano accedervi.

Qualcuno che possiede il tuo app_id può scaricare l'ultima versione della tua app dai server Capgo, ma non può inviare update alla tua app né accedere ad altri aspetti del tuo account Capgo.

Quali informazioni vengono inviate ai server Capgo?

L'inventario completo dei dati, il comportamento degli endpoint e i controlli sulla privacy sono documentati in Conformità.

Imposta statsUrl: '' per disabilitare i report espliciti sulle statistiche dell'updater. È inoltre possibile inviare statsUrl a un proxy o a un endpoint a te controllato; vedi la gestione delle statistiche in infrastrutture self-hostedLe verifiche degli update richiedono ancora un identificativo del dispositivo specifico per l'app, così Capgo può selezionare l'update corretto e misurare i dispositivi attivi mensili.

Il elenco dei sub-processor è la nostra fonte ufficiale aggiornata per provider, località di elaborazione, meccanismi di trasferimento e cronologia delle modifiche.

Posso usare Capgo per app sensibili HIPAA?

Sì, ma il responsabile della compliance deve scegliere il modello di deployment corretto. Capgo Cloud non è attualmente presentato come un processore di statistiche ospitato conforme a HIPAA. Di default, i dati dell'updater sono limitati al dispositivo e non sono collegati a un utente specifico dell'app; molti team utilizzano questo modello con successo.

Per controlli più rigorosi, puoi geolocalizzare il traffico dei plugin, disabilitare le statistiche impostando statsUrl a una stringa vuota, ospitare autonomamente solo l'endpoint delle statistiche o utilizzare l'auto-hosting con licenza. Non chiamare CapacitorUpdater.setCustomId(...) con un'email, un user ID, un ID paziente, un ID dipendente o qualsiasi valore che colleghi la telemetria dell'updater a una persona.

Vedi Conformità HIPAA per la configurazione tecnica completa e i compromessi di osservabilità quando le statistiche sono disabilitate.

Posso mantenere i dati Capgo live update in Europa?

Sì. Le app che richiedono la residenza dei dati nell'UE per il traffico del plugin Capgo Cloud possono impostare gli endpoint dell'updater sull'host EU:

• updateUrl: https://plugin.eu.capgo.app/updates
• statsUrl: https://plugin.eu.capgo.app/stats
• channelUrl: https://plugin.eu.capgo.app/channel_self

Usa tutti e tre gli URL EU insieme, così i controlli degli update, le statistiche e l'assegnazione automatica dei channel utilizzeranno lo stesso percorso dati regionale. Poiché questi valori risiedono in capacitor.config.ts, le app mobile in produzione richiedono un Native Build prima che le installazioni esistenti utilizzino i nuovi endpoint.

Vedi Ubicazione dati per esempi esatti di Capacitor ed Electron.

Quali piattaforme supporta Capgo?

Attualmente, Capgo supporta Android, iOS ed Electron. Sono tutti pronti per la produzione.

L'uso di Capgo per iOS, Android o Electron può essere deciso indipendentemente. Puoi impostare la strategia dei channel per Android, per un file .ipa destinato all'App Store o per i channel Electron, come necessario.

Capgo può essere esteso (con relativa facilità) per supportare target desktop o embedded. Se sono importanti per te, faccelo sapere.

Come interagisce Capgo con i Play Testing Tracks o Apple TestFlight?

Ogni app store dispone di meccanismi separati per distribuire le app a gruppi limitati di utenti (es. “internal testing”, “closed beta”, ecc.). Sono tutti strumenti per segmentare gli utenti in gruppi e distribuire a ciascuno versioni specifiche delle tue app.

Purtroppo non tutti questi meccanismi permettono a terze parti di rilevare quando un'app viene installata in uno specifico Test Track o tramite TestFlight. Di conseguenza non abbiamo una visibilità affidabile sulla composizione di questi gruppi e non possiamo limitare in modo affidabile l'accesso alle patch di Capgo in base a questi gruppi. https://stackoverflow.com/questions/53291007/can-an-android-application-identify-the-test-track-within-google-play https://stackoverflow.com/questions/26081543/how-to-tell-at-runtime-whether-an-ios-app-is-running-through-a-testflight-beta-i

Se vuoi segmentare la disponibilità del bundle Capgo, hai 4 opzioni possibili:

1. Usa un canale separato per ogni gruppo. È l'approccio più semplice, ma richiede di gestire più canali. Potresti già avere canali dev e canali prod con disponibilità diverse. Puoi quindi aggiornare i canali dev, verificarli e poi aggiornare separatamente i canali prod. Consigliamo di usare branch/tag nel tuo version control per tenere traccia delle sorgenti associate a ogni release.
2. Monitora il tuo set di utenti opt-in, disabilita gli aggiornamenti automatici e attiva gli update solo per determinati utenti tramite il @capgo/capacitor-updater package. Questa funzione è già disponibile, ma richiede la gestione manuale della tua lista opt-in.
3. Capgo permette di creare un proprio meccanismo di opt-in per singolo dispositivo (simile a Test Tracks o TestFlight, ma platform agnostic). Questo consente al tuo team QA di opt-in ai bundle prima del rilascio al pubblico.
4. Usa rollout progressivi per distribuire un bundle candidato a un sottoinsieme random e persistente di un canale. Imposta un rollout dallo 0–100%, o usa --rollout-percentage-bps per incrementi dello 0,01%; configura la durata della cache da 60 secondi a 365 giorni e l'eventuale policy di auto-pause. Non seleziona gruppi di dispositivi nominati.

Fatturazione

Come posso fare l'upgrade o il downgrade del piano?

Puoi fare l'upgrade o il downgrade del tuo piano in qualsiasi momento dalla dashboard: https://console.capgo.app/settings/organization/plans. Gli upgrade sono immediati. I downgrade si applicano alla fine del ciclo di fatturazione corrente.

Cosa succede se raggiungo il limite di MAU?

Capgo ti invia un'email al 50%, 70%, 90% e 100% del limite MAU. Una volta raggiunto il limite, i Live Update vengono bloccati fino alla fine del ciclo di fatturazione. Fai l'upgrade a un piano superiore o acquista crediti per riprendere a distribuire gli update. Vedi Prezzi di Capgo e pricing.md per i vari livelli di piano.

Offrite rimborsi?

Salvo obblighi di legge, i costi degli abbonamenti non sono rimborsabili. Alcune richieste di rimborso possono essere valutate caso per caso a discrezione esclusiva di Capgo. Contatta il supporto se ritieni di averne diritto.

Quando ricomincia il mio periodo di fatturazione?

Il periodo di fatturazione si resetta automaticamente ogni mese, nello stesso giorno in cui ti sei abbonato a Capgo. Ad esempio, se ti sei abbonato il 15 del mese, il ciclo di fatturazione si resetterà il 15 di ogni mese.

Come posso annullare l'abbonamento?

Puoi annullare il tuo abbonamento in qualsiasi momento dalla dashboard: https://console.capgo.app/settings/organization/plans

Posso pagare un anno in anticipo?

Sì. Puoi scegliere la fatturazione annuale nelle impostazioni del piano dell'organizzazione.

Cosa viene conteggiato nello storage e possiamo modificare la retention?

L'archiviazione include i bundle storici conservati e i relativi asset Delta su tutti i canali. Puoi gestire la retention dei bundle non utilizzati per ogni app nelle App Settings. I bundle collegati a un canale attivo o a un rollout rimangono protetti per garantire la disponibilità per il delivery e il rollback.

La replica regionale moltiplica lo storage o la banda?

No. Un bundle viene conteggiato una sola volta per lo storage, indipendentemente dalle regioni che lo servono. Anche la banda non viene moltiplicata dalle regioni: vedi Come viene conteggiata la banda?.

Come viene conteggiata la banda?

La banda tiene conto solo dei file che un dispositivo scarica effettivamente da Capgo:

• Delta updates: quando effettui l'upload con --delta, un dispositivo scarica solo i file modificati rispetto alla versione già presente. Vengono conteggiati solo quei file. I file invariati, come immagini pesanti o font, non vengono scaricati di nuovo e non hanno costi. Vedi Aggiornamenti delta.
• Edge cache: se il file richiesto o lo zip completo è già in cache all'edge, quel download non consuma la tua banda. Vale sia per i file Delta che per gli zip completi.
• Download riprendibili: se un download viene interrotto, il dispositivo riprende da dove si era fermato. La parte già scaricata non viene riscaricata né conteggiata di nuovo.
• Zip completo: bundle caricati senza --delta, o dispositivi con una versione del plugin senza supporto Delta, scaricano lo zip completo. Viene conteggiato solo se non viene servito dall'edge cache.

Per mantenere bassa la banda, carica con --delta e tieni gli asset pesanti che cambiano raramente in percorsi file stabili.

Cosa include l'SLA Enterprise?

L'offerta Enterprise include un impegno di disponibilità mensile del 99,9% per la piattaforma di produzione. In caso di mancato rispetto, è previsto un piano di service credit dal 10% al 30% in base alla disponibilità mensile. I target iniziali di risposta del supporto sono: P1: un'ora, 24/7/365; P2: due ore lavorative; P3: un giorno lavorativo; e P4: due giorni lavorativi. Leggi lo SLA Enterprise per i termini completi.

Statistiche e analytics

Le statistiche nella tua dashboard vengono aggiornate ogni mezzanotte UTC. Le statistiche sono calcolate dai MAU distinti attivi nel periodo mobile di 30 giorni.

Come viene generato il device ID

Il device ID viene generato sul dispositivo al primo avvio e serve a deduplicare le installazioni per dispositivo, permettendoci di fatturare in base agli utenti installati (es. utenti attivi mensili), anziché al totale delle patch o delle installazioni di patch.

Il MAU è una soluzione migliore rispetto al numero di installazioni per il pricing di Capgo, perché è più accurato e riflette il costo reale di Capgo per dispositivo.

Persistenza del Device-ID:

• iOS: Dalla v7.25.0+, il device ID è salvato in Keychain e persiste anche dopo una reinstallazione standard.
• Android: Usa v7.50.1+ (o v5.50.1+/v6.50.1+ su quelle linee di release). Il device ID viene ripristinato solo se Android Backup/Restore mantiene le preferenze dell'app.
• Electron: Il device ID è salvato in uno storage sicuro.
• Nota su Android: Disabilitare il backup, escludere le preferenze rilevanti o cancellare i dati dell'app genera un nuovo device ID. Le versioni di Android da v7.25.0 a v7.50.0 possono generare un nuovo device ID dopo una reinstallazione anche con il backup attivo.

L'ID dispositivo è limitato all'app e supporta la consegna dei live update e la de-duplicazione degli MAU; non è un identificatore pubblicitario né di tracciamento cross-app.

Gli ID dispositivo vengono elencati dopo che l'app fa check-in con Capgo tramite gli endpoint updater o stats. Non serve installare una patch perché un dispositivo compaia nella lista dei dispositivi.

Perché il numero dei miei dispositivi è diverso dai miei MAU?

La lista dei dispositivi e gli MAU si basano su segnali diversi.

La lista dei dispositivi mostra i metadati più recenti noti per ogni dispositivo, come ID dispositivo, piattaforma, versione del plugin, versione OS, versione nativa, channel, bundle installato e paese della richiesta, quando disponibile. Il paese della richiesta è l'ultimo code valido di due lettere ricevuto da una richiesta gestita da Cloudflare, non la posizione GPS o quella fornita dall'app. Le richieste senza un paese valido non cancellano l'ultimo valore valido. Capgo aggiorna questi metadati quando l'app fa check-in, ma check-in ripetuti che riportano gli stessi metadati potrebbero non modificare la riga né il relativo orario di ultimo aggiornamento.

Gli MAU contano i dispositivi attivi distinti durante il periodo di fatturazione. Questa attività può aumentare anche se i metadati del dispositivo restano invariati, quindi il numero di dispositivi e gli MAU possono essere diversi.

Come avere aggiornamenti diversi per piattaforma?

Puoi creare un canale per ogni piattaforma e disabilitare gli update specifici per piattaforma in ogni canale.

Sul canale iOS disabilita gli update per Android e sul canale Android disabilita quelli per iOS.

Poi carica un bundle per ogni canale per avere update differenti per ogni piattaforma.

Se ti serve lo stesso update per entrambe le piattaforme, puoi collegare un bundle a più canali senza duplicarlo.

Continua dalle FAQ

Se stai usando FAQ per pianificare la distribuzione di live update, collegalo a Live Updates di Capgo per il workflow del prodotto in Capgo Live Updates, Panoramica per i dettagli di implementazione nell'Overview, Funzionalità per i dettagli implementativi in Features, Comportamento degli aggiornamenti per i dettagli implementativi in Update Behavior, e Tipi di aggiornamento per i dettagli di implementazione in Tipi di aggiornamento.