Des captures d’écran propres depuis le simulateur iOS et l’émulateur Android

Pour obtenir une capture propre du simulateur iOS, forcez la barre d’état avec xcrun simctl status_bar booted override --time 9:41 --batteryState charged --batteryLevel 100, puis capturez avec xcrun simctl io booted screenshot. Sur Android, activez le mode démo de l’interface système via adb, qui fige l’horloge, remplit les icônes de batterie et de signal et masque les notifications, puis capturez avec adb exec-out screencap -p.

Voilà pour la barre d’état. Une capture prête pour le store demande aussi la bonne taille d’appareil, un format de fichier que le store accepte et un écran rempli de données crédibles. Ce guide passe tout ça en revue, avec des commandes à copier-coller.

Pourquoi la barre d’état compte dans les captures d’écran du store

Une capture prise pendant le développement garde tout ce que faisait le simulateur à ce moment-là : 14:17, 34 % de batterie, un nom d’opérateur, une icône de notification égarée. Rien de tout ça n’est faux, mais ça fait inachevé, et ça détourne le regard de la partie de l’écran qui compte.

Google est très clair là-dessus. Ses consignes sur les éléments graphiques demandent de nettoyer la barre de notifications pour qu’elle affiche une batterie, un Wi-Fi et un réseau cellulaire pleins, sans aucune notification. Apple ne formule pas de règle sur la barre d’état, mais l’heure 9:41 est la convention de son propre marketing, et une barre d’état identique sur toutes vos captures donne à la série un air cohérent.

Comment afficher 9:41 dans la barre d’état du simulateur iOS

La commande simctl status_bar fait partie de Xcode depuis plusieurs versions. Nous avons vérifié les options ci-dessous avec xcrun simctl status_bar help dans Xcode 27. Démarrez le simulateur voulu, puis lancez :

xcrun simctl status_bar booted override \
  --time 9:41 \
  --dataNetwork wifi \
  --wifiMode active --wifiBars 3 \
  --cellularMode active --cellularBars 4 \
  --operatorName '' \
  --batteryState charged --batteryLevel 100

booted cible le simulateur en cours d’exécution. Si plusieurs sont démarrés, passez plutôt son UDID (obtenu avec xcrun simctl list devices booted). Chaque option est facultative, mais il en faut au moins une.

Vérifiez ce qui est appliqué avec xcrun simctl status_bar booted list. Quand vous avez terminé, revenez à la normale :

xcrun simctl status_bar booted clear

Le réglage survit aux relances de l’app : vous pouvez le définir une fois et capturer toute une série. Réinitialiser le simulateur l’efface.

Capturer l’écran iOS à la bonne taille

xcrun simctl io booted screenshot shot.png enregistre l’écran du simulateur à sa taille native en pixels. Le contour du simulateur et le cadre de l’appareil ne sont pas inclus ; vous obtenez uniquement l’écran. C’est donc l’appareil que vous choisissez qui détermine si App Store Connect accepte le fichier.

Choisir un simulateur qui correspond à une taille acceptée

Les spécifications des captures d’écran d’Apple listent les tailles exactes en pixels de chaque emplacement. L’emplacement que la plupart des guides appellent 6,9 pouces (App Store Connect l’intitule désormais « iPhone with Dynamic Island, large display ») accepte 1260 × 2736, 1290 × 2796 et 1320 × 2868 en portrait. Quand nous avons capturé depuis un simulateur iPhone 17 Pro Max, le fichier faisait 1320 × 2868 : il convient donc à cet emplacement sans redimensionnement. Pour l’iPad, un simulateur iPad Pro 13 pouces correspond à l’emplacement 13 pouces, qui accepte 2064 × 2752 et 2048 × 2732. Notre référence des tailles de captures d’écran liste les autres.

Si vous préférez créer un appareil dédié aux captures, pour ne pas toucher à votre simulateur de tous les jours :

xcrun simctl create store-shots "iPhone 17 Pro Max"
xcrun simctl boot store-shots
open -a Simulator

Éviter l’erreur de transparence

Le PNG écrit par simctl contient un canal alpha, même si chaque pixel est opaque. Les spécifications d’App Store Connect indiquent que les images ne peuvent contenir ni canal alpha ni transparence. Si vous importez la capture directement, enregistrez-la plutôt en JPEG :

xcrun simctl io booted screenshot --type=jpeg 01-home.jpg

# or convert an existing PNG on macOS
sips -s format jpeg 01-home.png --out 01-home.jpg

Si la capture passe d’abord par un outil de design, gardez le PNG ; c’est le fichier exporté qui doit être sans alpha.

Comment obtenir une barre d’état propre sur l’émulateur Android

Android intègre un mécanisme prévu pour ça : le mode démo de l’interface système (System UI demo mode). Il est documenté dans l'Android Open Source Project, et il fonctionne sur les émulateurs comme sur les vrais appareils avec le débogage USB. Autorisez-le d’abord, puis envoyez les commandes sous forme de broadcasts :

adb shell settings put global sysui_demo_allowed 1

demo() { adb shell am broadcast -a com.android.systemui.demo -e command "$@"; }

demo enter
demo clock -e hhmm 0941
demo battery -e level 100 -e plugged false
demo network -e wifi show -e level 4
demo network -e mobile show -e datatype none -e level 4
demo notifications -e visible false

Nous les avons lancées sur un émulateur API 35 : chaque broadcast s’est terminé et la barre d’état s’est mise à jour immédiatement. Quand vous avez terminé :

adb shell am broadcast -a com.android.systemui.demo -e command exit

Le mode démo va plus loin. status masque des icônes précises comme l’alarme, le Bluetooth ou la localisation ; bars -e mode rend la barre opaque, translucide ou semi-transparente. La page AOSP liste toutes les commandes.

Capturer l’écran de l’émulateur

adb exec-out screencap -p > 01-home.png

Utilisez exec-out plutôt que shell : la commande transmet les octets bruts, et le PNG n’est pas corrompu par la conversion des fins de ligne. Comme simctl, screencap ne capture que l’écran. Les skins d’émulateur dessinent un cadre autour de la fenêtre, mais ce cadre n’arrive jamais dans le fichier : les cadres d’appareil doivent être ajoutés après coup.

Attention à la limite 2:1 sur Google Play

Celle-ci piège beaucoup de monde. Les règles de Google Play pour les captures d’écran imposent que chaque côté mesure entre 320 et 3840 pixels et que le grand côté ne dépasse pas le double du petit. Beaucoup de téléphones actuels sont plus allongés que ça. Notre capture depuis un émulateur Pixel 9 Pro faisait 1280 × 2856, soit un ratio d’environ 2,23, que Play n’accepte pas tel quel.

Vous avez deux options :

• Capturer sur un profil 16:9. Créez un AVD avec un écran de 1080 × 1920. La capture s’importe directement et respecte aussi le minimum de 1080 px que Google indique pour être éligible aux formats de recommandation basés sur les captures d’écran.
• Composer autour. Placez la capture allongée dans un canevas de 1080 × 1920 avec un titre et un arrière-plan. C’est de toute façon ce que font la plupart des séries de captures mises en page.

Google demande aussi du JPEG ou du PNG 24 bits sans alpha. La sortie de screencap est en RGBA : convertissez-la avant une importation directe, comme sur iOS.

Préparer des données de démo réalistes avant de capturer

Une barre d’état parfaite au-dessus d’une liste vide reste une capture faible. La règle 2.3.3 des App Review Guidelines d’Apple précise que les captures doivent montrer l’app en cours d’utilisation, pas seulement le visuel du titre, la page de connexion ou l’écran de lancement. En pratique, les écrans qui fonctionnent ont un contenu qui ressemble à celui d’une vraie personne : un budget avec quelques dizaines de transactions, un suivi d’habitudes à trois semaines de série, une conversation avec des échanges crédibles.

Les approches qui marchent bien, de la moins à la plus exigeante :

• Un compte de démo. Un compte sur l’environnement de staging, rempli à la main une fois et tenu propre. Simple, mais il finit par dériver.
• Un argument de lancement qui charge des fixtures. Testez un argument comme -demoData dans les builds de débogage et chargez un fichier JSON de contenu d’exemple. Passez-le avec xcrun simctl launch booted com.example.app -demoData, ou en extra d’intent sur Android.
• Des tests d’UI qui préparent l’état. Si vous automatisez ensuite les captures, le test peut créer exactement les données dont chaque écran a besoin.

Le simulateur peut aussi être préparé en ligne de commande pour qu’aucune demande d’autorisation n’apparaisse sur une capture :

# Add sample photos to the library
xcrun simctl addmedia booted ~/demo/photos/*.jpg

# Pre-grant permissions so no system dialog appears
xcrun simctl privacy booted grant photos com.example.app
xcrun simctl privacy booted grant location com.example.app

Les noms comptent plus qu’on ne le croit. « Test User » et « asdf » se repèrent à l’autre bout de la pièce. Utilisez des noms plausibles, des montants réalistes et des dates proches d’aujourd’hui. Notre liste des erreurs courantes sur les captures d’écran détaille les petits indices qui trahissent une capture.

Basculer entre mode clair et sombre, et changer de langue

Si vous proposez un mode sombre ou des fiches localisées, capturez chaque variante depuis la même configuration plutôt que de changer les Réglages à la main.

Les arguments de langue iOS ne s’appliquent qu’à ce lancement, ce qui est pratique : le simulateur reste en anglais pendant que l’app tourne en allemand. La commande de langue par app sur Android nécessite Android 13 (API 33) ou ultérieur ; nous avons vérifié sa syntaxe avec adb shell cmd locale help sur API 35.

Les captures localisées valent l’effort quand l’app elle-même est traduite. Capturer l’interface en allemand, c’est la première moitié du travail ; les titres ont besoin du même traitement. Notre guide pour localiser vos captures d’écran App Store explique quoi traduire et dans quel ordre, et pourquoi traduire ne suffit pas à localiser couvre le reste.

Tout assembler : un script de capture

Voici un petit script shell qui prépare un simulateur iOS, capture les versions claire et sombre d’un écran, puis remet tout en ordre. La navigation entre les écrans est à votre charge (ou à celle des deep links, que la plupart des apps ont déjà) :

#!/bin/sh
set -e
DEVICE=booted
APP=com.example.app
OUT=./screenshots/en-US
mkdir -p "$OUT"

xcrun simctl status_bar $DEVICE override --time 9:41 \
  --dataNetwork wifi --wifiBars 3 --cellularBars 4 \
  --batteryState charged --batteryLevel 100

for MODE in light dark; do
  xcrun simctl ui $DEVICE appearance $MODE
  xcrun simctl launch --terminate-running-process $DEVICE $APP -demoData
  sleep 2
  xcrun simctl openurl $DEVICE "example://home"
  sleep 1
  xcrun simctl io $DEVICE screenshot --type=jpeg "$OUT/01-home-$MODE.jpg"
done

xcrun simctl status_bar $DEVICE clear

Au-delà de quelques écrans et de quelques langues, un script comme celui-ci devient un travail de maintenance, et c’est là qu’entrent en jeu les outils pilotés par les tests d’UI, comme snapshot de fastlane.

Que faire de captures propres

Une capture propre, c’est de la matière première. La plupart des fiches la placent dans un visuel mis en page, avec un titre qui dit ce que l’écran apporte à l’utilisateur, parce qu’une capture nue ne s’explique pas d’elle-même dans la seconde ou deux que l’on passe à faire défiler. Notre guide pas à pas pour créer des captures d’écran App Store prend le relais à partir d’ici, et les bonnes pratiques pour les captures d’écran expliquent quoi mettre sur chacune.

Cette étape de design peut se faire dans n’importe quel outil. Dans Launch Shots, vous déposez vos captures, et le générateur de captures d’écran App Store s’occupe du cadre d’appareil, de la mise en page des titres et des tailles d’export pour chaque store.

En bref

• iOS : xcrun simctl status_bar booted override --time 9:41 --batteryState charged --batteryLevel 100, puis xcrun simctl io booted screenshot --type=jpeg shot.jpg, puis status_bar booted clear.
• Android : settings put global sysui_demo_allowed 1, des broadcasts du mode démo pour l’horloge, la batterie, le réseau et les notifications, adb exec-out screencap -p, puis -e command exit.
• Capturez sur un simulateur ou un émulateur dont la taille d’écran est acceptée telle quelle par le store : iPhone 17 Pro Max pour le plus grand emplacement iPhone, un AVD 16:9 pour Play.
• Supprimez le canal alpha avant d’importer directement une capture sur l’un ou l’autre store.
• Chargez des données de démo réalistes et accordez les autorisations à l’avance pour qu’aucun écran vide ni aucune boîte de dialogue système n’apparaisse sur une capture.
• Scriptez les changements de mode clair/sombre et de langue pour que chaque variante vienne de la même configuration.