Expo SDK 58 : échec EAS Build iOS, diagnostic 2026

Symptôme : après la mise à niveau vers Expo SDK 58, EAS Build échoue sur iOS. Première réponse : récupérez le journal Xcode complet et cherchez la première erreur exploitable, avant de modifier la configuration. Vérifiez ensuite les changements de migration, les fichiers transmis, les variables d’environnement et les identifiants de signature. L’échec ne prouve pas que la mise à niveau en est la cause.

Ce diagnostic s’adresse aux indépendants et petites équipes dont la compilation iOS EAS ne se termine plus après une mise à niveau. Il convient aussi aux projets utilisant des config plugins, un répertoire iOS maintenu manuellement ou des modules natifs. Enfin, il aide les personnes sans Mac local à décider si une reproduction interactive est réellement nécessaire.

Dernière vérification : 6 novembre 2026, à partir du journal officiel des changements d’Expo SDK 58, de la documentation de dépannage et de compilation iOS d’Expo et des exigences système actuelles de Xcode publiées par Apple.

Expo SDK 58 : diagnostiquer l’échec EAS Build iOS par son étape

Le message de fin de compilation est rarement un diagnostic suffisant. Il faut d’abord déterminer si EAS s’est arrêté pendant l’installation, la génération native, la compilation Xcode, l’archivage, la signature ou l’envoi vers la boutique. Ces étapes n’impliquent pas les mêmes fichiers ni les mêmes corrections. La documentation du processus de compilation iOS d’EAS aide à replacer les lignes du journal dans leur contexte.

Commencez par ouvrir la compilation concernée dans le tableau de bord EAS et téléchargez le journal complet. Le résumé visible dans la page peut masquer le premier message déterminant. Dans le fichier téléchargé, remontez depuis l’échec final jusqu’à la première erreur qui nomme un fichier, un paquet, une commande ou une configuration précise.

Un extrait de journal peut ressembler à ceci ; il s’agit d’un exemple schématique, pas d’un résultat de test :

[phase d’installation] ...
[phase de génération iOS] ...
[phase de compilation Xcode] ...
error: échec explicite lié à une dépendance ou à un fichier
[phase de synthèse] compilation échouée

La ligne de synthèse confirme l’échec, mais ne désigne pas nécessairement sa cause. Notez le nom de la phase, le premier message d’erreur concret, le commit compilé et le profil EAS employé. Comparez ensuite ces éléments au dernier état connu comme fonctionnel.

Première vérification : établir un état de référence

Avant de changer quoi que ce soit, conservez le commit, le journal intégral et le profil de compilation. Dans le dépôt, ces commandes aident à consigner l’état suivi par Git :

git rev-parse HEAD
git status --short
git diff -- package.json app.json app.config.js eas.json

Les résultats ne décrivent ni les fichiers non suivis ni les secrets injectés par le service. Il faut donc les compléter par une vérification des variables et de l’archive de compilation. Ne copiez jamais la valeur d’un secret dans un rapport ou une capture d’écran.

Les changements SDK 58 ne désignent pas automatiquement la cause

Les notes de migration d’Expo SDK 58 présentent des changements susceptibles d’affecter certains projets. Cela ne signifie pas que tous les projets subissent la même rupture, ni que chaque échec apparu après la mise à niveau est dû au SDK. Consultez le journal officiel de SDK 58, puis reliez chaque changement à une fonctionnalité, une configuration ou un chemin de code réellement utilisé.

Cette nuance est particulièrement importante si l’application possède un répertoire iOS modifié à la main. Un projet qui génère ses fichiers natifs à partir de sa configuration ne suit pas nécessairement la même voie qu’un projet où l’équipe maintient directement ces fichiers. L’état du dépôt, les config plugins et les modifications apportées à AppDelegate peuvent changer l’interprétation d’un même message.

Pour un projet généré, inspectez les entrées de configuration et les sorties natives produites par les plugins concernés. Si un plugin est impliqué, comparez son paramétrage et la version de sa dépendance avec le commit qui compilait. Si l’équipe modifie directement le répertoire iOS, examinez aussi ces changements locaux : une migration peut exiger une adaptation ciblée, pas une régénération aveugle.

Les notes de SDK 58 évoquent également les exigences de cycle de vie liées aux scènes pour les applications utilisant le SDK iOS 27. Consultez les conditions et limites décrites dans le journal officiel déjà cité et vérifiez les exigences de la version Xcode concernée dans la page des configurations système de Xcode. N’approfondissez cette piste que si l’application utilise le chemin de code ou le comportement concerné ; ce point ne constitue pas une preuve de panne généralisée.

Quand EAS ne reçoit pas les fichiers attendus

Un projet peut fonctionner sur une machine et échouer dans le service distant parce que le fichier nécessaire n’a pas été inclus dans l’archive envoyée. Un fichier non suivi, exclu par Git ou par les règles EAS, ou créé uniquement sur la machine locale n’est pas automatiquement disponible au serveur de compilation. Vérifiez ce qui fait partie du dépôt et les règles d’exclusion avant de changer des dépendances.

La documentation sur l’inclusion et l’exclusion des fichiers avec .easignore précise comment préparer les fichiers transmis. Comparez les règles du projet à l’erreur précise : fichier de configuration absent, ressource introuvable ou module impossible à résoudre. Ne supposez pas que le contenu visible dans votre environnement local est identique à celui que reçoit EAS.

Séparez ensuite les étapes. Un échec pendant l’installation ne se corrige pas en modifiant la signature. Une erreur de compilation native ne se résout pas nécessairement en régénérant le JavaScript. Repérez la première phase fautive dans le journal, puis vérifiez uniquement les éléments qui entrent dans cette phase.

Les variables d’environnement méritent un contrôle distinct. Comparez leurs noms, leur disponibilité pour le profil et leur contexte d’utilisation avec la documentation des variables d’environnement EAS. Faites cette vérification sans afficher les valeurs sensibles. Si la configuration dépend d’une variable absente, une compilation locale peut réussir tout en produisant une configuration distante différente.

Trois comparaisons pour choisir la prochaine vérification

Les comparaisons ci-dessous ne remplacent pas le journal ; elles évitent de mélanger des causes indépendantes. L’objectif est de vérifier une hypothèse à la fois et de garder une trace des changements.

Relevez les versions utiles, sans confondre une version déclarée dans un fichier avec celle réellement utilisée :

node --version
npm --version
xcodebuild -version

La dernière commande n’est pertinente que sur un Mac équipé de Xcode. Comparez son résultat aux exigences de la version de Xcode et du SDK iOS visés, en vous appuyant sur les exigences système publiées par Apple. Ces informations décrivent l’environnement ; elles ne révèlent pas à elles seules la cause d’un échec.

La compilation locale n’est pas une preuve contre EAS

Une compilation locale aboutie constitue un indice utile, mais pas une conclusion. Elle ne démontre pas que l’archive envoyée à EAS contient les mêmes fichiers, que les variables du service sont correctes ou que les outils sont identiques. La procédure de compilation locale EAS peut servir à rapprocher certaines étapes de la compilation, mais elle ne reproduit pas automatiquement chaque condition du service distant.

Si un Mac est disponible, utilisez-le pour comparer le commit, les dépendances et la construction native. Si l’erreur se produit uniquement dans EAS, conservez les journaux et contrôlez d’abord les variables, l’archive et les versions d’outils. Une reproduction locale négative signifie seulement que le problème ne s’est pas reproduit dans cet environnement précis.

Un arbre de décision pour éviter les corrections au hasard

Choisissez la branche correspondant au premier échec démontré par le journal. Si plusieurs indices apparaissent, traitez d’abord la phase la plus précoce : les étapes ultérieures peuvent simplement échouer parce qu’une étape précédente n’a pas fourni son résultat.

• Si la première erreur apparaît pendant l’installation, vérifiez le manifeste, le fichier de verrouillage, les versions de dépendances et le contenu envoyé. Sinon, passez à la génération native.
• Si la génération native échoue, vérifiez si le projet génère ou maintient son répertoire iOS, puis examinez les config plugins et les changements de migration effectivement utilisés. Sinon, passez à la compilation Xcode.
• Si Xcode échoue sur un fichier ou module précis, remontez à ce code et à la dépendance qui le fournit. Comparez les outils Xcode réellement employés avant de modifier les certificats.
• Si l’archive ou la signature échoue, contrôlez séparément les identifiants de l’application, l’équipe Apple sélectionnée et les identifiants de signature. N’effacez pas les certificats pour résoudre une erreur de compilation qui les précède.
• Si la compilation aboutit, mais que l’application plante, classez le problème comme une erreur d’exécution. Reproduisez-le avec une version de production et les journaux de l’appareil ; ne traitez pas le plantage comme un échec EAS.
• Si seul EAS échoue et que l’erreur dépend de Xcode ou de fichiers natifs, reproduisez cette partie sur un Mac dont les outils sont rapprochés de l’environnement attendu. Si l’écart vient d’une variable ou d’un fichier absent, corrigez plutôt le profil ou l’archive.

Cette méthode limite les changements à une hypothèse vérifiable. Elle réduit aussi le risque d’introduire une panne supplémentaire en modifiant simultanément la configuration, les plugins et la signature.

Signature, archive et erreur après installation : trois problèmes distincts

Une erreur de certificat ou d’équipe intervient à un autre niveau qu’une erreur de compilation. Examinez le point précis où le processus s’arrête et vérifiez que l’identifiant de l’application correspond au projet et à la configuration de signature attendus. Une révocation ou une création de nouveaux certificats sans lien avec le message d’erreur peut compliquer le diagnostic sans réparer le problème initial.

Après une correction, relancez la compilation depuis le même commit, avec le même profil et les mêmes variables, en ne changeant que l’élément concerné. Vérifiez séparément que l’archive est créée, qu’elle est signée comme prévu et que son envoi vers l’étape suivante aboutit. Un résultat différent après plusieurs modifications ne permet pas d’identifier laquelle a réellement corrigé la panne.

À l’inverse, si l’application se compile, s’installe puis se ferme ou présente un écran inattendu, le problème concerne l’exécution. Utilisez les conseils de dépannage iOS d’Expo pour examiner la compilation de production et les journaux de l’appareil. Le changement de cycle de vie des scènes associé à SDK 58 ne devient une piste que si le code du projet emprunte effectivement le chemin concerné.

Questions fréquentes sur le dépannage d’EAS Build

Quel journal donne le meilleur indice après un échec ?

Téléchargez le journal iOS/Xcode complet depuis les détails de compilation EAS. Le résumé final est utile pour confirmer l’échec, mais la première erreur concrète indique généralement quelle étape examiner. Cherchez un nom de fichier, un module, une commande ou une valeur manquante, puis comparez cette ligne à la phase correspondante du processus.

Pourquoi la compilation locale réussit-elle quand EAS échoue ?

Comparez le commit réellement compilé, les versions des outils, le fichier de verrouillage, les variables et les règles d’archive. Il est possible que le Mac local ait un fichier non suivi ou une variable absente du profil EAS. Conservez les deux journaux et vérifiez ces écarts avant d’attribuer la cause au service distant.

Comment vérifier un config plugin ou une dépendance native ?

Reliez le message d’erreur à un paquet, un fichier natif ou une sortie de génération précis. Examinez la configuration du plugin et la modification de migration associée, puis vérifiez que cette fonctionnalité est utilisée par le projet. Si le répertoire iOS est maintenu manuellement, incluez ses changements dans la comparaison au lieu de supposer qu’il est régénéré.

Que faire si aucun Mac local n’est disponible ?

Vous pouvez commencer sans Mac : conservez l’identifiant du commit et le journal complet, vérifiez l’archive, les dépendances et les variables, puis suivez la phase fautive. Si le problème exige une inspection native dans Xcode, un Mac distant permet une reproduction interactive. Cette démarche complète le diagnostic, mais ne prouve pas que l’environnement reproduit toutes les conditions EAS.

Choisir entre EAS, un Mac local et un Mac distant

EAS évite à l’équipe de maintenir en permanence une machine de compilation, mais ses résultats dépendent du commit, de l’archive et du profil distant. Un Mac local offre un accès direct à Xcode et aux fichiers natifs, au prix de l’achat, de la maintenance et de la disponibilité de la machine. Un Mac distant peut convenir lorsqu’il faut examiner un projet iOS, reproduire une compilation native ou inspecter une archive sans acheter de matériel ; il ne remplace pas l’analyse des variables et journaux du service EAS.

Si la panne vient uniquement d’une dépendance ou d’une configuration, corrigez le projet et relancez EAS : louer un Mac n’apportera pas la solution. En revanche, lorsque l’erreur nécessite Xcode, des outils natifs ou une session interactive, la location peut éviter de réserver un Mac personnel à un dépannage ponctuel. Vous pouvez comparer les options d’accès Mac proposées par OnceMac et consulter les informations sur les centres de données OnceMac pour vérifier si cette approche convient à votre situation. Si la compilation doit rester stable et intensive dans la durée, évaluez aussi le coût et les contraintes d’un Mac dédié plutôt que de choisir la location par défaut.

La décision immédiate reste fondée sur le premier échec observable : corrigez les fichiers et variables lorsqu’ils diffèrent, inspectez les plugins si la génération native échoue, et réservez la reproduction sur Mac aux erreurs qui demandent réellement Xcode ou une vérification native.

Questions fréquentes