Dans une vraie app
Le fichier eas.json est la pièce à lire en premier dans un projet. Un setup sain a au moins trois profils : development (developmentClient: true, distribution interne), preview (release, distribution interne, canal preview) et production (canal production, autoIncrement pour le numéro de build). Chaque profil pointe vers un canal EAS Update ; c’est ce lien qui décide quelles mises à jour OTA un binaire recevra par défaut, et il n’est modifiable ensuite que depuis l’app, via Updates.setUpdateRequestHeadersOverride.
Les pièges habituels tiennent aux secrets et à l’environnement : des variables EXPO_PUBLIC_* qui diffèrent entre local et EAS, un fichier google-services.json ignoré par git et donc absent sur le runner (à passer en variable d’environnement de type fichier), ou un .easignore qui exclut par mégarde un dossier nécessaire. Une version de Node, Xcode ou Java épinglée dans le profil (node, image) évite les surprises quand EAS change ses images par défaut.
Pour diagnostiquer un build qui passe en local et échoue sur EAS, eas build --local reproduit le pipeline sur votre machine avec les mêmes étapes. Pour l’audit, je vérifie que les credentials sont gérés par EAS ou au moins documentés, que le profil de production n’embarque pas developmentClient, et que les builds iOS passent sur une image compatible avec la version d’Xcode exigée par Apple pour la soumission.
Termes liés
Prebuild (Continuous Native Generation)
La commande Expo qui génère les dossiers android et ios à partir de app.json et des config plugins, au lieu de les maintenir à la main.
OTA update (EAS Update)
Livrer un nouveau bundle JavaScript et ses assets aux apps déjà installées, sans passer par les stores ; EAS Update est le service d’Expo pour ça.
Development build
Un build debug de votre propre app qui embarque expo-dev-client : vos modules natifs, plus un launcher pour se connecter à Metro.
Runtime version
L’identifiant qui garantit qu’une update OTA n’est appliquée qu’aux builds dont le code natif est compatible avec elle.
CocoaPods
Le gestionnaire de dépendances iOS historique de React Native (Podfile, pod install, .xcworkspace), en maintenance et en cours de remplacement par SwiftPM.
Nos offres sur ce sujet
Migration Expo
Passer une app React Native bare sur Expo : prebuild, config plugins, dev builds, EAS Build et Update. Par PRs, dans votre repo, sans réécrire l’app.
Développement d’app
De l’idée aux stores avec une squad de seniors React Native déjà rodée : cadrage, architecture Expo, design system, CI/CD, publication, passation.