Captures d’écran App Store avec Expo : pourquoi EAS Submit les ignore et comment les livrer rapidement (2026)

Si tu livres une app Expo, ton chemin de release se termine probablement par une seule ligne : eas submit. Elle prend le build produit par EAS et le confie à Apple ou Google. Propre, sans éclat, fiable. Puis tu ouvres App Store Connect pour mettre le build en ligne et — les emplacements de captures d’écran sont vides. À chaque fois.

Beaucoup de gens se heurtent à ça parce qu’EAS donne l’impression de tout faire. Il compile, il signe, il soumet. Sûrement qu’il gère aussi les captures d’écran ? Non, et la documentation le dit clairement. Ce n’est pas un bug ni une fonctionnalité manquante qu’on peut signaler — c’est simplement en dehors du périmètre d’EAS Submit.

Ce qu’EAS Submit fait vraiment (et ne fait pas)

EAS Submit est un service de livraison de binaires. Il uploade exactement une chose : ton archive d’app compilée — un .ipa pour iOS, un .aab pour Android — dans le pipeline de traitement du store. La documentation Expo est explicite sur cette limite :

« EAS Submit uploade ton binaire mais ne gère pas les métadonnées de la fiche store, les captures d’écran ni les notes de version. »

Il existe un outil complémentaire, EAS Metadata, qui peut automatiser certaines parties de ta fiche App Store — nom de l’app, sous-titre, descriptions localisées, mots-clés, URL d’assistance — depuis un fichier de configuration. Il est vraiment utile et vaut la peine d’être configuré. Mais lis attentivement son périmètre : les captures d’écran n’en font pas partie. EAS Metadata pousse du texte, pas des images. Tes captures d’écran, sur les deux stores, restent à ta charge pour les produire et les uploader.

Le problème des captures d’écran avec Expo se décompose donc en deux tâches distinctes, et il est utile de les garder séparées dans ta tête :

1. Capturer — extraire les frames brutes des vrais écrans de ton app depuis un build.
2. Composer & localiser — transformer ces frames brutes en panneaux marketing encadrés, légendés et disponibles en plusieurs langues, tels que les stores les affichent.

EAS ne fait ni l’un ni l’autre. Le guide d’assets store d’Expo te renvoie à capturer les frames toi-même et à concevoir les panneaux dans un outil comme Figma. Parcourons les deux tâches avec des commandes concrètes.

Tâche 1 : capturer les frames depuis un build dev ou preview

Tu veux des captures d’écran de la vraie app, donc tu as besoin de l’app qui tourne quelque part où tu peux la capturer. Pour Expo, cela signifie un dev client ou un preview build — pas Expo Go, car Expo Go affiche l’interface d’Expo Go elle-même et ta configuration native peut différer. Compile et lance localement avec les commandes Expo standard :

• npx expo run:ios — précompile le natif iOS, compile et démarre ton app dans le simulateur iOS.
• npx expo run:android — idem pour un émulateur Android (ou un appareil connecté).

Avec l’app à l’écran dans le simulateur iOS, la capture se fait en une seule commande depuis ton terminal Mac :

xcrun simctl io booted screenshot home.png

booted cible le simulateur en cours d’exécution et écrit un PNG pixel-perfect dans ton répertoire de travail. Deux options importent pour le store : --type=png (la valeur par défaut, et ce que les stores attendent) et --mask=ignored versus --mask=black — le masque contrôle si l’encoche et les coins arrondis sont rendus dans l’image. Pour les uploads App Store, tu veux généralement les pixels rectangulaires plats, puis ajouter le cadre d’appareil ensuite lors de la composition — la capture sans masque est donc habituellement le bon point de départ.

Sur Android, capturez directement depuis l’émulateur (ou l’appareil) avec adb :

adb exec-out screencap -p > home.png

Utilise exec-out, pas shell screencap. Le chemin shell standard pipe le PNG à travers un pseudo-terminal qui corrompt le binaire sur certaines configurations (tu obtiens un fichier corrompu avec des retours chariot parasites) ; exec-out transmet les octets directement et est la forme fiable. Si tu fais tourner plusieurs émulateurs, cible l’un d’eux avec adb -s <serial> depuis adb devices.

C’est tout l’outillage de capture manuelle : deux commandes, une par plateforme, sans dépendances au-delà de Xcode et du Android SDK que tu as déjà pour un build natif Expo.

Tâche 1, automatisée : Maestro ou Detox

Naviguer manuellement jusqu’au bon écran et exécuter ces commandes à la main convient pour une poignée de captures. Dès que tu as huit écrans répartis sur deux classes d’appareils, ou que tu veux des captures régénérées à chaque release pour qu’elles ne dérivent jamais de la vraie interface, tu automatises la capture avec un outil de test end-to-end capable de piloter l’app et de prendre des frames.

Maestro est l’outil qu’Expo lui-même utilise dans ses exemples de workflows EAS documentés. Les flows sont en YAML simple, ce qui maintient la barrière à l’entrée basse. Un flow qui navigue vers un écran et le capture ressemble à ceci :

appId: com.you.yourapp --- - launchApp - tapOn: "Get started" - assertVisible: "Your dashboard" - takeScreenshot: dashboard

Exécute-le avec maestro test flows/home.yaml. La commande takeScreenshot écrit un PNG dans le répertoire de sortie des tests (pointe MAESTRO_TESTS_DIR où tu veux que les assets atterrissent). Les mêmes flows tournent en CI sur EAS Workflows — l’exemple documenté par Expo compile un .apk avec un profil de build e2e-test puis exécute un flow .maestro/ dessus — ce qui te permet de connecter la capture de captures d’écran au même job que ta suite e2e.

Detox est l’autre option établie, avec une API JavaScript plus stricte et plus programmatique :

const path = await device.takeScreenshot('dashboard');

Sois honnête avec toi-même sur la configuration de Detox avec Expo. Detox ne supporte pas officiellement Expo. En pratique, ça fonctionne si tu exécutes npx expo prebuild pour générer les projets natifs et que tu compiles un client de style release (pas un dev client) afin que le bundle JS soit embarqué — puis tu pointes Detox vers ce binaire. C’est plus de pièces mobiles que le YAML de Maestro, et le gain est l’API de synchronisation et d’assertions plus stricte de Detox. Si tu utilises déjà Detox, réutilise-le pour la capture ; si tu choisis pour la première fois et que ton objectif est les captures d’écran du store, Maestro est le chemin le plus léger.

Tâche 1, manuelle : le bon choix pour les releases peu fréquentes

L’automatisation se rentabilise quand tu livres souvent. Si tu sors une à trois releases par an — ce qui décrit la plupart des apps Expo indépendantes — mettre en place des flows Maestro ou une configuration Detox pour capturer des captures d’écran est un travail que tu paies une fois et que tu rentabilises à peine. Pour cette cadence, contente-toi de :

1. Démarrer le build avec npx expo run:ios / run:android, alimenté avec des données de démo réalistes.
2. Naviguer manuellement vers chaque écran phare.
3. Capturer chacun avec la commande simctl / adb ci-dessus.

Vingt minutes de clics valent mieux qu’une demi-journée de configuration d’un harnais de tests que tu auras oublié comment maintenir d’ici la prochaine release. Il n’y a aucune honte à la capture manuelle — les stores ne savent pas comment le PNG a été créé.

Tâche 2 : composition et localisation en 50 langues

Voici la partie que les outils de capture ne touchent délibérément pas, et c’est pourtant la partie sur laquelle les stores te notent vraiment. Un PNG brut issu de simctl, c’est l’interface de ton app sur fond blanc. Ce qui remonte dans les résultats de recherche et convertit sur la page produit, c’est le panneau marketing : la capture d’écran dans un cadre d’appareil, sur un fond coloré à ta charte, avec une légende d’une ligne qui explique l’intérêt de cet écran — généralement présenté en carrousel multi-panneaux qui se lit de gauche à droite. Et sur l’App Store, les captures d’écran sont localisées par taille d’appareil et par langue, donc un lancement sérieux représente des dizaines de variantes, pas cinq.

C’est là que Mokbi s’insère de manière ciblée, et il vaut la peine d’être précis sur la limite. Mokbi ne capture pas ton app — tu produis toujours les frames sources avec les commandes Expo ci-dessus. Ce qu’il fait, c’est prendre ces frames et te permettre, dans le navigateur : de les placer dans de vrais cadres d’appareil, d’ajouter des légendes et des fonds dégradés, de composer des carrousels multi-panneaux, de traduire les légendes en 50 langues en un clic, et d’exporter en lot toutes les dimensions App Store et Play Store à la fois. Tu conçois gratuitement avec un aperçu en filigrane ; l’export illimité est inclus dans un abonnement — Solo €29.99/mo (1 app) ou Studio €49.99/mo (jusqu’à 5 apps), sans achat unique. Il remplace l’étape avec le modèle Figma qu’Expo survole dans son guide — rien de plus, rien de moins.

Le workflow combiné réaliste

1. Compiler un build dev/preview. npx expo run:ios et npx expo run:android, alimentés avec des données de démo correctes.
2. Capturer les frames sources. Manuellement via xcrun simctl io booted screenshot et adb exec-out screencap -p, ou automatisé via takeScreenshot de Maestro / device.takeScreenshot de Detox — idéalement sur EAS Workflows pour qu’elles se régénèrent à chaque release.
3. Composer les panneaux marketing. Encadrer, légender et agencer le carrousel depuis ces frames brutes.
4. Localiser et exporter en lot. Traduire les légendes dans toutes tes langues cibles, exporter toutes les dimensions requises pour les deux stores.
5. Uploader les assets de la fiche. Captures d’écran dans App Store Connect et Play Console ; combiner avec EAS Metadata pour les champs texte si tu l’utilises.
6. Soumettre le binaire. eas submit — la seule étape qu’EAS gère vraiment.
7. Prochaine release : recapturer les écrans modifiés, réouvrir le projet de composition sauvegardé, échanger les frames, réexporter. Les légendes et les traductions restent en place.

Quand tu peux passer l’automatisation

Recours à Maestro ou Detox pour la capture quand la dérive des captures d’écran est un vrai coût : tu livres chaque semaine, ton interface change constamment, ou tu maintiens beaucoup d’apps et tu ne peux pas te permettre des visuels store obsolètes. Dans ces cas, les frames régénérées en CI se rentabilisent et l’outillage de captures d’écran React Native (qu’Expo hérite) vaut l’investissement.

Pour tous les autres — les équipes qui livrent une fois par trimestre — passe. Capture manuelle avec deux commandes en terminal, puis composition et localisation dans le navigateur, te mènent à une fiche soignée en plusieurs langues en une après-midi, sans rien à maintenir entre les releases. Adapte l’outillage à ta cadence, pas à ce qui fait bonne figure sur un tableau de bord CI.

Dans tous les cas, la partie binaire est réglée : eas submit s’en charge. Vérifie tes captures d’écran par rapport aux exigences actuelles du store avant d’uploader — Apple rejette une fiche pour un seul pixel de décalage — et le reste du lancement n’est que de la conception.

À lire ensuite

• Pour les développeurs Expo
• Captures d’écran App Store React Native
• Comparaison : Mokbi vs fastlane
• Tailles de captures d’écran App Store
• Exigences de captures d’écran App Store

Ouvrir l’éditeur →