La meilleure mise à jour en direct est celle que vos utilisateurs remarquent à peine.
Cela signifie généralement trois choses :
- La mise à jour est petite.
- La mise en œuvre est contrôlée.
- La récupération est instantanée si quelque chose se produit mal.
Les mêmes conseils pour garder les mises à jour OTA économes 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 : Mises à jour Delta, canaux, annulations automatiques, ciblage de version, et optionnel chiffrement de bout en bout.
Si vous utilisez ces deux ensemble, vous obtenez des payloads plus petits, des installations plus rapides, et beaucoup moins de chaos opérationnel.
L'efficacité compte même lorsque le MAU reste le même
Un détail utile spécifique à Capgo : le MAU Capgo est effectivement le nombre de dispositifs actifs mensuels qui ont contacté le service de mise à jour au cours des 30 derniers jours.
Ainsi, réduire un bundle n'est pas principalement un tour de passe-passe pour réduire le comptage du MAU. Cela compte parce qu'il améliore les parties que les utilisateurs et les équipes ressentent vraiment :
- Téléchargements plus rapides sur les réseaux cellulaires ou les Wi-Fi faibles
- Expérience meilleure avec Mises à jour directes
- Moins de bande passante gaspillée sur les mises à jour échouées ou annulées
- Un rayon d'impact plus petit lors de la mise en production ou de la mise en ligne d'une mise à jour
Les mises à jour économes sont vraiment axées sur la vitesse, la sécurité et la discipline opérationnelle.
1. Définir par défaut les mises à jour Delta
Si vous faites seulement une chose, faites ceci.
Capgo’s Les mises à jour Delta Envoient uniquement les fichiers qui ont changé entre les versions au lieu de télécharger à nouveau le bundle web complet. C'est le plus grand gain pour la performance des mises à jour OTA de routine.
bun run build
bunx @capgo/cli@latest bundle upload --channel staging --delta
Lorsque votre passe de QA est terminée :
bunx @capgo/cli@latest bundle upload --channel production --delta
Si vous voulez que CI reste strict, utilisez --delta-only afin que personne ne retombe accidentellement sur les téléchargements de bundle complets :
bunx @capgo/cli@latest bundle upload --channel production --delta-only
Utilisez uniquement --delta-only lorsque votre flotte de production prend en charge les mises à jour Delta. Sur les versions de plugins mixtes, les appareils plus anciens qui ne supportent pas la livraison delta basée sur le manifeste ne seront pas en mesure de télécharger cette mise à jour.
Cela compte encore plus si vous utilisez directUpdate, car le temps entre « mise à jour trouvée » et « application rechargée » devient visible pour l'utilisateur.
2. Traitez les actifs comme des actifs, pas comme du bagage JavaScript
Les actifs volumineux sont où les lots OTA se gonflent discrètement.
Quelques règles pratiques :
- Ne faites pas passer les grandes images ou les médias à l'intérieur du JavaScript lorsqu'un fichier d'actif normal fera l'affaire.
- Keep frequently changing content on your own CDN or API if it does not need to live inside the shipped app bundle.
- Laissez les actifs stables rester stables. Avec les mises à jour Delta, les fichiers inchangés sont réutilisés au lieu d'être téléchargés à nouveau.
- C'est l'une des façons les plus faciles de garder __CAPGO_KEEP_0__ rapide même lorsque votre application grandit. Le pire modèle est une petite correction de l'interface utilisateur qui oblige les utilisateurs à télécharger un tas de médias non liés.
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. Gardez les versions natives pour les changements réels natives
Capgo met à jour la couche web : HTML, CSS, JavaScript et les actifs chargés en temps de exécution.
Ce n'est pas le bon canal pour :
- de nouveaux plugins natives,
- les modifications de permissions,
capacitor.config.tsles changements,- toute chose qui modifie l'état du projet native iOS ou Android.
Cette ligne compte aussi pour la performance. Si vous continuez à injecter des changements structurels majeurs dans la voie de mise à jour OTA, votre stratégie d'actualisation devient plus lourde et plus risquée au fil du temps.
Utilisez deux voies de mise à jour à des fins délibérées :
Voie native
Pour les changements de plugins, les modifications de permissions et la configuration native :
bun run build
bunx cap sync
Ensuite, expédiez une mise à jour normale dans l'app store.
Capgo voie
Pour une itération sécurisée du niveau web :
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 un grand nombre d'actifs à durée de vie longue. Une nouvelle construction de magasin intègre cette nouvelle ligne de base, ce qui réduit les différences futures Capgo.
4. Utilisez les canaux pour garder la taille de la mise à jour petite
Une mise à jour « mince » ne concerne pas seulement les mégaoctets. C'est aussi le nombre de dispositifs qui reçoivent la mise à jour avant de savoir si elle est bonne.
Capgo’s système de canaux est la manière la plus propre de contrôler cela :
stagingpour les tests de qualitébetapour les testeurs invitésproductionpour tout le mondehotfixpour la récupération d'urgence
A un flux simple ressemble à ceci :
- Envoyez vers
staging. - Validez sur des appareils réels.
- Sortez progressivement, qu'il s'agisse de canaux contrôlés ou de lancement basé sur des pourcentages.
- Revenez immédiatement si la santé baisse.
Si votre application a plusieurs baselines natives dans la wild, associez les canaux avec la ciblage de version. Cela empêche les paquets incompatibles ou trop lourds d'atteindre les anciens binaires.
Pour les équipes qui veulent même des boucles de revue plus serrées, Capgo fonctionne également bien pour les prévisions 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 la charge de démarrage
Plus vous voulez que l'mise à jour soit appliquée rapidement, plus votre chemin d'initialisation doit être discipliné.
Capgo’s comportement de mise à jour les docs recommandent explicitement de pairer directUpdate avec les mises à jour Delta. C'est le bon paramètre par défaut.
La deuxième barrière est notifyAppReady().
import { CapacitorUpdater } from '@capgo/capacitor-updater'
CapacitorUpdater.notifyAppReady()
Si votre application ne signale pas prête dans la fenêtre de 10 secondes par défaut, ou dans ce que notifyAppReady() vous avez défini dans votre __CAPGO_KEEP_0__ config, __CAPGO_KEEP_1__ peut marquer cette version invalide et restaurer la version précédente valide. Ce comportement de reversion est ce que vous voulez en production, mais cela signifie également que vous devriez garder l'initialisation propre : 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:
- au bon endroit
notifyAppReady()Évitez le travail lent au moment de l'initialisation dans le chemin critique - Avoid slow boot-time work in the critical path
- Enregistrez et restaurez l'état de l'application avec soin si vous rechargez immédiatement.
- Testez les scénarios de réseau mauvais et de périphériques de faible performance avant une mise à l'échelle large.
Si vous n'avez pas révisé cela récemment, le guide de notification notifyAppReady est digne d'être relu. 6. Utilisez les canaux d'actualisation internes au lieu de reconstructions natives inutiles. Beaucoup d'équipes mobiles gaspillent leur temps à construire des binaires pour des changements qui sont clairement web-only.
Si le changement est :
copie,
polissage de l'interface utilisateur,
- flux de démarrage,
- logique de l'écran de tarification,
- If you have not reviewed it recently, the "notifyAppReady" guide is worth re-reading.
- 6. Use internal update channels instead of unnecessary native rebuilds
- branchement d'analytique,
- drapeaux de fonctionnalité,
- alors une mise à jour API est souvent l'artefact de revue le plus rapide.
Cela signifie moins de rebuilds natives, moins de changement de flux de 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 briser la frontière native/web.
That means fewer native rebuilds, less TestFlight churn, and a tighter feedback loop for the team. It is one of the most underused benefits of Capgo: you can move more review and QA work into the OTA lane without breaking the native/web boundary.
mise en scène avec un ID d'application mobile unique couvre une méthode pratique pour garder cela propre au fil du temps. 7. Gardez séparé lean de secret
Les petits paquets et les paquets sécurisés résolvent des problèmes différents.
Les canaux contrôlent l'éligibilité. Ils ne rendent pas un paquet confidentiel par eux-mêmes.
Si vous avez besoin de garanties de livraison plus fortes :
protectedTokens
- activer mise à jour Live chiffrée,
- utiliser stockage personnalisé ou livraison auto-hébergée,
- garder les clés privées que dans la CI ou les workflows d'opérateur sécurisés.
Cela ne rend pas la taille de la mise à jour sans importance. Il suffit de dire que vous devriez optimiser pour les deux dimensions :
- se concentrer sur la vitesse,
- chiffrer pour le contrôle de la livraison,
- canaux pour le contrôle de la mise en production,
- retour en arrière pour la récupération.
Un workflow pratique « lean Capgo »
Si vous voulez un modèle opérationnel simple par défaut, utilisez celui-ci :
- Maintenez les voies de publication natives et OTA séparées.
- Téléchargez les modifications JS avec
--deltapar défaut. - Utilisez
staginget les canaux avantbetaRegardezproduction. - mettre à jour les statistiques et les journaux après le lancement, et non seulement avant. Transformez les PRs en prévisualisations installables lorsque la construction native n'est pas nécessaire.
- Maintenez les médias importants et changeants hors du bundle lorsque cela est possible.
- Rafraîchissez la base native après une croissance majeure des actifs ou des modifications natives.
- __CAPGO_KEEP_0__
- Traitez et annulez le comportement comme partie de l'ingénierie de la mise en production, et non comme des triviaux de configuration.
notifyAppReady()Cette combinaison reste rapide pendant plus longtemps que l'approche commune « envoyez simplement ce qui a changé ».
Réflexion finale
Pour les équipes __CAPGO_KEEP_0__, « maigre et rapide » n'est pas juste un problème de taille de paquet.
For Capgo teams, “lean and fast” is not just a bundle-size problem.
Utilisez les mises à jour Delta pour la taille du payload, les canaux pour la taille de la mise en route et les annulations pour la taille de l'échec. Une fois que vous pensez à l'OTA de cette façon, vos mises à jour restent rapides même lorsque l'application, l'équipe et la base d'utilisateurs deviennent plus grandes.
Continuez à partir de Comment garder les mises à jour __CAPGO_KEEP_0__ maigres et rapides
Keep going from How to Keep Capgo Updates Lean and Fast
Comment garder les mises à jour __CAPGO_KEEP_0__ maigres et rapides How to Keep Capgo Updates Lean and Fast Canal Utilisez les mises à jour Delta pour la taille du payload, les canaux pour la taille de la mise en route et les annulations pour la taille de l'échec. Une fois que vous pensez à l'OTA de cette façon, vos mises à jour restent rapides même lorsque l'application, l'équipe et la base d'utilisateurs deviennent plus grandes. pour les détails d'implémentation dans les canaux, Canaux 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 bêta, et Solution de ciblage de version pour le flux de travail du produit dans la Solution de ciblage de version.