MÉTÉO
FEMA
Des consignes d'urgence où une petite erreur de contenu peut devenir critique.
- Installations Google Play
- 1,6 M
- Note du store
- 4.0
Mises à jour directes
Affichez la dernière version dès l'ouverture de l'app
Par défaut, un live update s'exécute une session après son téléchargement. Les modes de direct update l'appliquent à l'ouverture, derrière votre splash screen, pour que le premier écran vu par l'utilisateur soit déjà la nouvelle version.
Essai gratuit illimité de 14 jours. Aucune carte bancaire requise Garantie de remboursement de 14 jours. Résiliable à tout moment.
Besoin d'une offre Enterprise ? Parler à notre équipe
autoUpdate : atInstall, onLaunch ou toujours
Splash screen held until the update is ready
Les téléchargements delta réduisent l'attente
Le problème
Background updates arrive one session late
Ce qui se passe en mode par défaut
1
L'utilisateur ouvre l'application
L'application démarre avec le bundle qu'elle possède déjà. L'updater vérifie s'il y en a un nouveau et le télécharge en arrière-plan.
2
La session utilise la version actuelle
Pendant le reste de cette session, l'utilisateur utilise le code qui a été installé avant votre correctif.
3
La mise à jour s'applique au prochain resume
Lorsque l'utilisateur quitte l'application, l'updater installe le nouveau bundle. Il sera visible lors de la prochaine ouverture de l'application.
Pour la plupart des releases, c'est le compromis idéal. Mais quand la session suivant votre upload doit exécuter le nouveau code, utilisez le mode direct update.
Quand la première session est critique
Un flux de paiement ou de connexion défectueux
Les utilisateurs qui ouvrent l'application ne devraient plus voir l'écran défectueux avant que la correction ne soit appliquée.
Un correctif de sécurité au niveau web
Vous voulez que le JavaScript patché s'exécute dès le lancement, pas lors de la session suivante.
Un changement temporel
Termes, mentions ou contenus d'événements qui doivent être à jour dès le premier écran affiché.
La solution
Ce qui change avec le mode direct update
L'updater vérifie au lancement pendant que votre splash screen reste affiché. Si un nouveau bundle est disponible, il le télécharge et l'applique avant que le splash screen ne disparaisse.
Mode par défaut (atBackground)
1
L'utilisateur ouvre l'app
2
L'app affiche la version actuelle
3
La mise à jour se télécharge en arrière-plan
4
La mise à jour s'applique au prochain resume
No wait at launch. Users see the update one session later.
Mode direct (onLaunch)
1
L'utilisateur ouvre l'app et l'écran de splash reste affiché
2
L'updater vérifie et télécharge les fichiers modifiés
3
La mise à jour s'applique, le splash disparaît, la nouvelle version s'affiche
Les utilisateurs voient la nouvelle version dès le premier écran. Ils attendent sur l'écran de splash pendant le téléchargement.
Comment ça marche
Comment configurer les mises à jour directes
Le mode direct est une configuration native, il est donc déployé via un build store en premier. Ensuite, chaque live update le suit. Les commandes proviennent de la doc Capgo.
-
Ajoutez le plugin splash screen et choisissez un mode
Installez @capacitor/splash-screen, puis configurez autoUpdate, autoSplashscreen et launchAutoHide dans capacitor.config.ts.
Gestion du splash screennpm install @capacitor/splash-screen npx cap sync // capacitor.config.ts plugins: { CapacitorUpdater: { autoUpdate: 'onLaunch', // or 'atInstall' / 'always' autoSplashscreen: true, keepUrlPathAfterReload: true, }, SplashScreen: { launchAutoHide: false }, } -
Incluez la config dans un build pour les stores
Le fichier capacitor.config est compilé dans l'app native, donc le nouveau mode arrivera chez les utilisateurs avec votre prochaine release sur les stores. Capgo Build peut le générer dans le cloud.
Documentation Capgo Buildnpx @capgo/cli@latest build request --platform ios npx @capgo/cli@latest build request --platform android -
Envoyez les bundles en deltas
Les utilisateurs attendent le téléchargement au lancement, donc n'envoyez que les fichiers modifiés. CLI détecte les modes d'application instantanée et propose un upload de delta.
Docs des delta updatesnpx @capgo/cli@latest bundle upload --channel production --delta -
Gardez le rollback automatique activé
Appelez notifyAppReady() une fois votre app démarrée. Si un nouveau bundle échoue au démarrage, l'appareil revient au dernier bundle fonctionnel.
Docs de notifyAppReady()import { CapacitorUpdater } from '@capgo/capacitor-updater' await CapacitorUpdater.notifyAppReady()
Choisissez le mode adapté à votre app
Les mises à jour directes sont un compromis : une courte attente au lancement en échange de la nouvelle version dès le premier écran.
Trois modes d'application instantanée
Configurez autoUpdate dans capacitor.config.ts. Chaque mode définit quand une mise à jour peut s'appliquer pendant que l'utilisateur attend.
- atInstall : uniquement juste après une nouvelle installation ou une mise à jour du build natif via un store
- onLaunch : lors du démarrage de l'app depuis un état fermé (cold start)
- toujours : lors de chaque vérification au premier plan, même si l'app est ouverte
3
Modes d'application instantanée dans autoUpdate
Gestion du splash screen
Les modes directs nécessitent @capacitor/splash-screen avec launchAutoHide sur false et autoSplashscreen sur true. L'updater masque l'écran de splash une fois la mise à jour appliquée ou lorsqu'il détecte qu'aucune mise à jour n'est requise.
- Aucun appel manuel à SplashScreen.hide() n'est nécessaire
- keepUrlPathAfterReload maintient l'utilisateur sur la même route après le rechargement
- Listen for appReady if you need extra work after the splash hides
autoSplashscreen
Requis pour chaque mode direct
Compromis à prévoir
Les utilisateurs attendent le téléchargement au lancement, et avec une mise à jour, ils peuvent recharger l'app à tout moment pendant son utilisation. Prévoyez les deux cas.
- Faites un upload avec --delta pour ne télécharger que les fichiers modifiés
- Save and restore app state so a reload does not lose user progress
- Gardez le mode par défaut quand un délai d'une session convient
--delta
Recommandé pour chaque upload de mise à jour directe
Quand utiliser les mises à jour directes
Utilisez le mode direct quand la session actuelle doit exécuter le nouveau code. Gardez le mode par défaut pour le reste.
Corrections de bugs critiques
Bugs de paiement, de connexion ou de données où utiliser l'ancien code une session de plus est inacceptable.
Onboarding au premier lancement
atInstall applique le dernier bundle juste après une nouvelle installation ou une mise à jour depuis les stores, pour que les nouveaux utilisateurs démarrent sur votre onboarding actuel.
Contenu daté
Pages d'événements, annonces ou conditions qui doivent être à jour dès que l'utilisateur ouvre l'app.
Correctifs de sécurité
Corrections de sécurité de la couche web exécutables dès le lancement. Les correctifs du code natif nécessitent toujours une release sur les stores.
Releases de routine
Les ajustements de style et les petites fonctionnalités justifient rarement l'attente au lancement. Le mode par défaut les applique une session plus tard.
Apps restant ouvertes des heures
Avec l'option always, des vérifications périodiques (toutes les 10 minutes par défaut) peuvent appliquer une mise à jour pendant que l'app est ouverte. Sauvegardez l'état avant de compter dessus.
Réduire l'attente au lancement
L'attente au lancement correspond à la vérification de la mise à jour plus le téléchargement. Les delta updates limitent le téléchargement aux seuls fichiers modifiés.
~50 ms
Latence API typique
Delta
Seuls les fichiers modifiés sont téléchargés
1 Md+
Mises à jour livrées par mois
Solutions par type d'équipe
Trouvez la solution adaptée aux besoins de votre équipe
Apps développées avec Capacitor
Les apps d'information publique exigent des correctifs urgents
Les apps d'urgence, de santé ou citoyennes ne peuvent pas attendre des jours pour corriger une checklist, un lien ou une notice locale. Les direct updates permettent à la couche web d'évoluer dès que le correctif est approuvé.
MÉTÉO
MÉDICAL
Connectez SUS
Dossiers médicaux et interfaces de conseils où les contenus approuvés doivent être diffusés rapidement.
- Installations Google Play
- 27,7 M
- Note du store
- 4.6
SOCIAL
e-Título
Workflows d'identité civique nécessitant un guidage sécurisé par version sur tous les appareils.
- Installations Google Play
- 54,9 M
- Note du store
- 4.8
Témoignages clients
Ce que disent les équipes qui déploient avec Capgo
Kapil
Fondateur, NuTriQ
“Pouvoir pousser instantanément des mises à jour OTA en production sans attendre les cycles complets de validation de l’App Store est un avantage opérationnel énorme.”
Sergiu S
Lead Developer, drivolino GmbH
« Le plugin Capgo Capacitor Updater a totalement transformé notre façon de déployer les mises à jour. Ce qui prenait des jours ne prend plus que quelques minutes. »
Luis Dominguez
Celui qui paie, Anirol
« Depuis que j'utilise Capgo, tout est plus rapide, et je peux offrir à mes utilisateurs le temps qu'ils méritent sans négliger ma vie quotidienne. »
FAQ
Questions sur les direct updates
Quand les utiliser, comment les configurer et quel est leur coût au lancement.
Devons-nous utiliser les direct updates ou le mode background par défaut ?
Utilisez le mode par défaut pour la plupart des releases : il n'y a pas d'attente au lancement et les utilisateurs reçoivent la mise à jour à la session suivante. Utilisez le mode direct lorsque la session qui démarre après votre upload doit exécuter le nouveau code, par exemple pour un checkout défectueux ou un correctif de sécurité de la couche web.
Doc sur le comportement des mises à jour
Quelle est la différence entre atInstall, onLaunch et always ?
atInstall applique une mise à jour immédiatement seulement après une nouvelle installation ou une mise à jour du build natif sur le store, puis se comporte comme le mode par défaut. onLaunch s'applique immédiatement quand l'app démarre d'un état arrêté. always vérifie à chaque passage au premier plan et s'applique dès que le téléchargement est terminé, même pendant que l'utilisateur est dans l'app.
Paramètres de l'updater
Pourquoi le plugin splash screen est-il requis ?
Les modes directs appliquent la mise à jour pendant que l'utilisateur attend. Sans @capacitor/splash-screen, autoSplashscreen: true et launchAutoHide: false, les utilisateurs peuvent voir un scintillement ou l'ancienne UI avant le rechargement. Avec ces options, le splash screen reste affiché jusqu'à ce que la mise à jour soit appliquée ou que l'updater confirme qu'aucune n'est nécessaire.
Gestion du splash screen
Pouvons-nous activer les direct updates avec un live update ?
Non, autoUpdate se trouve dans capacitor.config, qui est lu par l'application native lors du temps de build. Déployez ce nouveau paramètre via une release sur les stores. Ensuite, chaque live update suivra le nouveau mode.
Docs de compatibilité native
Notre config utilise directUpdate. Est-ce toujours supporté ?
directUpdate est obsolète mais toujours détecté. Ses valeurs correspondent aux modes autoUpdate atInstall, onLaunch et always. Migrez le paramètre vers autoUpdate lors de votre prochaine release native.
Paramètres de l'updaterDéployez votre prochain correctif dès le premier écran
Essayez le mode direct update sur un build de test pendant votre essai et mesurez le temps d'attente au lancement de votre propre application.
Essayez les direct updates de Capgo : les live updates s'appliquent au lancement, derrière votre splash screen.
support humain par Martin
Essai gratuit illimité de 14 jours. Aucune carte bancaire requise Garantie de remboursement de 14 jours. Résiliable à tout moment.
Essai gratuit de 14 jours. Aucune carte bancaire requise.