Guide de dépannage d'applications pour CapacitorJS et Electron

Le jeudi soir, votre application de magasin CapacitorJS pour Android 14 affiche des tableaux de bord vides. Les clients iOS naviguent normalement. Les utilisateurs Electron ne signalent rien. L'ingénieur en charge suppose une regression de WebView, ouvre Android Studio et passe des heures à comparer le comportement de rendu sur différents appareils. La cause finale n'est pas un bug de rendu du tout. Une clé de production API a atteint les clients mobiles après une invalidation de cache CDN qui n'a pas atteint les clients mobiles.

Cet incident est familier car les erreurs mobiles rarement respectent les limites de votre dépôt. Une modification JavaScript fraîche peut être innocente tandis qu'une mise en production, une valeur de configuration, un état de permission, une dépendance de service ou un chemin réseau brise le parcours de l'utilisateur. Une analyse d'incident de Microsoft a trouvé que 40% des incidents de production provenaient de code ou de bugs de configuration, tandis que 60% provenaient d'infrastructures, de déploiements et de dépendances de servicesLa leçon pratique est simple: Le dépannage d'applications doit commencer par le domaine de failure complet, et non par la trace de pile. (L'analyse d'incidents de Microsoft)

Cette feuille de route suit le workflow que j'utilise après la mise en production de CapacitorJS et Electron : définir exactement ce que l'utilisateur a exécuté, inspecter les données de production avant de tenter la reproduction, vérifier les causes non code, puis déboguer la couche la plus étroite qui correspond au symptôme. Les sept mouvements sont la mise en scène des incidents, les journaux étayés, le débogage web et natif, les vérifications de réseau et d'état, les garde-fous CI, la récupération de mise à jour en direct, et une revue post-incident qui attribue le travail de prévention.

Table des matières

• L'Été où le tableau de bord s'est éteint
  • Établir la surface de failure exacte
  • Reproduire en supprimant les variables
• Lecture des journaux à partir de la vue web, native et du système d'exploitation
  • Correspondre chaque symptôme à sa preuve
  • Corréler avant de filtrer
• Débogage des couches Web et Native
  • Commencez par la vue Web
  • Passez aux outils natifs lorsque les indices pointent dans cette direction
• Premiers contrôles sur le réseau, le stockage et les autorisations
• Tests automatisés et CI comme systèmes d'alerte précoce
  • Testez la logique partagée et les coques
  • Faites en sorte que les échecs soient bloquants pour la fusion
• Mises à jour en temps réel comme un canal de récupération d'urgence
  • Utilisez un lancement protégé
• Analyse post-incident qui prévient la prochaine
  • Utilisez cinq blocs concrets
  • Affectez du travail avant de clore l'incident

The Nuit où le tableau de bord s'est éteint

Par jeudi soir, les utilisateurs d'Android signalent un tableau de bord vide tandis que les utilisateurs de bureau Electron continuent à travailler normalement. La première hypothèse était une regression d'Android 14 ou WebView. Cette piste a resserré la recherche, mais elle n'a pas identifié l'échec. Les utilisateurs affectés ont également partagé un canal de mise à jour, un chemin de configuration mémorisé, un environnement API et une séquence particulière de requêtes de tableau de bord.

Le technicien en charge a commencé par comparer les versions de WebView. Les résultats semblaient plausibles et n'ont mené à rien. Un tableau de bord vide peut provenir d'une exception de rendu, d'une réponse vide API, d'une requête rejetée, d'un jeton invalide, d'une bannière de fonctionnalité ou d'une lecture de stockage qui empêche la restauration de session. Avant de modifier code, déterminez quelles sont les versions binaires, les bundles Web, les configurations et les chemins de serveur que les utilisateurs affectés ont reçus.

Déterminez l'aire de failure exacte

Commencez par la télémétrie de production, pas un ordinateur portable de développeur. La recommandation de Google pour les crash et les ANR d'Android consiste à resserrer les événements par appareil, système d'exploitation et fenêtre de tempspuis à utiliser logcat lors de la reproduction lorsque la localisation de l'échec reste incertaine.La recommandation de Google pour la dépanne des vitales d'Android)

Capturer ces champs d'une session affectée :

• Identité de la construction : Enregistrer la version de l'application native, l'ID de construction, l'empreinte du bundle Web et la date de mise à jour.
• Chaîne de distribution : Confirmer si l'utilisateur a reçu du contenu canari, bêta, en phase de test ou stable.
• Contexte d'exécution : Notez la version d'Android ou iOS, le modèle de l'appareil, le type de réseau, l'état des permissions et si l'app a été redémarrée à partir de l'arrière-plan.
• Dernière action réussie : Conservez la séquence de clic exacte, la requête, le statut de réponse et le résultat visible.
• Instantané de la configuration : Comparez l'API URL de base, les drapeaux de fonctionnalité, les paramètres d'authentification et la configuration du plugin avec un appareil connu pour fonctionner correctement.

Capacitor maintient la version native séparée du contenu web exécuté à l'intérieur de la vue WebView. Deux utilisateurs peuvent partager un fichier d'installation tandis que recevant des ensembles de scripts JavaScript différents. Ils peuvent également partager un bundle web tout en utilisant des plugins natifs différents. Electron nécessite le même contrôl’à travers le manifest de la mise à jour, la version du processus principal, le bundle du navigateur et le canal de mise à jour. Les métadonnées du package du navigateur ne suffisent pas à établir ce que l'utilisateur a exécuté.

Réproduisez en supprimant les variables

Après avoir collecté les identifiants, classez l'incident comme canari uniquement, en phase de test ou pleinement déployé. Une erreur spécifique à un canard pointe vers une affectation ciblée d'un bundle, d'une étiquette ou d'un canal. Une erreur en phase de déploiement suggère une logique de sélection d'audience ou de dispositif. Une erreur pleinement déployée met en priorité la configuration partagée, le comportement backend et la compatibilité native.

Différenciez le dispositif affecté par rapport à un dispositif connu et bon. Vérifiez les versions des plugins natifs, la hache web, le canal, l'environnement API, l'état d'authentification et les autorisations accordées. Réexécutez la séquence d'action de l'utilisateur localement avant de chercher un émulateur. Si une seule étiquette contrôle l'erreur, maintenez les autres variables stables et bissez le comportement de cette étiquette.

Règle pratique : N'appellez pas une reproduction « le même bug » avant que l'ID de build, le canal, le bundle web, le système d'exploitation et la configuration ne correspondent.

L'incident du tableau de bord Android a activé la correction de la configuration. L'équipe a comparé des captures d'écran, a confirmé que le binaire natif était valide et a vérifié que la fenêtre de visualisation et le tableau de bord code n'étaient pas modifiés. Les clients de production demandaient un environnement avec un crédentiel de phase de test car l'invalidation de cache antérieure n'avait pas atteint tous les clients mobiles. Le travail de récupération s'est donc concentré sur la correction de la configuration, la mise en place de têtes d'invalidation de cache appropriées et la vérification de la purge CDN des régions et des chemins des clients affectés.

La séquence compte car une commande de purge réussie ne prouve pas que chaque utilisateur puisse récupérer la valeur corrigée. Vérifiez les réponses CDN, l'âge de la cache, les hachages de bundle ou de configuration, et une session client fraîche avant de déclarer la récupération. Une reconstruction native aurait ajouté du temps de déploiement sans modifier l'artefact qui a causé l'échec.

Utilisez la même discipline pour les incidents futurs : identifiez l'artefact de l'utilisateur, localisez la surface de l'échec, éliminez les différences environnementales, et déboguez ensuite code. Un guide de réponse à l'incident écrit pour les équipes mobiles devrait conserver ces vérifications aux côtés du livre de runbook en appel, y compris les requêtes de télémétrie, la responsabilité de déploiement, la vérification de purge et la décision d'utiliser une mise à jour en direct lorsque le binôme natif n'est pas le composant qui a échoué. La lecture des journaux à partir de la vue Web, natif et du système d'exploitation Une application CapacitorJS ou Electron produit des preuves à plusieurs niveaux, et chaque niveau répond à une question différente. La vue Web peut afficher les exceptions JavaScript et les requêtes échouées, mais elle ne pourra pas expliquer tous les échecs de plugin. Les journaux natifs exposent le comportement de la passerelle et du cycle de vie, tandis que le système d'exploitation enregistre la pression de la mémoire, les refus de permission et la terminaison du processus que l'application __CAPGO_KEEP_0__ peut ne jamais observer.

Un diagramme illustrant les trois couches pour la lecture des journaux : la vue Web, la couche natif et le système d'exploitation pour le dépannage d'application mobile.

A CapacitorJS or Electron application produces evidence at several layers, and each layer answers a different question. The WebView can show JavaScript exceptions and failed requests, but it won’t explain every plugin failure. Native logs expose bridge and lifecycle behavior, while the operating system records memory pressure, permission denials, and process termination that application code may never observe.

couche de la vue Web

couche de la vue Web couche de la vue Webcollecter les erreurs de console, les rejets de promesses non gérées, les événements de navigation, les URL de requête, les statuts de réponse et les temps de requête. Un rejet silencieux d'un plugin est particulièrement dangereux. L'interface utilisateur peut continuer à s'afficher même si une opération de caméra, de système de fichiers, de stockage sécurisé ou de notification a déjà échoué.

Le couche native contient les sorties de logcat Android, les enregistrements iOS, les exceptions de pont de plugin, les événements de cycle de vie de l'activité ou du contrôleur de vue, et les traces de crash natives. Electron ajoute le flux de journal de processus principal, les événements d'auto-mise à jour, les échecs de création de fenêtre et les messages IPC. Un erreur de rendu ne sera pas nécessairement visible dans la sortie de console du processus principal, et une panne de processus principal ne sera pas visible dans la sortie de console du rendu. os_log Le

couche OS explique les événements hors du contrôle de l'application. Cherchez la pression de mémoire, la terminaison de fond, les restrictions de batterie, les permissions refusées, les tueurs de processus et les rapports de crash système. Cette couche explique souvent une panne apparente « aléatoire » qui n'a pas d'utilisable pile de JavaScript. Corréler avant de filtrer

Utilisez un ID de requête ou d'opération partagé à travers la vue Web, le pont natif, le backend et le siphon de journal central. Ajoutez l'ID avant que l'utilisateur ne commence une action, puis conservez-le tout au long de la requête réseau et de la callback native. Corréler les horodatages dans un format cohérent, tenez compte du dérive de l'horloge du dispositif et n'appliquez le filtre du bruit de framework qu'après avoir conservé l'événement original.

The

Enregistrez les mêmes champs contextuels dans chaque couche : version de l'application, hachage du bundle web, canal, appareil, système d'exploitation, session et état de la bannière de fonctionnalité. La collecte centralisée signifie que l'essai de reproduction peut être comparé avec les preuves de l'utilisateur au lieu de les remplacer par des hypothèses. Un outil de toolkit d'analyse de logs pratique un outil d'analyse de logs pratique pour le débogage mobile un outil d'analyse de logs pratique pour le débogage mobile

Déboguer la couche qui possède le symptôme. Une écran gelé qui répond toujours aux événements de cycle de vie natifs commence généralement dans la Vue de l'application Web. Une terminaison de processus, une exception de plugin ou une erreur de démarrage appartiennent à l'outil de débogage natif ou au processus principal d'Electron. Passer d'une couche à l'autre sans cette règle de routage crée une activité sans éliminer la cause.

Déboguer la couche qui possède le symptôme

Sur Android, connectez un build de débogage __CAPGO_KEEP_0__ à Chrome et ouvrez

On Android, connect a debuggable Capacitor build to Chrome and open chrome://inspectpendant l'enquête BrowserWindow.webContents.openDevTools() Désormais, vous pouvez déboguer la couche qui possède le symptôme

Les traces de pile de production sont utiles uniquement lorsqu'elles se mappent sur la source. Téléchargez et conservez les cartes de source pour chaque bundle web, puis vérifiez que l'artefact de symbolisation correspond à l'exact hash du bundle. Ajoutez un intercepteur de console contrôlé pour les opérations critiques, mais évitez de logger des informations de connexion, des jetons ou des données personnelles. Capturer les noms d'opération, les identifiants de requête, les classes de réponse et les transitions d'état au lieu.

Passer aux outils natifs lorsque les preuves le suggèrent.

Filtrez Logcat d'Android Studio par le package d'application, puis reproduisez avec la séquence d'action la plus petite possible. npx cap run android --livereload raccourcit le boucle d'itération pour les modifications de WebView, mais il ne valide pas l'artefact natif empaqueté. Sur iOS, exécutez depuis Xcode et utilisez la fenêtre Dispositifs pour les journaux de dispositif. Le Profiler de Temps d'Instruments aide avec le travail de CPU soutenu, tandis que les Allocations aident à identifier la croissance de la mémoire.

Electron a deux cibles de débogage. Utilisez les outils DevTools du rendu pour le comportement DOM, JavaScript et réseau. Utilisez --inspect ou --inspect-brk pour le processus principal, et conservez son sortie stderr pendant le démarrage et les tests d'auto-mise à jour.

Routez par symptôme. Le comportement de l'interface utilisateur commence dans le WebView. La terminaison native commence dans Android Studio ou Xcode. La défaillance de démarrage d'Electron commence dans le processus principal.

Une explication utile de pourquoi cette séparation compte apparaît dans Capacitor’s modèle de pont WebView et natif. Le pont est une limite, pas une surface de débogage unique. Traitez-l’ainsi, et chaque ligne de journal a une meilleure chance de répondre à la question que vous avez.

Premiers Contrôles de Réseau, Stockage et Autorisations

Les équipes vérifient souvent l’API en premier lieu car les erreurs de réseau ressemblent à des erreurs techniques et familières. Cette habitude manque les échecs causés par un état obsolète, des déclarations de permissions modifiées ou une mise à niveau de plateforme qui a modifié le comportement du sandbox. Le contrôle le plus rapide dépend du domaine d'échec.

Pour les problèmes de stockage, storage.estimate() peut révéler la pression de quota, mais ce ne sera pas diagnostiquer tous les problèmes de base de données. Testez un sandbox d'application nettoyé manuellement, puis comparez le comportement avec le profil existant. Capacitor La rotation de la clé d'encryption des préférences peut rendre précédemment des valeurs valides illisibles, tandis que le journal de écriture SQLite à l'avance peut laisser un état endommagé après une interruption brutale. Les applications Electron peuvent également sembler perdre des données lorsque l'upgrade du système d'exploitation change la résolution userData du chemin.

Les permissions méritent la même attention. Les descriptions d'utilisation iOS doivent correspondre à la capacité demandée. Le comportement des permissions Android peut dériver après SDK des changements, et les invites de notification peuvent courir avec l'initialisation de démarrage froid. Le gestionnaire de permissions d'Electron peut rejeter une demande avant que le rendu reçoive une explication utile.

Si un utilisateur dit « ça fonctionnait hier », inspectez le stockage et les permissions avant d'assumer que le réseau a changé.

Les Tests Automatisés et CI comme Systèmes d'Alerte Précoce

Les tests CI détectent les régressions à un coût le plus bas lorsque ceux-ci testent l'artefact que les utilisateurs exécuteront. Un ensemble de tests verts contre un serveur de développement ne prouve pas que le paquet Android signé, l'archive iOS ou l'installateur Electron peuvent démarrer, charger leur bundle et effectuer une opération authentifiée réelle.

Testez la logique partagée et les shells

Utilisez Vitest pour la logique web partagée et Jest pour le comportement du processus principal d'Electron. Pour les Capacitor plugins, testez le contrat JavaScript et la mise en œuvre native séparément, puis ajoutez une couverture d'intégration pour le refus de permission, la disponibilité de matériel, les réponses malformées et l'interruption de cycle de vie.

Playwright peut exercer un bundle web construit. Pour Electron, utilisez Playwright Electron ou un shell de test équivalent contre le binôme empaqueté, et non seulement le rendu servi par un processus de développement local. Le test empaqueté attrape les actifs manquants, les chemins incorrects, les erreurs de signature et les hypothèses de démarrage que les tests de navigateur masquent.

La couverture de dispositif doit refléter votre base d'installation réelle. BrowserStack ou Sauce Labs peuvent exercer un ensemble délibérément sélectionné de profils de dispositif, de systèmes d'exploitation, d'états de permission et de conditions de réseau. L'objectif n'est pas la taille maximale de la matrice. C'est une couverture de failure représentative.

Faites que les échecs soient bloquants

Ajoutez des contrôles explicites pour :

• Les changements de bundle : Rejeter les deltas de taille de bundle inattendus et les cartes de source manquantes.
• Alignement natif : Détection de la dérive de version du plugin et d'incompatibilités minSdkVersion Paramètres.
• Intégrité de l'artefact : Vérifier les signatures, l'identité du package, les actifs intégrés et les manifestes de version.
• Comportement de démarrage : Lancer l'application empaquetée et effectuer une requête d'endpoint authentifiée.
• Comportement de mise à jour : Installer un bundle plus ancien, appliquer la mise à jour candidate, redémarrer et confirmer le comportement de retrait.

Publier chaque résultat à travers un GitHub contrôle de statut pour bloquer la fusion avec un signal rouge. Un build qui passe les tests unitaires mais échoue à la vérification de la signature des artefacts devrait être considéré comme échoué, et non comme « presque vert ».

Le configuration continue pour les Capacitor mises à jour est utile lors de la mise en place de ces vérifications dans une pipeline répétable. La CI n'est pas un substitut pour la télémétrie de production, mais elle réduit le nombre de défauts qui atteignent la mise en production et donne aux ingénieurs en appel moins d'inconnus lors d'une incident.

Actualisations en direct comme un canal de récupération d'urgence

Une régression de production n'a pas toujours besoin d'une nouvelle mise à jour native. Si le défaut se trouve dans le JavaScript, le CSS, le texte, la configuration ou un autre élément web, une mise à jour en direct peut restaurer le parcours utilisateur pendant que l'équipe prépare une mise à jour appropriée. Cela rend la livraison d'actualisations en direct un canal de récupération opérationnel et non simplement une commodité pour les changements cosmétiques.L’exigence de sécurité est le contrôle. Séparez des canaux nommés pour les audiences canari, bêta et stable. Gardez l'ID de l'application native et les contraintes de runtime compatibles explicites, et enregistrez le paquet que chaque audience reçoit. Une mise à jour en direct ne peut pas ajouter une permission native, remplacer un plugin native, modifier le processus principal d'Electron ou réparer une erreur qui se produit avant que l'actualiseur puisse s'initialiser. Ces cas nécessitent toujours une mise à jour de magasin ou d'installateur.

Un diagramme de flux montrant le processus de récupération d'urgence pour les régressions de production d'applications en utilisant les mises à jour en direct pour des corrections plus rapides.

Un flux d'urgence devrait ressembler à ceci :

Confirmez la portée :

1. Identifiez les versions natives affectées, les canaux, les hachages de paquets et les signaux de failure. configuration continue pour les __CAPGO_KEEP_0__ mises à jour est utile lors de la mise en place de ces vérifications dans une pipeline répétable. La CI n'est pas un substitut pour la télémétrie de production, mais elle réduit le nombre de défauts qui atteignent la mise en production et donne aux ingénieurs en appel moins d'inconnus lors d'une incident.
2. Préparez la plus petite mise à jour : Modifiez uniquement le comportement web requis pour restaurer le chemin en panne.
3. Ciblez un public canari : Envoyez le bundle à un canal contrôlé plutôt qu'à chaque installation.
4. Regardez les données de télémétrie : Vérifiez les signaux de crash, de chargement, de requête et d'erreur de mise à jour contre le groupe affecté.
5. Promouvez ou annulez : Étendez uniquement lorsque les signaux restent sains. Rétablissez immédiatement lorsque la mise à jour introduit une nouvelle erreur.

La mise à jour automatique devrait utiliser des seuils de taux de crash ou d'erreur de chargement explicites choisis par l'équipe. Un retrait protège les utilisateurs uniquement lorsque l'actualiseur peut détecter une erreur et que le bundle précédent reste disponible. Gardez l'historique de version et les garde-fous de canal intactes afin que le support puisse expliquer ce qui s'est passé sur un appareil particulier.

Capgo fournit la livraison de bundle web signée, les canaux ciblés, les journaux par appareil, les métriques d'adoption et de failure, l'historique de version et la protection de retrait automatique pour les applications CapacitorJS et Electron. La règle de décision pratique est directe :Utilisez une mise à jour en direct lorsque la correction est confinée au bundle web et que l'actualiseur peut démarrer en toute sécurité ; planifiez une mise à jour native lorsqu'il s'agit du runtime, du plugin, de la permission, du package ou du processus principal est impliqué. Capacitor flux de mise à jour en temps réel descrit la frontière entre ces deux chemins.

Analyse post-incident qui prévient la prochaine

Un bilan rétrospectif mérite sa place lorsqu'il change le système. Écrivez-le pendant que les journaux, le contexte de déploiement et les décisions des opérateurs sont disponibles. Gardez le document factuel, sans faute et suffisamment précis pour que l'ingénieur suivant puisse identifier la garde-fou manquante sans reconstituer l'incident entier.

Utilisez cinq blocs concrets

Chronologie avec des horodatages de télémétrie Enregistrez la première requête échouée, la version affectée, la création de l'alerte, les étapes d'enquête, la mitigation et la récupération. Pour l'incident du tableau de bord Android, la chronologie pourrait montrer que la vue vide est apparue après un déploiement de configuration tandis que iOS continuait à recevoir des réponses valides.

Mode de panne visible par l'utilisateur Describez ce que les clients ont vécu, et non ce que code a fait. « Les utilisateurs Android ont vu un tableau de bord vide après l'authentification » donne plus de directions aux répondants que « API clé de correspondance ». La première description pointe vers le parcours brisé et les signaux qui auraient dû le détecter.

Écart de détection Énoncez pourquoi l'équipe a appris tard. Le suivi des crash peut avoir resté vert car l'application s'est affichée correctement, tandis qu'aucun alerte n'a suivi les échecs de requête authentifiée ou les payloads de tableau de bord vides. Enregistrez le signal manquant et où il aurait dû être émis.

Facteurs non code contributifs Listez les dérives de configuration, le comportement de cache, les horaires de déploiement, les dépendances de service, les modifications de permission ou une course à l'actualisation automatique d'Electron. Ces domaines méritent des vérifications précoce car une panne en production peut survenir sans défaut dans l'application code.

Garde-barrière préventive. Attribuez le test ou le contrôle qui aurait détecté l'incident. Des exemples incluent la validation des informations d'identification de production lors du déploiement, la vérification de la configuration délivrée à partir de clients représentatifs ou l'ajout d'un test de démarrage d'Electron empaqueté. Une garde-barrière nécessite un propriétaire et une condition de panne, et non seulement une phrase dans le bilan.

Les chemins de notification appartiennent à la même revue. Si les alertes par courriel échouent à rejoindre l'équipe, utilisez un outil pratique sur comment empêcher les courriels de passer par le spam dans Gmail pendant la vérification de la notification, vérifiez ensuite le chemin d'alerte. N'attribuez pas la création réussie d'un message comme preuve que l'opérateur a reçu l'alerte.

Attribuez le travail avant de fermer l'incident.

Pour chaque bloc, nommez un propriétaire, une date limite et une méthode de vérification. Revoyez l'incident à nouveau dans les 24 heurescontext

Utilisez ce dernier checklist :

• Avons-nous identifié la version native de build et du bundle web ?
• A-t-on distingué code, la configuration, le déploiement, l'infrastructure et les causes de dépendance ?
• Les données de télémétrie ont-elles montré l'échec visible de l'utilisateur, et non seulement les plantages ?
• A-t-on testé le canal affecté et un canal connu pour être correct ?
• A-t-on ajouté un garde-fou qui faille avant la production ?
• A-t-on documenté si une mise à jour en direct ou une mise en production native était appropriée ?
• Un propriétaire nommé a-t-il vérifié la correction ?

Les plaintes des utilisateurs montrent pourquoi la revue doit couvrir plus que les plantages. Dans un audit de 6 634 applications 6 634-app auditdes échecs de paiement ont affecté 28.6% de la compatibilité des appareils 28.4%de la friction de l'interface utilisateur et de l'expérience utilisateur 25.4%de problèmes de souscription 21.8%, et erreurs d'authentification 17.2%, tandis que les plantages se classent septième à 10.3%. (L'étude de Bright App Data sur les plaintes concernant les applications mobiles) Un processus de dépannage qui ne pose qu'une seule question : « Pourquoi l'application a-t-elle planté ? » peut négliger les échecs empêchant le paiement, l'inscription ou l'utilisation normale du produit.

Les données de stabilité soutiennent le même modèl’opérationnel. Un benchmark place la médiane d'application à 99,95% de sessions sans plantage, avec les meilleures applications à 99.99% et les applications moins performantes à 99,77% ou moins. Il rapporte également une médiane de taux d'ANR de 2,62 par 10 000 sessions, un taux d'excès de mémoire de 1,12 par 10 000 sessions, et les taux d'appuis-bas des applications de 64 à 103 par 10 000 sessions , en fonction du niveau de qualité. (Le benchmark de stabilité mobile ) La stabilité élevée laisse encore des échecs significatifs. Les équipes ont besoin de télémétrie pour les requêtes échouées, les états vides, les blocages, les erreurs d'actualisation et d'autres symptômes utilisateurs.

Un rapport de 2026 indique que les utilisateurs ont déposé 6 fois plus de plaintes concernant les bases de l'application cassées que de demandes de nouvelles fonctionnalités, et que 15,4 % d'abandon après une seule panne tandis que plus de la moitié abandonnent après 2-3 panne. (Le rapport 2026 sur les bases de l'application cassées ) La réponse est pratique : détecter largement, se rétablir rapidement et convertir chaque incident en un contrôle testable.

Utilisez Capgo Pour délivrer des mises à jour de web-bundle signées CapacitorJS et Electron à travers des canaux contrôlés, inspecter la telemétrie par appareil et annuler une correction JavaScript échouée sans attendre une revue de magasin. Connectez-l’à la chaîne de lancement, définissez des audiences stables et canari, et testez le chemin de récupération avant la prochaine panne du tableau de bord.