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.

Le programme 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 reproduire la façon dont votre application de production démarre. Soudain, la lacune devient évidente. Vous ne déboguez plus votre application. Vous déboguez un environnement simplifié.

C'est là que le client de développement Expo change le flux de travail. Il conserve 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, des environnements de prévisualisation et la validation des mises à jour sans prétendre que Expo Go peut couvrir tout.

Tableau de Contenu

• Pourquoi vous devez aller au-delà d'Expo Go
  • Ce qui cède en premier
  • Pourquoi le client de développement est le prochain pas à faire
  • Le changement de mentalité
• Prérequis et configuration du projet
  • Démarrez avec le compte et la couche CLI
  • Installez le package qui rend la workflow possible
  • Vérifiez votre configuration d'application dès le début
  • Quelle est une bonne configuration initiale
• Construirez 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 Temps Réel
  • Où CI/CD s'insère
  • Le rôle des mises à jour en temps réel
  • Les habitudes d'équipe qui préviennent la chaos
• Dépannage des pièges courants et corrections
  • When le client ne se connecte pas à Metro
  • When les rebuilds semblent aléatoires
  • Les échecs de construction et la 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, met en route rapidement un projet React Native et donne un boucle de feedback rapide. C'est exactement pourquoi beaucoup d'équipes commencent par là.

Le problème commence lorsque l'application cesse d'être un prototype. Expo documente Expo Go comme un en notant qu'il 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 et positionné comme un expo-dev-client 'Debug' build pour les applications de niveau production dans l'introduction aux builds de développement Expo sandbox builds de développement.

Qu'est-ce qui cède en premier

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

• Dépendances natives : Un package a besoin de code natives que Expo Go ne contient pas.
• L'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 autorisations ou recevra des événements.
• L'équipe QA : Un testeur a besoin d'un fichier binaire stable qui représente la mise en œuvre native réelle de l'application.

Cela ne sont pas des cas d'extrémité. C'est 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 une application binaire personnalisée avec les outils de développement d'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 que votre équipe teste contre, au lieu de se fier à un conteneur générique.

Cette évolution compte plus qu'il n'y paraît. Une fois que vous passez à un client personnalisé, la question change de « Exécute-t-il dans Expo Go ? » à « Fonctionne-t-il 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 est un contexte utile car elle met en évidence où les équipes commencent à regarder au-delà des workflows sandbox-first.

Le changement de mentalité

La plus grande erreur que je vois est de traiter le client 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 gagner le contrôle:

C'est un bon échange dans le développement d'applications professionnelles. Vous arrêtez d'optimiser pour la démo la plus facile et vous 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.

La documentation et les conseils de l'écosystème d'Expo décrivent les builds de développement comme un « environnement de développement complet et doté de toutes les fonctionnalités » ce qui est représentatif d'un environnement de production réel une fois que les applications dépendent de natives code personnalisées ou d'une QA de niveau production, comme abordé dans l'aperçu de Draftbit des outils de développement Expo et des builds de développement Expo dev tools et builds de développement.

Démarrez avec le compte et la couche CLI

Vous avez besoin de deux choses fonctionnant avant que la couche d'application compte :

1. Accès à l'CLI Expo
2. Accès à l'CLI EAS

Vous devrez également être connecté à votre compte Expo depuis le terminal. Les équipes ont souvent tendance à passer sous silence cela car les commandes locales peuvent sembler correctes jusqu'à ce qu'une première build distante ou un prompt de mot de passe apparaisse.

Une configuration propre comprend généralement :

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

Installez le package qui rend la procédure possible

Le centre de cette configuration est expo-dev-client. Sans cela, vous n'avez pas le lancement personnalisé et le shell natif axé 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 « exécution dans un sandbox partagé » en « exécution à l'intérieur de notre propre binaire de développement ».

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

Vérifiez votre configuration d'application tôt

Une grande partie de la confusion provient de la manière dont on traite app.json ou app.config.js les fichiers de métadonnées. Ce ne sont pas des fichiers de métadonnées. Ces fichiers définissent l'identité.

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 : S'il s'agit d'identités de production et de staging séparées, reflétez cela intentionnellement.

S'il votre environnement local est encombré, il est recommandé de le nettoyer avant la première build. Le guide de Capgo sur la mise en place d'un environnement local Capgo n'est pas spécifique à Expo, mais il est un bon rappel que le travail mobile réprouvable commence par des outils locaux stables et une configuration explicite. setting up a Capacitor local environment Utilisez ce checklist avant de démarrer EAS :

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

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

Créer votre client personnalisé avec EAS

C'est à ce stade que le workflow devient réel. Vous arrêtez de parler d'un client personnalisé et en générez un.

Expo recommande un flux de construction de build de développement pour les applications avec des natives code personnalisées installer expo-dev-clientgénérer une application native avec EAS Build ou localement, puis exécuter npx expo start --dev-client. Expo note également dans le aperçu du flux de travail que les modifications uniquement JavaScript restent rapides, tandis que les modifications natives-code nécessitent un nouveau build de développement.

Le flux de base EAS

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

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

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

Ce que votre profil de construction fait vraiment

Un development Un profil n'est pas juste un étiquette. Il indique au système de construction que ce fichier binaire est destiné à un développement actif, et non à une distribution de magasin.

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

• inclure le comportement du client de développement
• s'être facile à lancer pour les développeurs et les testeurs
• se connecter à un serveur Metro pendant le travail quotidien
• restent utilisables jusqu'à ce que les dépendances natives changent

C'est également là où les CI deviennent pratiques. Une fois qu'un profil de build existe et se comporte de manière prévisible, vous pouvez le mettre en œuvre.

Si votre équipe réfléchit plus largement à la place de React Native dans un travail de modernisation plus large, Wonderment Apps a une perspective utile sur React Native pour la modernisation de l'IA. Cela est pertinent car le client de développement devient souvent partie de la couche de base opérationnelle lorsque les équipes expédient 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 le build terminé, 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.
• Sur iOS : Vous travaillerez avec un .ipa ou un simulateur compatible en fonction de la cible.
• Pour les collègues : Partagez la construction à travers les mécanismes EAS normaux au lieu de demander à chacun de créer le leur depuis zéro, à moins que cela ne soit nécessaire.

Une construction 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

Ne vous attendez pas à ce que la première construction élimine la complexité native. Elle la place simplement 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 construction de développement. C'est normal. Le récompense est que votre travail quotidien en JavaScript continue de se dérouler rapidement à l'intérieur d'un client qui reflète votre application.

Exécuter et Déboguer 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.

Démarrer le serveur avec npx expo start --dev-clientAlors ouvrez le client de développement sur votre simulateur, émulateur ou appareil physique et connectez-vous à travers l'interface de lancement. Cet lancement est l'une des importantes modifications introduites par expo-dev-clientEn même temps, le support de débogage comme l'inspection des requêtes réseau, tel que documenté dans la La page Expo SDK pour le client de développement.

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 vous connectez au serveur actuel. Ensuite, vous travaillez principalement comme vous le faisiez avant, en modifiant 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 : Utile lors du passage entre des environnements ou des serveurs hébergés par des collègues.
• Menu du développeur : Gives you the actions you expect during active iteration.
• Inspection de réseau : Aide lorsque l'interface utilisateur semble brisée mais que la vraie question est une erreur de requête, un état d'authentification ou une mise en réseau 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 utilisateur code. Le bug est souvent en dehors du composant sur lequel vous regardez.

Voici l'avantage pratique. Un seul fichier exécutable installé 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 QA souhaite le mode de production, et le développeur souhaite une brancher locale.

Si votre équipe livre également des coquilles mobiles basées sur le web, le guide ultime de Capgo pour le débogage des applications Capgo est à lire pour l'esprit de débogage plus large. Les outils diffèrent, mais la discipline est similaire : inspectez le transport, l'environnement et le comportement de runtime avant de supposer. ultimate guide to debugging Capacitor apps Ce qui fonctionne bien :

Situation

Pourquoi le client de développement est utile

Ce qui ne fonctionne pas bien :

• Considérer le client comme jetable : S'il n'est pas maintenu par l'équipe, la confusion se répand rapidement.
• Ignorer les limites de reconstruction native : Une fois que les dépendances natives changent, les clients obsolètes gaspillent du temps.
• En supposant que toutes les erreurs de connexion sont des bugs d'application : Beaucoup sont simplement des problèmes de l'environnement local.

Intégration 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 partie des opérations d'é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 réviseurs 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 :

• Les modifications de demande de tirage : CI crée ou valide une build de développement lorsqu'il y a des changements dans les dépendances natives.
• Environnements basés sur les branches : Diverses branches correspondent à différents canaux d'actualisation ou à des cibles de serveur.
• Flux de travail partagé des testeurs : Le QA installe un ou plusieurs clients de développement connus et passe par le lanceur et 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 s'ils valident une modification native ou une mise à jour livrée sur une version existante.

Le rôle des mises à jour en direct

Le client de développement permet souvent aux équipes de gagner le plus de temps opérationnellement. Le client de développement est un endroit fort pour valider le comportement de la 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 simulant la production, comme décrit plus tôt dans la documentation Expo.

Cela ouvre une utilisation utile de la division :

Pour les équipes en dehors de la pile d'actualisation Expo, La guide d'intégration CI/CD de Capgo pour les mises à jour OTA montre un modèl’opérationnel comparable du côté Capgo. Il s'agit d'une option pour les équipes qui veulent des canaux de mise à jour contrôlés et une automatisation autour de la livraison des mises à jour. Le modèle fiable est simple. Construire lorsque les changements natives Capacitor sont prêts. Publier lorsque le binaire installé contient déjà tout ce dont le changement a besoin.

The reliable pattern is simple. Build when native code changes. Publish when the installed binary already contains everything the change needs.

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

The technical setup matters, but the operating rules matter more:

• Nommez les canaux clairement : staging, production, et les noms de prévisualisation devraient être évidents.
• Documentez les déclencheurs de reconstruction : Une nouvelle extension, un changement de permission ou une mise à jour native SDK ne devrait jamais être une décision subjective.
• Conservez une stratégie de client installable par environnement : De trop nombreux variants créent du bruit de support.
• Vérifiez explicitement la mise à jour : Quelqu'un devrait vérifier que la mise à jour s'applique et se lance dans le même binaire que l'équipe attend.

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

Troubleshooting des pièges et des solutions courants

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

L'un des problèmes les plus courants et peu discutés est le manque de connexion à 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 les équipes distribuées, un point mis en évidence dans ce Vidéo de dépannage du client Expo.

Lorsque le client ne se connecte pas à Metro

C'est le problème qui consomme le plus de temps car il ressemble à une application défectueuse alors que l'application est souvent en bon état.

Vérifiez d'abord :

• Mêmes hypothèses de réseau : Les appareils et les ordinateurs portables peuvent sembler connectés alors qu'ils sont 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 dispositif d'entreprise : Les appareils gérés peuvent parfois restreindre 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.

N'essayez pas de déboguer les erreurs de connexion à partir de l'application en premier. Confirmez que l'appareil peut effectivement atteindre la machine exécutant Metro.

Lorsque les rebuilds semblent aléatoires

Une autre frustration courante est le sentiment que certaines modifications apparaissent instantanément tandis que d'autres refusent obstinément de le faire.

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

Ceci n'est pas un défaut dans le flux de travail. C'est le flux de travail qui fait exactement ce qu'il doit faire.

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

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

• La désynchronisation des dépendances : Aucune version de package ne correspond à la majeure partie du projet.
• Préjugés de plugins natifs : Un plugin de configuration attend une mise en place que le projet n'a pas.
• La confusion des informations d'identification : La signature ou l'accès au compte n'est pas cohérent au sein de l'équipe.
• Les attentes locales obsolètes : Quelqu'un suppose qu'une mise à jour fraîche n'est pas nécessaire alors qu'elle l'est.

l'article de Capgo sur les problèmes et les solutions de mise à jour en direct courants pour les développeurs est une lecture supplémentaire utile du côté de la mise en production. Même pile, même leçon : de nombreux « bugs » d'application sont en réalité des bugs de livraison, d'environnement ou de version. Le client de développement Expo fonctionne le mieux lorsque l'équipe considère la fiabilité de l'environnement comme partie intégrante de l'ingénierie. Et non comme une afterthought. Une fois que vous faites cela, la mise en place devient prévisible, et c'est ce que vous voulez de la tooling mobile. Si votre équipe livre également des applications __CAPGO_KEEP_0__ et nécessite un moyen contrôlé de livrer des mises à jour de JavaScript, d'actifs et de configurations sans attendre la revue de la boutique,

Si votre équipe livre également des applications __CAPGO_KEEP_0__ et nécessite un moyen contrôlé de livrer des mises à jour de JavaScript, d'actifs et de configurations sans attendre la revue de la boutique,

Si votre équipe livre également des applications Capacitor et nécessite un moyen contrôlé de livrer des mises à jour de JavaScript, d'actifs et de configurations sans attendre la revue de la boutique, Capgo est une option à évaluer. Il fournit des mises à jour en temps réel, des contrôles de déploiement et des intégrations CI/CD pour Capacitor et les workflows Electron.