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 reproduire 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, des environnements de prévisualisation et des validations de mise à jour sans prétendre 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 avec le compte et le niveau CLI
  • Installez le package qui rend le flux possible
  • Vérifiez votre configuration d'application dès le début
  • Quel est un bon premier niveau de configuration
• Création de votre Client personnalisé avec EAS
  • Le flux de base EAS
  • Ce que votre profil de build fait vraiment
  • Installation du résultat
  • Ce que vous ne devez 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 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 beaucoup d'équipes commencent par là.

Le problème commence lorsque l'application cesse d'être un prototype. salle d'essai et note que ce dernier 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 la version de développement est conçu autour de expo-dev-client et positionné comme une “Debug” build for production-grade apps build de débogage pour les applications de niveau production.

Un tableau de comparaison mettant en évidence les principales différences et limitations entre les outils Expo Go et Expo Development Client.

Ce qui casse en premier

• En pratique, la première cassure est généralement l'une de ces: Les dépendances natives : une package a besoin de code natives que Expo Go ne contient 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 autorisations ou recevra des événements.
• Équipe QA : Un testeur a besoin d'un binaire stable qui représente la configuration 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 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 teste, 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 « Cette application fonctionne-t-elle dans Expo Go ? » à « Cette application fonctionne-t-elle dans l'application que nous sommes en train de construire ? » C'est la bonne question.

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

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 professionnelle. 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 aux 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 » qui est représentatif d'un environnement de production réel une fois que les applications dépendent de natives code personnalisées ou de tests de qualité de production, comme couvert dans l'aperçu de Draftbit sur les outils de développement d'Expo et les builds de développement Démarrez avec le compte et la couche __CAPGO_KEEP_0__.

Start with the account and CLI layer

L'accès d'Expo à __CAPGO_KEEP_0__

1. Expo CLI access
2. EAS CLI accès

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

Une installation propre comprend généralement :

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

Installez le package qui rend la workflow possible

Le centre de cette installation est expo-dev-client. Sans cela, vous n'avez pas le lancement 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 la configuration Expo est cohérente. Les commandes exactes peuvent varier en fonction de votre gestionnaire de packages, mais le point architectural n'en change pas : ce package est ce qui transforme l'application de « exécute dans un sandbox partagé » en « exécute dans notre propre binaire de développement ».

Règle pratique : Construirez 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 le même binaire.

Vérifiez la configuration de l'application dès le début

Une grande partie de la confusion provient du fait de traiter app.json ou app.config.js comme des métadonnées uniquement. Ce n'est pas le cas. 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 même appareil.
• Un identifiant de bundle ou de package unique : Essentiel pour les builds natives et la signature ultérieure.
• Nettoyage de l'environnement intention : Si l'équipe utilise des identités de production et de staging séparées, reflétez cela intentionnellement.

Si votre environnement local est encombré, il est utile de le nettoyer avant la première construction. Le guide de Capgo sur la mise en place d'un environnement local Capacitor n'est pas spécifique à Expo, mais c'est un bon rappel que le travail mobile réprouvable commence avec des outils locaux stables et une configuration explicite.

Quel est un bon premier paramétrage ?

Utilisez ce tableau de vérification avant de démarrer EAS :

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

Construire votre client personnalisé avec EAS

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

Expo recommande un flux de construction de développement pour les applications avec un code: install natif personnalisé expo-dev-clientGénérer une application native avec EAS Build ou localement, puis exécuter npx expo start --dev-clientExpo note également dans la vue d'ensemble du flux de travail que les modifications uniquement en JavaScript restent rapides, tandis que les modifications natives-__CAPGO_KEEP_0__ nécessitent une nouvelle mise à jour de développement. Vue d'ensemble du flux de travail Un infographique à quatre étapes illustrant le processus de création d'un client de développement Expo à l'aide d'outils EAS code.

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

Installez et authentifiez avec EAS __CAPGO_KEEP_0__

1. Install and authenticate with EAS CLI
2. Créez un profil de mise à jour de développement
3. Déclenchez une mise à jour pour iOS ou Android
4. Installez le résultat binarisé sur un appareil ou un simulateur
5. Ce que EAS vous donne, c'est de la cohérence. Au lieu que chaque développeur improvise un état de construction native local, l'équipe peut produire des binaires à partir d'une définition de construction partagée.

Expo also notes in the

Qu'est-ce que votre profil de construction fait vraiment

B development Un profil n'est pas juste un étiquette. Il informe le système de construction que ce 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
• ê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

C'est aussi là où le CI devient pratique. Une fois qu'un profil de construction existe et se comporte de manière prévisible, vous pouvez le automatiser.

Si votre équipe pense plus largement à la façon dont React Native s'insère dans un travail de modernisation plus large, Wonderment Apps a une perspective utile sur React Native pour la modernisation de l'IAC'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.

Une courte visite guidée peut aider si vous souhaitez voir le flux en action :

L'installation du résultat

Une fois la construction 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 émulateur.
• Sur iOS : Vous travaillerez avec un .ipa ou un résultat compatible avec le simulateur en fonction du cible.
• Pour les collègues : Partagez la construction par les mécanismes EAS normaux au lieu de demander à chacun de créer le leur depuis zéro à moins de 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 code changement.

What ne pas attendre

Ne vous attendez pas à ce que la première construction élimine la complexité native. Elle place cette complexité dans le bon endroit.

Si vous ajoutez un nouveau module natif, modifiez les permissions, mettez à jour les dépendances natives au 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é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.

Démarrer 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 à travers l'interface utilisateur de lancement. Ce lancement est l'une des importantes modifications introduites par expo-dev-client, aux côtés du support de débogage comme l'inspection des requêtes réseau, comme documenté dans le page de client de développement d'Expo pour SDK.

Une session de développement normale

Une session typique ressemble à ceci :

Vous tirez 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 quitter 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 environnements ou serveurs hébergés par des collègues.
• Menu du développeur : Vous donnez les actions que vous attendez pendant l'itération active.
• Inspection de réseau : Aide lorsque l'interface utilisateur 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 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 que vous regardez.

Voici l'avantage pratique. Un seul fichier binaire 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 la mise en scène, et le développeur souhaite une branche locale.

Si votre équipe livre également des coques mobiles basées sur le web, le guide ultime de Capgo guide ultime de débogage des applications Capacitor Il est recommandé d'inspecter le comportement de transport, d'environnement et de temps d'exécution avant de faire des suppositions.

Ce qui fonctionne bien et ce qui ne fonctionne pas

Ce qui fonctionne bien :

Ce qui ne fonctionne pas bien :

• Considérer le client comme un déchet : Si l'équipe ne le maintient pas, la confusion s'installe rapidement.
• Ignorer les limites de reconstruction native : Une fois que les dépendances natives changent, les clients obsolètes gaspillent du temps.
• Supposer que toutes les erreurs de connexion sont des bogues d'application : Beaucoup sont juste des problèmes d'environnement local.

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

Le client de développement Expo devient beaucoup plus précieux lorsqu'il cesse d'être une mise en place personnelle et devient partie intégrante des opérations d'équipe.

Une workflow mature sépare généralement les préoccupations. Les modifications natives produisent une nouvelle build de développement. Les modifications JavaScript et d'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 dépendances natives modifiées.
• Environnements basés sur branch : Différentes branches correspondent à des canaux d'actualisation ou des cibles de serveur différents.
• Flux de travail de test partagé : La QA installe un ou plusieurs clients de développement connus et bascule de contexte à travers le lancement et la configuration d'actualisation.

Cette structure réduit l'ambiguïté. Les développeurs savent quand ils ont besoin d'une rebuild. Les testeurs savent si ils valident une modification native ou une mise à jour livrée sur une base d'un binôme existant.

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

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 solide pour valider le comportement des mises à 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 d'Expo.

Cela ouvre une utilisation utile :

Pour les équipes en dehors de l'Expo update stack, La guide d'intégration CI/CD de Capgo pour les mises à jour OTA montre un modèle opérationnel comparable du côté Capgo. Il s'agit d'une option pour les équipes qui souhaitent 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 modifications natives Capacitor sont prêtes. Publier lorsque le binaire installé contient déjà tout ce dont la modification 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 :

Nommer les canaux clairement :

• , et les noms de prévisualisation devraient être évidents. staging, productionDocumenter les déclencheurs de reconstruction :
• Une nouvelle extension, une modification de permission ou une mise à jour native __CAPGO_KEEP_0__ ne devrait jamais être un jugement. New plugin, permission change, or native SDK update should never be a judgment call.
• Conserver une stratégie de client installable par environnement : Trop de variantes créent du bruit dans le support.
• Faites la validation de mise à jour explicite : Quelqu'un devrait vérifier que la mise à jour s'applique et démarre à l'intérieur du même binaire que l'équipe 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.

Dépannage des pièges courants et corrections

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 fait de ne pas 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 les équipes distribuées, 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 cassée lorsque l'application est souvent en bon état.

Vérifiez ces éléments en premier :

• 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 que Metro ne tolère pas bien.
• Règles de pare-feu : Les outils de sécurité peuvent bloquer le trafic de développement local sans le faire apparaître clairement.
• Politiques de dispositif 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 ton React code.

N'essaie pas de déboguer les erreurs de connexion à l'intérieur de l'application en premier. Confirme que l'appareil peut vraiment 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 devrait faire.

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

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

• Incohérence de dépendance : Une version de package ne correspond pas à celle du reste du projet.
• Assumptions de plugin natif : Un plugin de configuration s'attend à ce que le projet soit configuré de manière différente.
• Confusion de crédentials : L'accès de signature ou n'est pas cohérent à travers l'équipe.
• Attentes locales obsolètes : Quelqu'un suppose qu'une nouvelle construction n'est pas nécessaire lorsque c'est le cas.

Capgo's article sur les problèmes et solutions de mise à jour en direct courants pour les développeurs est une lecture supplémentaire utile pour la partie de lancement de ce problème. Leçon identique, pile différente : beaucoup de « bogues d'applications » sont en réalité des bogues 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 pas comme une afterthought. Une fois que vous faites cela, la configuration devient prévisible, et prévisible est ce que vous voulez de la mise en œuvre de outils mobiles.

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