FAQ

Si vous avez des questions non résolues ici, n'hésitez pas ! Que ce soit en ouvrant un issue ou sur Discord, work.

C'est quoi le « code push » ?

Code push, aussi appelé « mises à jour over-the-air » (OTA), est un service cloud permettant aux développeurs Capacitor de déployer des mises à jour sur leurs apps en production. Capgo fonctionne actuellement sur Android, iOS et Electron.

« Code Push » fait référence au nom d'une fonctionnalité de déploiement utilisée par la communauté React Native de Microsoft et Expo, dont aucun ne supporte Capacitor.

Est-ce que les versions Capgo CLI majeures de Capacitor doivent correspondre à mon plugin ?

No. Always use the latest Capgo CLI (npx @capgo/cli@latest). Les consoles CLI et Capgo suivent leur propre versioning et restent compatibles avec toutes les versions majeures des plugins updater supportés. Les plugins Capgo suivent Capacitor versions majeures ; voir le versionnement Capgo pour les tags LTS tels que @lts-v7.

Quelle est la différence entre un bundle et une release ?

Nous utilisons le terme « release » pour désigner la préparation d'un binaire pour les stores. Pour pouvoir générer un bundle plus tard, Capgo doit connaître le binaire exact qui a été publié sur les stores.

Nous utilisons le terme « bundle » pour désigner un patch pouvant être appliqué à une release afin de la mettre à jour vers de nouveaux code. npx @capgo/cli@latest bundle upload la commande est utilisée pour générer un bundle à partir de votre nouveau code local, qui est ensuite déployé auprès de vos utilisateurs.

Are there Delta update file-path limitations?

Oui :

• Fichiers de zéro octet : Les logs CLI Ignoring empty file... et excluent les fichiers vides des fichiers delta. Cela n'interrompt pas l'upload, donc un fichier vide peut modifier le bundle final sans stopper votre déploiement. N'incluez pas de fichiers de zéro octet dans les chemins du bundle Delta.
• Chemins avec des espaces : Les uploads Delta échouent rapidement avec une erreur claire si un chemin de bundle contient un espace. Renommez vos fichiers ou répertoires pour supprimer les espaces avant d'envoyer une mise à jour Delta.

Consultez Mises à jour delta pour les détails de configuration.

Quelle est la roadmap ?

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

Notre équipe travaille aussi en public, vous pouvez donc voir sur quoi nous travaillons à tout moment. Nous serons ravis de répondre à vos questions sur notre roadmap ou nos priorités via les issues Github ou Discord.

Puis-je utiliser Capgo avec mon équipe ?

Oui ! Tous les plans supportent un nombre illimité de développeurs. Nous limitons uniquement les métriques de l'app (MAU, stockage et bande passante) pour chaque organisation.

Consultez Équipes pour plus d'informations.

Est-ce que Capgo stocke mon code source ?

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

Pour une sécurité accrue, vous avez deux options :

• Chiffrement de bout en bout: Chiffrez votre bundle avant l'upload pour le protéger lors du stockage et du transit, et empêcher des tiers de générer des mises à jour chiffrées valides sans votre clé privée. Cela ne rend pas les assets web livrés impossibles à rétro-concevoir, car la clé publique est présente dans l'application distribuée.
• Upload via URL externe: Stockez le bundle sur votre propre serveur et fournissez simplement le lien de téléchargement à Capgo avec l'option --external <url>

Consultez également notre politique de confidentialité : https://capgo.app/privacy

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

Non. Les fichiers du bundle sont des assets web publics destinés à être téléchargés par les utilisateurs de votre application. Toute personne connaissant l'URL du bundle peut récupérer ces fichiers, et Capgo en informe les utilisateurs lors de la configuration et dans la documentation.

L'accès aux fichiers du bundle n'est pas considéré comme une violation de données. Ne placez pas de secrets, d'identifiants, de données personnelles ou de données réglementées dans votre bundle d'application. Si vous avez besoin d'une confidentialité accrue pour des cas d'usage de haute sécurité, utilisez le chiffrement de bout en bout, mais considérez toujours les code et les assets de l'application déployée comme publics du point de vue de la sécurité.

Puis-je utiliser Capgo depuis mon système CI ?

Oui. Capgo est conçu pour être utilisé depuis des systèmes CI. Nous avons publié un guide pour Android et les actions Github et iOS, et pour GitLab. Les autres systèmes CI devraient être similaires.

N'hésitez pas à nous contacter via GitHub ou Discord si vous rencontrez le moindre problème.

Quel est le rapport avec Firebase Remote Config ou Launch Darkly ?

La Code push permet d'ajouter de nouveaux code / de remplacer code sur l'appareil. Firebase Remote Config et Launch Darkly sont des systèmes de configuration. Ils vous permettent de modifier la configuration de votre app sans avoir à déployer une nouvelle version. Ils ne sont pas destinés à remplacer code.

Quelle empreinte de dépendances cela ajoute-t-il ?

Je n'ai pas mesuré récemment, mais je m'attends à ce que la bibliothèque de push code ajoute moins d'un mégaoctet aux applications Capacitor. Nous savons comment réduire cela si cela devient une priorité. Si la taille est un blocage pour vous, n'hésitez pas à nous le faire savoir !

Est-ce que Capgo fonctionne sur le simulateur iOS 18.4 ?

Non. En raison d'un problème en amont affectant le simulateur iOS 18.4, Capgo ne s'y exécute pas de manière fiable. Veuillez tester sur un appareil réel ou utiliser une autre version du simulateur iOS.

Voir les détails dans le ticket React Native : facebook/react-native#50510

Est-ce que le push code fonctionne avec de grandes applications ?

Oui. Il n'y a aucune limite sur la taille de l'application pouvant être mise à jour via un push code. Comme indiqué ci-dessous, Capgo peut modifier n'importe quel code JS de votre application, quelle que soit sa taille.

À noter : une taille plus importante rend le téléchargement des mises à jour plus difficile pour les utilisateurs. Nous recommandons de garder votre app la plus légère possible.

À quoi peut me servir le push code de Capgo ?

Nous avons constaté diverses utilisations, notamment :

• Corrections d'urgence sur des apps en production.
• Shipping bug fixes to users on older versions of your app.
• Déploiements constants (ex. toutes les heures).

Notez que la plupart des stores interdisent le déploiement de code qui modifie de manière significative le comportement de l'app. Veuillez consulter ci-dessous pour plus d'informations.

What counts as a “MAU” for Capgo?

Un MAU est un appareil actif mensuel (Monthly Active Device). Un appareil distinct qui contacte Capgo sur une période glissante de 30 jours compte pour un MAU pour cet ID d'app natif. Le même appareil physique utilisé avec deux ID d'app natifs distincts compte une fois pour chaque ID d'app ; il n'y a pas de déduplication entre eux.

Si vos flavours diffèrent uniquement par leur couche web ou le routage des mises à jour, utilisez un seul ID d'app natif avec des canaux. Cela permet de regrouper les flavours sous une seule application Capgo et simplifie les releases. Utilisez des ID d'app natifs distincts lorsqu'une flavour nécessite un bundle ID, une identité de signature, un ensemble d'entitlements ou une fiche store différents.

Sur iOS, v7.25.0+ conserve l'ID d'appareil aléatoire propre à l'app lors des réinstallations classiques via le Keychain. Sur Android, utilisez v7.50.1+ (ou v5.50.1+ et v6.50.1+ sur ces lignes de release) ; l'ID n'est restauré que si Android Backup/Restore conserve les préférences de l'app. Désactiver la sauvegarde, exclure ces préférences ou effacer les données de l'app génère un nouvel ID d'appareil. Mettre à jour l'app ne crée pas de nouvel ID d'appareil.

Pour les builds de test et de développement, désactivez la livraison des builds de développement et des émulateurs sur les canaux de production. Cela pilote la livraison, pas les MAU : un appareil peut quand même être comptabilisé lorsqu'il contacte Capgo. Pour l'exclure de l'usage en production, désactivez les live updates et n'appelez pas les endpoints Capgo de production. Voir Tester les Native Builds sans live updates pour les paramètres exacts.

À quoi ne pouvons-nous pas utiliser Capgo code push ?

Capgo ne peut pas modifier le code natif comme Java, Kotlin, Objective-C, Swift, les plugins natifs ou la configuration native. Ces changements nécessitent une nouvelle release de l'app native. Pour le périmètre de la revue des stores, consultez les politiques de l'App Store et de Google Play.

Puis-je déployer des modifications de capacitor.config.ts via Capgo ?

Non. Règle simple : Capgo peut envoyer le dossier du web build généré, incluant le HTML, le CSS, le JavaScript, les assets et les modifications de packages pure JavaScript intégrées à ce build. Les changements de capacitor.config.ts, la configuration de plugins natifs, l'installation ou la mise à jour de packages natifs, et tout ce qui nécessite une modification du projet iOS ou Android via npx cap sync ou npx cap copy nécessitent une release de l'app native.

Le fichier de configuration Capacitor est lu au moment du build natif et compilé dans le binaire de l'app native. Si vous devez modifier votre configuration Capacitor, vous devez :

1. Mise à jour capacitor.config.ts localement
2. Recompilez votre application native (npx cap sync suivi d'un build natif)
3. Soumettez le nouveau binaire aux stores

Est-ce que Capgo soumet aux stores pour moi ?

Le build Capgo peut compiler et signer un projet natif iOS ou Android préparé et, une fois configuré, soumettre le résultat signé à App Store Connect ou Google Play. Vous pouvez conserver votre CI actuelle pour les dépendances privées, les builds web, la synchro Capacitor et la préparation native personnalisée ; Capgo reçoit le projet natif préparé pour l'étape de build natif.

Consultez Build Capgo et le référence de configuration de build pour le workflow et les options de soumission aux stores.

Que stocke Capgo sur le disque et où ?

L'updater Capgo (inclus dans votre application lors du build) met en cache le dernier bundle téléchargé dans le seul répertoire depuis lequel capacitor autorise le chargement de code. Sur Android, il se trouve dans /data/user/0/com.example.app/code_cache/capgo_updater bien que la base de ce chemin soit fournie par le système Android et puisse changer dynamiquement à l'exécution. Sur les appareils iOS, les données sont stockées sous Library/Application Support/capgo.

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

Quel est le lien avec le Hot Reload de Capacitor ?

Le Hot reload de Capacitor est une fonctionnalité réservée au développement. Le push Code est destiné à la production.

Le Hot Reload est une fonctionnalité de Capacitor qui vous permet de modifier code sur l'appareil pendant le développement. Cela nécessite de compiler l'application Capacitor avec un proxy pour se connecter à votre machine locale.

Le push Code est une fonctionnalité qui vous permet de modifier code sur l'appareil en production. Nous utilisons différentes techniques pour rendre cela possible selon la plateforme.

Quels types de changements les push code de Capgo prennent-ils en charge ?

Capgo peut modifier n'importe quel code JS dans votre application. Cela inclut le code de l'app et les code générés. Vous pouvez aussi mettre à jour les dépendances dans package.json tant qu'elles ne nécessitent pas de changements code natifs.

Nous ne prévoyons pas de supporter la modification du code natif (ex: Java/Kotlin sur Android ou Objective-C/Swift sur iOS), et l'outil vous avertira s'il détecte un changement de code natif, car celui-ci ne sera pas inclus dans le bundle.

Est-ce que cela fonctionne sur le Web ?

Le push Code n'est pas nécessaire pour le web car le web fonctionne déjà ainsi. Lorsqu'un utilisateur ouvre une application web, elle télécharge la dernière version depuis le serveur si nécessaire.

Si vous avez un cas d'usage pour code push avec le web, nous serions ravis de le savoir !

Cela fonctionnera-t-il sur iOS, Android, Mac, Windows, Linux, etc. ?

Oui.

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

Quelles versions d'OS Capgo prend-il en charge ?

Capgo supporte les mêmes versions d'Android que Capacitor.

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

Quelles versions de Capacitor sont prises en charge par Capgo ?

Capgo ne supporte actuellement que les releases stables récentes de Capacitor. Nous pourrions également supporter des versions plus anciennes de Capacitor, mais nous n'avons pas encore mis en place l'infrastructure nécessaire pour les maintenir dans le temps. Nous prévoyons de supporter plus de versions de Capacitor à l'avenir, y compris n'importe quelle version pour nos clients enterprise. https://github.com/Cap-go/capgo/issues/1100

Capgo suit les versions stables de Capacitor et effectue généralement une mise à jour quelques heures après chaque release stable. Notre système de mise à jour est automatisé et prend quelques minutes pour s'exécuter. Nous effectuons ensuite une étape de vérification manuelle supplémentaire avant la publication sur nos serveurs.

Quel est le lien avec le processus de révision ou les politiques de l'App Store/Play Store ?

Capgo ne livre des changements qu'à la couche web de Capacitor : le HTML, le CSS, le JavaScript et les assets déjà présents dans la WebView de l'app. Cela ne modifie pas le binaire natif, les plugins natifs, les permissions, les entitlements, la signature ou les métadonnées du store.

Utilisez une release native sur les stores pour chaque changement natif et pour les changements matériels pouvant affecter la fonction ou l'usage de l'app validé lors de la révision. Gardez les live updates dans le cadre de l'expérience utilisateur que vous avez soumise et déclarée.

Est-ce que Capgo peut provoquer un rejet d'exécution d'un code distant d'Apple ?

Non. Ce n'est pas possible. Capgo n'installe ni n'exécute de code natif, de bibliothèques dynamiques, de frameworks ou de plugins, et ne peut pas appeler dlopen, dlsym, performSelector:, ou method_exchangeImplementations(). Il remplace uniquement le JavaScript, le HTML, le CSS et les assets statiques à l'intérieur de la WebView ou du moteur JavaScriptCore déjà compilé dans le binaire examiné.

Lorsque l'App Review cite la directive 2.5.2 ou l'« exécution de code à distance », ne considérez pas Capgo comme la cause. Lisez l'avis de review, puis inspectez le projet natif et les autres SDK pour détecter un chargement d'exécutable ou l'utilisation de API privées. Une ancienne note de review sur le linking dynamique dans le chemin d'auto-masquage du splash screen Capgo était un bug de ce plugin natif, pas des live updates, et ce lien a été supprimé.

La règle d'Apple sur l'exécution de code à distance affecte-t-elle Capgo ?

Non. Capgo ne peut pas provoquer le rejet d'une exécution code à distance. Voir Est-ce que Capgo peut provoquer un rejet d'exécution d'un code distant d'Apple ?. Capgo est conçu pour la couche web interprétée dans les applications Capacitor. Il n'installe ni n'exécute de code natif après la review. Apple examine toujours chaque application selon ses propres éléments, et Capgo ne peut garantir aucun résultat.

La directive App Review 2.5.2 d'Apple indique que les apps ne peuvent pas « télécharger, installer ou exécuter code qui introduit ou modifie des fonctionnalités ou le comportement de l'app ». Les équipes de revue citent cette règle, ainsi que l'Apple Developer Program License Agreement section 3.3.1(B) on exécute code, lorsqu'ils rejettent les applications qui utilisent des ressources distantes pour modifier leur comportement après approbation. Les exemples typiques incluent dlopen, dlsym, performSelector:, ou des scripts distants qui accèdent à des API privées.

Le même contrat de licence autorise le code interprété à être téléchargé lorsqu'il :

• ne modifie pas l'objectif principal de l'app,
• ne contourne pas la signature, le sandbox ou d'autres mécanismes de sécurité de l'OS, et
• ne crée pas un store ou une vitrine pour d'autres applications.

Section 3.3.1(C) interdit séparément de fournir, déverrouiller ou activer des fonctionnalités ou des capacités supplémentaires via des mécanismes de distribution autres que l'App Store, la distribution d'applications personnalisées ou TestFlight, à moins qu'Apple n'ait donné son accord écrit préalable ou que l'activité soit autorisée par la section 3.3.9(A) (Achats intégrés API). La manière dont cette clause s'applique à un bundle OTA interprété code est une question juridique qui relève de votre équipe et de vos conseillers.

Capgo remplace le JavaScript, le HTML, le CSS et les assets statiques qui s'exécutent déjà dans la WebView ou le moteur JavaScriptCore de votre application. Il ne livre pas de binaires natifs, de code machine code, de bibliothèques dynamiques ou de plugins. Directive 4.7 (précisée dans novembre 2025) s'applique lorsque votre application propose des mini-apps HTML5 et JavaScript, des mini-jeux, des chatbots, des plug-ins ou des logiciels similaires qui ne sont pas intégrés au binaire. Si les utilisateurs peuvent parcourir ou lancer plusieurs expériences logicielles distinctes depuis votre application, évaluez les exigences supplémentaires de la directive 4.7 avec votre conseiller. Un produit unique mettant à jour son propre bundle web via des canaux est une expérience utilisateur différente, mais seul Apple décide si vos métadonnées correspondent à cette description.

Déployez les capacités natives, les permissions, les entitlements et les changements de fonctionnalités majeures via un binaire App Store classique. Utilisez Capgo pour les correctifs et améliorations de la couche web qui restent dans l'application que vous avez soumise. Voir l'exécution code à distance d'Apple et Capgo pour une analyse de conformité plus détaillée, ou le guide sur le blog pour la directive 2.5.2, l'ADPLA 3.3.1(B) et la clarification de la directive 4.7 de 2025.

Est-ce que Capgo garantit la validation par l'App Store ou Google Play ?

Non. Apple et Google examinent chaque application et chaque release selon ses propres critères, et Capgo ne peut garantir l'approbation ou l'issue d'un examen individuel. Votre équipe reste responsable du contenu de l'app, des informations fournies, de la portée des mises à jour et de la conformité aux politiques actuelles des stores.

Pour la planification des examens et des releases, consultez directement les politiques officielles : Règles de révision de l'App Store d'Apple et Politique Google Play sur les abus d'appareils et de réseau.

Puis-je utiliser Capgo dans mon pays ?

Nous n'avons pas cherché à restreindre l'accès à Capgo depuis un pays spécifique.

Nous sommes conscients que certains pays imposent des restrictions sur les URL accessibles. Capgo utilise actuellement le Cloud Cloudflare pour l'hébergement, incluant le stockage R2 et les workers Cloudflare.

Les URL suivantes sont utilisées par Capgo :

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

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

Si votre région impose de bloquer l'accès à l'une de ces URL, dites-le-nous et nous chercherons une solution avec vous. Les serveurs proxy sont une option.

Puis-je auto-héberger Capgo ?

Oui. Enterprise prend en charge les déploiements sous licence de Capgo auto-hébergés lorsque vous devez exécuter le backend de l'updater sur votre propre infrastructure. Voir Updater auto-hébergé pour le modèle de déploiement et les endpoints.

Est-ce que l'envoi de code nécessite une connexion internet ?

Oui. On peut imaginer faire tourner un serveur pour distribuer les mises à jour indépendamment d'internet, mais une forme de connectivité réseau reste nécessaire pour acheminer les mises à jour vers les appareils.

Quel est l'impact de l'absence de connectivité réseau sur Capgo ?

L'updater Capgo (inclus dans votre application quand vous la compilez avec Capgo) est conçu pour être résilient face aux problèmes de connectivité réseau.

Avec le comportement de mise à jour par défaut, au lancement de l'application, l'updater Capgo est sollicité ; il lance alors un thread séparé pour effectuer une requête réseau vers les serveurs de Capgo afin de demander une mise à jour. Nous utilisons volontairement un thread séparé pour ne rien bloquer de ce que l'application est en train de faire. Si la requête réseau échoue ou expire, l'updater tentera simplement de vérifier à nouveau au prochain lancement de l'application.

Les outils en ligne de commande Capgo (ex. npx @capgo/cli@latest bundle upload) nécessitent une connexion réseau pour fonctionner. Si vous utilisez Capgo pour distribuer votre application, assurez-vous que votre système de CI dispose d'un accès réseau.

Que se passe-t-il si un utilisateur ne fait pas de mise à jour pendant longtemps et en rate une ?

Notre implémentation envoie toujours une mise à jour spécifiquement adaptée à l'appareil qui la demande, en mettant toujours l'appareil demandeur à jour vers la dernière version disponible. Ainsi, si un utilisateur ne fait pas de mise à jour pendant un certain temps, il passera à côté des versions intermédiaires.

Le serveur de mise à jour peut être modifié pour répondre soit avec la version incrémentale suivante, soit avec la dernière version, selon les besoins de votre application. N'hésitez pas à nous faire savoir si d'autres comportements de mise à jour sont importants pour vous.

Quel est le lien entre Capgo et Capacitor ?

Capgo est un plugin pour Capacitor qui ajoute des push code. Capgo n'est pas un remplaçant de Capacitor. Vous pouvez continuer à utiliser les outils Capacitor que vous connaissez et adorez déjà.

Nous suivons la dernière release stable de Capacitor et mettons à jour notre plugin de push code pour qu'il soit compatible.

Quand les mises à jour ont-elles lieu ?

Par défaut, l'updater Capgo vérifie les mises à jour au démarrage de l'application. Il s'exécute sur un thread en arrière-plan et ne bloque pas le thread UI. Les mises à jour seront installées pendant que l'utilisateur utilise l'application et seront appliquées au prochain redémarrage de celle-ci.

Il est également possible d'exécuter l'updater Capgo manuellement via le @capgo/capacitor-updater package, ce qui permet de déclencher des mises à jour à tout moment, y compris via une notification push.

L'updater Capgo est conçu pour que l'application continue de fonctionner normalement lorsque le réseau est indisponible, ou que le serveur est hors ligne ou injoignable. Si vous choisissez un jour de supprimer une mise à jour de nos serveurs, tous vos clients continueront de fonctionner normalement.

Nous avons ajouté la possibilité de faire un rollback des patchs. Le plus simple est d'associer un bundle précédent à votre canal pour revenir en arrière.

Dois-je garder mon app_id secret ?

Non. L' app_id est inclus dans votre application et peut être public sans risque. Vous pouvez l'ajouter à votre gestion de versions (même publiquement) sans craindre qu'un tiers y accède.

Une personne possédant votre app_id peut récupérer la dernière version de votre application depuis les serveurs Capgo, mais elle ne peut pas envoyer de mises à jour à votre application ni accéder à aucun autre aspect de votre compte Capgo.

Quelles informations sont envoyées aux serveurs Capgo ?

L'inventaire complet des données, le comportement des endpoints et les contrôles de confidentialité sont documentés dans Conformité.

Définissez statsUrl: '' pour désactiver l'envoi des rapports de statistiques de l'updater. Vous pouvez également envoyer statsUrl vers un proxy ou un endpoint que vous contrôlez ; voir la gestion des statistiques sur une infrastructure auto-hébergée. Les vérifications de mise à jour nécessitent toujours un identifiant d'appareil propre à l'app pour que Capgo puisse sélectionner la bonne mise à jour et mesurer les appareils actifs mensuels.

Le la liste des sous-traitants est notre source de vérité publique à jour concernant les providers, les lieux de traitement, les mécanismes de transfert et l'historique des changements.

Can I use Capgo for HIPAA-sensitive apps?

Oui, mais votre responsable conformité doit choisir le bon modèle de déploiement. Capgo Cloud n'est pas actuellement présenté comme un service hébergé de traitement des statistiques conforme à HIPAA. Par défaut, les données de l'updater sont limitées à l'appareil et ne sont pas liées à un utilisateur connu de l'application, et de nombreuses équipes utilisent ce modèl’avec succès.

Pour des audits plus stricts, vous pouvez géolocaliser le trafic des plugins, désactiver les statistiques en réglant statsUrl sur une chaîne vide, auto-héberger uniquement l'endpoint de statistiques, ou utiliser l'auto-hébergement sous licence. N'appelez pas CapacitorUpdater.setCustomId(...) avec un e-mail, un ID utilisateur, un ID patient, un ID employé ou toute valeur permettant de lier la télémétrie de l'updater à une personne.

Consultez Conformité 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 live update de Capgo en Europe ?

Oui. Les applications nécessitant la résidence des données dans l'UE pour le trafic du plugin Cloud Capgo peuvent configurer les endpoints de l'updater sur l'hôte EU :

• 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 pour que les vérifications de mise à jour, les statistiques et l'auto-assignation de canal utilisent le même chemin de données régional. Comme ces valeurs résident dans capacitor.config.ts, production mobile apps need a native release before existing installs use the new endpoints.

Consultez Localisation des données pour des exemples précis avec Capacitor et Electron.

Quelles plateformes Capgo prend-il en charge ?

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

L'usage de Capgo pour iOS, Android ou Electron peut relever de décisions indépendantes. Vous pouvez définir votre stratégie de canaux pour Android et un ipa compilé pour l'App Store, ou pour des canaux Electron, selon vos besoins.

Capgo peut (relativement facilement) être adapté pour supporter le desktop ou l'embarqué. Si cela est important pour vous, n'hésitez pas à nous le faire savoir.

Comment Capgo interagit-il avec les Play Testing Tracks ou Apple TestFlight ?

Chaque store possède ses propres mécanismes pour distribuer des apps à des groupes d'utilisateurs restreints (ex: « test interne », « bêta fermée », etc.). Ce sont tous des moyens de segmenter vos utilisateurs en groupes et de distribuer des versions spécifiques de vos apps à chacun.

Malheureusement, tous ces mécanismes ne permettent pas aux tiers de détecter si une app est installée via un canal de test spécifique ou via TestFlight. Par conséquent, nous n'avons pas de visibilité fiable sur la composition de ces groupes, et ne pouvons pas restreindre l'accès aux patchs Capgo en fonction de ceux-ci de manière fiable. 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é d'un bundle Capgo, voici 4 options possibles :

1. Utiliser un canal distinct pour chaque groupe. C'est l'approche la plus simple, mais elle nécessite de gérer plusieurs canaux. Vous avez peut-être déjà des canaux dev et prod avec des disponibilités différentes. Vous pouvez ainsi mettre à jour vos canaux dev, les vérifier, puis mettre à jour vos canaux prod séparément. Nous recommandons d'utiliser des branches / tags dans votre versionnage pour aider à suivre les sources associées à chaque release.
2. Suivez votre propre ensemble d'utilisateurs opt-in, désactivez les mises à jour automatiques et déclenchez des mises à jour uniquement pour certains utilisateurs via le @capgo/capacitor-updater package. Cela fonctionne aujourd'hui, mais vous devez gérer votre propre liste d'opt-in.
3. Capgo permet de créer son propre mécanisme d'opt-in par appareil (similaire aux Test Tracks ou TestFlight, mais agnostique de la plateforme). Cela permet à votre équipe QA de faire opt-in sur le bundle avant qu'il ne soit déployé auprès du grand public.
4. Utiliser déploiements progressifs pour livrer un bundle candidat à un sous-ensemble aléatoire et persistant d'un canal. Définissez un déploiement de 0 à 100 %, ou utilisez --rollout-percentage-bps pour des incréments de 0,01 % ; configurez la durée du cache de 60 secondes à 365 jours et une politique de pause automatique optionnelle. Cela ne sélectionne pas de groupe d'appareils nommé.

Facturation

Comment changer de plan (upgrade ou downgrade) ?

Vous pouvez changer votre plan à tout moment depuis votre dashboard : https://console.capgo.app/settings/organization/plansLes montées en gamme prennent effet immédiatement. Les descentes en gamme s'appliquent à la fin de votre cycle de facturation actuel.

Que se passe-t-il si j'atteins ma limite de MAU ?

Capgo vous envoie un e-mail à 50 %, 70 %, 90 % et 100 % de votre limite de MAU. Une fois la limite atteinte, les live updates sont bloqués jusqu'à la fin de votre cycle de facturation. Passez à un plan supérieur ou achetez des crédits pour reprendre la diffusion des mises à jour. Voir les tarifs Capgo et Tarifs pour les différents paliers de plan.

Proposez-vous des remboursements ?

Sauf obligation légale, les frais d'abonnement payés ne sont pas remboursables. Certaines demandes de remboursement peuvent être examinées au cas par cas à la seule discrétion de Capgo. Contactez le support si vous pensez y avoir droit.

When does my billing period reset?

Les périodes de facturation sont réinitialisées automatiquement chaque mois à la date de votre premier abonnement à Capgo. Par exemple, si vous vous êtes abonné le 15 du mois, votre période de facturation sera réinitialisée le 15 de chaque mois.

Comment annuler mon abonnement ?

Vous pouvez annuler votre abonnement à tout moment depuis votre dashboard : https://console.capgo.app/settings/organization/plans

Puis-je payer un an à l'avance ?

Oui. Vous pouvez choisir la facturation annuelle dans les paramètres du plan de votre organisation.

Qu'est-ce qui est comptabilisé dans le stockage et peut-on modifier la rétention ?

Le stockage inclut les bundles historiques conservés et leurs assets Delta sur vos canaux. Vous contrôlez la rétention des bundles inutilisés pour chaque app dans les App Settings. Les bundles liés à un canal actif ou à un déploiement progressif restent protégés pour rester disponibles pour la livraison et le rollback.

La réplication régionale multiplie-t-elle le stockage ou la bande passante ?

Non. Un bundle n'est compté qu'une seule fois pour le stockage, peu importe les régions qui le servent. La bande passante n'est pas non plus multipliée par les régions : voir Comment la bande passante est-elle comptabilisée ?.

Comment la bande passante est-elle comptabilisée ?

La bande passante ne comptabilise que les fichiers qu'un appareil télécharge réellement depuis Capgo :

• Mises à jour delta : lorsque vous effectuez un upload avec --delta, un appareil ne télécharge que les fichiers qui ont changé depuis la version qu'il possède déjà. Seuls ces fichiers sont comptabilisés. Les fichiers inchangés, comme les images volumineuses ou les polices, ne sont pas téléchargés à nouveau et ne coûtent rien. Voir Mises à jour delta.
• Cache edge : si un fichier demandé ou un zip complet est déjà en cache à l'edge, ce téléchargement n'est pas décompté de votre bande passante. Cela s'applique aussi bien aux fichiers Delta qu'aux zips complets.
• Reprise des téléchargements : si un téléchargement est interrompu, l'appareil reprend là où il s'est arrêté. La partie déjà téléchargée n'est pas téléchargée à nouveau et n'est pas comptabilisée.
• Zip complet : les bundles envoyés sans --delta, ou les appareils utilisant une version de plugin sans support Delta, téléchargent le zip complet. Cela n'est comptabilisé que lorsqu'il n'est pas servi depuis le cache edge.

To keep bandwidth low, upload with --delta and keep large assets that rarely change in stable file paths.

Que comprend le SLA Enterprise ?

L'offre Enterprise inclut un engagement de disponibilité mensuelle de 99,9 % pour la plateforme de production. En cas de non-respect de cet engagement, le barème de crédits de service va de 10 % à 30 % selon la disponibilité mensuelle. Les objectifs initiaux de délai de réponse du support sont : P1 : une heure, 24/7/365 ; P2 : deux heures ouvrées ; P3 : un jour ouvré ; et P4 : deux jours ouvrés. Consultez le SLA Enterprise pour les conditions complètes.

Stats et analytics

Les stats de votre dashboard sont mises à jour chaque minuit UTC. Les stats sont calculées à partir des MAUs sur la période glissante de 30 jours.

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

L'ID de l'appareil est généré sur l'appareil au premier lancement. Il sert à dédoublonner les installations par appareil et nous permet de facturer en fonction des utilisateurs ayant installé l'app (par ex. les utilisateurs actifs mensuels), plutôt que sur le nombre total de patches ou d'installations de patches.

Les utilisateurs actifs mensuels (MAU) sont une meilleure base de facturation que le nombre d'installations pour tarifer Capgo : c'est plus précis et cela reflète le coût réel de Capgo par appareil.

Persistance de l'ID de l'appareil :

• iOS: À partir de la v7.25.0, l'ID de l'appareil est stocké dans le Keychain et persiste lors des réinstallations normales.
• Android: Utilisez la v7.50.1+ (ou v5.50.1+/v6.50.1+ sur ces branches de release). L'ID de l'appareil n'est restauré que si Android Backup/Restore conserve les préférences de l'application.
• Electron: L'ID de l'appareil est stocké dans un stockage sécurisé.
• Avertissement Android: Désactiver la sauvegarde, exclure les préférences concernées ou effacer les données de l'application génère un nouvel ID de l'appareil. Les versions Android 7.25.0 à 7.50.0 peuvent générer un nouvel ID de l'appareil après une réinstallation, même avec la sauvegarde activée.

L'ID de l'appareil est limité à l'application et permet la livraison de Live Update ainsi que la déduplication des MAU ; ce n'est pas un identifiant publicitaire ou de suivi cross-app.

Les ID d'appareils sont listés après que l'application a communiqué avec Capgo via les endpoints updater ou stats. Un appareil n'a pas besoin d'installer un patch pour apparaître dans la liste.

Pourquoi mon nombre d'appareils est-il différent de mes MAU ?

La liste des appareils et les MAU reposent sur des signaux différents.

La liste des appareils affiche les dernières métadonnées connues pour chaque appareil, comme l'ID, la plateforme, la version du plugin, la version de l'OS, la version native, le canal, le bundle installé et le pays de la requête si disponible. Le pays est le dernier code code valide reçu d'une requête gérée par Cloudflare pour cet appareil, et non une position GPS ou fournie par l'app. Les requêtes sans pays valide ne suppriment pas la dernière valeur connue. Capgo met à jour ces métadonnées lors du check-in de l'app, mais des check-ins répétés avec les mêmes métadonnées peuvent ne pas modifier la ligne ou son heure de dernière mise à jour.

Les MAU comptent les appareils actifs distincts durant la période de facturation. Cette activité peut augmenter même si les métadonnées de l'appareil restent identiques, d'où la différence possible entre le nombre d'appareils et les MAU.

Comment avoir des mises à jour différentes par plateforme ?

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

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

Ensuite, envoyez un bundle sur chaque canal pour avoir une mise à jour différente par plateforme.

Si vous souhaitez la même mise à jour pour les deux plateformes, vous pouvez lier un bundle à plusieurs canaux sans avoir à le dupliquer.

Continuer la FAQ

Si vous utilisez FAQ pour planifier la livraison de live update, connectez-l’à Capgo Live Updates pour le workflow produit dans Capgo Live Updates, Aperçu pour les détails d'implémentation dans Vue d'ensemble, Fonctionnalités pour le détail d’implémentation dans Fonctionnalités, Comportement de mise à jour pour les détails d'implémentation dans Update Behavior, et Types de mise à jour pour les détails d'implémentation dans Update Types.