FAQ

Si vous avez des questions non répondues ici, veuillez demander ! Les deux, ouvrir un problème ou demander sur Discord travail.

Qu'est-ce que “code push”?

Code push, également appelé « mises à jour en ligne » (OTA), est un service cloud permettant aux développeurs Capacitor de déployer des mises à jour dans leurs applications en production. Capgo fonctionne actuellement sur Android, iOS et Electron.

“Code Push” fait référence au nom d'une fonction de déploiement utilisée par la communauté React Native de Microsoft et Expo, qui ne supportent pas Capacitor.

Quelle est la différence entre un bundle et une version de sortie ?

Nous utilisons le terme « version de sortie » pour désigner la préparation d'un binaire pour les magasins d'applications. Pour générer ensuite un bundle Capgo doit connaître le binaire exact qui a été envoyé aux magasins d'applications.

Nous utilisons le terme « bundle » pour désigner une mise à jour qui peut être appliquée à une version de sortie pour la mettre à jour vers de nouvelles code. Le npx @capgo/cli@latest bundle upload commande est utilisée pour générer un bundle à partir de votre nouveau code local qui est ensuite envoyé à vos utilisateurs.

Quel est le plan de développement ?

Nos tableaux de projet sont également publics et se trouvent à : https://github.com/orgs/Cap-go/projects

Notre équipe travaille également en public, vous pouvez donc voir ce que nous travaillons en tout temps. Nous sommes heureux de répondre à toutes vos questions sur notre plan de route ou nos priorités via les Github issues ou Discord.

Puis-je utiliser Capgo avec mon équipe ?

Oui ! Tous les plans supportent des développeurs illimités. Nous ne limitons que les métriques d'application (MAU, stockage et bande passante) à chaque organisation.

Voir Équipes For plus d'informations.

Le Capgo stocke-t-il mon source code?

Non. Les serveurs Capgo ne voient jamais votre source code. Lorsque vous exécutez npx @capgo/cli@latest bundle uploadLe Capgo stocke un fichier zip du code minifié/compilé - le même code qu'un navigateur recevrait, et non votre source code.

Pour une sécurité supplémentaire, vous avez deux options :

• Chiffrement de bout en bout: Chiffrez votre bundle avant de l'envoyer pour le protéger en stockage et en transit et pour empêcher les tiers de générer des mises à jour chiffrées valides sans votre clé privée. Cela ne rend pas les actifs web distribués impossibles à décompiler car la clé publique est présente dans l'application distribuée.
• Chargement de fichier externe: Stockez le bundle sur votre propre serveur et fournissez uniquement au Capgo le lien de téléchargement avec l'option --external <url>

Voir également notre politique de confidentialité : https://capgo.app/privacité

Les fichiers de bundle sont-ils des données privées ?

Non. Les fichiers de bundle sont des actifs web publics destinés à être téléchargés par vos utilisateurs d'application. N'importe qui qui connaît l'URL du bundle peut récupérer ces fichiers, et Capgo informe les utilisateurs de cela lors de la configuration et dans la documentation.

L'accès aux fichiers de bundle n'est pas considéré comme une violation de données. N'insérez pas de secrets, de crédentiels, de données personnelles ou de données réglementées dans votre bundle d'application. Si vous avez besoin d'une confidentialité plus forte pour des cas d'utilisation de haute sécurité, utilisez une encryption de bout en bout, mais traitez toujours les code et les actifs de l'application comme publics du point de vue de la sécurité.

Peut-on utiliser Capgo à partir de mon système CI ?

Oui. Capgo est conçu pour être utilisé à partir de systèmes CI. Nous avons publié un guide pour Android et Github Actions et iOSet pour GitLab. D'autres systèmes CI devraient être similaires.

Veuillez ne pas hésiter à nous contacter sur GitHub ou Discord si vous rencontrez des problèmes.

Comment cela se rapporte-t-il à Firebase Remote Config ou Launch Darkly?

Le Code push permet d'ajouter de nouveaux code / de remplacer code sur le dispositif. Firebase Remote Config et Launch Darkly sont tous deux des systèmes de configuration. Ils vous permettent de modifier la configuration de votre application sans avoir à envoyer une nouvelle version. Ils ne sont pas destinés à remplacer code.

Quel est l'impact sur la taille du pied de dépense de dépendances?

I n'ai pas mesuré récemment, mais je suppose que la bibliothèque de push code ajoutera moins d'un mégaoctet aux applications Capacitor. Nous connaissons des moyens de rendre cela plus petit lorsque cela devient une priorité. Si la taille est un bloqueur pour vous, veuillez nous le faire savoir!

Le Capgo fonctionne-t-il sur le simulateur iOS 18.4?

Non. En raison d'un problème upstream affectant le simulateur iOS 18.4, le Capgo ne fonctionne pas de manière fiable là-bas. Veuillez tester sur un appareil réel ou utiliser une version différente du simulateur iOS.

Voir les détails dans l'incident React Native : facebook/react-native#50510

Le code push fonctionne-t-il avec des applications volumineuses?

Oui. Il n'y a pas de limite sur la taille de l'application qui peut être mise à jour avec le code push. Comme indiqué en dessousCapgo peut modifier n'importe quel code JS dans votre application, quel que soit sa taille.

À noter : une taille plus importante rend plus difficile aux utilisateurs le téléchargement des mises à jour. Nous recommandons de garder votre application aussi petite que possible.

Qu'est-ce que je peux utiliser Capgo code pour pousser ?

On a vu une variété d'utilisations, notamment :

• Réparations d'urgence pour les applications en production.
• Expédition de correctifs de bogues aux utilisateurs sur des versions plus anciennes de votre application.
• Expédition constante (par exemple, toutes les heures).

Notez que la plupart des magasins d'applications interdisent l'expédition de code qui modifie le comportement de l'application d'une manière significative. Veuillez consulter ci-dessous pour plus d'informations.

What compte comme un « MAU » pour Capgo?

Un MAU est un « Utilisateur Actif Mensuel ». Dans le contexte de Capgo , cela fait référence en réalité à un Dispositif Actif Mensuel. Nous comptons un MAU comme tout dispositif qui a contacté nos serveurs au cours des 30 derniers jours. Nous ne comptons pas les dispositifs qui n'ont pas contacté nos serveurs au cours des 30 derniers jours.

Important: À partir de la version de plugin v5.10.0, v6.25.0 et v7.25.0, le deviceID persiste désormais entre les redémarrages de l'application. Avant ces versions, chaque redémarrage d'application générerait un nouveau deviceID et serait compté comme un nouveau MAU.

Avec les versions actuelles :

• Le DeviceID persiste entre les réinstallations de l'application (stocké de manière sécurisée dans Keychain sur iOS et EncryptedSharedPreferences sur Android)
• Mise à jour de l'application : cela ne crée pas de nouveau Device ID
• Pendant le développement, si vous utilisez une ancienne version du plugin (< v5.10.0 / v6.25.0 / v7.25.0), chaque réinstallation crée toujours un nouveau MAU

Remarque : les téléchargements TestFlight et les changements de canal sur Android peuvent toujours générer de nouvelles inscriptions de dispositifs en fonction de votre configuration.

Nous recommandons de désactiver les appareils de développement et les émulateurs après la première configuration pour réduire le nombre de dispositifs dupliqués.

Quoi ne pouvons-nous pas utiliser Capgo code pour ?

Comme ci-dessus, Capgo ne doit pas être utilisé pour violer les politiques de l'App Store. Voir ci-dessous pour plus d'informations. Également, __CAPGO_KEEP_0__ ne prend pas en charge la modification du __CAPGO_KEEP_1__ natif (par exemple Java/Kotlin sur Android ou Objective-C/Swift sur iOS). L'outil vous avertira pendant une mise à jour tentée si vous avez modifié le __CAPGO_KEEP_2__ natif. What can’t we use __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ push for?

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.

Puis-je mettre à jour les modifications de capacitor.config.ts via Capgo?

Non. Règle courte : Capgo peut envoyer le dossier de build web généré, y compris HTML, CSS, JavaScript, ressources et modifications de packages pure-JavaScript bundlées dans cet output. Les modifications à capacitor.config.ts, la configuration de plugin natif, les installations ou mises à jour de packages natifs et tout ce qui doit mettre à jour le projet iOS ou Android à travers npx cap sync ou npx cap copy exigent une mise à jour de l'application native.

Le fichier de configuration Capacitor est lu à l'heure de la construction native et compilé dans le binaire de l'application native. Si vous avez besoin de modifier votre configuration Capacitor, vous devez :

1. Mettre à jour capacitor.config.ts localement
2. Reconstruire votre application native (npx cap sync suivi d'une construction native)
3. Soumettre la nouvelle version binaire aux magasins d'applications

Le Capgo soumet-il les magasins pour moi?

Le Capgo ne prend pas actuellement en charge la soumission aux magasins d'applications en votre nom. Nous avons des plans pour y ajouter à l'avenir, mais pour l'instant, vous devrez continuer à utiliser vos processus existants pour soumettre aux magasins d'applications.

Vous pouvez utiliser notre Guide CI Android pour automatiser ce processus et Guide CI iOS.

Qu'est-ce que Capgo stocke sur le disque dur et où?

L'Capgo mise à jour (inclus dans votre application lors de la construction de votre application) met en cache le dernier bundle téléchargé dans le seul répertoire qui capacitor autorise à charger code. Sur Android, il est situé dans /data/user/0/com.example.app/code_cache/capgo_updater même si la base de ce chemin est fournie par le système Android et peut changer dynamiquement en temps de exécution. Sur les appareils iOS, les données sont stockées sous Library/Application Support/capgo.

Les outils de ligne de commande Capgo (par exemple, npx @capgo/cli@latest bundle upload) sont installés sur le disque dans les npm caches, vos identifiants de connexion sont stockés dans votre répertoire personnel dans ~/.capgo.

Comment cela se rapporte-t-il à Capacitor Hot Reload?

Le hot reload de Capacitor est une fonctionnalité réservée au temps de développement. Le Code push est pour la production.

Le hot reload est une fonctionnalité de Capacitor qui vous permet de modifier code sur le dispositif pendant le développement. Il nécessite la construction de l'application Capacitor avec un proxy pour se connecter à votre machine locale.

Le Code push est une fonctionnalité qui vous permet de modifier code sur le dispositif en production. Nous utiliserons une variété de techniques différentes pour rendre cela possible en fonction du plateau-forme.

Quels types de modifications Capgo code push supporte-t-il?

Capgo peut modifier n’importe quel code JS dans votre application. Cela comprend les code d’application et les code générés. Vous pouvez également mettre à jour les dépendances dans package.json à condition qu’elles ne nécessitent pas de modifications natives code.

Nous n’avons pas l’intention de soutenir la modification de modifications natives code (par exemple Java/Kotlin sur Android ou Objective-C/Swift sur iOS), et l’outil vous avertira si il détecte que vous avez modifié des modifications natives code car elles ne seront pas incluses dans le bundle.

Cette fonctionnalité prend-elle en charge le Web ?

Le push Code n’est pas nécessaire pour le Web car le Web fonctionne déjà de cette manière. Lorsqu’un utilisateur ouvre une application Web, il télécharge la dernière version depuis le serveur si nécessaire.

Si vous avez un cas d’utilisation pour le push code avec le Web, nous aimerions en savoir plus !

Cette fonctionnalité fonctionnera-t-elle sur iOS, Android, Mac, Windows, Linux, etc. ?

Oui.

Jusqu'à présent, nous nous sommes concentrés sur le support d'Android, iOS et Electron, et code est prêt à la production sur les trois.

Quels versions d'OS est Capgo compatible ?

Capgo prend en charge les mêmes versions d'Android que Capacitor.

Capacitor prend actuellement en charge Android API niveau 22+ et iOS 13.0+: https://capacitorjs.com/docs/main/reference/support-policy

Quelles versions de Capacitor est Capgo compatible ?

Capgo prend actuellement en charge uniquement les dernières versions stables de Capacitor. Nous pourrions prendre en charge des versions plus anciennes de Capacitor également, nous n'avons tout simplement pas construit l'infrastructure nécessaire pour maintenir de telles versions à long terme. Nous comptons prendre en charge plus de versions de Capacitor à l'avenir, y compris toute version pour nos clients entreprises. https://github.com/Cap-go/capgo/issues/1100

Capgo suit Capacitor stable et met à jour généralement dans les quelques heures d'une mise à jour stable. Notre système pour effectuer ces mises à jour est automatisé et prend quelques minutes à exécuter. Nous effectuons ensuite une vérification manuelle supplémentaire avant de publier sur nos serveurs.

Comment cela se rapporte-t-il au processus ou aux politiques de la boutique App/Play Store?

Les développeurs sont liés par leurs accords avec les fournisseurs de magasins lorsqu'ils choisissent d'utiliser ces magasins. Code push est conçu pour permettre aux développeurs de mettre à jour leurs applications et de se conformer encore aux politiques des magasins sur les canaux de livraison iOS, Android et Electron. De même que la variété de produits commerciaux disponibles pour y parvenir avec React Native (par exemple Microsoft, Microsoft publie également un guide sur la manière dont leur solution se conforme aux politiques des magasins :).

https://__CAPGO_KEEP_0__.com/microsoft/react-native-__CAPGO_KEEP_1__-push#store-guideline-compliance github push est une technique largement utilisée dans les magasins d'applications. Toutes les grandes applications dont je suis conscient utilisent code push. La principale politique dont il faut tenir compte est de ne pas modifier le comportement de l'application d'une manière significative. Voir

Code push is a widely used technique throughout the app stores. All of the large apps I’m aware of use code push. The major policy to be aware of is not to change the behavior of the app in a significant way. Please see __CAPGO_KEEP_0__ Pour plus d'informations.

Capgo respecte-t-il les lignes directrices de la boutique Play?

Oui.

La boutique Play propose deux restrictions concernant les outils d'actualisation.

1. Les mises à jour doivent utiliser un interpréteur ou une machine virtuelle (Capgo utilise JavaScript dans 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.

2. Les modifications de l'application ne doivent pas être trompeuses (par exemple, changer la finalité de l'application via l'actualisation). https://support.google.com/googleplay/android-developer/answer/9888077 S'il vous plaît, soyez clair avec vos utilisateurs sur ce que vous leur fournissez avec votre application et ne violatez pas leurs attentes avec des changements comportementaux significatifs à l'aide de Capgo.

Capgo est conçu pour être compatible avec les lignes directrices de la Play Store. Cependant Capgo est un outil, et comme avec tout outil, il peut être abusé. L'abus délibéré de Capgo pour violer les lignes directrices de la Play Store constitue une violation de la Capgo Conditions d'utilisation et peut entraîner la fermeture de votre compte.

Enfin, les services de mise à jour de code sont largement utilisés dans l'industrie (tous les grands applications dont je suis conscient utilisent-les) et il existe de multiples autres services de mise à jour de code disponibles publiquement (par exemple, expo.dev et appcenter.ms). C'est un chemin bien balisé.

Microsoft publie également une guide sur la façon dont leur bibliothèque de codepush « react native » est conforme aux magasins d'applications : https://github.com/microsoft/react-native-code-push#store-guideline-compliance

Capgo est-il conforme aux lignes directrices de l'App Store ?

Oui.

De même que la Play Store, l'App Store offre des restrictions techniques et des restrictions de politique.

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 utilise le JavaScript dans un WebView pour se conformer à la restriction d'interprétation uniquement pour les mises à jour sur iOS. Si votre application ne se livre pas à un comportement délibérément trompeur via les mises à jour (par exemple, en changeant la finalité de l'application via la mise à jour), la mise à jour via Capgo (ou toute autre solution de mise à jour code) est une pratique standard de l'industrie et conforme aux lignes directrices de l'App Store.

Abuser délibérément de Capgo pour violer les lignes directrices de l'App Store est une violation de Capgo Conditions d'utilisation et peut entraîner la fermeture de votre compte.

Microsoft publie également un guide sur la façon dont leur bibliothèque « codepush » React Native se conforme aux magasins d'applications : https://github.com/microsoft/react-native-code-push#store-guideline-compliance

Puis-je utiliser Capgo dans mon pays ?

Nous n'avons pas tenté de restreindre l'accès à Capgo à partir de tout pays.

Nous reconnaissons que certains pays ont des restrictions sur les URLs qui peuvent être accédées à partir du pays. Capgo utilise actuellement Cloudflare Cloud pour l'hébergement, y compris R2 Storage et les travailleurs Cloudflare.

Les URL suivantes sont utilisées par Capgo :

• https://api.capgo.app — utilisé par les npx @capgo/cli outils de ligne de commande pour interagir avec les serveurs Capgo ainsi que l'actualiseur Capgo sur les appareils des utilisateurs pour vérifier les mises à jour.
• https://*.r2.cloudflarestorage.com — utilisé par npx @capgo/cli l'outil de ligne de commande pour télécharger et télécharger le bundle

Si toutes ces URL sont accessibles depuis votre pays, alors Capgo devrait fonctionner.

Si votre région nécessite de bloquer l'accès à l'une de ces URL, veuillez nous le faire savoir et nous pouvons travailler avec vous pour trouver une solution. Les serveurs proxy sont une option.

Puis-je héberger moi-même Capgo?

Oui, vous pouvez héberger vous-même Capgo. Le guide n'est pas encore écrit, mais le code est open source et disponible sur https://github.com/cap-go/capgo

Est-ce que code nécessite Internet pour fonctionner ?

Oui. On pourrait imaginer exécuter un serveur pour distribuer les mises à jour séparément de l'internet général, mais une forme de connectivité réseau est requise pour transporter les mises à jour vers les appareils.

Comment Capgo est-il affecté par l'absence de connectivité réseau ?

L'Capgo updater (inclus dans votre application lorsque vous construisez votre application avec Capgo) est conçu pour être résistant aux problèmes de connectivité réseau.

Dans le comportement de mise à jour par défaut, lorsque l'application est lancée, elle alerte l'Capgo updater, qui démarre un thread séparé pour effectuer une requête réseau vers les serveurs de Capgo et demander une mise à jour. Nous utilisons intentionnellement un thread séparé pour éviter d'affecter tout autre chose que l'application puisse faire. Si la requête réseau échoue ou expire, l'updater essaiera simplement de vérifier à nouveau la prochaine fois que l'application est lancée.

L'Capgo command line tools (par exemple, __CAPGO_KEEP_2__) nécessitent une connectivité réseau pour fonctionner. Si vous utilisez Capgo pour distribuer votre application, vous devez vous assurer que votre système CI a une connectivité réseau. npx @capgo/cli@latest bundle upload) require network connectivity to function. If you are using Capgo to distribute your app, you should ensure that your CI system has network connectivity.

What happens if a user doesn’t update for a long time and misses an update?

Notre mise en œuvre envoie toujours une mise à jour spécifiquement conçue pour le dispositif qui la demande, mettant à jour le demandeur à la dernière version disponible. Ainsi, si un utilisateur ne met pas à jour pendant un moment, il « manque » les mises à jour intermédiaires.

Le serveur de mise à jour pourrait être modifié pour supporter la réponse avec soit la prochaine version incrémentale, soit la dernière version en fonction des besoins de votre application. Veuillez nous faire savoir si les comportements de mise à jour alternatifs sont importants pour vous.

Comment Capgo se rapporte-t-il à Capacitor?

Capgo est un plugin pour Capacitor qui ajoute code de la poussée. Capgo n'est pas une remplacement pour Capacitor. Vous pouvez continuer à utiliser les outils de Capacitor que vous connaissez et aimez.

On suit la dernière version stable de Capacitor et met à jour notre plugin de poussée code pour qu'il fonctionne avec elle.

Quand se produisent les mises à jour?

Par défaut, l'Capgo met à jour vérifie les mises à jour lors du démarrage de l'application. Il s'exécute sur un thread de fond et ne bloque pas le thread de l'interface utilisateur. Toute mise à jour sera installée pendant que l'utilisateur utilise l'application et sera appliquée la prochaine fois que l'application sera redémarrée.

Il est également possible de lancer manuellement l'Capgo metteur à jour à l'aide du @capgo/capacitor-updater package, grâce auquel il est possible de déclencher des mises à jour à tout moment, y compris via une notification push.

Le metteur à jourCapgo est conçu de telle sorte que lorsque le réseau n'est pas disponible, ou que le serveur est en panne ou inaccessible, l'application continuera à fonctionner normalement. Si vous choisissez un jour de supprimer une mise à jour de nos serveurs, tous vos clients continueront à fonctionner normalement.

Nous avons ajouté la possibilité de revenir sur des correctifs. La chose la plus simple est de simplement attacher un bundle précédent à votre canal pour annuler.

Faut-il conserver mon secret d'application ?

Non. Le app_id fait partie de votre application et est en sécurité pour être public. Vous pouvez le vérifier dans le contrôle de version (même publiquement) et ne vous soucier de personne qui pourrait l'accéder.

Quelqu'un qui a votre app_id Peut récupérer la dernière version de votre application à partir des serveurs de Capgo, mais ils ne peuvent pas envoyer d'actualisations à votre application ou accéder à tout autre aspect de votre compte de Capgo.

Quelles informations sont envoyées aux serveurs de Capgo ?

Même si Capgo se connecte au réseau, il ne transmet aucune information identifiable personnellement. Inclure Capgo ne devrait pas affecter vos déclarations pour le Play Store ou l'App Store.

Les requêtes envoyées de l'application aux serveurs de Capgo incluent :

• app_id (spécifié capacitor.config.json)
• canal (facultatif en capacitor.config.json)
• release_version (versionName de AndroidManifest.xml ou CFBundleShortVersionString de Info.plist ou capacitor.config.json si défini en CapacitorUpdater.version )
• version_number (généré en tant que partie de npx @capgo/cli@latest bundle upload)
• os_version (par exemple ‘11.2.1’)
• Plateforme (par exemple ‘android’, nécessaire pour envoyer la bonne mise à jour) C’est tout. Le code pour cela est dans updater/library/src/network.rs
• identifiant_de_device (généré sur le dispositif lors de la première exécution, utilisé pour éviter les doublons d'installation par appareil et permettre de facturer en fonction des utilisateurs installés (par exemple, utilisateurs actifs mensuels), plutôt que le nombre total de mises à jour ou le nombre total d'installations de mises à jour)
• identifiant_custom (facultatif, défini en temps réel par le développeur, utilisé pour lier un appareil à un utilisateur dans votre système)

Puis-je utiliser Capgo pour les applications sensibles à la HIPAA ?

Oui, mais votre responsable de conformité doit choisir le bon modèle de déploiement. Le Cloud de Capgo n'est pas actuellement présenté comme un processeur de statistiques hôte conforme à la HIPAA. Par défaut, les données de mise à jour sont scoping appareil et ne sont pas liées à un utilisateur de l'application connu, et beaucoup d'équipes utilisent ce modèle avec succès.

Pour des examens plus stricts, vous pouvez localiser le trafic du plugin, désactiver les statistiques en définissant statsUrl à une chaîne vide, héberger uniquement l'endpoint de statistiques, ou utiliser l'hébergement autonome sous licence. N'appelez pas CapacitorUpdater.setCustomId(...) avec un adresse e-mail, un identifiant d'utilisateur, un identifiant de patient, un identifiant d'employé ou toute valeur qui remet la télémétrie de mise à jour à une personne.

Voir Conformité à la HIPAA pour la configuration technique complète et les compromis d'observabilité lorsque les statistiques sont désactivées.

Puis-je conserver les données de mise à jour en direct de Capgo en Europe?

Oui. Les applications qui nécessitent une résidence des données de l'UE pour le trafic du plugin Cloud Capgo peuvent définir les points de terminaison de mise à jour sur l'hôte de l'UE :

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

Utilisez les trois URL de l'UE ensemble afin que les contrôles de mise à jour, les statistiques et l'attribution de canal utilisent la même voie de chemin de données régionale. Puisque ces valeurs vivent dans capacitor.config.tsles applications mobiles de production ont besoin d'une mise en production native avant les installations existantes utilisent les nouveaux points de terminaison.

Voir Emplacement des données pour les exemples exacts de Capacitor et Electron.

Quels plateformes supporte Capgo?

Actuellement, Capgo prend en charge Android, iOS et Electron. Toutes sont prêtes pour la production.

L'utilisation de Capgo pour iOS, Android ou Electron peut être une décision independante. Vous pouvez définir votre stratégie de canal pour Android et un fichier ipa construit pour l'App Store, ou les canaux Electron, selon vos besoins.

Capgo peut (relativement facilement) être adapté pour supporter les cibles bureau ou embarquées. Si cela est important pour vous, veuillez nous en informer.

Comment Capgo interagit-il avec les pistes de test Play ou Apple TestFlight ?

Chaque magasin d'applications a des mécanismes séparés pour distribuer des applications à des groupes d'utilisateurs limités (par exemple « test interne », « bêta fermée », etc.). Ces mécanismes sont tous destinés à segmenter vos utilisateurs en groupes et à distribuer des versions spécifiques de vos applications à chaque groupe.

Malheureusement, ces mécanismes ne permettent pas tous de détecter quand des applications sont installées dans une piste de test spécifique ou via TestFlight. Ainsi, nous n'avons pas de visibilité fiable sur la composition de ces groupes, et ne pouvons pas nous fier pour gérer l'accès aux correctifs de Capgo en fonction de ces groupes. 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

Si vous souhaitez segmenter la disponibilité du Capgo bundle, il existe 4 options potentielles :

1. Utilisez un canal séparé pour chaque groupe. Cette approche est la plus directe, mais nécessite que vous gériez plusieurs canaux. Vous pouvez déjà avoir des canaux de développement et des canaux de production avec des disponibilités différentes. Vous pouvez ainsi mettre à jour vos canaux de développement, les vérifier et mettre ensuite à jour séparément vos canaux de production. Nous recommandons d'utiliser des branches / étiquettes dans votre contrôle de version pour aider à suivre les sources associées à chaque version.
2. Suivez votre propre ensemble d'utilisateurs qui ont opté pour la mise à jour, désactivez les mises à jour automatiques et déclenchez les mises à jour uniquement pour certains utilisateurs via le @capgo/capacitor-updater package. Cette fonctionnalité fonctionne aujourd'hui, mais nécessite que vous gériez votre propre liste d'opt-in.
3. Capgo permet de créer son propre mécanisme d'opt-in sur une base par appareil (similaire aux pistes de test ou à TestFlight, mais sans dépendre d'une plateforme spécifique). Cela permet à votre équipe de test de s'inscrire au bundle avant qu'il ne soit promu au public général.
4. Capgo permet des lancements avec un pourcentage basé. Cela ne vous permet pas de choisir les appareils à envoyer, mais peut vous aider à lancer progressivement et à annuler en cas de problèmes.

Facturation

Comment puis-je mettre à niveau ou dégrader mon plan ?

Vous pouvez mettre à niveau ou dégrader votre plan à tout moment dans votre tableau de bord : https://console.capgo.app/settings/organization/plans

Quand se réinitialise mon période de facturation ?

Les périodes de facturation sont réinitialisées automatiquement chaque mois au mois où vous avez souscrit à Capgo. Par exemple, si vous avez souscrit le 15 du mois, votre période de facturation se réinitialisera le 15 de chaque mois.

Comment puis-je annuler mon abonnement ?

Vous pouvez annuler votre abonnement à tout moment dans votre tableau de bord : https://console.capgo.app/settings/organization/plans

Peut-on payer pour un an à l'avance ?

Oui, vous pouvez le faire à tout moment dans votre tableau de bord : https://console.capgo.app/settings/organisation/plans

Statistiques et analyses

Les statistiques de votre tableau de bord sont mises à jour chaque nuit UTC. Les statistiques sont calculées en fonction du nombre de MAU qui ont été installés sur vos appareils.

Comment est généré l'ID de l'appareil

L'ID de l'appareil est généré sur l'appareil lors de la première exécution, et est utilisé pour éviter les doublons d'installations par appareil et nous permettre de facturer en fonction des utilisateurs installés (par exemple, utilisateurs actifs mensuels), plutôt que le nombre total de patchs ou d'installations de patchs.

Le nombre d'utilisateurs actifs mensuels est une meilleure solution que le nombre d'installations pour déterminer le prix Capgo, car il est plus précis et reflète le coût réel Capgo par appareil.

Persistance de l'ID de l'appareil (Mise à jour dans v6.25.0 et v7.25.0):

• Comportement actuel : L'ID de l'appareil persiste désormais après les réinstallations de l'application. Il est stocké de manière sécurisée dans la clé de chiffrement de l'appareil (iOS) ou dans les SharedPreferences chiffrés (Android), ce qui nous permet de suivre le même appareil même après l'annulation/reinstallation.
• Comportement précédent (avant v6.25.0/v7.25.0) : Pour des raisons de confidentialité liées aux politiques des magasins d'Apple et Google, l'ID de l'appareil était réinitialisé à chaque réinstallation de l'application, ce qui rendait impossible de suivre le même appareil lors des réinstallations.

Les règles de confidentialité sont appliquées par Apple et Google, et Capgo respecte leurs meilleures pratiques pour l'identification des appareils.

Les ID d'appareil sont listés après que l'application a vérifié avec Capgo à l'aide de l'interface de mise à jour ou des points de terminaison de statistiques. Un appareil n'a pas besoin d'installer un patch avant de pouvoir apparaître dans la liste des appareils.

Pourquoi mon numéro d'appareil est différent de mon MAU ?

La liste des appareils et le MAU sont basés sur des signaux différents.

The device list shows the latest known metadata for each device, such as the device ID, platform, plugin version, OS version, native version, channel, installed bundle, and request country when available. The request country is the latest valid two-letter code received from a Cloudflare-handled request for that device, not GPS or app-provided location. Requests without a valid country do not clear the last valid value. Capgo updates this metadata when the app checks in, but repeated check-ins that report the same metadata may not change the row or its last update time.

Les MAU comptent les appareils actifs distincts pendant la fenêtre de facturation. Cette activité peut augmenter même lorsque les métadonnées de l'appareil restent les mêmes, donc le nombre d'appareils et les MAU peuvent être différents.

Comment avoir une mise à jour différente par plateforme ?

Vous pouvez créer un canal pour chaque plateforme et désactiver les mises à jour spécifiques à la plateforme dans chaque canal.

Sur le canal iOS, désactiver les mises à jour Android et sur le canal Android, désactiver les mises à jour iOS.

Ensuite, télécharger un bundle dans chaque canal pour avoir une mise à jour différente pour chaque plateforme.

Si vous avez besoin d'avoir la même mise à jour pour les deux plateformes, vous pouvez lier un bundle à plusieurs canaux. Pas besoin de dupliquer le bundle.

Continuez à partir de FAQ

Si vous utilisez FAQ pour planifier la livraison d'actualisations en direct, connectez-le à Capgo Mises à jour en direct pour le flux de travail du produit dans Capgo Mises à jour en direct, Aperçu pour les détails d'implémentation dans Aperçu, Fonctionnalités pour les détails d'implémentation dans Fonctionnalités, Comportement d'actualisation Détails d'implémentation pour le comportement de mise à jour, et Types de mise à jour Détails d'implémentation pour les types de mise à jour.