Symptôme → solution la plus rapide

Le simulateur iOS s’installe et s’exécute sur macOS, pas sur Windows : la documentation Expo sur le simulateur iOS le précise. Si l’erreur de module natif dans Expo Go vient d’un composant absent de l’application, arrêtez de réinstaller le paquet : passez à un development build, c’est-à-dire votre propre application de développement qui embarque les éléments natifs du projet. Sous Windows, vous pouvez continuer à éditer le code et demander une construction iOS dans le cloud avec EAS Build ; cela ne transforme pas votre PC en simulateur iOS.

Pour qui ? Vous suivez un cours Expo ou React Native et vous venez de rencontrer une erreur de module natif ? Ce guide vous aide à déterminer si Expo Go est encore adapté.

Vous n’avez qu’un ordinateur Windows ou celui de votre école ? Vous pourrez distinguer les essais possibles sur appareil physique, la construction à distance et les tests qui nécessitent réellement un Mac.

Vous avez déjà ajouté une bibliothèque native ? Les étapes de vérification ci-dessous vous permettront de tester le bon type d’application, sans confondre code JavaScript et environnement iOS.

Identifier le type de blocage

Une erreur affichée pendant le lancement ne signifie pas automatiquement que le module natif est absent. Avant de changer d’outil, classez le symptôme : vous éviterez de modifier un projet sain pour traiter le mauvais problème.

L’installation de la dépendance échoue

Si le gestionnaire de paquets signale qu’il ne peut pas récupérer ou installer une bibliothèque, le problème se situe d’abord dans l’installation : nom de paquet, connexion réseau, versions incompatibles ou configuration du projet. Le message survient avant même que l’application essaie d’appeler le module sur un appareil.

Dans ce cas, relever le texte complet de l’erreur est plus utile que de changer immédiatement de mode de lancement. Vérifiez que la dépendance figure dans le projet et que l’installation s’est terminée sans erreur. Si le paquet ne s’installe pas, passer à un development build ne réparera pas, à lui seul, un problème de téléchargement ou de configuration.

L’application démarre, puis JavaScript échoue

Une erreur JavaScript se produit lorsque votre code, ou une bibliothèque JavaScript, n’obtient pas le résultat attendu. Elle peut être liée à une mauvaise valeur, à un import incorrect ou à une fonction appelée dans un contexte inadapté. L’application peut parfois afficher un message explicite ou s’arrêter après une action précise.

Reproduisez le problème avec le même geste, puis regardez la ligne ou l’action mentionnée dans l’erreur. Si le module est reconnu, mais que son utilisation échoue, vérifiez d’abord les paramètres et la manière dont vous l’appelez, en suivant la documentation de la bibliothèque. Changer d’application de test ne corrigera pas nécessairement un bug logique dans votre code.

Le module natif est introuvable à l’exécution

Le cas caractéristique est différent : le projet contient bien le paquet JavaScript, mais l’application indique que le module natif ne peut pas être trouvé ou qu’il n’est pas disponible. Un paquet JavaScript peut servir d’intermédiaire vers du code installé dans l’application. Ajouter le paquet au projet ne signifie donc pas que ce code natif a été ajouté à Expo Go, qui est une application déjà construite.

Expo Go inclut un ensemble défini de bibliothèques natives. Consultez la liste officielle des bibliothèques tierces prises en charge et la FAQ Expo sur les development builds pour vérifier si votre dépendance est utilisable dans Expo Go. Si la bibliothèque a besoin d’une partie native qui n’est pas incluse, répéter l’installation du même paquet ne changera pas le contenu de l’application Expo Go.

Notez aussi le moment où l’erreur apparaît : pendant l’installation, au démarrage, ou après avoir appuyé sur une commande de votre interface. Ces repères vous aideront à séparer un problème de paquet d’une erreur JavaScript et d’une limite de l’application de test.

Passer à son application de développement

Un development build est une version de votre application destinée au développement, avec les dépendances et éléments natifs nécessaires au projet. Il ne s’agit pas d’un greffon que l’on ajoute à Expo Go. Vous lancez une application distincte, construite pour votre projet. Le guide Expo consacré aux development builds explique cette différence et leur rôle.

Dans quels cas quitter Expo Go ?

Faites le changement lorsque la bibliothèque requise ne figure pas parmi les composants utilisables dans Expo Go, ou lorsque votre projet dépend d’une configuration native spécifique. Vérifiez les instructions de la bibliothèque : une dépendance peut nécessiter des étapes de configuration supplémentaires. Le guide Expo sur la personnalisation du code natif aide à repérer les projets qui vont au-delà du JavaScript.

En revanche, si votre exercice porte uniquement sur l’interface et la logique JavaScript, et que les bibliothèques employées fonctionnent dans Expo Go, vous pouvez continuer avec cette application. Il n’est pas nécessaire de passer à un environnement plus complexe juste parce que le cours mentionne React Native ou Expo.

Pourquoi le module reste-t-il introuvable après le changement ?

Un development build n’est pas mis à jour automatiquement dès que vous ajoutez une dépendance native. L’application installée a été construite à partir d’un état antérieur du projet : elle peut donc ne pas contenir les nouveaux éléments nécessaires. Après un changement de dépendance native ou de configuration native, vérifiez si vous devez reconstruire et réinstaller l’application.

À l’inverse, une modification limitée au JavaScript ne signifie pas nécessairement qu’il faut refaire la partie native. Suivez le parcours prévu par votre projet et distinguez ce qui a changé : le code de l’application, ou bien la liste et la configuration de ses composants natifs. La documentation Expo sur l’utilisation d’un development build détaille le cycle de travail associé.

Pour un projet de cours, gardez une note simple des modifications qui ont précédé la panne : paquet ajouté, option de configuration changée, code JavaScript modifié. Vous pourrez alors relier l’erreur à un changement précis, au lieu d’enchaîner les reconstructions sans savoir ce qui a été corrigé.

À retenir : si l’application de développement a été construite avant l’ajout du module natif, un test dans cette ancienne application ne vérifie pas la nouvelle dépendance. Confirmez que l’application installée correspond bien à la version actuelle du projet.

Choisir une voie de test adaptée à votre ordinateur

L’éditeur, le service de construction et l’appareil d’exécution ne sont pas le même outil. Vous pouvez écrire le projet sur Windows, demander à EAS Build de le construire à distance, puis exécuter le résultat sur un appareil compatible. Pour ouvrir le simulateur iOS, il faut toutefois un environnement macOS : une construction cloud ne fournit pas un simulateur Windows.

Option Ce que vous pouvez vérifier Limite à prendre en compte
Expo Go Interface et code JavaScript avec les bibliothèques compatibles Ne contient pas les modules natifs absents de son ensemble intégré
Appareil physique Utilisation de votre application de développement sur un appareil pris en charge Ne remplace pas le simulateur iOS ni les outils Xcode
EAS Build Demander une construction iOS à distance depuis un projet préparé La construction cloud ne fait pas fonctionner le simulateur sur Windows
Mac avec simulateur iOS Tester l’application dans un simulateur iOS et utiliser les outils macOS appropriés Nécessite l’accès à un Mac et un projet configuré pour ce parcours

Expo décrit la construction à distance dans sa documentation sur EAS Build pour les simulateurs iOS. Lisez les prérequis actuels de cette procédure avant de la suivre : les commandes, les versions et les conditions d’accès peuvent évoluer. Ne partez pas du principe qu’une construction iOS réussie signifie que vous pouvez l’ouvrir sur votre ordinateur Windows comme une application Windows.

Sans Mac, peut-on créer une application de développement iOS ?

Vous pouvez continuer à préparer et modifier votre projet sous Windows, puis utiliser une construction iOS dans le cloud lorsque votre projet et votre compte répondent aux conditions documentées. EAS Build effectue alors la construction à distance ; il ne lance pas le simulateur iOS sur votre PC. La documentation officielle des constructions EAS décrit la procédure de construction destinée au simulateur.

Pour un essai sur appareil physique, suivez plutôt la procédure Expo prévue pour installer et ouvrir un development build sur l’appareil concerné. Vérifiez que le type de construction choisi correspond à l’appareil cible. La documentation des development builds et de leur utilisation fournit le cadre général. Les modalités précises dépendent du projet, de l’appareil et des consignes officielles en vigueur ; ne copiez pas une commande trouvée dans un ancien tutoriel sans la vérifier.

Les identifiants et secrets de projet méritent une précaution particulière. Si votre projet utilise des variables d’environnement, consultez la documentation Expo sur les variables d’environnement EAS. Ne publiez pas de clés dans un dépôt accessible à tous et ne transmettez pas des identifiants personnels à un camarade pour contourner une étape de configuration.

Quand un Mac distant devient-il utile ?

Un Mac est pertinent lorsque le cours vous demande réellement de lancer le simulateur iOS, d’utiliser Xcode ou de vérifier un comportement qui n’est pas couvert par votre appareil physique. Il peut aussi servir à réaliser les étapes qui doivent être exécutées dans macOS. Il ne devient pas obligatoire pour apprendre chaque notion Expo, ni pour écrire du JavaScript, ni pour toute bibliothèque native : le besoin dépend du test demandé.

Vous pouvez par exemple continuer à modifier les fichiers sur votre ordinateur habituel et réserver l’accès à macOS aux vérifications qui l’exigent. Avant de choisir, vérifiez que la méthode de connexion, les fichiers du projet et les consignes de votre cours sont compatibles avec ce travail à distance. Si vous comparez cette solution à un achat ou à un autre mode d’accès, consultez les possibilités d’accès à un Mac distant et confrontez-les à la durée réelle de votre projet.

Chaque voie a ses avantages et ses limites :

  • EAS Build vous permet de demander une construction sans disposer d’un Mac local, mais ne remplace pas l’utilisation du simulateur iOS sur Windows.
  • Un iPhone ou un iPad compatible vous permet d’essayer l’application sur un appareil réel, mais ne reproduit pas l’environnement du simulateur.
  • Le Mac de votre école évite de préparer un autre environnement, mais son accès et les logiciels disponibles peuvent dépendre des règles de l’établissement.
  • Un Mac distant peut couvrir une séance de travail macOS sans achat d’une machine, mais vous devez vérifier la compatibilité de votre workflow et la qualité d’accès avant d’en faire votre poste principal.

Vérifier le résultat sur le projet du cours

Une fois le parcours choisi, reprenez le même projet qui provoquait l’erreur. Créer un exemple distinct peut prouver que l’outil fonctionne, mais ne confirme pas que votre projet de cours, avec ses dépendances et sa configuration, est réparé.

Procédez dans cet ordre :

  1. Enregistrez les changements du projet. Vérifiez que le paquet et les éventuelles options requises sont bien présents dans les fichiers du projet. Relisez les instructions officielles de la bibliothèque pour repérer une configuration oubliée.
  2. Choisissez le bon mode d’exécution. Si la bibliothèque exige du code natif absent d’Expo Go, démarrez l’application de développement construite pour le projet, et non Expo Go. Les deux applications ne contiennent pas nécessairement les mêmes composants.
  3. Reconstruisez après une modification native. Si vous avez ajouté une dépendance native ou changé sa configuration depuis la dernière construction, vérifiez la nécessité de reconstruire et de réinstaller l’application. Ne concluez pas que la bibliothèque est incompatible après l’avoir testée dans une ancienne version.
  4. Appelez le module concerné. Déclenchez dans l’interface la fonction qui échouait. Vérifiez que l’application trouve le module, puis que le résultat correspond à ce que le cours demande.
  5. Testez une modification JavaScript. Changez un texte ou un élément d’interface, enregistrez le fichier et vérifiez que l’application reflète la modification selon le flux de développement utilisé. Si seul ce changement échoue, reprenez le diagnostic JavaScript au lieu de reconstruire automatiquement l’application native.
  6. Validez sur la cible demandée. Si le cours exige un simulateur iOS, effectuez la vérification dans un environnement macOS capable de l’exécuter. Si l’objectif est seulement de confirmer une fonction sur un appareil physique, consignez le modèle d’appareil et le type d’application utilisés. La documentation Expo sur les simulateurs iOS rappelle la limite de plateforme.

À la fin, notez ce qui a été testé : l’application utilisée, l’appareil ou le simulateur, le module appelé et le résultat obtenu. Cette trace est utile si l’enseignant ne reproduit pas votre problème ou si vous devez revenir à une version précédente du projet. Elle évite aussi de confondre « le projet se construit » avec « le module fonctionne sur la cible de test ».

Si le cours n’exige pas le simulateur, ne compliquez pas votre environnement avant d’en avoir besoin : gardez Expo Go pour les exercices compatibles, ou choisissez une construction et un appareil adaptés au module. Si, en revanche, vous devez examiner l’application dans le simulateur ou utiliser Xcode, un ordinateur Windows seul ne couvre pas cette étape. Acheter un Mac uniquement pour une validation ponctuelle peut être disproportionné ; EAS Build construit à distance, mais ne remplace pas le simulateur local. Un Mac d’école peut suffire si vous y avez accès au bon moment. Si vous avez besoin d’un environnement macOS pour terminer cette vérification, vous pouvez comparer les conditions d’accès proposées par MACCOME, puis ne retenir cette option que si votre projet et votre cours s’y prêtent.