Déploiement d'applications Ionic : Guide complet pour 2026

Vous avez terminé l'application. Elle fonctionne proprement dans le navigateur, l'interface utilisateur ressent juste, et les flux de base sont stables. Puis le déploiement apparaît et transforme un projet Ionic simple en trois voies de diffusion différentes, chacune avec ses propres outils, règles de signature, processus de revue et stratégie de mise à jour.

Ce sont là où des heures significatives sont souvent perdues. Pas en écrivant des fonctionnalités, mais en assemblant des builds natifs, des hébergements web, des automatisations de lancement et des correctifs post-lancement en un processus que les gens peuvent répéter sans deviner. Déploiement d'applications Ionic La meilleure façon de procéder est de ne plus considérer iOS, Android et PWA comme des projets séparés et de les traiter comme un système de publication unique avec différents résultats.

Sommaire

• Votre application Ionic est maintenant construite, qu'est-ce que vous faites ensuite ?
• Préparation de votre projet pour la production
  • Démarrez par des vérifications d'environnement
  • Verrouillez la configuration Capacitor
  • Générez les actifs une seule fois
• Déploiement natif pour iOS et Android
  • Construire la couche web en premier
  • Flux de travail de publication Android
  • Flux de travail de publication iOS
• Déployer votre application Ionic sous forme de PWA
  • Construire pour le web avec intention
  • Activer le comportement hors ligne avec soin
  • Choisissez un hébergement en fonction de votre flux de travail
• Automatiser les builds avec des pipelines CI/CD
  • Qu'est-ce qui doit figurer dans le pipeline
  • Une forme d'action pratique GitHub
  • L'hygiène des secrets et de la signature
• Envoyer des mises à jour instantanément avec Capgo
  • Quelles mises à jour OTA devraient gérer
  • Configurer les canaux avant votre première incident
  • Envoyer des petites corrections sans toucher le code natif code
• Problèmes et meilleures pratiques de déploiement courants
  • Échecs qui se présentent répétitivement
  • Comportements de mise en production qui préviennent le travail répétitif

Votre application Ionic est construite. Qu'est-ce qu'il faut faire ensuite ?

La plupart des développeurs rencontrent le même point. ionic serve Elle ressemble à une réussite, les appels locaux API fonctionnent, et l'application semble terminée. Elle ne l'est pas. Elle n'a été testée qu'en navigateur, elle n'est pas signée, et elle n'est pas connectée aux contraintes de la revue de l'App Store, de la signature Play et de l'hébergement web de production.

Le déploiement en production change les questions que vous posez. Vous arrêtez de vous demander si l'application s'affiche et vous commencez à vous demander si le bundle est réproducible, si les projets natifs sont synchronisés, si les variables d'environnement sont séparées de manière propre, et si vous pouvez corriger un bug non natif après la mise en production sans créer un éclaboussement de résubmission dans la boutique.

Ce changement compte parce que Ionic se situe dans une voie hybride. Votre application a une couche web, mais les coquilles natives décident toujours comment elle est installée, signée, revue et mise à jour. Les équipes qui traitent le déploiement comme un après-coup finissent généralement par avoir un dérive de configuration entre les plateformes, des projets natifs périmés et des étapes de mise en production manuelles fragiles. Les équipes qui le font bien définissent une voie de mise en production unique pour toutes les cibles et rendent chaque étape spécifique à la plateforme explicite.

Un cycle de vie de déploiement propre ressemble généralement à ceci :

• Préparez le projet configurez Capacitor de manière cohérente avec les identifiants d'application, les icônes, les valeurs d'environnement et les builds de production.
• Créer des artefacts de mise en production natives Utilisez les outils de plateforme pour Android et iOS, et non seulement les commandes Ionic.
• Envoyez un build PWA pour les utilisateurs qui ont besoin d'accès instantané au navigateur.
• Automatiser les parties de routine pour que les builds ne dépendent pas de la mémoire d'un développeur qui doit se rappeler d'une liste de vérifications.
• Planifiez les mises à jour post-lancement pour que les correctifs d'actifs web ne soient pas retardés par la revue de l'App Store lorsqu'ils ne le sont pas.

Si votre application actuelle a l'air encore « d'une application web qui se lance par hasard dans un shell de téléphone », corrigez cela en premier. Une référence utile pour cette transition est ce guide sur la transformation d'une application web en application mobile avec Capacitor.

Votre première soumission réussie de l'App Store provient généralement de la discipline, et non de la malice.

Préparez votre projet pour la production

Avant de générer toute build, traitez le projet comme un candidat à la mise en production. La plupart des déploiements endommagés proviennent de petites incohérences qui étaient sans gravité en développement local et coûteuses en production.

Démarrez par les vérifications d'environnement

Exécutez les éléments de base en premier :

ionic doctor
npm ci
npx cap doctor

ionic doctor catches common CLI and environment issues. npm ci est préférable à npm install pour le travail de mise en production car il installe à partir du fichier de verrouillage exactement comme il a été commit. npx cap doctor aide à mettre en évidence les incompatibilités de plugin et de plateforme avant que Xcode ou Android Studio ne les transforme en erreurs plus difficiles à lire.

Utilisez les builds de mise en production à partir d'un état propre chaque fois que possible. Si l'application ne se construit que après des patchs locaux, des dossiers supprimés ou des fichiers natifs édités à la main, votre processus de déploiement n'est pas encore stable.

Quelques vérifications sont dignes d'être effectuées chaque fois :

• Vérifiez l'ID de l'application. Modification appId Pouvez-vous modifier cela trop tard créer des confusions de magasin et de signature.
• Confirmer l'état du plugin. Les modifications des plugins natifs nécessitent généralement une synchronisation fraîche, et parfois un redémarrage de la plateforme.
• Examiner l'injection d'environnement. Les points de terminaison, les clés et les drapeaux de fonctionnalité API devraient provenir de la configuration spécifique à l'environnement, et non de constantes inline.

Pour une analyse plus approfondie de ce qui doit différer entre les cibles de mise en production, cet article sur les différences entre le développement et la production dans les applications __CAPGO_KEEP_0__ development vs production differences in Capacitor apps Bloquer la configuration __CAPGO_KEEP_0__

Lock down Capacitor config

et la réviser comme l'infrastructure de production, et non comme les métadonnées de l'application. capacitor.config.ts Confirm

A un fichier typique, cela ressemble à ceci :

import type { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  appId: 'com.example.myapp',
  appName: 'My App',
  webDir: 'www',
  bundledWebRuntime: false,
};

export default config;

Trois champs sont importants immédiatement :

Si vous utilisez un serveur de développement local pendant le développement, assurez-vous que la configuration de production ne pointe pas les builds natifs vers elle. Cette seule erreur cause beaucoup d'incidents de type « ça marche en dev, écran vide en release ».

Règle pratique : Si une build de production dépend d'une configuration de serveur local en cours, ce n'est pas une build de production.

Générez les actifs une seule fois

Ne redimensionnez pas les icônes et les écrans de splash manuellement. Utilisez une seule source d'actif de haute qualité et générez les sorties de plateforme à partir d'elle.

Dans les workflows actuels de Capacitor, de nombreux équipes utilisent l'outil officiel de gestion d'actifs à travers l'écosystème CLI. Le paquet exact peut varier en fonction de la version de la pile, mais la discipline est la même : gardez une icône canonique et une source d'écran de splash canonique sous contrôle de version, générez les sorties, puis passez en revue les résultats à l'intérieur de Xcode et d'Android Studio avant la soumission.

Cela évite un mode de failure familier où l'icône PWA est actuelle, Android utilise toujours une ancienne ressource de fond, et iOS affiche une image de démarrage obsolète car un seul dossier n'a jamais été mis à jour.

Un passage de production solide comprend également :

1. Construire vos actifs web en mode production.
2. Synchroniser les projets natifs.
3. Ouvrez chaque IDE natif et inspectez manuellement le nom de l'application, les icônes, les permissions et les paramètres de signature.
4. Testez sur un appareil physique avant de packager quoi que ce soit pour les magasins.

Déploiement natif pour iOS et Android

Le déploiement natif est là où votre application Ionic cesse d'être « juste web » et commence à répondre aux règles du plateau. Le bundle web peut être partagé, mais iOS et Android divergent rapidement une fois que les paramètres de signature, de packaging et les exigences des magasins entrent en jeu.

Construire la couche web en premier

Produisez toujours des actifs web frais avant de toucher le packaging natif :

ionic build
npx cap sync

Certains équipes disent encore ionic build --prod par habitude. Dans les projets modernes, le comportement de production exact dépend de votre outilage de framework, mais le principe est inchangé : générer une build de mise en production optimisée, puis la synchroniser dans les plateformes natives.

Après synchronisation, ouvrez les projets natifs directement :

npx cap open android
npx cap open ios

C'est également un bon moment pour réviser la configuration Android pour les applications Capacitor Si votre projet a toujours une configuration native instable.

Flux de workflow d'Android

La voie de mise en production d'Android est généralement plus prévisible que celle d'iOS, mais elle se brise quand la signature est configurée de manière légère.

Générez une clé de publication une fois et stockez-la de manière sécurisée :

keytool -genkeypair -v -keystore upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias upload

Conservez le fichier de clé de publication, l'alias et les mots de passe dans un magasin de secrets sécurisé. N'en faites pas un commit. N'en laissez pas un message dans un chat de l'équipe. N'assumez pas que quelqu'un d'autre les a sauvés.

Configurez ensuite la signature dans Gradle. Les équipes configurent généralement cela dans les fichiers ou utilisent l'interface utilisateur de signature d'Android Studio, en fonction de la quantité de processus qu'elles veulent scripter. Une configuration typique comprend un bloc et un type de construction de mise en production qui y fait référence. build.gradle L'artefact de mise en production que vous souhaitez généralement pour la soumission sur Play Store est un signingConfigs AAB

et non un APK de débogage. Dans Android Studio, utilisez le chemin de menu pour générer un bundle signé, choisissez la variante de mise en production et exportez l'application bundle. Si vous préférez les builds en ligne de commande, Gradle peut gérer cela une fois la signature configurée. Les pièges courants d'Android se manifestent de manière familière :Le flux de workflow d'Android

La voie de mise en production d'Android est généralement plus prévisible que celle d'iOS, mais elle se brise quand la signature est configurée de manière légère.

• Mot de passe de clé de stockage incorrect produit des échecs de signature qui semblent plus dramatiques qu'ils ne le sont.
• Élimination de la signature de débogage créer des builds qui s'installent localement mais ne sont pas valides pour la mise en ligne de l'appareil
• Plugin désynchronisé s'produit lorsque quelqu'un modifie une dépendance de plugin natif et passe à côté npx cap sync.
• Nom de package incohérent causes des problèmes si l'entrée de l'application Play Console a été créée avec un identifiant différent.

Un modèle qui fonctionne bien est celui-ci : commit web code, construire la couche web, synchroniser natif, construire l'artefact de mise en ligne de la release à partir du projet natif, et archiver l'exacte hache de commit aux côtés du bundle généré.

Flux de travail de mise en ligne iOS

iOS est plus exigeant, et la plupart des problèmes de déploiement proviennent de la confusion sur l'identité de signature plutôt que de code problèmes.

Ouvrez le projet dans Xcode et allez directement à Authentification & CapacitésVérifiez que l'équipe sélectionnée est correcte, que l'identifiant de l'ensemble correspond au registre d'application que vous souhaitez déployer, et que la signature automatique fonctionne comme prévu ou est intentionnellement remplacée par une provisionnement manuel.

Vous vous retrouvez généralement confronté à ces éléments en mouvement :

Pour le travail de libération locale, construisez l'application dans Xcode, sélectionnez un appareil physique ou un appareil iOS générique comme cible, puis choisissez Archiver. Une fois l'archivage terminé, utilisez la fenêtre d'organisation pour valider et distribuer vers App Store Connect.

Si Xcode indique que la signature est brisée, lisez l'ID de bundle exact, l'équipe et les noms de profil avant de modifier quoi que ce soit. La génération aléatoire de certificats rend souvent le problème plus grave.

Si vous n'avez pas un Mac, vous avez toujours besoin d'un environnement macOS pour produire un artefact de libération iOS réel. Dans la pratique, les équipes résolvent cela avec un Mac local, un Mac cloud loué ou un service CI/CD mobile qui exécute des builds macOS pour eux.

Cette étape guidée est un bon point de départ avant votre première archive et soumission :

Une autre leçon difficilement acquise : ne modifiez pas les fichiers natifs générés avec légèreté si vous pouvez l'éviter. Placez les configurations répétitives dans les paramètres de projet appropriés, la configuration du plugin ou les scripts de construction. Les éditions manuelles non documentées sont la raison pour laquelle une libération réussit une fois et échoue la prochaine fois que l'autre développeur synchronise le projet.

Déploiement de votre application Ionic en tant que PWA

Un chemin PWA donne à votre application Ionic la voie la plus rapide vers les utilisateurs. Aucune revue de magasin. Aucune cérémonie de signature. Aucune friction d'installation pour les personnes qui ont besoin d'accès immédiat depuis le navigateur.

Ce niveau de vitesse est utile même lorsque les applications natives restent votre principal canal. Beaucoup d'équipes utilisent la PWA comme surface de distribution parallèle pour les outils internes, les expériences pré-login, les panneaux d'administration ou les marchés où l'installation de l'application ajoute une résistance inutile.

Construire pour le web avec intention

Votre PWA commence par une construction web de production :

ionic build

La partie importante n'est pas la commande elle-même. Il s'agit de s'assurer que le résultat est optimisé, pointe vers les services de production et contient les actifs et le manifeste finals que vous souhaitez envoyer.

Vérifiez ces fichiers avant de les déployer :

• index.html devrait faire référence aux bons actifs compilés.
• manifest.webmanifest devrait comporter le nom de production, les icônes et les paramètres de mise en page que vous souhaitez.
• Fichiers de travailleur de service devraient ne pas exister que si vous prévoyez utiliser la mise en cache hors ligne.
• Sortie de l'environnement devrait faire référence aux points de terminaison en direct, et non aux services locaux ou de mise en scène.

Activer le comportement hors ligne avec soin

Si votre stack Ionic utilise Angular, le service worker Angular est la voie habituelle pour obtenir le support hors ligne et le stockage. C'est puissant, mais il est aussi facile à mal configurer.

Cachez trop agressivement et les utilisateurs restent coincés sur des données obsolètes. Cachez trop peu et l'application ne sent pas résiliente lorsque les connexions deviennent floues. La bonne configuration dépend de l'application. Une coque marketing peut stocker lourdement. Un tableau de bord avec des données opérationnelles changeantes à grande vitesse nécessite une stratégie plus conservatrice.

Traitez le support hors ligne comme une décision de produit, et non comme une case à cocher. Certaines écrans doivent stocker. Certaines doivent toujours récupérer des données fraîches.

Testez des scénarios réels, et non juste des hypothèses à la Lighthouse. Ouvrez l'application une fois, déconnectez le dispositif, relancez-la, et inspectez ce qui fonctionne encore. Ensuite, reconnectez-vous et confirmez que le service worker se met à jour sans piéger les utilisateurs sur une interface utilisateur stagne.

Choisissez l'hébergement en fonction de votre workflow

Pour les PWAs Ionic, les plateformes d'hébergement statique sont généralement suffisantes. Les options que les équipes recherchent le plus souvent sont Netlify, Vercel et Firebase Hosting.

Voici la vue pratique de l'échange :

Un flux de déploiement simple sur l'un d'entre eux ressemble à ceci : connectez le dépôt, définissez la commande de build, définissez le répertoire de sortie, ajoutez les variables d'environnement et vérifiez les règles de reécriture afin que la navigation côté client ne se casse pas lors du rafraîchissement.

Pour les applications Ionic utilisant la navigation basée sur le routeur, la configuration de l'hébergement doit envoyer les chemins non correspondants vers l'entrée de l'application. Si cette reécriture n'est pas configurée, la page d'accueil fonctionne et les liens profonds échouent. C'est l'un des erreurs de déploiement les plus courantes des PWAs.

Automatiser les Builds avec les pipelines CI/CD

Le travail de libération manuel est acceptable une fois. Après cela, cela devient une responsabilité. Quelqu'un oublie une étape de synchronisation, quelqu'un construit à partir d'une branch sale, quelqu'un signe avec la mauvaise configuration, et soudain l'artefact généré ne peut pas être confié.

Les pipelines CI/CD fixent cela en transformant votre séquence de libération en code. Au lieu de se fier à la mémoire, vous définissez exactement comment l'application est construite, synchronisée, testée et emballée chaque fois.

Qu'est-ce qui doit figurer dans la chaîne d'outils ?

Pour les projets Ionic, une chaîne d'outils utile effectue généralement ces tâches dans l'ordre suivant :

1. Installer les dépendances à partir du fichier de verrouillage.
2. Construire l'application web.
3. Syncroniser les Capacitor plateformes.
4. Exécuter les tests ou au moins une validation de base.
5. Produire des artefacts natifs pour la plateforme cible.
6. Stocker ou publier la sortie de la construction.

Cette chaîne est également là où les bonnes habitudes d'infrastructure comptent. Si vos exécutants de construction, votre stockage d'artefacts ou vos étapes de déploiement vous semblent fragiles, ce guide sur l'optimisation des nuages essentielle pour les petites entreprises est digne d'être lu car la même discipline opérationnelle s'applique aux pipelines de livraison mobile. Un pipeline efficace est essentiel pour les projets Ionic. Pour les projets Ionic, une chaîne d'outils utile effectue généralement ces tâches dans l'ordre suivant :

A practical GitHub Actions shape

GitHub Actions is a good default because many Ionic teams already host code on GitHub. The workflow below shows the overall shape for an Android release build.

name: Android Release Build

on:
  push:
    branches:
      - main

jobs:
  build-android:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm ci

      - name: Build web assets
        run: npm run build

      - name: Sync Capacitor
        run: npx cap sync android

      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17

      - name: Build Android bundle
        run: cd android && ./gradlew bundleRelease

Cela ne signe pas une mise à jour par lui-même à moins que vous fournissiez également des matériaux de clé de stockage et une configuration de signature Gradle. C'est intentionnel. La signature doit rester séparée du fichier de workflow public.

Si vous souhaitez une implémentation axée sur les appareils mobiles, cet article sur la mise en place de CI/CD pour les applications CAPGO est directement pertinent. setting up CI/CD for Capacitor apps La partie la plus difficile du CI/CD mobile n'est pas l'écriture de YAML. C'est la gestion des secrets sans créer un incident futur.

Utilisez des secrets de repository ou d'organisation pour :

Les mots de passe de clés de stockage

Les alias de clés

• Les fichiers de clés de stockage encodés
• Le texte de l'article est : A practical CAPGO Actions shape
• CAPGO Actions est une bonne valeur par défaut car de nombreuses équipes Ionic hébergent déjà CAPACITOR sur CLOUDFLARE. La workflow suivante montre la forme générale pour une mise à jour Android.
• API tokens utilisés lors de la mise en production
• Valeurs de construction spécifiques à l'environnement

Un modèl’Android courant consiste à encoder en base64 la clé de signature, à stocker la chaîne codée en secret, à la reconstruire pendant le workflow et à indiquer à Gradle le fichier reconstruit. La même principale s'applique à tout matériau de signature : injectez-le pendant la construction, n'y stockez jamais dans le référentiel.

Le CI/CD devrait éliminer l'erreur humaine, pas centraliser les connaissances tribales cachées. Si seulement un développeur comprend comment les secrets de mise en production s'imbriquent, la chaîne de production est toujours fragile.

Une recommandation pratique : séparez la validation de la mise en production. Laissez les demandes de tirage exécuter l'installation, la vérification de l'indentation, les tests et les builds web. Laissez une branche protégée ou une approbation manuelle déclencher les artefacts de production signés. Cela maintient votre chaîne de production rapide pour le développement normal et contrôlée pour la distribution réelle.

La mise en production des mises à jour instantanément avec Capgo

Les magasins de mise en production sont nécessaires pour les modifications natives de code, les modifications de permissions et tout ce qui modifie le code binaire de l'application. Ce ne sont pas un bon véhicule pour chaque correction de texte, chaque correction de style ou chaque bug JavaScript qui vit entièrement dans la couche web.

C'est pourquoi Mises à jour OTA ont de l'importance dans les projets Ionic et Capacitor. Elles permettent aux équipes de livrer des actifs web mis à jour aux applications installées sans attendre la revue du magasin, tant que la modification reste dans les limites de ce que la coquille native supporte déjà.

Ce que les mises à jour OTA devraient gérer

Utilisez les mises à jour OTA pour les changements comme :

• Corrections de logique JavaScript qui ne nécessitent pas une nouvelle plugin native.
• ajustements CSS pour les maquettes brisées ou les mises à jour de la marque.
• copie de modifications telles que le texte, les étiquettes et le texte juridique.
• échanges d'actifs statiques où l'application sait déjà comment les charger.

Ne les utilisez pas comme un contournement pour des changements réels natives. Si vous ajoutez une nouvelle dépendance native, modifiez les permissions ou modifiez quelque chose que le code du magasin doit contenir, expédiez une mise à jour de magasin normale.

Cette frontière compte car le but de l'OTA est la vitesse avec le contrôle, et non le contournement des règles du plateau de manière irresponsable.

Configurez les canaux avant votre premier incident

Les meilleures workflows OTA utilisent les canauxUn canal de production fournit des mises à jour stables aux utilisateurs. Un canal de test ou bêta reçoit les mises à jour en premier afin que les testeurs internes puissent les valider sur des applications installées réelles.

Cet modèle vous aide à éviter le pire erreur OTA, qui consiste à pousser directement à tout le monde parce qu'une correction semble urgente. Les corrections urgentes nécessitent encore des garde-fous.

Un ensemble typique commence par l'installation de plugins et l'initialisation de l'application selon la documentation du plateau, puis l'affectation de canal en fonction de l'environnement. L'article sur les mises à jour OTA sécurisées pour les magasins d'applications est un bon point de référence pour définir correctement ces limites. Publiez des correctifs sans toucher le __CAPGO_KEEP_0__ natif Une fois l'actualiseur intégré, le workflow pratique devient simple. Construisez les actifs web mis à jour, publiez-les sur le canal prévu, puis laissez l'application récupérer et les appliquer à l'ouverture selon votre politique de mise à jour.

Push small fixes without touching native code

Réglez le CSS dans l'application Ionic.

Exécutez la construction web de production.

1. Publiez les actifs web mis à jour sur le canal de production.
2. Exécutez la construction web de production.
3. Publiez le bundle résultant dans le canal de staging.
4. Testez sur les builds installés.
5. Promouvez ou publiez la même correction pour la production.

Cet approche change la réponse aux incidents. Sans OTA, une erreur de layer web peut vous laisser attendre la revue de l'application et l'adoption de l'utilisateur de la nouvelle version binaire. Avec OTA, vous pouvez corriger les fichiers affectés, les envoyer à l'audience ciblée et observer le déploiement de manière contrôlée.

Les mises à jour rapides ne sont utiles que si vous pouvez les cibler de manière sûre et les annuler lorsque nécessaire.

Les équipes qui bénéficient le plus d'OTA ne sont pas des équipes téméraires. Ce sont des équipes disciplinées avec des limites de libération claires, des canaux nommés et une habitude de traiter les correctifs de layer web comme un flux séparé des libérations natives.

Problèmes de déploiement courants et meilleures pratiques

La plupart des problèmes de déploiement ne sont pas uniques. Ils se répètent dans les équipes parce que les mêmes erreurs se produisent sous pression de délai.

Les erreurs qui se répètent

Les erreurs de signature Android proviennent généralement d'une mauvaise saisie du mot de passe, d'une mauvaise alias ou d'un fichier de clé de signature incorrect utilisé dans la configuration de libération. Lorsque cela se produit, arrêtez de changer les mots de passe aveuglément. Vérifiez d'abord les valeurs du fichier, de l'alias et du secret.

Les erreurs de build iOS proviennent souvent d'une incompatibilité entre l'identifiant de bundle, la sélection de l'équipe, le certificat et le profil de provisionnement. Les messages d'erreur d'Xcode peuvent sembler denses, mais l'incompatibilité est généralement littérale. L'une de ces valeurs ne correspond pas aux autres.

Les écrans vides après l'installation sont un classique. Les causes courantes incluent :

• Application de production pointant vers un serveur de développement au lieu d'actifs embarqués
• Actifs Web non reconstruits avant npx cap sync
• Avant de travailler sur une nouvelle fonctionnalité, créez un problème et discutez-en. Avant de travailler sur une nouvelle fonctionnalité, mentionnez le problème.
• Les modifications de plugin ne sont pas synchronisées dans les projets natifs

Les valeurs de l'environnement de temps d'exécution manquent

dans la version de mise en production réelle

Les habitudes de mise en production qui empêchent le réaménagement

Les meilleures pratiques sont ennuyantes, et c'est pourquoi elles fonctionnent.

Si votre équipe livre des applications Capacitor et souhaite une méthode plus sûre pour livrer des correctifs de la couche web après le lancement, Capgo est valable à évaluer. Il vous donne un flux de travail OTA structuré avec des canaux, des déploiements contrôlés et un support de retrait pour que vous puissiez livrer des mises à jour de JavaScript, CSS, copie et actifs sans transformer chaque petit correctif en une autre soumission de magasin d'applications.