Votre Guide pour le Client de Développement Expo

Vous êtes généralement prêt pour le client de développement d'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 refléter 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 d'Expo change le flux de travail. Il garde le boucle JavaScript rapide que les gens aiment chez Expo, mais déplace la mise à l'essai 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 Avez Besoin de Passer au-delà d'Expo Go
  • Ce qui casse en premier
  • Pourquoi le client de développement est le prochain pas à faire
  • Le changement de mentalité
• Prérequis et Configuration du Projet
  • Commencez par le compte et la couche CLI
  • Installez le package qui rend le flux de travail possible
  • Vérifiez votre configuration d'application dès le début
  • Quelle est une bonne première configuration
• Créer votre client personnalisé avec EAS
  • Le flux de base EAS
  • Ce que votre profil de build fait vraiment
  • Installer le résultat
  • Ce que vous ne devriez pas attendre
• Exécuter et Déboguer 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égrer avec CI/CD et Mises à jour en temps réel
  • Où s'insère la CI/CD
  • Le rôle des mises à jour en temps réel
  • Les habitudes d'équipe qui préviennent la chaos
• Diagnostic des pièges et des solutions courants
  • Lorsque le client ne se connecte pas à Metro
  • Lorsque 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, 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. Expo documente Expo Go comme un sandwich 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 développement est construit autour de expo-dev-client et positionné comme un “Debug” build pour les applications de production dans l'introduction des builds de développement Expo Une comparaison en tableau des principaux différences et limitations entre les outils Expo Go et Expo Development Client.

Dans la pratique, la première cassure est généralement l'une de ces choses :

Les dépendances natives :

• Un package a besoin de __CAPGO_KEEP_0__ natives que Expo Go ne contient pas A package needs native code that Expo Go doesn’t include.
• Un flux OAuth se comporte différemment une fois que l'application utilise une configuration native réelle Les notifications et les fonctionnalités du dispositif :
• __CAPGO_KEEP_0__ 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 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 teste, 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 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 un contexte utile car elle met en évidence où les équipes commencent à regarder au-delà des workflows de sandbox.

Le changement de mentalité

The biggest mistake I see is treating the Expo development client like a one-time setup task. It isn’t. It’s a workflow choice.

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 aux reconstructions répétées. 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 à l'__CAPGO_KEEP_0__ d'Expo

1. L'accès à l'CLI EAS
2. EAS CLI access

Une configuration propre comprend généralement :

Une configuration propre comprend généralement :

• Votre session d'Expo : 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 iOS ou Android partageable.
• Un projet qui fonctionne déjà localement : N'introduisez pas de complexité de construction avant que le démarrage de l'application fonctionne de base.

Installez le package qui rend la workflow possible

Le centre de cet ensemble 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 votre configuration Expo est cohérente. Les commandes exactes peuvent varier en fonction de votre gestionnaire de package, 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 : Construisez le client de développement une fois que la liste des dépendances natives est stable enough pour que les équipes puissent installer et utiliser le même binaire.

Vérifiez votre configuration d'application dès le début

Une grande partie de la confusion provient du fait de considérer 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 paquet ou de bundle unique : Essentiel pour les builds natifs et la signature ultérieure.
• Une intention d'environnement claire : 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 recommandé de le nettoyer avant la première build. Capgo's guide to configuration d'un environnement local Capacitor ce 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 tableau de contrôle 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.

Créer 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érer un.

Expo recommande un flux de travail de build de développement pour les applications avec des natives code: install expo-dev-clientGénérez une application native avec EAS Build ou localement, puis exécutez npx expo start --dev-clientExpo note également dans l' aperçu du flux de travail 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 simple même si la première exécution peut sembler étrangère :

1. Installer et s'authentifier avec EAS CLI
2. Initialiser ou confirmer la configuration de build
3. Créer un profil de build de développement
4. Déclencher une build pour iOS ou Android
5. Installer le résultat binarisé 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 binaires à partir d'une définition de build partagée.

Ce que votre profil de build fait vraiment

Un 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 l'App Store. development Un

That usually means the installed app devrait :

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

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

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. C'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 :

L'installation du résultat

Une fois le build terminé, traitez la sortie 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 simulateur compatible avec l'output en fonction de la cible.
• Pour les collègues : Partagez la build via les mécanismes EAS normaux au lieu de demander à chacun de créer le leur depuis zéro à moins de besoin.

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

Ce que vous ne devriez pas attendre

N'attendez pas que la première build élimine la complexité native. Elle met 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 build de développement. C'est normal. La récompense est que votre travail JavaScript quotidien 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 de lancement. Cette interface 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 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émarrer Metro, lancer l'application et vous connecter au serveur actuel. Ensuite, vous travaillez principalement comme vous le faisiez avant, en changeant JavaScript et en voyant des 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

The extra tooling isn’t decorative. It solves daily problems.

• Menu de lancement : Utile lors du passage entre les environnements ou les serveurs hébergés par les collègues.
• Menu du développeur : Vous donne les actions que vous attendez pendant l'itération active.
• Inspection du réseau : S'agit-il d'un problème de requête, d'un état d'authentification ou d'une mise en réseau incorrecte ? L'interface utilisateur peut paraître cassée, mais l'erreur réside peut-être dans la demande, l'état d'authentification ou la 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 que 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 de test souhaite la version de staging 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 débogage des Capgo ultimate guide to debugging Capacitor apps __CAPGO_KEEP_0__

Ce qui fonctionne bien et ce qui ne fonctionne pas

Ce qui fonctionne bien :

What ne fonctionne pas bien :

• Considérer le client comme jetable : Si l'équipe ne le maintient pas, la confusion s'installe rapidement.
• Ignorer les limites de reconstruction natives : 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 simplement des problèmes de l'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 configuration personnelle et devient 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 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

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

Un modèle courant ressemble à ceci :

• Les modifications de la demande de tirage : La CI crée ou valide une build de développement native lorsque les dépendances natives ont changé.
• Les environnements basés sur les branches : Differentes branches correspondent à des canaux de mise à jour ou des cibles de serveur différents.
• Le flux de travail du testeur partagé : Le QA installe un ou plusieurs clients de développement connus et change 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 reconstruction. Les testeurs savent si 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 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 d'Expo.

Cela ouvre une utilisation utile :

Pour les équipes en dehors de l'Expo update stack, Guide d'intégration de Capgo CI/CD pour les mises à jour OTA montre un modèle opérationnel comparable du côté Capacitor. C'est une option pour les équipes qui veulent des canaux de mise en production contrôlés et une automatisation autour de la livraison des mises à jour.

Le modèle fiable est simple. Construire lorsque des changements natifs code sont présents. Publier lorsque le binaire installé contient déjà tout ce dont le changement a besoin.

Les habitudes de l'équipe qui préviennent la chaos

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

• Nommer les canaux clairement : staging, productionet les noms de prévisualisation devraient être évidents.
• Documenter les déclencheurs de reconstruction : Une nouvelle extension, un changement de permission ou une mise à jour native SDK ne devrait jamais être un jugement.
• Conserver une stratégie d'un client installable par environnement : Trop de variantes créent du bruit de support.
• Faire la validation des mises à jour explicite : Quelqu'un devrait vérifier que la mise à jour s'applique et se lance à l'intérieur du 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.

Dépannage des problèmes courants et corrections

La plupart des problèmes du client de développement Expo sont ordinaires dès que vous savez où chercher. Ils ont l'air 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 l'incapacité à se connecter à Metro sur des 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 l'équipe distribuée, un point mis en évidence dans ce Vidéo de dépannage du client Expo Dev.

Lorsque le client ne se connecte pas à Metro

C'est l'incident qui brûle le plus de temps car il ressemble à une application brisée lorsque l'application est souvent en bon état.

Vérifiez ces éléments 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 que Metro ne la 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 savoir.
• 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.

Ne débogue pas les échecs de connexion à partir de l'application en premier. Confirme que l'appareil peut vraiment atteindre la machine 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 refusent obstinément de s'appliquer.

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

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

Les échecs de construction et la dérive de l'équipe

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

• Incompatibilité de dépendance: Une version de package ne correspond pas à celle du reste du projet.
• Préjugés de plugin natif: Un plugin de configuration s'attend à une mise en place que le projet n'a pas.
• Confusion des informations d'identification: La signature ou l'accès au compte n'est pas cohérent au sein de l'équipe.
• Attentes locales obsolètes: Quelqu'un suppose qu'une construction fraîche n'est pas nécessaire alors qu'elle l'est.

Capgo's article sur Problèmes et solutions d'actualisation en temps réel pour les développeurs est une lecture complémentaire utile pour la partie de lancement de ce problème. Même pile, même leçon : 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 considère la fiabilité de l'environnement comme une partie de l'ingénierie. Et pas comme une afterthought. Une fois que vous faites cela, la configuration devient prévisible, et c'est ce que vous voulez d'un outil de développement mobile.

Si votre équipe livre également des applications Capacitor et a besoin d'une façon contrôlée de livrer des mises à jour JavaScript, des actifs et des configurations sans attendre la revue de l'application store, Capgo 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.