Votre guide pour le client de développement Expo

Vous êtes généralement prêt pour le client de développement Expo au moment précis où Expo Go commence à vous mentir.

L'application fonctionne dans le sandbox. La mise à jour rapide se sent bien. Ensuite, vous ajoutez une dépendance native, configurez les notifications push, testez un flux OAuth ou essayez de refléter la façon dont votre application de production démarre. Soudain, la lacune devient évidente. Vous n'êtes plus en train de déboguer votre application. Vous déboguez un environnement simplifié.

C'est là que le client de développement Expo change le flux de travail. Il garde le boucle JavaScript rapide que les gens aiment chez Expo, mais déplace la mise en œuvre de tests dans un code natif personnalisé qui se comporte beaucoup plus comme l'application que vous allez finalement envoyer. Pour les développeurs solo, cela signifie moins de surprises tard dans le cycle. Pour les équipes, cela signifie un processus de développement qui peut supporter des builds partagés, des tests de qualité, des environnements de prévisualisation et la validation des mises à jour sans faire semblant que Expo Go peut couvrir tout.

Table des matières

• Pourquoi vous devez aller au-delà d'Expo Go
  • Ce qui casse en premier
  • Pourquoi le client de développement est le prochain pas à faire
  • La mutation de l'esprit
• Prérequis et configuration du projet
  • Commencez par la couche de compte et CLI
  • Installez le package qui rend le flux de travail possible
  • Check your app configuration early
  • Quelle est la bonne première configuration
• Créer votre client personnalisé avec EAS
  • Le flux EAS de base
  • Ce que votre profil de build fait vraiment
  • L'installation du résultat
  • Ce que vous ne devriez pas attendre
• Exécution et débogage avec votre nouveau client
  • Une session de développement normale
  • Les outils de débogage qui comptent
  • Ce qui fonctionne bien et ce qui ne fonctionne pas
• Intégration avec CI/CD et mises à jour en direct
  • Où CI/CD s'insère
  • Le rôle des mises à jour en temps réel
  • Les habitudes de l'équipe qui préviennent la chaos
• Dépannage des pièges et des solutions courants
  • Lorsque le client ne se connecte pas à Metro
  • Lorsque les rebuilds semblent aléatoires
  • Échecs de construction et dérive de l'équipe

Pourquoi vous devez aller au-delà d'Expo Go

Expo Go est utile au début. Il supprime la friction de configuration, permet de démarrer rapidement un projet React Native et donne un boucle de feedback rapide. C'est exactement pourquoi de nombreuses équipes commencent par là.

Le problème commence lorsque l'application cesse d'être un prototype. Expo documente Expo Go comme un salle d'essai et note que cela ne peut pas simuler avec précision certaines capacités natives comme les notifications ou l'authentification OAuth, tandis que le modèle de construction de développement est construit autour de expo-dev-client et positionné comme un Débogage pour applications de production dans le Introduction aux builds de développement Expo.

Qu'est-ce qui cède d'abord

En pratique, la première défaillance est généralement l'une de ces choses :

• Dépendances natives : Un package nécessite une code native que Expo Go ne fournit pas.
• Authentification : Un flux OAuth se comporte différemment une fois que l'application utilise une configuration native réelle.
• Notifications et fonctionnalités de l'appareil : Le sandbox ne reflète pas la façon dont l'application de production demandera des permissions ou recevra des événements.
• Équipe QA : Un testeur a besoin d'un binaire stable qui représente la mise en place native réelle de l'application.

Ce ne sont pas des cas d'extrémité. Ce sont des étapes normales dans un projet mobile réel.

Expo Go est excellent pour prouver une interface. C'est un endroit faible pour valider le comportement de production.

Pourquoi le client de développement est le bon pas suivant

Le client de développement Expo vous donne un binaire d'application personnalisé avec les outils de développement de Expo intégrés. Cela signifie que vous conservez une expérience de développeur solide, mais la couche native est maintenant à vous. Le client installé devient la chose contre laquelle votre équipe test, au lieu de se fier à un conteneur générique.

Cette évolution compte plus qu'elle ne le semble. Une fois que vous passez à un client personnalisé, la question change de « Cette application fonctionne-t-elle dans Expo Go ? » à « Cette application fonctionne-t-elle dans l'application que nous construisons ? » C'est la bonne question.

Si vous comparez également des modèles plus larges de livraison d'applications, l'écriture de Capgo sur une alternative à Expo C'est un contexte utile car il met en avant où les équipes commencent à chercher au-delà des workflows sandbox-first.

Le changement de mentalité

L'erreur la plus courante que je vois est de considérer l'outil de développement Expo comme une tâche de configuration unique. Ce n'est pas le cas. C'est une choix de workflow.

Vous acceptez un compromis pour obtenir le contrôle :

C'est un bon échange dans le développement d'applications professionnelle. Vous arrêtez d'optimiser pour la démo la plus facile et commencez à optimiser pour une livraison fiable.

Prérequis et Configuration du Projet

Avant de construire quoi que ce soit, mettez le projet dans un état qui peut survivre à des builds répétitifs. La plupart des premières tentatives échouées proviennent de la suppression de la configuration de base, et non de l'Expo lui-même.

Développements d'application pour Expo décrivent les builds de développement comme un « environnement de développement complet » Cela reflète un environnement de production réel une fois que les applications dépendent de natives personnalisées code ou d'une QA de niveau production, comme le décrit l'aperçu de Draftbit. Commencez par la couche de compte et __CAPGO_KEEP_0__.

Commencez avec le compte et la couche CLI.

You need two things working before the app layer matters:

1. Expo CLI access
2. EAS CLI access

You’ll also want to be logged into your Expo account from the terminal. Teams often gloss over this because local commands can appear fine until the first remote build or credential prompt appears.

Votre session de compte Expo :

• Votre session de compte EAS : Cela relie le travail local aux services de construction à distance et à la propriété du projet.
• EAS CLI installé : EAS est ce qui transforme votre projet en un binaire partageable iOS ou Android.
• Un projet qui fonctionne déjà localement : N'ajoutez pas de complexité de build avant que le démarrage de l'application base fonctionne.

Installez le package qui rend la mise en œuvre possible

Le centre de cette configuration est expo-dev-client. Sans cela, vous n'avez pas le lanceur personnalisé et la console native axée sur le débogage qui définit le flux de travail du client de développement Expo.

Installez-le dans le projet d'application, puis vérifiez que votre configuration Expo est cohérente. Les commandes exactes peuvent varier en fonction de votre gestionnaire de packages, mais le point architectural est le même : ce package est ce qui transforme l'application de « fonctionne dans un sandbox partagé » en « fonctionne dans notre propre binaire de développement ».

Règle pratique : Construirez le client de développement une fois la liste des dépendances natives stable suffisamment pour que les équipes puissent installer et utiliser la même version binaire.

Vérifiez votre configuration d'application tôt

A lot of confusion comes from treating app.json ou app.config.js as metadata only. It’s not. These files define identity.

Assurez-vous que le projet dispose de :

• Un nom d'application unique : Utile lorsque les développeurs installent plusieurs variantes sur un appareil.
• Un identifiant de paquet ou de bundle unique : Essentiel pour les builds natifs et la signature ultérieure.
• Une intention de l'environnement claire : Si l'équipe utilise des identités de production et de pré-production séparées, reflétez cela intentionnellement.

If your local environment is messy, it’s worth tightening it up before the first build. Capgo’s guide to setting up a Capacitor local environment n'est pas spécifique à Expo, mais c'est un bon rappel que le travail mobile réplicable commence avec des outils locaux stables et une configuration explicite.

Quel est un bon premier paramétrage ?

Utilisez ce checklist avant de démarrer EAS :

Le but n'est pas la perfection. Le but est de rendre la première build ennuyeuse. C'est un gain.

Construire votre client personnalisé avec EAS

C'est le moment où le workflow devient réel. Vous arrêtez de parler d'un client personnalisé et en générez un.

Expo recommande un workflow de build de développement pour les applications avec un client natif personnalisé code: install expo-dev-clientGénérez un client natif personnalisé avec EAS Build ou localement, puis exécutez npx expo start --dev-client. Expo note également dans le workflow d'aperçu que les changements JavaScript seuls restent rapides, tandis que les changements natifs-code nécessitent une nouvelle build de développement.

Le flux EAS de base

La séquence est claire même si la première exécution vous semble étrangère :

1. Installez et authentifiez avec EAS CLI
2. Initialisez ou confirmez la configuration de build
3. Créez un profil de build de développement
4. Déclenchez une build pour iOS ou Android
5. Installez le fichier binaire résultant sur un appareil ou un simulateur

Ce que EAS vous donne, c'est de la cohérence. Au lieu que chaque développeur improvise l'état de build natif local, l'équipe peut produire des fichiers binaires à partir d'une définition de build partagée.

Ce que votre profil de build fait vraiment

A development Le profil n'est pas juste un étiquette. Il indique au système de build que ce binaire est destiné à un développement actif, et non à une distribution dans les magasins.

Cela signifie généralement que l'application installée devrait :

• intégrer le comportement du client de développement
• être facile à lancer pour les développeurs et les testeurs
• se connecter à un serveur Metro pendant le travail quotidien
• restez réutilisable jusqu'à ce que les dépendances natives changent

Lorsque le profil de build existe et se comporte de manière prévisible, vous pouvez le mettre en automatisme.

Si votre équipe réfléchit plus largement à la place de React Native dans les travaux de modernisation plus larges, Wonderment Apps a une perspective utile sur React Native pour la modernisation de l'IA. C'est pertinent car le client de développement devient souvent partie de la couche de base opérationnelle lorsque les équipes livrent des changements de produit plus fréquents sur les surfaces mobiles.

Un court parcours peut aider si vous voulez voir le flux en action :

Installation du résultat

Une fois la build terminée, traitez le résultat comme un véritable fichier binaire d'application, car c'est ce qu'il est.

• Sur Android : Vous installerez généralement un .apk sur un appareil physique ou un émulateur.
• On iOS : Vous travaillerez avec un .ipa ou un simulateur compatible avec l'output en fonction du cible.
• Pour les collègues : Partagez la build via les mécanismes EAS normaux plutôt que de demander à chacun de créer la leur depuis zéro, sauf si nécessaire.

Une build de développement est la plus facile à gérer lorsque l'équipe s'accorde sur une règle : reconstruire pour les changements natifs, pas pour chaque changement de code.

Ce que ne faut pas attendre

N'attendez pas que la première compilation élimine la complexité native. Elle la place dans le bon endroit.

Si vous ajoutez un nouveau module natif, modifiez les permissions, mettez à jour les dépendances natives de niveau SDK, ou modifiez la configuration native pilotée par plugin, vous aurez besoin d'une nouvelle build de développement. C'est normal. Le récompense est que votre travail JavaScript quotidien continue de se déplacer rapidement à l'intérieur d'un client qui reflète votre application.

Exécution et Débogage avec votre nouveau client

La première fois que vous ouvrez votre client installé et que vous le connectez à Metro, la différence est évidente. Cela ressemble à Expo, mais plus longtemps dans le sens du jouet-box.

Commencez le serveur avec npx expo start --dev-client. Ensuite, ouvrez le client de développement sur votre simulateur, émulateur ou appareil physique et connectez-vous via l'interface de lancement. Cet lancement est l'une des importantes modifications introduites par expo-dev-clientAvec l'assistance de débogage comme l'inspection des requêtes réseau, comme documenté dans le page de dev client Expo SDK.

Une session de développement normale

Une session typique ressemble à ceci :

Vous récupérez la dernière branche. Le client de développement installé est déjà sur votre appareil. Vous démarrez Metro, lancez l'application et connectez-vous au serveur actuel. Ensuite, vous travaillez principalement comme avant, en changeant le JavaScript et en voyant les mises à jour rapidement.

La grande différence apparaît lorsque vous avez besoin d'inspecter un comportement qui dépend d'un environnement natif réel. Le client personnalisé vous permet de tester ces flux sans sortir de votre boucle régulière.

Les outils de débogage qui comptent

Les outils supplémentaires ne sont pas décoratifs. Ils résolvent des problèmes quotidiens.

• Interface de lancement : Pratique lors du passage entre environnements ou serveurs hébergés par des collègues.
• Menu du développeur : Fournit les actions attendues lors d'une itération active.
• Inspection de réseau : Aide lorsque l'interface semble brisée mais que le problème réel est une erreur de requête, un état d'authentification ou une mise en relation d'environnement incorrecte.

Lorsque les appels de API échouent dans un client de développement, inspectez le chemin de requête et les hypothèses d'environnement avant de toucher à l'interface code. Le bug est souvent en dehors du composant sur lequel vous vous concentrez.

Voici l'avantage pratique. Un seul fichier exécuté peut valider plusieurs environnements sans recompiler chaque fois. C'est particulièrement utile lorsque le réviseur souhaite tester une prévisualisation de PR, l'ingénieur de test souhaite la version de staging et le développeur souhaite une branch locale.

Si votre équipe embarque également des coques mobiles basées sur le web, Capgo’s ultimate guide to debugging Capacitor apps C'est d'une grande valeur pour l'esprit de débogage plus large. Les outils diffèrent, mais la discipline est similaire : inspecter le comportement de transport, d'environnement et d'exécution avant de supposer.

Quels éléments fonctionnent bien et quels-uns ne le font pas.

Ce qui fonctionne bien :

Ce qui ne fonctionne pas bien :

• Traitant le client comme un déchet : Si l'équipe ne le maintient pas, la confusion se répand rapidement.
• Ignorant les limites de reconstruction natives : Once native dependencies change, stale clients waste time.
• Assuming all connection failures are app bugs: Beaucoup sont des problèmes liés à l'environnement local.

Intégrant avec CI/CD et Mises à jour en direct

Le client de développement Expo devient beaucoup plus précieux lorsqu'il cesse d'être un setup personnel et devient une partie des opérations de l'équipe.

Un flux de travail mature sépare généralement les préoccupations. Les changements natives produisent une nouvelle build de développement. Les changements JavaScript et les actifs se déplacent par un chemin d'actualisation plus rapide. Les examinateurs et la QA n'ont pas besoin de demander si ils testent la bonne chose car l'équipe a convenu de canaux, de profils de build et de destinations d'actualisation.

Où CI/CD s'insère

Le client de développement fonctionne bien avec CI car il donne à l'automatisation une cible stable.

Un modèle courant ressemble à ceci :

• Demandes de mise à jour : Le CI crée ou valide une build de développement lorsque les dépendances natives ont changé.
• Les environnements basés sur branch : Les branches différentes correspondent à différents canaux d'actualisation ou à des cibles de serveur.
• Flux de travail partagé des testeurs : La QA installe un ou plusieurs clients de développement connus et passe de contexte à l'aide du lancement et de la configuration d'actualisation.

Cette structure réduit l'ambiguïté. Les développeurs savent quand ils ont besoin d'une reconstruction. Les testeurs savent si ils valident une modification native ou une mise à jour livrée sur une base binaire existante.

Le rôle des mises à jour en temps réel

Le client de développement est souvent le moyen le plus rapide de gagner du temps opérationnel. Le client de développement est un endroit fort pour valider le comportement de mise à jour avant la mise en production car il peut passer entre les serveurs de développement et les mises à jour publiées dans une coquille d'application similaire à la production, comme décrit plus tôt dans la documentation Expo.

Cela ouvre une utilisation utile de la séparation :

Pour les équipes en dehors de la pile de mise à jour Expo, La guide d'intégration CI/CD de Capgo pour les mises à jour OTA présente un modèl’opérationnel comparable du côté Capacitor. C'est une option pour les équipes qui veulent des canaux de mise à jour contrôlés et une automatisation de la livraison.

Le modèle fiable est simple. Construisez lorsque les modifications natives code sont prêtes. Publiez lorsque le fichier binaire installé contient déjà tout ce dont la modification a besoin.

Les habitudes d'équipe qui préviennent le chaos

La configuration technique compte, mais les règles d'exploitation comptent plus :

• Nommez les canaux clairement : staging, productionet les noms de prévisualisation devraient être évidents.
• Documentez les déclencheurs de reconstruction : Nouveau plugin, changement de permission ou mise à jour native SDK ne devrait jamais être une décision subjective.
• Conservez une stratégie de client installable par environnement : Trop de variantes créent du bruit de support.
• Faire valider explicitement les mises à jour. Quelqu'un devrait vérifier que l'actualisation s'applique et se lance dans le même binaire que l'équipe s'attend.

À ce stade, le client de développement Expo cesse d'être un avantage pour les développeurs et devient une infrastructure de mise en production.

Résolution de problèmes courants et corrections

La plupart des problèmes liés au client de développement Expo sont ordinaires dès que vous savez où chercher. Ils semblent mystérieux car les erreurs se produisent souvent à des frontières : ordinateur portable vers appareil, Metro vers application, configuration native vers runtime JavaScript.

Un des problèmes les plus courants et les moins discutés est la difficulté à se connecter à Metro sur les appareils physiques en raison de la segmentation du réseau local, des VPN ou des règles de pare-feu dans les environnements d'entreprise et de travail distribué, un point mis en évidence dans ce Vidéo de dépannage du client de développement Expo.

Lorsque le client ne se connecte pas à Metro

C'est l'erreur qui brûle le plus de temps car elle ressemble à une application défectueuse lorsque l'application est souvent en bon état.

Vérifiez ces points en premier lieu :

• Mêmes hypothèses de réseau : Les appareils et les ordinateurs portables peuvent sembler connectés tout en étant sur des segments isolés.
• Interférence VPN : Un VPN d'entreprise ou personnel peut rediriger le trafic de manière qui ne convient pas bien à Metro.
• Règles de pare-feu : Les outils de sécurité peuvent bloquer le trafic de développement local sans le faire savoir.
• Politiques de dispositifs d'entreprise : Les appareils gérés restreignent parfois les modèles de trafic sur lesquels les outils de développement dépendent.

Si le projet fonctionne dans un simulateur mais pas sur un appareil physique, soupçonnez le réseau avant de soupçonner votre React code.

Ne déboguez pas les erreurs de connexion à partir de l'application en premier lieu. Confirmez que l'appareil peut atteindre effectivement le serveur exécutant Metro.

Lorsque les rebuilds semblent aléatoires

Un autre problème courant est le sentiment que certaines modifications apparaissent instantanément tandis que d'autres persistent.

Cela signifie généralement que l'équipe n'a pas intériorisé la limite de rebuild :

C'est le flux de travail qui fonctionne comme il le devrait.

Échecs de construction et dérive de l'équipe

Lorsque les constructions échouent, la cause racine est souvent l'une de ces :

• Différence de dépendance : Une version de package ne correspond pas à celle du reste du projet.
• Assumptions de plugins natifs : Un plugin de configuration attend une mise en place que le projet n'a pas.
• Confusion de crédentials : L'accès à l'inscription ou à l'account n'est pas cohérent au sein de l'équipe.
• Attentes locales obsolètes : Quelqu'un suppose qu'une nouvelle build n'est pas nécessaire alors qu'elle l'est.

Capgo’s article sur common live update issues and solutions for developers est une lecture supplémentaire utile pour la partie de lancement de ce problème. Différents stack, même leçon : beaucoup de « bugs d'application » sont en réalité des bugs de livraison, d'environnement ou d'alignement de version.

Le client de développement Expo fonctionne le mieux lorsque l'équipe traite la fiabilité de l'environnement comme partie intégrante de l'ingénierie. Et non comme une pensée après-coup. Une fois que vous faites cela, la mise en place devient prévisible, et prévisible est ce que vous voulez d'un outil de développement mobile.

Si votre équipe développe également des applications Capacitor et a besoin d'une méthode contrôlée pour livrer des mises à jour de JavaScript, d'actifs et de configurations sans attendre l'examen de la boutique. Capgo C'est une option à évaluer. Elle fournit des mises à jour en temps réel, des contrôles de déploiement et des intégrations CI/CD pour Capacitor et Electron.