Saubere Screenshots aus dem iOS-Simulator und Android-Emulator

Für einen sauberen Screenshot aus dem iOS-Simulator überschreibst du die Statusleiste mit xcrun simctl status_bar booted override --time 9:41 --batteryState charged --batteryLevel 100 und nimmst dann mit xcrun simctl io booted screenshot auf. Unter Android schaltest du per adb den System-UI-Demo-Modus ein. Der legt die Uhrzeit fest, füllt Akku- und Empfangssymbole und blendet Benachrichtigungen aus. Aufgenommen wird dann mit adb exec-out screencap -p.

Damit ist die Statusleiste erledigt. Ein Store-tauglicher Screenshot braucht aber auch die richtige Gerätegröße, ein Dateiformat, das der Store akzeptiert, und einen Bildschirm voller glaubwürdiger Daten. Dieser Guide geht alles durch, mit Befehlen zum Reinkopieren.

Warum die Statusleiste in Store-Screenshots wichtig ist

Ein Screenshot aus der Entwicklung zeigt, was der Simulator gerade so gemacht hat: 14:17 Uhr, 34 % Akku, ein Anbietername, irgendein verirrtes Benachrichtigungssymbol. Falsch ist davon nichts, aber es wirkt unfertig und lenkt den Blick von dem Teil des Bildschirms ab, um den es dir eigentlich geht.

Google sagt das ganz deutlich. Die Richtlinien für Vorschau-Assets bitten dich, die Benachrichtigungsleiste aufzuräumen, sodass sie vollen Akku, WLAN- und Mobilfunksymbole und keine Benachrichtigungen zeigt. Apple hat dazu keine ausdrückliche Regel, aber 9:41 Uhr ist die Konvention im eigenen Marketing, und eine einheitliche Statusleiste über alle Screenshots lässt das Set wie aus einem Guss wirken.

So stellst du die Statusleiste im iOS-Simulator auf 9:41

Den Befehl simctl status_bar gibt es schon seit einigen Xcode-Versionen. Wir haben die Flags unten mit xcrun simctl status_bar help in Xcode 27 abgeglichen. Starte den gewünschten Simulator und führ dann Folgendes aus:

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 zielt auf den laufenden Simulator. Wenn mehrere gestartet sind, gib stattdessen seine UDID an (aus xcrun simctl list devices booted). Jedes Flag ist optional, aber mindestens eins brauchst du.

Was gerade aktiv ist, siehst du mit xcrun simctl status_bar booted list. Wenn du fertig bist, setzt du alles zurück:

xcrun simctl status_bar booted clear

Der Override übersteht Neustarts der App, du kannst ihn also einmal setzen und ein ganzes Set aufnehmen. Wenn du den Simulator zurücksetzt, ist er weg.

Den iOS-Screenshot in der richtigen Größe aufnehmen

xcrun simctl io booted screenshot shot.png speichert den Bildschirm des Simulators in seiner nativen Pixelgröße. Simulatorfenster und Gehäuserahmen sind nicht dabei, du bekommst nur das Display. Ob App Store Connect die Datei akzeptiert, hängt also davon ab, welches Gerät du wählst.

Wähl einen Simulator, der zu einer zulässigen Größe passt

Apples Screenshot-Spezifikationen listen die genauen Pixelmaße für jeden Platz auf. Der Platz, den die meisten Guides 6,9 Zoll nennen (App Store Connect bezeichnet ihn inzwischen als „iPhone mit Dynamic Island, großes Display“), akzeptiert im Hochformat 1260 × 2736, 1290 × 2796 und 1320 × 2868. Als wir von einem iPhone 17 Pro Max-Simulator aufgenommen haben, kam die Datei mit 1320 × 2868 heraus und passt damit ohne Skalieren in diesen Platz. Fürs iPad passt ein 13-Zoll-iPad-Pro-Simulator zum 13-Zoll-Platz, der 2064 × 2752 und 2048 × 2732 akzeptiert. Den Rest findest du in unserer Übersicht der Screenshot-Größen.

Wenn du lieber ein eigenes Gerät nur für Screenshots anlegen willst, damit dein Alltags-Simulator unangetastet bleibt:

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

Den Transparenzfehler vermeiden

Das PNG von simctl hat einen Alphakanal, obwohl jedes Pixel deckend ist. Laut den Spezifikationen von App Store Connect dürfen Bilder keine Alphakanäle oder Transparenz enthalten. Wenn du die Aufnahme direkt hochlädst, speicher sie stattdessen als 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

Wenn der Screenshot zuerst in ein Designtool wandert, behalt das PNG; ohne Alpha muss erst die exportierte Datei sein.

So bekommst du eine saubere Statusleiste im Android-Emulator

Android bringt dafür einen eigenen Mechanismus mit: den System-UI-Demo-Modus. Er ist im Android Open Source Project dokumentiert und funktioniert auf Emulatoren und auf echten Geräten mit USB-Debugging. Erst erlaubst du ihn, dann schickst du Befehle als 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

Wir haben das auf einem Emulator mit API 35 ausgeführt. Jeder Broadcast lief durch, und die Statusleiste hat sich sofort aktualisiert. Wenn du fertig bist:

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

Der Demo-Modus kann noch mehr. status blendet einzelne Symbole wie Wecker, Bluetooth und Standort aus; bars -e mode stellt die Leiste auf deckend, durchscheinend oder halbtransparent. Die AOSP-Seite listet alle Befehle auf.

Den Emulator-Bildschirm aufnehmen

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

Nimm exec-out statt shell: Es überträgt die rohen Bytes, sodass das PNG nicht durch die Umwandlung von Zeilenenden kaputtgeht. Wie simctl nimmt screencap nur das Display auf. Emulator-Skins zeichnen zwar einen Rahmen um das Emulatorfenster, der landet aber nie in der Datei. Geräterahmen musst du also nachträglich hinzufügen.

Achte auf das 2:1-Limit bei Google Play

Darüber stolpern viele. Laut den Screenshot-Regeln von Google Play muss jede Seite zwischen 320 und 3840 Pixel lang sein, und die lange Seite darf höchstens doppelt so lang sein wie die kurze. Viele aktuelle Smartphones sind höher. Unsere Aufnahme aus einem Pixel 9 Pro-Emulator hatte 1280 × 2856, ein Verhältnis von etwa 2,23, und das nimmt Play so nicht an.

Du hast zwei Möglichkeiten:

• Auf einem 16:9-Profil aufnehmen. Leg ein AVD mit einem 1080 × 1920-Bildschirm an. Die Aufnahme lässt sich direkt hochladen und erfüllt auch das Minimum von 1080 px, das Google für Empfehlungsformate auf Basis von Screenshots angibt.
• Drumherum gestalten. Setz die hohe Aufnahme in eine 1080 × 1920-Arbeitsfläche mit Headline und Hintergrund. Das machen die meisten gestalteten Screenshot-Sets sowieso.

Google verlangt außerdem JPEG oder 24-Bit-PNG ohne Alpha. Die Ausgabe von screencap ist RGBA, also wandle sie vor einem direkten Upload um, genau wie unter iOS.

Vor der Aufnahme realistische Demodaten anlegen

Eine perfekte Statusleiste über einer leeren Liste bleibt ein schwacher Screenshot. Apples App-Review-Richtlinie 2.3.3 sagt, dass Screenshots die App im Einsatz zeigen sollen und nicht bloß Titelgrafik, Anmeldeseite oder Splashscreen. In der Praxis funktionieren Bildschirme mit Inhalten, die nach einem echten Menschen aussehen: ein Budget mit ein paar Dutzend Buchungen, ein Habit-Tracker drei Wochen in einer Serie, ein Chat mit glaubwürdigem Hin und Her.

Ansätze, die meist gut funktionieren, vom geringsten zum größten Aufwand:

• Ein Demo-Account. Ein Account auf Staging, einmal von Hand befüllt und ordentlich gehalten. Einfach, aber er veraltet mit der Zeit.
• Ein Launch-Argument, das Fixtures lädt. Prüf in Debug-Builds auf etwas wie -demoData und lade eine JSON-Datei mit Beispielinhalten. Übergib es mit xcrun simctl launch booted com.example.app -demoData oder unter Android als Intent-Extra.
• UI-Tests, die den Zustand vorbereiten. Wenn du die Aufnahmen später automatisierst, kann der Test genau die Daten anlegen, die jeder Bildschirm braucht.

Den Simulator kannst du auch per Kommandozeile vorbereiten, damit nie ein Berechtigungsdialog im Bild auftaucht:

# 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

Namen sind wichtiger, als man denkt. „Test User“ und „asdf“ erkennt man auf drei Meter Entfernung. Nimm plausible Namen, echt wirkende Beträge und Daten nahe an heute. Unsere Liste typischer Screenshot-Fehler zeigt mehr Details, an denen man einen Screenshot sofort durchschaut.

Hell/Dunkel und Sprache umschalten

Wenn deine App einen Dark Mode oder lokalisierte Store-Einträge hat, nimm jede Variante aus demselben Setup auf, statt in den Einstellungen von Hand umzuschalten.

Die iOS-Sprachargumente gelten nur für diesen einen Start, und das ist praktisch: Der Simulator bleibt auf Englisch, während die App auf Deutsch läuft. Der Android-Befehl für die Sprache pro App braucht Android 13 (API 33) oder neuer; die Syntax haben wir mit adb shell cmd locale help auf API 35 geprüft.

Lokalisierte Screenshots lohnen sich, wenn die App selbst übersetzt ist. Die deutsche Oberfläche aufzunehmen ist die erste Hälfte; die Headlines brauchen dieselbe Behandlung. Unser Guide zum Lokalisieren von App-Store-Screenshots erklärt, was du in welcher Reihenfolge übersetzt, und warum Übersetzen allein noch keine Lokalisierung ist erklärt den Rest.

Alles zusammen: ein Aufnahme-Skript

Hier ist ein kleines Shell-Skript, das einen iOS-Simulator vorbereitet, eine helle und eine dunkle Version eines Bildschirms aufnimmt und danach aufräumt. Die Navigation zwischen den Bildschirmen überlasse ich dir (oder Deep Links, die die meisten Apps ohnehin haben):

#!/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

Ab einer Handvoll Bildschirmen und Sprachen wird so ein Skript zur Wartungsaufgabe, und genau da kommen UI-Test-basierte Tools wie snapshot von fastlane ins Spiel.

Was du mit sauberen Aufnahmen machst

Eine saubere Aufnahme ist Rohmaterial. Die meisten Store-Einträge setzen sie in einen gestalteten Rahmen mit einer Headline, die sagt, was der Bildschirm für die Nutzer tut, denn ein nackter Screenshot erklärt sich nicht in den ein, zwei Sekunden, die jemand beim Vorbeiscrollen hinschaut. Unsere Schritt-für-Schritt-Anleitung für App-Store-Screenshots macht hier weiter, und die Best Practices für Screenshots zeigen, was auf jeden einzelnen gehört.

Diesen Designschritt kannst du in jedem Tool machen. In Launch Shots ziehst du die Aufnahmen rein, und der App-Store-Screenshot-Generator kümmert sich um Geräterahmen, Headlines-Layout und die Exportgrößen für jeden Store.

Kurz zusammengefasst

• iOS: xcrun simctl status_bar booted override --time 9:41 --batteryState charged --batteryLevel 100, dann xcrun simctl io booted screenshot --type=jpeg shot.jpg, dann status_bar booted clear.
• Android: settings put global sysui_demo_allowed 1, Demo-Modus-Broadcasts für Uhr, Akku, Netzwerk und Benachrichtigungen, adb exec-out screencap -p, dann -e command exit.
• Nimm auf einem Simulator oder Emulator auf, dessen Bildschirmgröße der Store direkt akzeptiert: iPhone 17 Pro Max für den größten iPhone-Platz, ein 16:9-AVD für Play.
• Entferne den Alphakanal, bevor du eine Aufnahme direkt in einen der beiden Stores hochlädst.
• Lade realistische Demodaten und erteile Berechtigungen vorab, damit kein leerer Zustand und kein Systemdialog im Bild landet.
• Skripte das Umschalten von Hell/Dunkel und Sprache, damit jede Variante aus demselben Setup kommt.