Saltare al contenuto

Domande frequenti

Se hai domande non risposte qui, per favore chiedi! Entrambi la creazione di un issue o chiedere su Discord lavoro.

Code push, anche noto come “aggiornamenti in tempo reale” (OTA) è un servizio cloud che consente ai Capacitor sviluppatori di distribuire aggiornamenti alle loro app in produzione. Capgo funziona attualmente su Android, iOS e Electron.

“Code Push” è un riferimento al nome di una funzione di distribuzione utilizzata dalla community di React Native da Microsoft e Expo, né alcuna di queste supporta Capacitor.

Utilizziamo il termine “release” per indicare la preparazione di un binario per le store di app. Per poter generare in seguito un bundle, Capgo deve conoscere l'esatto binario che è stato inviato alle store di app.

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

I nostri board di progetto sono anche pubblici e possono essere trovati a: https://github.com/orgs/Cap-go/projects

Il nostro team opera anche nel pubblico, quindi potete vedere cosa stiamo facendo in qualsiasi momento. Siamo felici di rispondere a qualsiasi domanda che avete sulla nostra roadmap o priorità via Github issue o Discord.

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

Vedi Teams per ulteriori informazioni.

No. Capgo server non vedono mai il tuo codice code. Quando esegui npx @capgo/cli@latest bundle upload, Capgo stores a zip file of the minified/compiled code - the same code that a browser would receive, not your source code.

Per ulteriori sicurezze, hai due opzioni:

  • Chiarificazione fine-all'uso: Cifra il tuo pacchetto prima di caricarlo per proteggerlo in archiviazione e in transito e per impedire a terze parti di generare aggiornamenti criptati validi senza la tua chiave privata. Ciò non rende impossibile per gli ingegneri web di reverse engineering i beni distribuiti perché la chiave pubblica è presente nell'applicazione distribuita.
  • Caricamento di URL esterno: Archivia il pacchetto sul tuo server e fornisce solo a Capgo il link di download con l'opzione --external <url>

Vedi anche la nostra politica sulla privacy: https://capgo.app/privacy

Posso utilizzare Capgo dal mio sistema di integrazione continua?

Sezione intitolata “Posso utilizzare Capgo dal mio sistema di integrazione continua?”

Sì. Capgo è destinato ad essere utilizzato dai sistemi CI. Abbiamo pubblicato una guida per Android e Github Actions e iOS, e per GitLab. Altri sistemi CI dovrebbero essere simili.

Per favore, non esitare a contattarci sui problemi di GitHub o Discord se incontrate problemi.

Come si relaziona questo a Firebase Remote Config o Launch Darkly?

Sezione intitolata “Come si relaziona questo a Firebase Remote Config o Launch Darkly?”

Il Code push consente di aggiungere nuovi code / sostituire code sul dispositivo. Firebase Remote Config e Launch Darkly sono entrambi sistemi di configurazione. Consentono di modificare la configurazione dell'app senza dover inviare una nuova versione. Non sono destinati a sostituire code.

Non ho misurato di recente, ma mi aspetto che la libreria di push code aggiunga meno di un megabyte agli Capacitor app. Sappiamo di modi in cui possiamo renderla più piccola quando diventa una priorità. Se il dimensionamento è un blocco per te, per favore ci informa!

No. A causa di un problema upstream che colpisce il simulatore iOS 18.4, Capgo non funziona in modo affidabile lì. Per favore testa su un dispositivo reale o utilizza una versione diversa del simulatore iOS.

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

Sì. Non esiste alcun limite sulle dimensioni dell'applicazione che può essere aggiornata con code push. Come notato di seguito, Capgo può modificare qualsiasi code JS nell'applicazione, indipendentemente dalle dimensioni.

Da notare: una dimensione più grande rende più difficile per gli utenti scaricare gli aggiornamenti. Consigliamo di mantenere l'app il più piccola possibile.

Abbiamo visto una varietà di utilizzi, tra cui:

  • Risparmi di emergenza per app in produzione.
  • Consegna di correzioni di bug agli utenti su versioni più vecchie dell'app.
  • Consegna costante (ad esempio, ogni ora).

Nota che la maggior parte delle store per app non consente di inviare code che cambia il comportamento dell'app in modo significativo. Per ulteriori informazioni, si prega di consultare di seguito per ulteriori informazioni.

Un MAU è un ‘Utente Attivo Mensile’. Nel contesto di Capgo, questo si riferisce effettivamente a un dispositivo attivo mensile. Contiamo un MAU come ogni dispositivo che ha contattato i nostri server negli ultimi 30 giorni. Non contiamo i dispositivi che non hanno contattato i nostri server negli ultimi 30 giorni.

Importante: A partire dalla versione del plugin v5.10.0, v6.25.0 e v7.25.0, il deviceID ora persiste attraverso i reinstall di app. Prima di queste versioni, ogni reinstall di app generava un nuovo deviceID e veniva conteggiato come nuovo MAU.

Con le versioni correnti:

  • DeviceID persiste attraverso i reinstall di app (archiviato in modo sicuro in Keychain su iOS e EncryptedSharedPreferences su Android)
  • Aggiornare l'app non crea un nuovo ID Device
  • Durante lo sviluppo, se si utilizza una versione più vecchia del plugin (&#x3C; v5.10.0 / v6.25.0 / v7.25.0), ogni reinstall ancora crea un nuovo MAU

Nota: I download di TestFlight e le scelte di canale in Android possono ancora generare nuove registrazioni di dispositivi a seconda della configurazione.

Consigliamo di disabilitare i dispositivi di sviluppo e gli emulatori dopo la prima configurazione per ridurre la quantità di dispositivi duplicati.

Come sopra, Capgo non deve essere utilizzato per violare le politiche degli store di app. Consultate le informazioni relative di seguito per ulteriori informazioni.

Inoltre Capgo non supporta la modifica dei code nativi (ad esempio Java/Kotlin su Android o Objective-C/Swift su iOS). L'utente verrà avvertito durante un'aggiornamento tentato se ha modificato i code nativi.

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

Sottosezione intitolata “Posso aggiornare le modifiche a capacitor.config.ts tramite Capgo?”

No. Le modifiche a capacitor.config.ts non possono essere inviate attraverso gli aggiornamenti live di Capgo. Il file di configurazione Capacitor viene letto al momento della compilazione nativa e compilato nel binario dell'app nativa. Ciò significa che qualsiasi modifica a capacitor.config.ts (come le configurazioni dei plugin, l'ID dell'app, le impostazioni del server o le opzioni dei plugin nativi) richiede una nuova versione nativa attraverso l'App Store o Google Play.

Capgo può solo aggiornare gli asset web (HTML, CSS, JavaScript) caricati in esecuzione. Se hai bisogno di modificare la configurazione di Capacitor, devi:

  1. Aggiornare capacitor.config.ts localmente
  2. Riavvia la tua app nativa (npx cap sync seguito da una costruzione nativa)
  3. Invia il nuovo binario ai negozi di app

Capgo non supporta attualmente l'invio dei binari ai negozi di app in tuo nome. Abbiamo piani per aggiungere questa funzionalità in futuro, ma per ora dovrai continuare a utilizzare i tuoi processi esistenti per inviare i binari ai negozi di app.

Puoi utilizzare il nostro guida CI per Android per automatizzare questo processo e guida CI per iOS.

Lo aggiornatore Capgo (incluso nell'applicazione quando costruisci l'app) memorizza il bundle scaricato più recente nella sola directory che capacitor consente 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 durante l'esecuzione. Su dispositivi iOS, i dati sono memorizzati sotto Library/Application Support/capgo.

Gli strumenti di riga di comando Capgo (ad esempio npx @capgo/cli@latest bundle upload) sono installati sul disco in npm cache, le tue credenziali di accesso sono memorizzate nella directory home in ~/.capgo.

La Hot reload di Capacitor è una funzionalità disponibile solo durante lo sviluppo. Code push è per la produzione.

La Hot reload è una funzionalità di Capacitor che ti consente di modificare code sul dispositivo durante lo sviluppo. Richiede la costruzione dell'app Capacitor con un proxy per connetterti al tuo computer locale.

Code push è una funzionalità che ti consente di modificare code sul dispositivo in produzione. Utilizzeremo una varietà di tecniche diverse per rendere possibile ciò a seconda del sistema operativo.

Capgo può modificare qualsiasi JS code del tuo'applicazione. Ciò include le code dell'app e le code generate. Puoi anche aggiornare le dipendenze in package.json a patto che non richiedano modifiche native code.

Non abbiamo piani per supportare la modifica di code native (ad esempio Java/Kotlin su Android o Objective-C/Swift su iOS), e lo strumento ti avviserà se rileva che hai modificato code native, poiché non sarà incluso nel pacchetto.

Code push non è necessario per il Web, poiché il Web funziona già in questo modo. Quando un utente apre un'app Web, scarica la versione più recente dal server se necessario.

Se hai un caso d'uso per code push con il Web, ci piacerebbe saperlo!

Sì.

Fino ad ora ci siamo concentrati sul supporto per Android, iOS e Electron, e code è pronto per la produzione su tutti e tre.

Capgo supporta le stesse versioni di Android di Capacitor.

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

Capgo supporta attualmente solo le ultime versioni stabili di Capacitor. Potremmo supportare anche versioni più vecchie di Capacitor, ma non abbiamo ancora sviluppato l'infrastruttura necessaria per mantenere tali versioni nel tempo. Intendiamo supportare più versioni di Capacitor in futuro, comprese le versioni per i nostri clienti aziendali. https://github.com/Cap-go/capgo/issues/1100

Capgo segue le versioni stabili di Capacitor e aggiorna generalmente entro poche ore di ogni rilascio stabile. Il nostro sistema per eseguire queste aggiornamenti è automatizzato e richiede pochi minuti per essere eseguito. Eseguiamo poi un ulteriore passaggio di verifica manuale prima di pubblicare sulle nostre server.

Come si relaziona questo al processo di revisione o alle politiche dell'App/Play Store?

Sezione intitolata “Come si relaziona questo al processo di revisione o alle politiche dell'App/Play Store?”

I developer sono vincolati dai loro accordi con i provider dei negozi quando scelgono di utilizzare quei negozi. Code push è progettato per consentire ai developer di aggiornare le loro app e di essere comunque in conformità con le politiche dei negozi per i canali di distribuzione iOS, Android e Electron. Allo stesso modo di quella varietà di prodotti commerciali disponibili per farlo con React Native (ad esempio Microsoft, Microsoft pubblica anche una guida su come la loro soluzione sia conforme alle politiche dei negozi:).

https://__CAPGO_KEEP_0__.com/microsoft/react-native-__CAPGO_KEEP_1__-push#store-guideline-compliance https://github.com/microsoft/react-native-code-push#store-guideline-compliance

Code push è una tecnica largamente utilizzata in tutti gli store per applicazioni. Tutti gli app di grandi dimensioni che conosco utilizzano code push. La principale politica da tenere a mente è non cambiare il comportamento dell'app in modo significativo. Per ulteriori informazioni, si prega di consultare di seguito per ulteriori informazioni.

Sì.

Il Play Store offre due restrizioni relative agli strumenti di aggiornamento.

  1. Gli aggiornamenti devono utilizzare un interprete o una macchina virtuale (Capgo utilizza JavaScript in un WebView). https://support.google.com/googleplay/android-developer/answer/9888379?hl=en
An app distributed via Google Play may not modify, replace, or update itself
using any method other than Google Play's update mechanism. Likewise, an app
may not download executable code (such as dex, JAR, .so files) from a
source other than Google Play. *This restriction does not apply to code
that runs in a virtual machine or an interpreter* where either provides
indirect access to Android APIs (such as JavaScript in a webview or
browser).
Apps or third-party code, like SDKs, with interpreted languages (JavaScript,
Python, Lua, etc.) loaded at run time (for example, not packaged with the
app) must not allow potential violations of Google Play policies.
  1. I cambiamenti dell'app non devono essere ingannevoli (ad esempio, cambiare lo scopo dell'app tramite l'aggiornamento). https://support.google.com/googleplay/android-developer/answer/9888077 Assicurati di essere chiaro con i tuoi utenti su cosa stai fornendo con la tua applicazione e non violare le loro aspettative con cambiamenti comportamentali significativi attraverso l'uso di Capgo.

Capgo è progettato per essere compatibile con le linee guida di Google Play. Tuttavia Capgo è uno strumento, e come con ogni strumento, può essere abusato. Abusare deliberatamente Capgo per violare le linee guida di Google Play è in violazione del Capgo Termini di Servizio e può portare alla sospensione del tuo account.

Infine, i servizi di push di code sono ampiamente utilizzati nell'industria (tutti gli app che conosco li utilizzano) e ci sono altri servizi di push code disponibili pubblicamente (ad esempio expo.dev e appcenter.ms). Si tratta di un percorso ben battuto.

Microsoft pubblica anche una guida su come il loro librario di reattivo nativo “codepush” soddisfi le linee guida degli store: https://github.com/microsoft/react-native-code-push#store-guideline-compliance

Sì.

Simile alla Play Store, l'App Store offre sia restrizioni tecniche che di politica.

3.2.2
... interpreted code may be downloaded to an Application but only so long as
such code:
(a) does not change the primary purpose of the Application by providing
features or functionality that are inconsistent with the intended and
advertised purpose of the Application as submitted to the App Store,
(b) does not create a store or storefront for other code or applications, and
(c) does not bypass signing, sandbox, or other security features of the OS.

Capgo utilizza JavaScript in un WebView per conformarsi alla restrizione solo-interprete per gli aggiornamenti su iOS. A condizione che la tua applicazione non stia sfruttando comportamenti ingannevoli tramite gli aggiornamenti (ad esempio, cambiando lo scopo dell'applicazione tramite l'aggiornamento), l'aggiornamento tramite Capgo (o qualsiasi altra soluzione di push code) è una pratica standard dell'industria e conforme alle linee guida dell'App Store.

Abusare deliberatamente di Capgo per violare le linee guida dell'App Store è in violazione di Capgo Termini di Servizio e può portare alla sospensione del tuo account.

Microsoft pubblica anche una guida su come il loro librario di “codepush” nativo reagisce alle restrizioni delle app store: https://github.com/microsoft/react-native-code-push#store-guideline-compliance

Non abbiamo tentato di limitare l'accesso a Capgo da nessun paese.

Riconosciamo che alcuni paesi hanno restrizioni su quali URL possono essere accessibili dal paese. Capgo utilizza attualmente Cloudflare Cloud per l'hosting, inclusa R2 Storage e Cloudflare workers.

I seguenti URL sono utilizzati da Capgo:

  • https://api.capgo.app — utilizzato dai npx @capgo/cli strumenti di linea di comando per interagire con i server Capgo nonché l'aggiornatore Capgo sulle dispositivi degli utenti per verificare le aggiornamenti.
  • https://*.r2.cloudflarestorage.com — utilizzato dal npx @capgo/cli strumento di linea di comando per caricare e scaricare bundle

Se tutte quelle URL sono accessibili dal tuo paese, allora Capgo dovrebbe funzionare.

Se la tua regione richiede di bloccare l'accesso a qualsiasi di quelle URL, ti preghiamo di informarci e possiamo lavorare con te per trovare una soluzione. I server proxy sono un'opzione.

Posso auto-hostare Capgo?

Se posso ospitare Capgo da solo?

Sì, puoi ospitare Capgo da solo. La guida non è ancora stata scritta, ma il code è open source e disponibile a https://github.com/cap-go/capgo

Sì. Si potrebbe immaginare di eseguire un server per distribuire gli aggiornamenti separatamente dalla rete internet generale, ma è richiesta una forma di connettività di rete per trasportare gli aggiornamenti ai dispositivi.

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

Sottosezione intitolata “Come Capgo è influenzato dalla mancanza di connettività di rete?”

L'aggiornatore Capgo (incluso nella tua applicazione quando costruisci l'applicazione con Capgo) è progettato per essere resiliente ai problemi di connettività di rete.

Nel comportamento di aggiornamento predefinito, quando l'applicazione si avvia, avverte l'aggiornatore Capgo, che avvia un thread separato per effettuare una richiesta di rete ai server di Capgo e chiedere un aggiornamento. Intenzionalmente utilizziamo un thread separato per evitare di influenzare qualsiasi altra cosa l'applicazione possa essere facendo. Se la richiesta di rete fallisce o scade, l'aggiornatore semplicemente cercherà di controllare nuovamente la prossima volta che l'applicazione si avvia.

Capgo strumenti di linea di comando (ad esempio npx @capgo/cli@latest bundle upload) richiedono la connessione di rete per funzionare. Se stai utilizzando Capgo per distribuire la tua app, dovresti assicurarti che il tuo sistema di integrazione abbia la connessione di rete.

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

Sezione intitolata “Cosa succede se un utente non aggiorna per molto tempo e perde un aggiornamento?”

La nostra implementazione invia sempre un aggiornamento specificamente tailizzato per il dispositivo che lo richiede, aggiornando sempre il richiedente alla versione più recente disponibile. Quindi se un utente non aggiorna per un po' di tempo, perderà gli aggiornamenti intermedi.

Il server di aggiornamento potrebbe essere modificato per supportare la risposta con la versione incrementale successiva o la versione più recente a seconda delle esigenze della tua applicazione. Ci faccia sapere se comportamenti di aggiornamento alternativi sono importanti per te.

Capgo è un plugin per Capacitor che aggiunge il push code. Capgo non è una sostituzione per Capacitor. Puoi continuare a utilizzare gli strumenti di Capacitor che già conosci e ami.

Seguiamo la versione stabile più recente di Capacitor e aggiorniamo il nostro plugin di push code per funzionare con essa.

Di default, l'aggiornatore Capgo controlla gli aggiornamenti all'avvio dell'applicazione. Esegue il lavoro in un thread di background e non blocca il thread UI. Gli aggiornamenti saranno installati mentre l'utente utilizza l'applicazione e verranno applicati la prossima volta che l'applicazione viene riavviata.

È anche possibile eseguire manualmente l'aggiornatore Capgo utilizzando il @capgo/capacitor-updater pacchetto, attraverso cui è possibile attivare gli aggiornamenti in qualsiasi momento, compresi tramite una notifica push.

L'aggiornatore Capgo è progettato in modo tale che quando la rete non è disponibile, o il server è down o non raggiungibile, l'applicazione continuerà a funzionare normalmente. Se scegliessi di cancellare un aggiornamento dai nostri server, tutti i tuoi client continueranno a funzionare normalmente.

Abbiamo aggiunto la possibilità di annullare le patch. La cosa più semplice è semplicemente attaccare un bundle precedente al tuo canale per annullare.

No. app_id è incluso nel tuo app e è sicuro essere pubblico. Puoi controllare il codice (anche pubblicamente) e non preoccuparti che qualcuno possa accedere a esso.

Qualcuno che ha il tuo app_id può estrarre la versione più recente del tuo app dai server di Capgo, ma non possono inviare aggiornamenti al tuo app o accedere ad alcun altro aspetto del tuo Capgo account.

Anche se Capgo si connette alla rete, non invia alcuna informazione personalmente identificabile. Includere Capgo non dovrebbe influire sulle dichiarazioni per il Play Store o l'App Store.

Il richieste inviate dall'app ai server di Capgo includono:

  • id_app (specificato capacitor.config.json)
  • canale (facoltativo in capacitor.config.json)
  • versione_di_rilascio (versionName da AndroidManifest.xml o CFBundleShortVersionString da Info.plist o capacitor.config.json se impostato in CapacitorUpdater.version )
  • Numero di versione (generato come parte di npx @capgo/cli@latest bundle upload)
  • Numero di versione del sistema operativo (ad esempio ‘11.2.1’)
  • platform (e.g. ‘android’, needed to send down the right patch) That’s it. The code for this is in updater/library/src/network.rs
  • Questo è tutto. Il __CAPGO_KEEP_0__ per questo è in
  • ID dispositivo (generato sul dispositivo al primo avvio, utilizzato per evitare duplicati per dispositivo e consentire di fatturare in base agli utenti installati (ad esempio utenti attivi mensili), piuttosto che patch totali o installazioni di patch totali)

Sottosezione intitolata “Quali piattaforme supporta Capgo?”

Attualmente, Capgo supporta Android, iOS e Electron. Tutti sono pronti per la produzione.

L'uso di Capgo per iOS, Android o Electron può essere una decisione independente. Puoi impostare la tua strategia di canale per Android e un ipa costruito per l'App Store, o canali di Electron, come necessario.

Capgo può (relativamente facilmente) essere reso compatibile con target desktop o embedded. Se sono importanti per te, per favore ci informa.

Sottosezione intitolata “Come interagisce Capgo con le piste di testing di Play o Apple TestFlight?”

Ogni negozio di app ha meccanismi separati per distribuire app a gruppi di utenti limitati (ad esempio “testing interno”, “beta chiusa”, ecc.). Sono tutti meccanismi per segmentare gli utenti in gruppi e distribuire versioni specifiche delle app a ciascuno.

Purtroppo, questi meccanismi non consentono a tutte le parti terze di rilevare quando le app sono installate in una pista di testing specifica o tramite TestFlight. Di conseguenza, non abbiamo una visibilità affidabile sulla composizione di questi gruppi e non possiamo quindi garantire 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 desiderate segmentare la disponibilità del pacchetto Capgo, ci sono 4 opzioni potenziali:

  1. Utilizzare un canale separato per ogni gruppo. Questo è l'approccio più diretto, ma richiede di gestire più canali. Potreste già avere dei canali di sviluppo e prodotti con disponibilità diverse. Potete quindi aggiornare i canali di sviluppo, verificarli e poi aggiornare separatamente i canali di prodotto. Consigliamo l'uso di branch / tag nel vostro controllo versione per aiutare a tenere traccia delle fonti associate a ogni rilascio.
  2. Segui il tuo set di utenti che hanno scelto di partecipare, disabilita gli aggiornamenti automatici e attiva gli aggiornamenti solo per certi utenti tramite il @capgo/capacitor-updater package. Questo funziona oggi, ma richiede che tu gestisca la tua lista di utenti che hanno scelto di partecipare.
  3. Capgo consente di creare il proprio meccanismo di opt-in su base dispositivo (simile a Test Tracks o TestFlight, ma agnostico a piattaforma). Ciò consente al tuo team di QA di opt-in per il bundle prima di essere promosso al pubblico generale.
  4. Capgo consentono di effettuare roll-out con base percentuale. Ciò non ti consente di scegliere quali dispositivi inviare, ma può aiutarti a distribuire gradualmente e a tornare indietro alla vista di qualsiasi problema.

Potrai aggiornare o ridurre il tuo piano in qualsiasi momento nel tuo pannello di controllo: https://console.capgo.app/settings/organization/plans

I periodi di fatturazione vengono riavviati automaticamente ogni mese nel mese in cui hai sottoscritto per la prima volta a Capgo. Ad esempio, se hai sottoscritto il 15 del mese, il tuo periodo di fatturazione si riavvierà il 15 di ogni mese.

Puoi cancellare la tua sottoscrizione in qualsiasi momento nel tuo pannello di controllo: https://console.capgo.app/impostazioni/organizzazione/piani

Sì, puoi farlo in qualsiasi momento nel tuo dashboard: https://console.capgo.app/settings/organization/plans

Gli statistici nel tuo dashboard vengono aggiornati ogni mezzanotte UTC. Gli statistici sono calcolati in base al numero di MAU gli utenti che hanno installato il tuo dispositivo.

The ID del dispositivo viene generato sul dispositivo alla prima esecuzione e viene utilizzato per evitare la duplicazione degli installi per dispositivo e consentire di fatturare in base agli utenti installati (ad esempio, utenti attivi mensili), piuttosto che su patch totali o installi di patch totali.

MAU è una soluzione migliore del numero di installi per prezzare Capgo, poiché è più accurata e riflette il costo reale di Capgo per dispositivo.

Persistenza dell'ID dispositivo (Aggiornato in v6.25.0 e v7.25.0):

  • Comportamento corrente: L'ID dispositivo persiste ora anche dopo la reinstallazione dell'app. Viene memorizzato in modo sicuro nella Keychain del dispositivo (iOS) o in EncryptedSharedPreferences (Android), consentendo di tracciare lo stesso dispositivo anche dopo l'installazione/rininstallazione.
  • Comportamento precedente (prima di v6.25.0/v7.25.0): Per motivi di privacy legati alle politiche degli store di Apple e Google, l'ID dispositivo veniva resettato alla reinstallazione dell'app, rendendo impossibile tracciare lo stesso dispositivo durante le reinstallazioni.

Il regolamento sulla privacy è applicato da Apple e Google, e Capgo rispetta le loro migliori pratiche per l'identificazione dei dispositivi.

L'ID dispositivo non sarà elencato nella tua lista di dispositivi fino a quando non installerai il primo patch.

Perché il mio numero di dispositivo è diverso dal mio MAU?

Sottosezione intitolata “Perché il mio numero di dispositivo è diverso dal mio MAU?”

Attualmente, l'elenco dei dispositivi non viene aggiornato con la frequenza desiderata rispetto al MAU.

L'elenco dei dispositivi viene aggiornato solo quando un dispositivo installa un aggiornamento.

Mentre il MAU viene aggiornato a ogni avvio dell'applicazione. Questo è una limitazione attuale della piattaforma. Il nostro piattaforma di analisi non supporta aggiornamenti raw quindi utilizziamo una base di dati convenzionale per l'elenco dei dispositivi.

Per limitare il numero di query alla base di dati, aggiorniamo solo una riga all'avvio dell'applicazione.

Questa limitazione verrà eliminata in futuro.

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

Sui canali iOS disabilita gli aggiornamenti per Android e sui canali Android disabilita gli aggiornamenti per iOS.

Poi carica un bundle per ogni canale per avere aggiornamenti diversi per ogni piattaforma.

Se hai bisogno di avere lo stesso aggiornamento per entrambe le piattaforme, puoi collegare un bundle a più canali. Non è necessario duplicare il bundle.