FAQ

Si vous avez une question qui n’est pas couverte ici, posez-la. Vous pouvez ouvrir une issue ou demander de l’aide sur Discord.

Qu’est-ce que « code push » ?

Le code push, aussi appelé mises à jour OTA (over-the-air), est un service cloud qui permet aux développeurs Capacitor de déployer des mises à jour en production sans repasser par les stores. Capgo fonctionne aujourd’hui sur Android et iOS, et a vocation à fonctionner partout où Capacitor est supporté.

L’expression « code push » fait référence à une fonctionnalité historiquement utilisée dans l’écosystème React Native, notamment via Microsoft et Expo, mais ces solutions ne prennent pas en charge Capacitor.

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

Par « release », nous entendons la préparation d’un binaire destiné aux stores d’applications. Pour générer un bundle compatible ensuite, Capgo doit connaître précisément le binaire qui a été publié.

Par « bundle », nous entendons un patch appliqué à une release existante pour la mettre à jour avec du nouveau code. La commande npx @capgo/cli@latest bundle upload permet de générer un bundle depuis votre code local puis de le distribuer à vos utilisateurs.

Quelle est la roadmap ?

Nos tableaux de projet sont publics : https://github.com/orgs/Cap-go/projects

Nous travaillons également en public : vous pouvez voir sur quoi nous avançons à tout moment. Nous répondons volontiers à vos questions sur la roadmap et les priorités via les issues GitHub ou Discord.

Puis-je utiliser Capgo avec mon équipe ?

Oui. Tous les plans autorisent un nombre illimité de développeurs. Les limites portent uniquement sur les métriques de l’application (MAU, stockage, bande passante) par organisation.

Consultez Teams pour plus d’informations.

Does Capgo store my source code?

No. Capgo servers never see your source code. When you run npx @capgo/cli@latest bundle upload, Capgo stores a zip file of the minified/compiled code - the same code that a browser would receive, not your source code.

For additional Sécurité, you have two Options:

End-to-End Chiffrement: Encrypt your Bundle before uploading, making it impossible for Capgo to read or modify the contents
External URL Upload: Store the bundle on your own server and only provide Capgo with the download link with the option --external <url>

Voir aussi our privacy policy: https://capgo.app/privacy

Can I use Capgo from my CI system?

Yes. Capgo is intended to be used from CI systems. We’ve published a Guide for Android and Github Actions and iOS, and for GitLab. Other CI systems should be similar.

Please don’t hesitate to reach out over GitHub issues or Discord if you encounter any issues.

How does this relate to Firebase Remote Config or Launch Darkly?

Code Pousser allows adding Nouveau code / replacing code on the Appareil. Firebase Remote Config and Launch Darkly are both Configuration systems. They allow you to change the Configuration of your Application without having to ship a Nouveau Version. They are not intended to replace code.

How big of a dependency footprint does this Ajouter?

I haven’t measured recently, but I expect the code Pousser library to Ajouter less than one megabyte to Capacitor apps. We know of ways we can make this smaller when that becomes a priority. If size is a blocker for you, please let us know!

Does Capgo work on the iOS 18.4 Simulator?

No. Due to an upstream Problème affecting the iOS 18.4 Simulator, Capgo does not run reliably there. Please Test on a real Appareil or use a different iOS simulator Version.

See details in the React Natif Problème: facebook/react-Natif#50510

Does code Pousser work with large applications?

Yes. There is no limit on the size of the Application that can be updated with code Pousser. As noted below, Capgo can change any JS code in your Application regardless of size.

To Remarque: A bigger size make it harder for Utilisateurs to Télécharger Mises à jour. We recommend keeping your Application as small as possible.

What can I use Capgo code Pousser for?

We’ve seen a variety of uses, including:

Emergency fixes to Production apps.
Shipping bug fixes to Utilisateurs on older versions of your Application.
Shipping constantly (e.g. every hour).

Remarque that most Application stores prohibit shipping code that changes the behavior of the Application in a significant way. Please see below for more Information.

What counts as a “MAU” for Capgo?

A MAU is a “Monthly Actif Utilisateur”. In Capgo’s context, this actually refers to a Monthly Actif Appareil. We count a MAU as any Appareil that has contacted our servers in the last 30 days. We do not count Appareils that have not contacted our servers in the last 30 days.

Important: Starting from plugin version v5.10.0, v6.25.0 and v7.25.0, the deviceID now persists across app reinstalls. Before these versions, each app reinstall would generate a new deviceID and count as a new MAU.

With the current versions:

DeviceID persists across Application reinstalls (stored securely in Keychain on iOS and EncryptedSharedPreferences on Android)
Updating the Application does not Créer a Nouveau Appareil ID
During Développement, if you’re using an older plugin Version (< v5.10.0 / v6.25.0 / v7.25.0), each reinstall still creates a Nouveau MAU

Remarque: TestFlight downloads and Canal switches in Android may still generate Nouveau Appareil registrations depending on your Configuration.

We recommend after first Configuration, to Désactiver dev Appareils and emulators to reduce the amount of duplicated Appareils.

What can’t we use Capgo code Pousser for?

As above, Capgo should not be used to violate Application Store polices. Please see below for more Information.

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

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

Non. Les modifications de capacitor.config.ts ne peuvent pas être envoyées via les mises à jour en direct de Capgo. Le fichier de configuration Capacitor est lu au moment de la compilation native et compilé dans le binaire de l’application native. Cela signifie que toute modification de capacitor.config.ts (comme les configurations de plugins, l’ID de l’application, les paramètres du serveur ou les options de plugins natifs) nécessite une nouvelle version native via l’App Store ou Google Play.

Capgo ne peut mettre à jour que les ressources web (HTML, CSS, JavaScript) qui sont chargées au moment de l’exécution. Si vous devez modifier votre configuration Capacitor, vous devez :

Mettre à jour capacitor.config.ts localement
Reconstruire votre application native (npx cap sync suivi d’une compilation native)
Soumettre le nouveau binaire aux stores d’applications

Does Capgo Soumettre to the stores for me?

Capgo does not currently Support submitting to the Application stores on your behalf. We have plans to Ajouter this in the future, but for now you will need to continue to use your existing processes to Soumettre to the Application stores.

You can use our CI Guide Android to automate this process and CI Guide iOS.

What does Capgo store on disk and where?

The Capgo updater (included in your application when you build your app) caches the latest downloaded bundle in the only directory that capacitor allow to load code. On Android, this is located in /data/user/0/com.example.app/code_cache/capgo_updater although the base of that path is provided by the Android system and can change dynamically at runtime. On iOS devices, data is stored under Library/Application Support/capgo.

The Capgo command line tools (e.g. npx @capgo/cli@latest bundle upload) are installed on disk in npm caches, your logins are stored in your home directory in ~/.capgo.

How does this relate to Capacitor Hot Reload?

Capacitor’s Hot reload is a Développement-time-only Fonctionnalité. Code Pousser is for Production.

Hot reload is a Fonctionnalité of Capacitor that allows you to change code on the Appareil during Développement. It requires Construction the Capacitor Application with a proxy to connect to your local machine.

Code Pousser is a Fonctionnalité that allows you to change code on the Appareil in Production. We will use a variety of different techniques to make this possible depending on the platform.

What types of changes does Capgo code Pousser Support?

Capgo can change any JS code in your application. This includes app code and generated code. You can also update dependencies in package.json as long as they don’t require native code changes.

We do not have plans to Support changing Natif code (e.g. Java/Kotlin on Android or Objective-C/Swift on iOS), and the tool will warn you if it detects that you have changed Natif code as it will not be included in the Bundle.

Does this Support Web?

Code Pousser isn’t needed for web as the web already works this way. When a Utilisateur opens a web Application it downloads the latest Version from the server if needed.

If you have a use case for code Pousser with web, we’d love to know!

Will this work on iOS, Android, Mac, Windows, Linux, etc?

Yes.

So far we’ve focused on Android and iOS Support, but code Pousser will eventually work everywhere Capacitor works. We’re ensuring we’ve built all the infrastructure needed to provide code Pousser reliably and safely before expanding to more platforms.

What OS versions does Capgo Support?

Capgo supports the same versions of Android that Capacitor supports.

Capacitor currently supports Android API level 22+ and iOS 13.0+: https://capacitorjs.com/docs/main/Référence/Support-policy

What versions of Capacitor does Capgo Support?

Capgo currently supports only recent Stable releases of Capacitor. We could Support older versions of Capacitor as well, we just haven’t built out the infrastructure necessary to maintain such over time. We intend to Support more versions of Capacitor in the future, including any Version for our Entreprise customers. https://github.com/Cap-go/capgo/issues/1100

Capgo tracks Capacitor Stable and generally Mises à jour within a few hours of any Stable Libération. Our system for doing these Mises à jour is automated takes a few minutes to run. We then do an extra manual verification step before publishing to our servers.

How does this relate to the Application/Play Store review process or policies?

Developers are bound by their agreements with store providers when they choose to use those stores. Code Pousser is designed to allow developers to Mise à jour their apps and still comply with store policies on iOS and Android. Similar to the variety of commercial products Disponible to do so with React Natif (e.g. Microsoft, Expo).

Microsoft also publishes a Guide on how their Solution complies with the Application stores: https://github.com/microsoft/react-Natif-code-Pousser#store-guideline-compliance

Code Pousser is a widely used technique throughout the Application stores. All of the large apps I’m aware of use code Pousser. The major policy to be aware of is not to change the behavior of the Application in a significant way. Please see below for more Information.

Does Capgo comply with Play Store guidelines?

Yes.

The Play Store offers two restrictions relating to Mise à jour tools.

Mises à jour must use an interpreter or virtual machine (Capgo uses JavaScript in a 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.

Changes to the Application must not be deceptive (e.g. changing the purpose of the Application via Mise à jour). https://Support.google.com/googleplay/Android-developer/answer/9888077 Please be clear with your Utilisateurs À propos what you are providing with your Application and do not violate their expectations with significant behavioral changes through the use of Capgo.

Capgo is designed to be compatible with the Play Store guidelines. However Capgo is a tool, and as with any tool, can be abused. Deliberately abusing Capgo to violate Play Store guidelines is in violation of the Capgo Terms of Service and can result in termination of your Compte.

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

Microsoft also publishes a Guide on how their react Natif “codepush” library complies with the Application stores: https://github.com/microsoft/react-Natif-code-Pousser#store-guideline-compliance

Does Capgo comply with Application Store guidelines?

Yes.

Similar to the Play Store, the Application Store offers both technical and policy restrictions.

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 uses JavaScript in a WebView to comply with the interpreter-only restriction for Mises à jour on iOS. So long as your Application is not engaging in deceptive behavior via Mises à jour (e.g. changing the purpose of the Application via Mise à jour), updating via Capgo (or any other code Pousser Solution) is standard industry practice and compliant with Application Store guidelines.

Deliberately abusing Capgo to violate Application Store guidelines is in violation of the Capgo Terms of Service and can result in termination of your Compte.

Microsoft also publishes a Guide on how their react Natif “codepush” library complies with the Application stores: https://github.com/microsoft/react-Natif-code-Pousser#store-guideline-compliance

Can I use Capgo in my country?

We have not attempted to restrict access to Capgo from any country.

We recognize that some countries have restrictions on what urls can be accessed from within the country. Capgo currently uses Cloudflare Cloud for hosting, including R2 Storage and Cloudflare workers.

The following URLs are used by Capgo:

https://api.capgo.app — used by the npx @capgo/cli command line tools to interact with the Capgo servers as well as the Capgo updater on users’ devices to check for updates.
https://*.r2.cloudflarestorage.com — used by the npx @capgo/cli command line tool to upload and download bundle

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

If your region requires blocking access to any of those URLs, please let us know and we can work with you to find a Solution. Proxy servers are one Option.

Can I self-host Capgo?

Yes, you can self-host Capgo. The Guide is not yet written, but the code is open source and Disponible at https://github.com/cap-go/capgo

Does code Pousser require the internet to work?

Yes. One could imagine running a server to distribute the Mises à jour separately from the general internet, but some form of network connectivity is required to transport Mises à jour to the Appareils.

How is Capgo affected by lack of network connectivity?

Capgo updater (included in your Application when you Construction your Application with Capgo) is designed to be resilient to network connectivity issues.

In the default Mise à jour behavior, when the Application launches it alerts the Capgo updater, which spawns a separate thread to make a network request to Capgo’s servers and ask for an Mise à jour. We intentionally use a separate thread to avoid affecting blocking anything else the Application might be doing. If the network request fails or times out, the updater will simply try to Vérifier again Suivant time the Application launches.

Capgo command line tools (e.g. 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 Utilisateur doesn’t Mise à jour for a long time and misses an Mise à jour?

Our implementation always sends an Mise à jour specifically tailored for the Appareil that is requesting it updating the requestor always to the latest Version Disponible. Thus if a Utilisateur doesn’t Mise à jour for a while they will “miss” intermediate Mises à jour.

The Mise à jour server could be changed to Support responding with either the Suivant incremental Version or the latest Version depending on your Application’s needs. Please let us know if alternative Mise à jour behaviors are Important to you.

How does Capgo relate to Capacitor?

Capgo is a plugin for Capacitor that adds code Pousser. Capgo is not a replacement for Capacitor. You can continue to use the Capacitor tooling you already know and love.

We track the latest Stable Libération of Capacitor and Mise à jour our code Pousser plugin to work with it.

When do Mises à jour happen?

By default, the Capgo updater checks for Mises à jour on Application startup. It runs on a background thread and does not block the UI thread. Any Mises à jour will be installed while the Utilisateur is using the Application and will be applied the Suivant time the Application is restarted.

It is also possible to run the Capgo updater manually using the @capgo/capacitor-updater package, through which it is possible to trigger updates at any time, including via a push notification.

The Capgo updater is designed such that when the network is not Disponible, or the server is down or otherwise unreachable, the Application will continue to run as normal. Should you ever choose to Supprimer an Mise à jour from our servers, all your clients will continue to run as normal.

We have added the ability to Restauration patches. The simplest thing is to simply attach a Précédent Bundle to your Canal to undo.

Do I need to keep my Application_id secret?

No. The app_id is included in your app and is safe to be public. You can check it into version control (even publicly) and not worry about someone else accessing it.

Someone who has your app_id can fetch the latest version of your app from Capgo servers, but they cannot push updates to your app or access any other aspect of your Capgo account.

What Information is sent to Capgo servers?

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

Requests sent from the Application to Capgo servers include:

app_id (specified capacitor.config.json)
channel (optional in capacitor.config.json)
release_version (versionName from AndroidManifest.xml or CFBundleShortVersionString from Info.plist or capacitor.config.json if set in CapacitorUpdater.version)
version_number (generated as part of npx @capgo/cli@latest bundle upload)
os_version (e.g. ‘11.2.1’)
platform (e.g. ‘android’, needed to send down the right patch) That’s it. The code for this is in updater/library/src/network.rs
device_id (generated on the Appareil on first run, used to de-duplicate per-Appareil installs and allow us to charge based on Utilisateurs installed to (e.g. monthly Actif Utilisateurs), rather than total patches or total patch installs)
custom_id (optional, set at runtime by the developer, used for you to link a Appareil to a Utilisateur in your system)

What platforms does Capgo Support?

Currently, Capgo supports iOS and Android. Both are Production ready.

Use of Capgo for iOS or Android can be independent decisions. You can set in your Canal to ship to Android and an ipa built to the Application Store or vice versa.

Capgo can (relatively easily) be made to Support desktop or embedded targets. If those are Important to you, please let us know.

How does Capgo interact with Play Test Tracks or Apple TestFlight?

Each of the Application stores have separate mechanisms for distributing apps to limited groups of Utilisateurs (e.g. “internal Test”, “closed Bêta”, etc.). These are all mechanisms for segmenting your Utilisateurs into groups and distributing specific versions of your apps to each.

Unfortunately, these not all of these mechanisms allow 3rd parties to detect when apps are installed in any specific Test Track or via TestFlight. Thus, we do not have reliable visibility into composition of these groups, and cannot reliably gate access to Capgo patches based on these groups. 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-Application-is-running-through-a-testflight-Bêta-i

If you’d like to segment availability of Capgo Bundle, there are 4 potential Options:

Use separate Canal for each group. This is the most straightforward approach, but requires you to manage multiple Canaux. You may already have a dev Canaux and prod Canaux with different availability. You can thus Mise à jour your dev Canaux, verify it and then separately Mise à jour your prod Canaux. We recommend using branches / tags in your Version control to Aide keep track of the sources associated with each Libération.
Track your own set of opt-in users, disable automatic updates, and trigger updates only for certain users via the @capgo/capacitor-updater package. This works today, but requires you to manage your own opt-in list.
Capgo allow creare its own opt-in mechanism on a per-Appareil basis (similar to Test Tracks or TestFlight, just platform agnostic). This allow your QA team to opt-in to Bundle before they’re promoted to the general public.
Capgo have percentage based rollouts. This does not let you choose which Appareils to send to, but can Aide you roll out incrementally and roll-Retour on sight of any problems.

Billing

How do I Mise à niveau or downgrade my plan?

You can Mise à niveau or downgrade your plan at any time in your Tableau de bord: https://console.capgo.app/Paramètres/Organisation/plans

When does my billing period Réinitialiser?

Billing periods are Réinitialiser automatically every month on the month you first subscribed to Capgo. For Exemple, if you subscribed on the 15th of the month, your billing period will Réinitialiser on the 15th of every month.

How do I Annuler my subscription?

You can Annuler your subscription at any time in your Tableau de bord: https://console.capgo.app/Paramètres/Organisation/plans

Can I pay for a year in advance?

Yes you can can at any time in your Tableau de bord: https://console.capgo.app/Paramètres/Organisation/plans

Stats and Analyse

The stats in your Tableau de bord are updated every midnight UTC. The stats are calculated based on the number of MAU that have been installed on your Appareils.

How Appareil ID is generated

The Appareil ID is generated on the Appareil on first run, and is used to de-duplicate per-Appareil installs and allow us to charge based on Utilisateurs installed to (e.g. monthly Actif Utilisateurs), rather than total patches or total patch installs.

MAU is a better Solution than number of installs to price Capgo, as it is more accurate and reflects the actual cost of Capgo per Appareil.

DeviceID Persistence (Updated in v6.25.0 and v7.25.0):

Current behavior: The deviceID now persists across Application reinstalls. It is stored securely in the Appareil’s Keychain (iOS) or EncryptedSharedPreferences (Android), allowing us to track the same Appareil even after uninstall/reinstall.
Précédent behavior (before v6.25.0/v7.25.0): For privacy reasons related to Apple and Google store policies, the deviceID was Réinitialiser on each Application reinstall, making it impossible to track the same Appareil across reinstalls.

The privacy rules are enforced by Apple and Google, and Capgo’s implementation complies with their best practices for Appareil identification.

Appareil ID will not be listed in your Appareil list until they get their first patch installed.

Why my Appareil number is different than my MAU?

Currently, the Appareil list is not updated as often as the MAU.

The Appareil list is updated only when a Appareil installs an Mise à jour.

While the MAU is updated at every Application launch. This is a current limitation of the platform. Our Analyse platform do not Support raw Mises à jour so we use conventional database for Appareils list.

To limit the number of database queries, we do Mise à jour row only on Application Mise à jour.

This limitation will be removed in the future.

How to have different Mise à jour by platform?

You can Créer a Canal for each platform. and Désactiver platform specific Mises à jour in each Canal.

On iOS Canal Désactiver Android Mises à jour and on Android Canal Désactiver iOS Mises à jour.

Then Télécharger a Bundle to each Canal to have different Mise à jour for each platform.

If you need to have the same Mise à jour for both platform, you can link one Bundle to multiple Canaux. No need to duplicate the Bundle.