Development build

Dans eas.json, le profil de développement se reconnaît à "developmentClient": true et en général "distribution": "internal", ce qui produit un APK ou un build ad hoc installable sans store. En local, npx expo run:ios ou run:android compilent le même build si expo-dev-client est dans les dépendances. La question à se poser à chaque git pull : le natif a-t-il changé ? Un nouveau package avec du code natif, un config plugin modifié, un bump de SDK, et le build installé n’est plus bon. Le message « native module not found » après un pull est presque toujours ça.

Une bonne pratique d’équipe est de calculer le fingerprint du projet (@expo/fingerprint, le même mécanisme que la politique de runtime version d’EAS Update) et de l’afficher dans l’app ou de le vérifier en CI, pour savoir quel development build correspond à quel commit. Les équipes qui gardent un build par développeur sur un simulateur pendant des semaines finissent par déboguer des écarts qui n’existent pas.

Le development build n’est pas un build de test : il embarque le dev menu, le launcher et les outils de debug, et ses performances ne représentent rien. Pour les testeurs et le QA, on produit un build preview (release, distribution interne), sans developmentClient.