How to Keep Capgo Updates Lean and Fast

Le meilleur live update est celui que vos utilisateurs ne remarquent même pas.

Cela signifie généralement trois choses :

Le téléchargement est petit.
La mise à jour est contrôlée.
La récupération est instantanée si quelque chose se produit.

Les mêmes conseils de mise à jour OTA « garder léger » qui fonctionnent dans le monde de React Native s'appliquent également à Capgo. La différence est que Capgo donne aux équipes Capacitor quelques leviers supplémentaires : Les mises à jour delta, Les canaux, Les retours automatiques, version ciblée, et facultatif chiffrement de bout en bout.

Si vous les utilisez ensemble, vous obtenez des payloads plus petits, des installations plus rapides et beaucoup moins de chaos opérationnel.

Le Lean compte même lorsque le MAU reste le même

Un détail utile spécifique à Capgo : le MAU de Capgo est effectivement le nombre de dispositifs actifs mensuels qui ont contacté le service de mise à jour au cours des 30 derniers jours.

So slimming a bundle is not mainly a trick to reduce MAU counting. It matters because it improves the parts users and teams actually feel:

Faster downloads on cellular or weak Wi-Fi
Expérience améliorée avec Mises à jour directes
Moins de bande passante gaspillée sur des releases échouées ou annulées
Zone d'impact réduite lors du test ou de la mise en production d'une mise à jour

Mises à jour économes sont vraiment axées sur la vitesse, la sécurité et la discipline opérationnelle.

1. Mettre à jour par défaut en delta

If you do only one thing, do this.

Capgo’s Mises à jour Delta Envoyez uniquement les fichiers modifiés entre versions au lieu de télécharger à nouveau le bundle web complet. C'est la plus grande victoire pour la performance OTA de routine.

bun run build
bunx @capgo/cli@latest bundle upload --channel staging --delta

Lorsque votre passe de QA est terminé :

bunx @capgo/cli@latest bundle upload --channel production --delta

Lorsque votre passe de QA est terminé : --delta-only Si vous voulez que CI reste strict, utilisez

bunx @capgo/cli@latest bundle upload --channel production --delta-only

Only use --delta-only when your production fleet supports Delta updates. On mixed plugin versions, older devices that do not support manifest-based delta delivery will not be able to download that update.

Cela compte encore plus si vous utilisez directUpdatecar la durée entre « mise à jour trouvée » et « application rechargée » devient visible pour l'utilisateur.

Traitez les actifs comme des actifs, pas comme un fardeau JavaScript.

Les actifs volumineux sont là où les bundles OTA se font discrètement gonfler.

Quelques règles pratiques :

Do not inline big images or media inside JavaScript when a normal asset file will do.
Conservez le contenu qui change fréquemment sur votre propre CDN ou API si cela ne doit pas vivre à l'intérieur du bundle d'application livré.
Soignez les images marketing, les vidéos de démarrage et les actifs de campagne ponctuels qui sont remplacés à chaque mise à jour.
Laissez les actifs stables rester stables. Les mises à jour Delta réutilisent les fichiers inchangés au lieu de les télécharger à nouveau.

This is one of the easiest ways to keep Capgo fast as your app grows. The worst pattern is a tiny UI fix that forces users to download a pile of unrelated media.

3. Conservez les versions natives pour les changements natives réels

Capgo met à jour la couche web : HTML, CSS, JavaScript et actifs chargés en temps de exécution.

C'est pas le bon canal pour :

plugins natives nouveaux,
changements de permissions,
capacitor.config.ts changements,
toute modification qui modifie l'état du projet native iOS ou Android.

Cette ligne compte également pour la performance. Si vous continuez à injecter des changements structuraux majeurs dans la voie de mise à jour OTA, votre stratégie de mise à jour devient plus lourde et plus risquée au fil du temps.

Utilisez deux voies de mise à jour délibérément :

Ligne native

Pour les changements de plugins, les changements de permissions et la configuration native :

bun run build
bunx cap sync

Then ship a normal store release.

Ligne Capgo

Pour une itération web en toute sécurité :

bun run build
bunx @capgo/cli@latest bundle upload --channel production --delta

Rafraîchissez régulièrement votre ligne de base native si vous avez ajouté récemment de nombreux actifs à long terme. Une nouvelle construction de l'app store intègre cette nouvelle ligne de base, ce qui garde les différences futures Capgo plus petites.

4. Use channels to keep rollout size small

Une mise à jour "léger" ne concerne pas seulement les mégaoctets. C'est aussi le nombre de dispositifs qui reçoivent la mise à jour avant de savoir qu'elle est bonne.

Capgo's le système de canaux est la manière la plus propre de contrôler cela :

staging pour les tests
beta pour les testeurs invités
production pour tout le monde
hotfix pour la récupération d'urgence

Un flux simple ressemble à ceci :

Télécharger vers staging.
Valider sur des appareils réels.
Sortez progressivement, qu'il s'agisse de canaux contrôlés ou de déploiement basé sur des pourcentages.
Revenez immédiatement si la santé chute.

Si votre application comporte plusieurs bases natives dans le monde réel, associez les canaux avec la ciblage de version. Cela empêche les paquets incompatibles ou trop lourds de rejoindre les anciens binaires.

Pour les équipes qui veulent même des boucles de revue plus serrées, Capgo convient également bien aux Aperçus de PR. Cela permet aux produits, à la QA et aux parties prenantes de tester les modifications JS uniquement sans attendre de nouvelles versions de TestFlight ou Play.

5. Si vous activez les mises à jour directes, optimisez le démarrage

Plus vous voulez que l'une des mises à jour soit appliquée rapidement, plus votre chemin d'initialisation doit être discipliné.

Capgo's comportement de mise à jour docs recommandent explicitement de pairer directUpdate avec les mises à jour Delta. C'est la bonne valeur par défaut.

Le deuxième garde-fou est notifyAppReady().

import { CapacitorUpdater } from '@capgo/capacitor-updater'

CapacitorUpdater.notifyAppReady()

Si votre application ne signale pas prête dans les 10 secondes par défaut notifyAppReady() fenêtre, ou dans ce qui vous intéresse appReadyTimeout you set in your Capacitor config, Capgo can mark that bundle invalid and restore the previous good version. That rollback behavior is what you want in production, but it also means you should keep startup clean:

Call notifyAppReady() Enregistrez et restaurez l'état de l'application avec soin si vous reloadz immédiatement
Évitez les tâches de démarrage lent dans le chemin critique
Sauvegardez et rétablissez l'état de l'application avec soin si vous rechargez immédiatement.
Test bad-network and low-end-device scenarios before broad rollout

Si vous n'avez pas révisé cela récemment, le guide de notification d'application est toujours utile de le relire.

6. Utilisez les canaux d'actualisation internes au lieu de reconstructions natives inutiles

Beaucoup d'équipes de mobile perdent du temps à construire des binaires pour des changements qui sont clairement web-only.

Si le changement est :

copie
Polissage UI
flux de prise en charge
logique de l'écran de tarification
branchement des analyses
drapeaux de fonctionnalité
affichage de réponse ou API

une mise à jour Capgo est souvent l'artefact de revue la plus rapide.

Cela signifie moins de rebuilds natives, moins de bouleversements sur TestFlight et un boucle de feedback plus serrée pour l'équipe. Il s'agit d'un des avantages les moins utilisés de Capgo: vous pouvez déplacer plus de travail de revue et de QA dans la voie OTA sans rompre la frontière native/web.

Notre guide sur en développement avec un ID d'application mobile unique aborde une méthode pratique pour maintenir cela propre au fil du temps.

7. Gardez séparé lean de secret

Les petits ensembles et les ensembles sécurisés résolvent des problèmes différents.

Les canaux contrôlent l'éligibilité. Ils ne rendent pas un ensemble confidentiel par eux-mêmes.

Si vous avez besoin de garanties de livraison plus fortes :

activez la cryptage de Live Update,
utilisez stockage personnalisé ou livraison auto-hébergée,
gardez les clés privées uniquement dans les flux de travail CI ou opérateurs sécurisés.

Cela ne rend pas la taille des mises à jour sans importance. Il s'agit simplement de vous assurer d'optimiser pour les deux dimensions :

maigre pour la vitesse
chiffré pour le contrôle de la livraison
canaux de contrôle de déploiement,
retour en arrière pour la récupération.

Un workflow pratique « maigre Capgo »

Si vous souhaitez un modèl’opérationnel par défaut simple, utilisez celui-ci :

Maintenez les voies de publication natives et OTA séparées.
Envoyez les modifications de JS avec --delta par défaut.
Utilisez staging et beta canaux avant production.
Regardez statistiques et journaux d'actualisation après le lancement, et non seulement avant.
Transformez les PR en prévisualisations installables lorsque la construction native n'est pas nécessaire.
Maintenez les médias importants et changeants hors du bundle autant que possible.
Actualisez la base native après une croissance majeure des actifs ou des changements natifs.
Traitez notifyAppReady() Comme partie de l'ingénierie de la mise en production, pas de trivia de configuration.

Cette combinaison reste rapide beaucoup plus longtemps que l'approche commune « juste téléchargez tout ce qui a changé ».

Réflexion finale

Pour les équipes Capgo, « lean et rapide » n'est pas juste un problème de taille de paquet.

C'est un problème de conception de mise à jour.

Use Delta updates for payload size, channels for rollout size, and rollbacks for failure size. Once you think about OTA that way, your updates stay quick even as the app, team, and user base get bigger.

Continuez à partir de Comment garder les mises à jour Capgo lean et rapides

Si vous utilisez Comment garder les mises à jour Capgo lean et rapides à planifier la routage des canaux et le déploiement étape par étape, connectez-l’avec Canal pour les détails d'implémentation dans les canaux, Canal pour les détails d'implémentation dans les canaux, Canaux pour les détails d'implémentation dans les Canaux, Solution de test bêta pour le flux de travail du produit dans la Solution de Test Beta. Solution de ciblage de version pour le flux de travail du produit dans la Solution de ciblage de version.