Saltare al contenuto

Domande frequenti

If hai domande non risposte qui, per favore chiedi! Entrambe la creazione di un problema o chiedere su Discord lavora.

Code push, anche noto come “aggiornamenti in tempo reale” (OTA) è un servizio cloud che consente ai sviluppatori di Capacitor 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, nessuna delle quali supporta Capacitor.

Cosa è la differenza tra un bundle e una release?

Sezione intitolata “Cosa è la differenza tra un bundle e una release?”

Utilizziamo il termine “release” per indicare la preparazione di un binario per i negozi di app. Per poter generare successivamente un bundle Capgo deve conoscere il binario esatto che è stato inviato ai negozi di app.

Utilizziamo il termine “bundle” per indicare un patch che può essere applicato a una release per aggiornarla a nuovi 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 in modo pubblico, quindi puoi vedere cosa stiamo lavorando in qualsiasi momento. Siamo felici di rispondere a qualsiasi domanda che hai sul nostro roadmap o priorità via Github issues o Discord.

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

Vedi Team per ulteriori informazioni.

No. I server del Capgo non vedono mai i miei file di origine code. Quando esegui npx @capgo/cli@latest bundle uploadCapgo archivia un file zip del code minificato/compilato - lo stesso code che un browser riceverebbe, non il tuo code.

Per ulteriori sicurezze, hai due opzioni:

  • Chiaro fino alla fine: Cifra il tuo bundle 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 reversare gli asset web distribuiti perché la chiave pubblica è presente nell'app distribuita.
  • URL esterno di caricamento: Archivia il bundle 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

No. I file del bundle sono asset web pubblici destinati a essere scaricati dagli utenti del tuo app. Chiunque conosca l'URL del bundle può estrarre quei file, e Capgo informa gli utenti di ciò durante la configurazione e nella documentazione.

L'accesso ai file del pacchetto non è considerato una violazione dei dati. Non inserire segreti, credenziali, dati personali o dati regolamentati nel tuo pacchetto dell'app. Se hai bisogno di una maggiore riservatezza per casi di utilizzo ad alto livello di sicurezza, utilizza la crittografia end-to-end, ma trattare comunque l'app code e gli asset come pubblici da un punto di vista della sicurezza dei report.

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 di integrazione continua. Abbiamo pubblicato una guida per Android e Github Actions e iOS, e per GitLab. Altri sistemi di integrazione continua dovrebbero essere simili.

Per favore, non esitare a contattarci su GitHub issue o Discord se incontri 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?”

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.

Quanto grande è l'impronta di dipendenza che questo aggiunge?

Sezione intitolata “Quanto grande è l'impronta di dipendenza che questo aggiunge?”

Non ho misurato di recente, ma mi aspetto che la libreria code push aggiunga meno di un megabyte agli Capacitor app. Sappiamo come ridurlo quando diventa una priorità. Se il peso è 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: https://github.com/facebook/react-native/issues/50510

Funziona code push con applicazioni grandi?

Sottotitolo: Funziona code push con applicazioni grandi?

Si. 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 maggiore rende più difficile per gli utenti scaricare gli aggiornamenti. Consigliamo di mantenere l'app il più piccola possibile.

Cosa posso utilizzare Capgo code push?

Sottotitolo: Cosa posso utilizzare Capgo code push?

Abbiamo visto una varietà di utilizzi, tra cui:

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

Nota che la maggior parte delle librerie di app proibisce l'invio di code che modifica il comportamento dell'app in modo significativo. Vedi di seguito per ulteriori informazioni.

Un MAU è un ‘Utente Attivo Mensile’. Nel contesto di Capgo, 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: Inizia dalla versione del plugin v5.10.0, v6.25.0 e v7.25.0, il deviceID persiste ora attraverso il riavvio dell'app. Prima di queste versioni, ogni riavvio dell'app generava un nuovo deviceID e veniva conteggiato come nuovo utente attivo mensile.

Con le versioni correnti:

  • Il DeviceID persiste attraverso il riavvio dell'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 stai utilizzando una versione del plugin più vecchia ( < v5.10.0 / v6.25.0 / v7.25.0), ogni reinstallazione crea ancora un nuovo utente attivo mensile

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

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

Cosa non possiamo utilizzare Capgo code per inviare?

Sezione intitolata “Cosa non possiamo utilizzare Capgo code per inviare?”

Come sopra, Capgo non deve essere utilizzato per violare le politiche degli store di app. Per ulteriori informazioni, si prega di consultare la sezione sottostante. Inoltre __CAPGO_KEEP_0__ non supporta la modifica di __CAPGO_KEEP_1__ nativi (ad esempio Java/Kotlin su Android o Objective-C/Swift su iOS). L'utente verrà avvertito durante un tentativo di aggiornamento se ha modificato __CAPGO_KEEP_2__ nativi.

Also Capgo does not support changing native code (e.g. Java/Kotlin on Android or Objective-C/Swift on iOS). The tool will warn you during an attempted update if you have changed native code.

Collegamento diretto a Posso aggiornare capacitor.config.ts modifiche tramite Capgo?

Section titled “Can I update capacitor.config.ts changes via Capgo?”

non possono essere inviate attraverso __CAPGO_KEEP_0__ live updates. Il file di configurazione __CAPGO_KEEP_1__ viene letto durante la compilazione nativa e compilato nel binario dell'app nativa. Ciò significa che qualsiasi modifica a capacitor.config.ts Cosa non possiamo utilizzare Capgo Capacitor per inviare? capacitor.config.ts (ad esempio le configurazioni dei plugin, l'ID dell'app, le impostazioni del server o le opzioni dei plugin nativi) richiedono 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 tua Capacitor configurazione, devi:

  1. Aggiornamento capacitor.config.ts localmente
  2. Riavvia la tua app nativa (npx cap sync seguito da una compilazione nativa)
  3. Invia il nuovo binario ai negozi dell'app

Capgo non supporta attualmente l'invio degli app per conto tuo. Abbiamo piani di aggiungere questo in futuro, ma per ora dovrai continuare a utilizzare i tuoi processi esistenti per inviare gli app agli store.

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

L'aggiornatore Capgo (incluso nella tua applicazione quando costruisci l'app) memorizza il bundle più recente scaricato 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 su disco nei cache npm, le tue credenziali di accesso sono memorizzate nella directory home in ~/.capgo.

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

Il Hot reload è una funzionalità di Capacitor che consente di modificare code sul dispositivo durante lo sviluppo. Ciò richiede la creazione dell'app Capacitor con un proxy per connettersi alla macchina locale.

Il Code push è una funzionalità che consente di modificare code sul dispositivo in produzione. Utilizzeremo una varietà di tecniche diverse per rendere possibile ciò a seconda della piattaforma.

Capgo può modificare qualsiasi code JS nell'applicazione. Ciò include le code dell'app e le code generate. È possibile anche aggiornare le dipendenze in package.json a condizione 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 vi avviserà se rileva che avete modificato code native, poiché non sarà incluso nel pacchetto.

Questa supporta il Web?

Se supporta questo il web?

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!

Funziona su iOS, Android, Mac, Windows, Linux, ecc.?

Sezione intitolata “Funziona su iOS, Android, Mac, Windows, Linux, ecc.?

Sì.

Fino ad ora ci siamo concentrati sull'app Android, iOS e Electron, e code push è pronto per la produzione su tutte e tre.

Quali versioni di sistema operativo supporta Capgo?

Sezione intitolata “Quali versioni di sistema operativo supporta Capgo?

Capgo supporta le stesse versioni di Android che Capacitor supporta.

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

Capgo attualmente supporta solo rilasci stabili recenti di Capacitor. Potremmo supportare anche versioni più vecchie di Capacitor, ma non abbiamo ancora costruito l'infrastruttura necessaria per mantenere tali versioni nel tempo. Intendiamo supportare più versioni di Capacitor in futuro, comprese qualsiasi versione 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 sui nostri server.

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

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

Gli sviluppatori sono vincolati dai loro accordi con i fornitori dei negozi quando scelgono di utilizzare quei negozi. Code push è progettato per consentire agli sviluppatori di aggiornare le loro app e ancora rispettare le politiche dei negozi su iOS, Android e canali di distribuzione Electron. Allo stesso modo delle varietà di prodotti commerciali disponibili per farlo con React Native (ad esempio Microsoft, Expo).

Microsoft pubblica anche una guida sul modo in cui la loro soluzione rispetta le regole degli store per le app: https://github.com/microsoft/react-native-code-push#regole-guida-compliance-gli-store

Code push è una tecnica molto utilizzata in tutti gli store per le app. 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ì.

Gli store di Google Play offrono due restrizioni relative agli strumenti di aggiornamento.

  1. Le 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=it
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 Per favore, sia chiaro con i vostri utenti su cosa state fornendo con la vostra 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 Play Store. Tuttavia Capgo è uno strumento, e come con ogni strumento, può essere abusato. Abusare deliberatamente Capgo per violare le linee guida di Play Store è in violazione del Capgo Termini e condizioni e può portare alla chiusura del vostro account.

Finally, code push services are widely used in the industry (all of the large apps I’m aware of use them) and there are multiple other code push services publicly available (e.g. expo.dev &#x26; appcenter.ms). This is a well trodden path.

Microsoft pubblica anche una guida su come il loro 'codepush' library di React Native rispetta le regole 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 rispettare la restrizione dell'interprete solo per le aggiornamenti su iOS. A condizione che la tua applicazione non stia sfruttando comportamenti ingannevoli tramite 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 rispetta le linee guida dell'App Store.

Abusando deliberatamente 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 reattivo nativo “codepush” rispetti le app store: https://github.com/microsoft/react-native-code-push#store-guideline-compliance

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

Riconosciamo che alcuni paesi hanno restrizioni su cosa può essere accesso da all'interno del paese. Capgo utilizza attualmente Cloudflare Cloud per l'hosting, compresi 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 di Capgo nonché l'aggiornatore di Capgo sulle dispositivi degli utenti per verificare gli aggiornamenti.
  • https://*.r2.cloudflarestorage.com — utilizzato dall' npx @capgo/cli strumento di linea di comando per caricare e scaricare i bundle

If tutti quei URL sono accessibili dal tuo paese, allora Capgo dovrebbe funzionare.

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

Può essere ospitato Capgo da parte mia?

Sottosezione intitolata “Puedo hospedar Capgo?”

Sì, puoi ospitare Capgo da solo. La guida non è ancora scritta, ma il code è open source e disponibile su 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 è influenzato Capgo dalla mancanza di connettività di rete?

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

L'aggiornatore di Capgo (incluso nella tua applicazione quando costruisci l'applicazione con Capgo) è progettato per essere resistente alle problematiche di connettività di rete.

Nel comportamento di aggiornamento predefinito, quando l'applicazione si avvia, avverte l'aggiornatore di Capgo, che avvia un thread separato per effettuare una richiesta di rete a Capgo’s server 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.

Gli strumenti di riga di comando di Capgo (ad esempio npx @capgo/cli@latest bundle upload) richiedono la connettività di rete per funzionare. Se stai utilizzando Capgo per distribuire la tua app, assicurati che il tuo sistema CI abbia la connettività 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 tailore per il dispositivo che richiede l'aggiornamento, aggiornando sempre il richiedente alla versione più recente disponibile. Quindi se un utente non aggiorna per un po' di tempo, perderà gli aggiornamenti intermedi.

The server di aggiornamento potrebbe essere modificato per supportare la risposta con la versione incrementale successiva o la versione più recente a seconda delle esigenze del tuo'applicazione. Ci informi se i comportamenti di aggiornamento alternativi sono importanti per te.

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

Seguiamo la versione stabile più recente di Capacitor e aggiorniamo il nostro plugin di push code per farlo 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 della 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, incluso tramite una notifica push.

L'aggiornatore Capgo è progettato in modo che quando la rete non è disponibile, o il server è down o non raggiungibile in altro modo, l'applicazione continuerà a funzionare normalmente. Se dovessi mai scegliere 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. L' app_id è incluso nella tua app e è sicuro essere pubblico. Puoi verificarlo nel controllo delle versioni (anche pubblicamente) e non preoccuparti che qualcun altro possa accedervi.

Chi ha il tuo app_id può estrarre la versione più recente della tua app dai server Capgo, ma non possono inviare aggiornamenti alla tua app o accedere ad alcun altro aspetto del tuo account Capgo.

Quali informazioni vengono inviate ai server Capgo?

Sezione intitolata “Quali informazioni vengono inviate ai server Capgo?”

Although Capgo connects to the network, it does not send any personally identifiable information. Including Capgo should not affect your declarations for the Play Store or App Store.

Requests sent from the app to Capgo servers include:

  • Le richieste inviate dall'applicazione ai server di __CAPGO_KEEP_0__ includono: capacitor.config.json)
  • app_id (specificato capacitor.config.json)
  • canale (facoltativo in capacitor.config.json release_version (versioneName da AndroidManifest.xml o CFBundleShortVersionString da Info.plist o CapacitorUpdater.version )
  • se impostato in npx @capgo/cli@latest bundle upload)
  • version_number (generato come parte di
  • 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
  • piattaforma (ad esempio ‘android’, necessario per inviare il patch giusto)
  • Quindi basta. Il __CAPGO_KEEP_0__ per questo è in

Sì, ma il proprietario della conformità deve scegliere il modello di distribuzione giusto. Capgo Cloud non è attualmente presentato come un elaboratore di statistiche ospitato HIPAA-compatibile. Di default, i dati dell'aggiornatore sono scritti su dispositivo e non sono legati a un utente di app noto, e molte squadre utilizzano quel modello con successo.

Per revisioni più severe, puoi geo-localizzare il traffico del plugin, disabilitare le statistiche impostando statsUrl a una stringa vuota, ospita solo l'endpoint delle statistiche, o utilizza l'hosting self-licenziato. Non chiamare CapacitorUpdater.setCustomId(...) con un indirizzo e-mail, ID utente, ID paziente, ID dipendente o qualsiasi valore che mappi la telemetria dell'aggiornatore a una persona.

Vedi Conformità HIPAA per la configurazione tecnica completa e le trade-off di osservabilità quando le statistiche sono disabilitate.

Posso mantenere Capgo i dati di aggiornamento in tempo reale in Europa?

Sezione intitolata “Posso mantenere Capgo i dati di aggiornamento in tempo reale in Europa?”

Yes. Apps that need EU data residency for Capgo Cloud plugin traffic can set the updater endpoints to the EU host:

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

Usa tutte e tre le URL UE insieme affinché le verifiche degli aggiornamenti, le statistiche e l'assegnazione del canale utilizzino la stessa percorso dati regionale. Poiché questi valori vivono in capacitor.config.tsla produzione, gli app mobili hanno bisogno di una versione nativa prima che gli installi esistenti utilizzino gli endpoint nuovi.

Vedi Ubicazione dei dati per esempi esatti di Capacitor e Electron.

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 i canali di Electron, come necessario.

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

How does Capgo interagisce con le piste di testing di Play o Apple TestFlight?

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

Ogni uno degli store per le app ha meccanismi separati per distribuire le app a gruppi di utenti limitati (ad esempio “testing interno”, “beta chiusa”, ecc.). Questi 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 terze parti di rilevare quando le app sono installate in una specifica pista di testing o tramite TestFlight. Pertanto, non abbiamo una visibilità affidabile sulla composizione di questi gruppi e non possiamo garantire l'accesso a Capgo patch 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. Usa un canale separato per ogni gruppo. Questo è l'approccio più diretto, ma richiede la gestione di più canali. Potresti già avere dei canali di sviluppo e dei canali di produzione con disponibilità diverse. Puoi quindi aggiornare i tuoi canali di sviluppo, verificarli e poi aggiornare separatamente i tuoi canali di produzione. Consigliamo l'uso di branch / tag nel tuo controllo delle versioni 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 la gestione del tuo elenco di utenti che hanno scelto di partecipare.
  3. Capgo consente di creare il proprio meccanismo di opt-in per un dispositivo alla volta (simile a Test Tracks o TestFlight, ma agnostico rispetto alle piattaforme). Ciò consente al tuo team di QA di opt-in per il bundle prima di essere promossi al pubblico generale.
  4. Capgo consente di avere roll-out basati sulle percentuali. Ciò non ti consente di scegliere quali dispositivi inviare, ma può aiutarti a distribuire gradualmente e a tornare indietro alla vista di qualsiasi problema.

Puoi aggiornare o ridurre il tuo piano in qualsiasi momento nel tuo pannello di controllo: https://console.capgo.app/impostazioni/organizzazione/piani

Quando si ricarica il mio periodo di fatturazione?

Sezione intitolata “Quando si ricarica il mio periodo di fatturazione?”

I periodi di fatturazione vengono resettati automaticamente ogni mese nel mese in cui hai sottoscritto per la prima volta Capgo. Ad esempio, se hai sottoscritto il 15 del mese, il tuo periodo di fatturazione si resettierà 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

Posso pagare un anno in anticipo?

Se posso pagare un anno in anticipo?

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

I dati statistici nel tuo dashboard vengono aggiornati ogni mezzanotte UTC. I dati statistici sono calcolati in base al numero di Utenti attivi mensili che sono stati installati sui tuoi dispositivi.

L'ID 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 in base al numero totale di patch o installi di patch.

Il MAU è una soluzione migliore del numero di installi per determinare il prezzo Capgo, poiché è più preciso e riflette il costo reale Capgo per dispositivo.

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

  • Comportamento corrente: L'ID dispositivo ora persiste 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 delle store di Apple e Google, l'ID dispositivo veniva resettato alla reinstallazione dell'app, rendendo impossibile tracciare lo stesso dispositivo durante le reinstallazioni.

Le regole sulla privacy sono applicate 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?

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

Attualmente, l'elenco dei dispositivi non viene aggiornato con la stessa frequenza del MAU.

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

Mentre il MAU viene aggiornato a ogni avvio dell'app. Questo è un limite attuale della piattaforma. Il nostro piattaforma di Analytics non supporta aggiornamenti raw, quindi utilizziamo una convenzionale database per l'elenco dei dispositivi.

Per limitare il numero di query al database, aggiorniamo solo la riga all'avvio dell'app.

Questo limite verrà eliminato in futuro.

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

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

Poi caricare un bundle in ogni canale per avere aggiornamenti diversi per ogni piattaforma.

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

Se stai utilizzando FAQ per pianificare la consegna di aggiornamenti in tempo reale, connettilo con Capgo Aggiornamenti in Tempo Reale per il flusso di lavoro del prodotto in Capgo Aggiornamenti in Tempo Reale, Panoramica per i dettagli di implementazione in Panoramica, Caratteristiche per i dettagli di implementazione in Caratteristiche Aggiorna il comportamento per il dettaglio di implementazione in Aggiorna il comportamento, e Tipi di Aggiornamento per il dettaglio di implementazione in Tipi di Aggiornamento.