Over-the-Air App Updates SaaS: How-To

Les mises à jour OTA peuvent corriger les bogues JavaScript, HTML, CSS et de ressources sans attendre une nouvelle mise à jour de l'application. Mais la plateforme que vous choisissez doit gérer plus que l'upload et le download. J'utilise cinq vérifications : Capacitor convient, champ d'actualisation, contrôle de déploiement, sécurité de retrait et accès CI/CD.

Capgo est un bon point de départ car son flux de mise à jour en temps réel couvre Mises à jour différentielles, canaux, retrait automatique et appels de pipeline. Les étapes ci-dessous montrent comment tester l'adaptabilité avant de mettre un système OTA en production.

Nous avons examiné les pages de documentation publique de cinq services de mise à jour OTA le 22 août 2026, y compris Ionic Appflow, Expo EAS Update, Shorebird et Microsoft App Center CodePush. Seuls 2 des 4 services encore actifs, Expo EAS Update et Shorebird, décrivent les étapes de retrait sur leurs propres pages de documentation. Seul 1, Shorebird, documente un chemin de mise à jour différentielle, et Microsoft App Center CodePush, une fois un choix commun, a été complètement retiré le 31 mars 2025. Vérifier les détails de retrait, de canal et d'étendue d'actualisation avant l'adoption permet de détecter les lacunes que les pages de la page d'accueil d'un fournisseur ne montreront pas.

Table des matières

• Capgo
• Étape 2 : Vérifiez l'adaptabilité, la sécurité et le périmètre de mise à jour
• Step 3: Connect the SaaS to Your Capacitor App
• Étape 4 : Créez des canaux pour des déploiements sécurisés et étalés
• Étape 5 : Automatiser les Retraites et Surveiller la Santé des Mises à Jour
• Étape 6 : Ajoutez les déploiements OTA à votre pipeline CI/CD
• FAQ
• Conclusion

1. Capgo

Capgo is a live-update SaaS for Ionic and Capacitor apps. It lets teams send web-layer changes over the air while keeping native changes in a normal app-store build.

La page officielle de Capgo describes the service as a way to manage and deploy OTA updates for Capacitor apps. That focus matters. A team that already has native builds in place may want a focused release layer instead of a large mobile platform.

Principale Raison à Retenir : Pick a platform that matches your app stack first. A long feature list can’t fix a poor Capacitor integration.

Start with a small test app. Add the Capgo plugin, build a known version, then publish one harmless text or style change. Check the full path:

• L'application vérifie une nouvelle mise à jour.
• Le bundle se télécharge par le canal prévu.
• La mise à jour est appliquée après le déclencheur approprié.
• Le bundle ancien reste disponible si le nouveau échoue.

Ensuite, testez une mise à jour différentielle. L'idée est d'envoyer que les parties modifiées d'un bundle lorsque le plateforme le supporte. Des transferts plus petits sont utiles lorsque les utilisateurs dépendent de données mobiles ou travaillent dans des endroits avec des liens faibles.

Capgo utilise également les canaux pour le contrôle des versions. Vous pouvez garder le développement, la mise en scène, la bêta et la production séparés. Cela donne à votre équipe de publication un endroit sûr pour tester un bundle avant que tous les utilisateurs ne le voient.

La tarification doit être vérifiée comme une souscription par organisation. Capgo fournit un essai gratuit de 14 jours, utilisez donc cette fenêtre pour tester votre propre application, votre flux de mise à jour et l'accès de votre équipe. N'avez pas jugé un service OTA à partir d'un bundle de démonstration seul. Testez le cas embarrassant, comme un téléchargement échoué ou une mauvaise route après une mise à jour.

Pour les équipes remplaçant un flux de publication CodePush, cartographiez les anciens habitudes de publication à un ensemble actuel avec un checklist de migration: révisez ce guide.

À la fin de cette étape, vous devriez avoir un concept de preuve de fonctionnement et une liste de lacunes. Si l'application ne peut pas se rétablir proprement en test, arrêtez-vous là. N'importez pas un chemin de mise à jour fragile en production.

Étape 2 : Vérifiez l'adaptabilité, la sécurité et la portée des mises à jour

La bonne mise à jour OTA SaaS doit s'adapter à code que vous prévoyez de livrer. OTA s'applique généralement à la couche web à l'intérieur d'une application Capacitor. Cela ne remplace pas une mise en production native lorsque vous modifiez la code native.

Ecrivez les types d'actualisations que votre équipe s'attend à publier. Placez chaque un dans une table de décision simple avant de comparer les fournisseurs.

Vérifiez maintenant la sécurité. Exigez des ensembles signés afin que l'application puisse vérifier que la mise à jour provient de votre chemin de déploiement fiable. Utilisez un transport chiffré. Limitez qui peut publier en production. Gardez un enregistrement de qui a approuvé chaque mise à jour.

Demandez où les clés résident et qui peut les faire tourner. Un compte partagé d'équipe rend les audits difficiles. Séparez les accès pour les développeurs, les gestionnaires de mise à jour et l'automatisation. Si un jeton CI est volé, annulez-le sans mettre en panne l'application entière.

La sécurité englobe également ce qui se passe sur le dispositif. L'application doit vérifier le paquet avant d'appliquer la mise à jour. Elle doit conserver une version connue bonne. Elle doit se fermer en cas de paquet corrompu ou incompatibles.

Les données de marché fournies pour cette évaluation indiquent un manque de suivi. Les analyses en temps réel ne sont apparues que dans 45% des outils étudiés. Cela signifie que vous ne devez pas supposer qu'un tableau de bord existe simplement parce que un fournisseur dit qu'il prend en charge les mises à jour en temps réel.

Demandez des questions spécifiques :

• Puis-je voir l'adoption par version d'app ?
• Peut-on filtrer les résultats par canal ?
• Peut-on détecter les téléchargements échoués ?
• Peut-on voir les appareils qui sont restés sur l'ancien ensemble ?
• Peut-on faire arrêter l'automatisation après un seuil d'erreur ?

Use a deeper release checklist when you set your rules. Treat security as part of release design, not as a final checkbox.

Vous devriez maintenant savoir quelles mises à jour appartiennent à OTA et lesquelles nécessitent une mise à jour de l'application. Cette frontière empêche de nombreux déploiements échoués.

Étape 3 : Connectez votre application Capacitor à votre SaaS

Connectez ensuite le service d'actualisation à une build propre Capacitor. L'objectif est d'obtenir une installation réplicable que chaque développeur et exécuteur CI peuvent reproduire.

Start in a test branch. Install the vendor package with your normal package manager, then sync the Capacitor project. Build the app for each target you support. Keep the native build unchanged while you test the web bundle path.

Connectez ensuite le service de mise à jour à une build __CAPGO_KEEP_0__ propre. L'objectif est d'obtenir une installation réplicable que chaque développeur et chaque exécuteur CI peuvent reproduire.

Commencez dans une branch de test. Installez le package de fournisseur avec votre gestionnaire de package normal, puis synchronisez le projet __CAPGO_KEEP_0__. Construisez l'application pour chaque cible que vous supportez. Gardez la build native inchangée pendant que vous testez le chemin de la bundle web.

Then install the build on a real device. Emulators help with basic checks, but they won’t show every network, storage, or resume behavior. Test these paths:

• Installation fraîche sans bundle précédent.
• Mise à jour depuis la version d'application précédente.
• Téléchargez en utilisant une connexion lente.
• Installation fraîche sans bundle précédent.
• App restart after a failed update.

Vérifiez également les rapports de version. La version de l'application native et la version du bundle OTA sont des valeurs différentes. Votre équipe de support a besoin des deux lorsque l'utilisateur signale un écran brisé.

Un bon plan de nommage facilite cela. Utilisez une étiquette de bundle lisible, un commit de build et une note de version qui indique ce qui a changé. Évitez les étiquettes telles que « la dernière ». Elles perdent de leur sens dès que deux versions sont actives.

Maintenez les limites natives visibles dans le processus de version. Si une modification ajoute un plugin, modifie une autorisation ou change une configuration iOS ou Android, dirigez-la vers une version native. Le chemin OTA devrait rejeter cette modification ou exiger une revue explicite.

Vous devriez avoir un appareil recevant un bundle de test par le même chemin que votre équipe utilisera plus tard. L'étape suivante ajoute des garde-fous autour de ce chemin.

Étape 4 : Créez des canaux pour des déploiements sécurisés et étalés

Les canaux fournissent une carte de mise à jour des applications en ligne pour un SaaS. Utilisez-les pour déterminer quels lots d'applications reçoivent lesquels.

Créez au moins quatre canaux si votre équipe a des mises à jour régulières.

• Development: for active work and quick checks.
• Staging: pour les travaux actifs et les vérifications rapides .
• Étape bêta : pour un groupe d'utilisateurs contrôlés.
• Production : pour la large diffusion.

Gardez les règles de canal simples. Un appareil devrait avoir une affectation claire. Documentez qui peut promouvoir un bundle et quels preuves ils ont besoin en premier.

Commencez par un petit groupe bêta. Observez le succès de l'installation, les rapports de crash, le flux de connexion et les écrans modifiés par la mise à jour. N'allez pas promouvoir un bundle uniquement parce que le nombre de téléchargements semble sain. Un bundle peut télécharger correctement et toujours casser un chemin clé après le lancement.

Fixez une règle d'arrêt avant de publier. Par exemple, arrêtez la promotion lorsque l'équipe voit un nouveau erreur liée au bundle ou lorsque le support signale une tâche brisée. Le seuil exact appartient à votre application. L'important est que quelqu'un ait la permission d'arrêter le roulage.

Utilisez les notes de mise à jour qui nomment la modification visible par l'utilisateur. « Fixer la validation de la commande » est plus utile que « bundle 184 ». Reliez chaque mise à jour à un commit ou un ticket afin que l'équipe puisse suivre la modification ultérieurement.

Les canaux aident également avec le support. Si un utilisateur a un problème, vous pouvez voir si l'appareil est sur bêta ou production. Vous pouvez alors déplacer l'appareil vers un canal sûr pendant que l'équipe enquête.

Conseil Pro : Gardez un bundle stable en production jusqu'à ce que le nouveau bundle passe ses premières vérifications en direct. Un roulage rapide est utile uniquement lorsque vous pouvez l'arrêter.

La livraison basée sur les canaux n'apparaît que dans 55 % des plateformes étudiées. Vérifiez cette fonctionnalité avec une affectation réelle d'appareil, pas avec une diapositive de vente. À la fin de cette étape, vous devriez être capable de promouvoir, d'arrêter et de rediriger une mise à jour.

Étape 5 : Automatiser les Retraits et Surveiller la Santé des Mises à Jour

Le retour en arrière est l'échappatoire pour une mauvaise mise à jour OTA. Le bon SaaS devrait vous permettre de faire passer les utilisateurs vers une version connue sans avoir à reconstruire l'application native.

Premièrement, marquez la dernière version stable avant chaque déploiement. Conservez la référence de commit et les notes de version à côté du registre de déploiement. Si une incident se déclenche, le propriétaire de la version devrait connaître la version cible dans les minutes.

Ensuite, testez le retour en arrière avant de le nécessiter. Publiez une version de test avec une faute contrôlée dans un canal non-productif. Confirmez que le service peut arrêter le déploiement et pointer le canal vers la version stable. Fermez ensuite et rouvrez l'application sur un appareil de test.

Fixez des contrôles de santé autour de la mise à jour elle-même. Observez les échecs de téléchargement, la fin de la mise à jour, les erreurs de l'application et la part d'appareils qui restent sur la version ancienne. Un taux élevé de téléchargement ne prouve pas que l'écran mise à jour fonctionne.

Les analyses en temps réel sont moins courantes que les acheteurs le pensent souvent. La plateforme de revue fournie a trouvé 45 % d'entre elles dans les outils étudiés. Cette carence change le test d'achat : demandez de voir les données d'événement exactes dont vous avez besoin avant de vous inscrire.

Le coût peut également influencer la décision de retour en arrière. Certains services facturent les utilisateurs actifs mensuels ou la bande passante. D'autres utilisent un modèle de souscription par organisation. Comparez le facture à votre base d'installation attendue, puis ajoutez le coût du temps passé à construire les contrôles de surveillance ou de libération manquants.

Capgo supporte le retrait automatique dans la revue des fonctionnalités fournie. Utilisez cette fonctionnalité avec une politique de publication claire. L'automatisation peut ramener les utilisateurs à la sécurité, mais elle ne peut pas décider si une modification de produit est acceptable pour votre entreprise.

Pour les équipes pesant un service OTA ciblé par rapport à une plateforme de publication plus large. Capgo et comparaison de déploiement avec Appflow fournit un ensemble utile de questions autour de la portée et du flux de travail.

Conserver un humain dans la boucle pour les incidents graves. La mise à l'arrêt automatique devrait gérer un déclencheur connu. Le propriétaire de la mise à jour devrait toujours examiner les journaux, confirmer la correction et décider quand reprendre.

Suivre, adopter, annuler. Ces trois actions doivent être visibles pour la même équipe dans la même journée de travail.

Prêt à mettre fin aux déploiements manuels risqués ?

Étape 6 : Ajoutez les déploiements OTA à votre pipeline CI/CD

La CI/CD transforme la mise à jour OTA en une tâche manuelle en un job contrôlé. Votre pipeline doit construire la couche web, exécuter les vérifications, publier sur le bon canal et laisser un journal d'audit.

Commencez par une mise en route sèche. Laissez le pipeline empaqueter le bundle sans le publier. Vérifiez les fichiers générés, l'étiquette de version, le commit source et la valeur de canal. Cela permet de détecter les variables d'environnement incorrectes avant que l'utilisateur ne voie la mise à jour.

Ajoutez ensuite des barrières d'approbation. Le développement peut publier automatiquement. La mise en production peut nécessiter un résultat de test. La production doit exiger une approbation nommée à moins que votre équipe n'ait une raison forte de supprimer ce pas.

Stockez vos identifiants de déploiement dans des secrets protégés. N'enregistrez jamais dans le dépôt. Accordez au pipeline uniquement l'accès dont il a besoin pour son canal. Un jeton de production ne doit pas se trouver dans un job de demande de tirage qui s'exécute sur un code non fiable.

Utilisez la même commande localement et en CI. Cela réduit l'écart entre le bureau de développement d'un développeur et le lanceur de version. Cela rend également un job échoué plus facile à reproduire.

Les hooks CI/CD sont rares dans la revue de la plateforme fournie. Seuls 27 % des outils interrogés ont listé des intégrations de pipeline. Cette lacune peut coûter plus de temps qu'une absence de tableau de bord car chaque mise à jour devient un transfert manuel.

Choose the pipeline events that match your team:

• Demande de tirage : exécutez les tests et vérifiez le bundle.
• Fusionner vers une branche de publication : publier en préproduction.
• Tag approuvé : publiez sur la version bêta.
• Approuver la version : promouvez vers la production.

Appflow est construit autour d'une plateforme CI/CD plus large et de construction native. Ce modèle peut convenir à une équipe cherchant un système géré unique pour les constructions natives et les mises à jour en temps réel. Si vous utilisez déjà des GitHub Actions ou GitLab, comparez la valeur de la plateforme plus large avec le flux de travail OTA plus petit que vous avez besoin.

Faites échouer le job lorsque le bundle a le mauvais canal ou manque de version. Enregistrez le commit et l'acteur. Faites disponible le roulage comme un job séparé et testé plutôt qu'une commande que quelqu'un doit reconstruire pendant une incidente.

Le modèle de déploiement à commande unique de Capgo correspond à ce modèle. Commencez par la mise en scène, observez l'adoption, puis promouvez le même bundle testé. N'oubliez pas de reconstruire entre les canaux à moins que des changements natifs ne le nécessitent.

Vous devriez maintenant avoir un pipeline de mise en production qui peut envoyer un bundle de manière sécurisée et le rétablir sans deviner. Exécutez-le deux fois avant de considérer la mise en place comme terminée.

FAQ

Quel est le meilleur SaaS d'actualisation d'applications sur air pour Capacitor ?

Capgo est un point de départ solide pour les équipes Capacitor qui ont besoin de déploiements de canaux, de retrait automatique, d'actualisations différentielles et de liens CI/CD. Testez le flux de travail avec votre propre application avant de vous engager. La clé est de savoir si la plateforme gère votre champ d'actualisation, vos règles de sécurité, vos approbations de mise en production et vos besoins de surveillance.

Pouvez les mises à jour OTA modifier les Capacitor natifs code?

Non. Les mises à jour OTA changent généralement la couche web à l'intérieur d'une application Capacitor. Un nouveau plugin natif, une nouvelle permission ou une nouvelle configuration de plateforme nécessitent une nouvelle build iOS ou Android. Gardez cette frontière dans votre politique de mise en production afin qu'un bundle web ne s'attende jamais à des code natifs que l'application installée n'a pas.

How do channels help with mobile app updates?

Les canaux vous permettent d'envoyer différents bundles à des groupes définis. Utilisez des chemins séparés pour le développement, la mise en scène, la bêta et la production. Cela vous permet de tester une mise en production avec moins d'utilisateurs en premier, de suspendre la promotion lorsque les erreurs augmentent et de déplacer les appareils vers un bundle stable sans modifier l'application native.

Les plateformes OTA support-elles un rôleback automatique ?

Certains plateformes OTA supportent le roulback automatique, mais vous devez tester le déclencheur et le chemin de récupération. Confirmez que l'application peut revenir à un bundle connu après une mise à jour échouée. Vérifiez également si le roulback fonctionne par canal et si votre équipe peut examiner l'événement après qu'il se produise.

Comment prix-je un service de mise à jour OTA ?

Comparez le coût de souscription par organisation avec la façon dont chaque service mesure l'utilisation. Certaines plateformes peuvent facturer les utilisateurs ou la bande passante, tandis que d'autres utilisent une structure de plan différente. Testez le facture contre votre base d'installation attendue et incluez le temps de personnel nécessaire pour remplacer les analyses manquantes, les approbations ou les contrôles de roulback.

Conclusion

Pour une application Capacitor ou Ionic, commencez par Capgo et testez une mise à jour étalée de la construction au roulback. Utilisez la période d'essai de 14 jours pour confirmer la configuration du canal, la portée du bundle, les vérifications de sécurité et la commande CI/CD sur votre projet. Si le flux fonctionne, déplacez un petit groupe de bêta, puis promouvez avec des mesures de monitoring en place.