FAQ

Si vous avez des questions non répondues ici, veuillez demander ! Les deux, ouvrir une issue 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 de Capacitor de déployer des mises à jour dans leurs applications en production. Capgo fonctionne actuellement sur Android, iOS et Electron.

« Code Push » est une référence au nom d'une fonction de déploiement utilisée par la communauté React Native depuis Microsoft et Expo, neither of which support 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 fichier binaire pour les magasins d'applications. Pour générer ultérieurement un bundle Capgo doit connaître le fichier 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 nouveaux 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.

Y-a-t-il des limitations de chemins de fichiers pour les fichiers de mise à jour Delta ?

Oui :

• Fichiers de zéro octets : Les journaux CLI Ignoring empty file... et exclut les fichiers vides du manifeste Delta. Il ne fait pas fail l'envoi, donc un fichier vide peut modifier le paquet résultant sans arrêter votre déploiement. N'incluez pas les fichiers de zéro octets dans les chemins du paquet Delta.
• Chemins contenant des espaces : Les téléchargements Delta échouent tôt avec un erreur claire lorsque un chemin de paquet contient un espace. Renommez les fichiers ou les dossiers pour supprimer les espaces avant de télécharger une mise à jour Delta.

Voir Mises à jour Delta pour les détails de configuration.

Quel est le plan de route ?

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 feuille de route ou nos priorités via les Github issues ou Discord.

Puis-je utiliser Capgo avec mon équipe ?

Voir

Équipes pour plus d'informations. Le __CAPGO_KEEP_0__ stocke-t-il mon code source __CAPGO_KEEP_1__ ?

Does Capgo store my source code?

Non. Les serveurs Capgo ne voient jamais votre source code. Lorsque vous exécutez npx @capgo/cli@latest bundle upload, Capgo stocke un fichier zip du code minifié/compilé - le même code qu'un navigateur recevrait, pas 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 déployé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 n'envoyez à Capgo que le lien de téléchargement avec l'option --external <url>

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

Sont les fichiers de bundle des données privées ?

Non. Les fichiers du bundle sont des actifs web publics destinés à être téléchargés par vos utilisateurs d'applications. 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 du 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'applications. Si vous avez besoin d'une confidentialité plus forte pour des cas d'utilisation de haute sécurité, utilisez la cryptage de bout en bout, mais traitez toujours les applications code et les actifs embarqués comme publics d'un point de vue de la sécurité des rapports.

Puis-je utiliser Capgo à partir de mon système CI?

Oui. Capgo est destiné à être utilisé à partir de systèmes CI. Nous avons publié une guide pour Android et les actions Github et iOS, et 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 l'appareil. 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 de la bibliothèque de dépendances ?

Je n'ai pas mesuré récemment, mais je pense que la bibliothèque de push code ajoutera moins d'un mégabyte aux applications Capacitor. Nous connaissons des moyens de la rendre plus petite lorsque cela devient une priorité. Si la taille constitue un obstacle pour vous, veuillez nous en informer !

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

Non. En raison d'un problème upstream affectant le simulateur iOS 18.4, 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

code push fonctionne-t-il avec des applications de grande taille?

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

À noter : une taille plus importante rend-il plus difficile pour les utilisateurs de télécharger les mises à jour. Nous recommandons de garder votre application aussi petite que possible.

What can I use Capgo code for?

On a vu diverses 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. Voir ci-dessous pour plus d'informations. Qu'est-ce qui compte comme un 'MAU' pour __CAPGO_KEEP_0__? Lien direct vers 'Qu'est-ce qui compte comme un 'MAU' pour __CAPGO_KEEP_0__?'

Lien direct vers 'Qu'est-ce qui compte comme un 'MAU' pour Capgo?'

Un MAU est un appareil actif mensuel. Un appareil distinct qui contacte Capgo au cours d'une période de 30 jours roulante compte comme un MAU pour cet ID d'application native. Le même appareil physique utilisé avec deux ID d'application native distincts compte une fois pour chaque ID d'application ; il n'est pas dédupliqué entre eux.

Si vos saveurs diffèrent uniquement par leur couche web ou leur mise à jour de routage, utilisez un ID d'application native avec canaux. Cela garde les saveurs sous une seule application Capgo et simplifie les mises à jour. Utilisez des ID d'application natives séparés lorsque une saveur nécessite un ID de bundle distinct, une identité de signature, un ensemble d'entitlements ou une liste de magasin.

Sur iOS, v7.25.0+ garde l'ID d'appareil aléatoire, scoping l'application, à travers les réinstallations normales en utilisant Keychain. Sur Android, utilisez v7.50.1+ (ou v5.50.1+ ] v6.50.1+ sur ces lignes de version); l'ID est restauré uniquement lorsque Android Backup/Restore conserve les préférences de l'application. Désactiver la sauvegarde, exclure ces préférences ou effacer les données de l'application génère un nouvel ID de appareil. Mettre à jour l'application ne crée pas de nouvel ID de appareil.

Pour les builds de test et de développement, désactivez la livraison de développement et d'émulateur sur les canaux de production. Cela contrôle la livraison, pas le MAU : un appareil peut toujours compter lorsqu'il contacte Capgo. Pour l'empêcher d'être utilisé en production, désactivez les mises à jour en direct et ne pas appeler les points de terminaison de production Capgo. Voir Testez les builds natifs sans mises à jour en direct pour les paramètres exacts.

Qu'est-ce que nous ne pouvons pas utiliser Capgo code push pour?

Capgo ne peut pas modifier les code natifs comme Java, Kotlin, Objective-C, Swift, les plugins natifs ou la configuration native. Ces modifications nécessitent une nouvelle version de l'application native. Pour le champ d'étude de la revue de l'application, voir Politiques d'App Store et Google Play.

Puis-je mettre à jour 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 regroupées dans cet output. Les modifications de capacitor.config.ts, la configuration des plugins natifs, l'installation ou la mise à jour de packages natifs et tout ce qui nécessite une mise à jour du 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 devez modifier votre Capacitor configuration, vous devez :

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

Capgo soumet-il les applications aux magasins pour moi ?

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

Voir Capgo Build et la référence de la configuration de build pour les options de flux de travail et de soumission de magasin.

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

Le mises à jour de Capgo (inclus dans votre application lorsque vous construisez votre application) cache le dernier bundle téléchargé dans le seul répertoire que capacitor autorise à charger code. Sur Android, cela se trouve 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 d'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 caches npm, 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. Code push est pour la production.

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

Code push est une fonctionnalité qui vous permet de modifier code sur l'appareil en production. Nous utiliserons une variété de techniques différentes pour rendre cela possible en fonction du plateau.

Quels types de modifications Capgo code push prennent en charge ?

Capgo peut modifier n'importe quel code JS dans votre application. Cela inclut les code de l'application et les code générés. Vous pouvez également mettre à jour les dépendances dans package.json tant qu'elles n'exigent pas de modifications natives de code.

Nous n'avons pas l'intention de soutenir la modification de code natives (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é les code natives car ils ne seront pas inclus dans le bundle.

Est-ce que cela prend en charge Web?

Le Code push 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, elle télécharge la dernière version du serveur si nécessaire.

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

Cela fonctionnera-t-il 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 toutefois pas encore mis en place 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 ?

Capgo n'envoie des mises à jour que pour la couche web Capacitor : le HTML, le CSS, le JavaScript et les actifs déjà exécutés dans la vue WebView de l'application. Il ne change pas le code natif, les plugins natifs, les permissions, les droits, la signature ou les métadonnées de la boutique.

Utilisez une mise à jour native pour chaque changement natif et pour les changements matériels qui pourraient affecter la finalité ou la fonctionnalité de l'application examinée. Gardez les mises à jour en direct à l'intérieur de l'expérience de l'application soumise et divulguée aux utilisateurs.

Capgo garantit-il l'approbation de la boutique App Store ou Google Play ?

Non. Apple et Google examinent chaque application et chaque mise à jour sur leurs propres faits, et Capgo ne peut pas garantir un résultat d'approbation ou de vérification individuel. Votre équipe reste responsable du contenu de l'application, des déclarations, de la portée des mises à jour et de la conformité aux politiques de la boutique actuelles.

Pour la planification de la revue et de la mise en ligne, lisez les politiques officielles directement : Directives de revue de l'App Store d'Apple et politique d'abus de dispositif et de réseau de Google Play.

Est-ce que je peux 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 ce que les urls peuvent être accessibles à partir du pays. Capgo utilise actuellement Cloudflare Cloud pour l'hébergement, y compris R2 Storage et les travailleurs Cloudflare.

Les URLs 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 l'outil de ligne de commande pour télécharger et télécharger le bundle npx @capgo/cli Si toutes ces URL sont accessibles depuis votre pays, alors __CAPGO_KEEP_0__ devrait fonctionner.

If all of those URLs are accessible from your country, then Capgo should work.

Peut-on héberger __CAPGO_KEEP_0__ soi-même ?

Lien direct vers Peut-on héberger Capgo soi-même ?

Yes. Enterprise supports licensed self-hosted Capgo deployments when you need to run the updater backend in your own infrastructure. See pour le modèle de déploiement et les points de terminaison. __CAPGO_KEEP_0__ nécessite-t-il l'internet pour fonctionner ?

code push nécessite-t-il l'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 tentera simplement de vérifier à nouveau la prochaine fois que l'application est lancée.

L'Capgo commandes de ligne de commande (par exemple, Capgo) nécessitent une connectivité réseau pour fonctionner. Si vous utilisez Capgo pour distribuer votre application, vous devriez 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.

Direct link à Qu'arrive-t-il si un utilisateur ne met pas à jour pendant longtemps et manque une mise à jour?

Notre mise en œuvre envoie toujours une mise à jour spécifiquement conçue pour le dispositif qui la demande, mettant ainsi à jour le demandeur à la dernière version disponible. Ainsi, si un utilisateur ne met pas à jour pendant un certain temps, il « manquera » 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 push. Capgo n’est pas une substitution pour Capacitor. Vous pouvez continuer à utiliser les outils Capacitor que vous connaissez et aimez.

Nous suivons la dernière version stable de Capacitor et mettons à jour notre plugin de push code pour qu’il fonctionne avec elle.

Quand se produisent les mises à jour ?

Par défaut, l’Capgo updater vérifie les mises à jour lors du démarrage de l’application. Il fonctionne sur un thread de fond et ne bloque pas le thread de l’interface utilisateur. Les mises à jour seront installées pendant que l’utilisateur utilise l’application et seront appliquées la prochaine fois que l’application sera redémarrée.

It est également possible de lancer le Capgo mis à jour manuellement à l'aide du @capgo/capacitor-updater package, par lequel il est possible de déclencher des mises à jour à tout moment, y compris via une notification push.

Le Capgo mis à jour est conçu de telle sorte que lorsque le réseau n'est pas disponible, ou le serveur est en panne ou inaccessible, l'application continuera à fonctionner normalement. Si vous décidez jamais 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.

Est-ce que j'ai besoin de garder mon app_id secret?

Non. Le app_id est inclus dans 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 accédant à cela.

Qui a votre app_id peut récupérer la dernière version de votre application à partir des serveurs Capgo, mais ils ne peuvent pas envoyer de mises à jour à votre application ou accéder à tout autre aspect de votre compte Capgo.

Quelle information est envoyée aux serveurs Capgo?

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

Définir statsUrl: '' pour désactiver les rapports de statistiques de mise à jour explicites. Vous pouvez également envoyer statsUrl à un proxy ou un point de terminaison que vous contrôlez ; voir la gestion des statistiques dans l'infrastructure auto-hébergée. Update checks still need an app-scoped device identifier so Capgo can select the correct update and measure monthly active devices.

La liste des sous-traitants est notre source de vérité publique à jour pour les fournisseurs, les emplacements de traitement, les mécanismes de transfert et l'historique des modifications. Compliance

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

Oui, mais votre propriétaire de conformité doit choisir le bon modèle de déploiement. Le Capgo Cloud n'est pas actuellement présenté comme un processeur de statistiques hébergé conforme à HIPAA. Par défaut, les données de mise à jour sont scoping de l'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 géolocaliser le trafic du plugin, désactiver les statistiques en définissant __CAPGO_KEEP_0__ à une chaîne vide, héberger uniquement l'endpoint de statistiques ou utiliser un hébergement autonome sous licence. N'appellez pas __CAPGO_KEEP_0__ avec un adresse e-mail, un ID d'utilisateur, un ID de patient, un ID d'employé ou toute valeur qui remapperait la télémétrie de mise à jour vers une personne. statsUrl Voir la page « Conformité HIPAA » pour la configuration technique complète et les compromis d'observabilité lorsque les statistiques sont désactivées. CapacitorUpdater.setCustomId(...) Puis-je conserver les données de mise à jour __CAPGO_KEEP_0__ en Europe ?

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

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

Oui. Les applications nécessitant une résidence des données en 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 vérifications de mise à jour, les statistiques et l'auto-assignation 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 nécessitent une mise en production native avant les installations existantes utilisent les nouveaux points de terminaison.

Voir L'emplacement des données pour les exemples exacts de Capacitor et Electron.

Quels plateformes Capgo supporte-t-il ?

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 des décisions independantes. Vous pouvez définir votre stratégie de canal pour Android et un ipa construit pour l'App Store, ou les canaux Electron, selon vos besoins.

Capgo peut (relativement facilement) être conçu pour supporter les cibles de bureau ou embarquées. Si celles-ci sont importantes pour vous, veuillez nous le faire savoir.

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 les applications à des groupes limités d'utilisateurs (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 les 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 nous 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 bundle Capgo, 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 participer, 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 (de même que les pistes d'essai ou TestFlight, mais sans dépendre d'une plateforme spécifique). Cela permet à votre équipe de test de s'opter pour le bundle avant qu'il ne soit promu au public général.
4. Utilisez les lancements progressifs pour livrer un bundle candidat à un sous-ensemble aléatoire et collant d'un canal. Définissez un lancement de 0 à 100 %, ou utilisez --rollout-percentage-bps pour des increments de 0,01 % ; configurez la durée de cache de 60 secondes à 365 jours et une politique d'arrêt automatique facultative. Cela ne sélectionne pas un groupe de dispositifs nommé.

Facturation

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

Vous pouvez mettre à niveau ou réduire 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 le mois où vous avez souscrit à Capgo. Par exemple, si vous vous êtes abonné 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/paramètres/de l'entreprise/abonnements

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

Oui. Vous pouvez choisir un facturation annuelle dans vos paramètres de plan d'entreprise.

Qu'est-ce qui compte envers le stockage, et pouvons-nous changer la rétention?

Le stockage comprend les versions historiques retenues et leurs actifs Delta sur tous vos canaux. Vous contrôlez la rétention des versions inutilisées pour chaque application dans les paramètres de l'application. Les versions liées à un canal actif ou à une mise en production restent protégées afin de rester disponibles pour la livraison et le rollback.

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

No. A bundle is counted once for storage, regardless of the regions serving it. Capgo bandwidth is based on device downloads that are not served from the edge cache; cache-served deliveries do not count against Capgo bandwidth usage.

__CAPGO_KEEP_0__ bande passante est basé sur les téléchargements de dispositifs qui ne sont pas servis à partir du cache de bordure ; les livraisons servies par le cache ne comptent pas contre la consommation de bande passante __CAPGO_KEEP_1__.

Section intitulée « Qu'est-ce que l'Enterprise SLA inclut ? » L'Enterprise inclut un engagement mensuel de disponibilité de 99,9 % pour la plateforme de production. Si cet engagement est manqué, le calendrier de crédit de service est de 10 % à 30 % en fonction de la disponibilité mensuelle. Les objectifs initiaux de réponse au support sont P1 : une heure, 24/7/365 ; P2 : deux heures de travail ; P3 : un jour de travail ; et P4 : deux jours de travail. Lisez le SLA Enterprise

pour les termes complets.

Section intitulée « Statistiques et analyses » Utilisateurs actifs actif pendant la période de 30 jours en cours.

Comment est généré l'ID du dispositif

L'ID du dispositif est généré sur le dispositif 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 MAU est une meilleure solution que le nombre d'installations pour tarifer Capgo, car il est plus précis et reflète le coût réel de Capgo par appareil.

Persistance de l'ID du dispositif :

• iOSÀ partir de v7.25.0+, l'ID du dispositif est stocké dans Keychain et persiste à travers les réinstallations normales.
• AndroidUtilisez v7.50.1+ (ou v5.50.1+/v6.50.1+ sur ces lignes de version). L'ID du dispositif est restauré uniquement lorsque Android Backup/Restore conserve les préférences de l'application.
• ElectronL'ID du dispositif est stocké dans un stockage sécurisé.
• Avertissement Android : La désactivation de la sauvegarde, l'exclusion des préférences pertinentes ou la suppression des données de l'application génère un nouvel ID de dispositif. Les versions Android de 7.25.0 à 7.50.0 peuvent générer un nouvel ID de dispositif après un réinstall even lorsque la sauvegarde est activée.

L'ID du dispositif est scoping d'application et prend en charge la livraison mise à jour en direct et la déduplication MAU ; il ne s'agit pas d'un identifiant de suivi publicitaire ou transversal d'application.

Les ID de dispositif sont listés après que l'application se connecte à Capgo via les points de terminaison de mise à jour ou de statistiques. Un appareil n'a pas besoin d'installer une mise à jour avant de pouvoir apparaître dans la liste des appareils.

Pourquoi mon numéro de dispositif est différent de mon MAU ?

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

La liste des appareils affiche les métadonnées les plus récentes pour chaque appareil, telles que l'ID du dispositif, la plateforme, la version du plugin, la version du système d'exploitation, la version native, le canal, le paquet installé et le pays de demande lorsque disponible. Le pays de demande est le dernier code à deux lettres code valide reçu d'une Cloudflare-traitée pour cet appareil, et non la localisation GPS ou fournie par l'application. Les demandes sans un pays valide ne suppriment pas la dernière valeur valide. Capgo met à jour ces métadonnées lors de la connexion de l'application, mais les connexions répétées qui signalent les mêmes métadonnées peuvent ne pas modifier la ligne ou sa date de mise à jour la plus récente.

Le comptage MAU compte 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 le MAU peuvent être différents.

Comment avoir des mises à jour différentes 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.

Puis télécharger un bundle pour chaque canal pour avoir des mises à jour différentes 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 de la 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, Vue d'ensemble pour les détails d'implémentation dans Vue d'ensemble, Caractéristiques pour les détails d'implémentation dans Caractéristiques, Comportement de mise à jour pour les détails d'implémentation dans Comportement de mise à jour, et Types de mise à jour pour les détails d'implémentation dans Types de mise à jour.