Screenshots are the last thing most developers think about before submitting an app, and they're the first thing users see in the store. They also cause avoidable trouble: wrong sizes block the upload, a messy status bar looks unfinished, and screenshots that don't match the app can get you rejected.
This guide covers the sizes each store needs, how to capture clean screenshots from an Expo app, how to automate them so you're not redoing them by hand every release, and what to put in them.
What sizes do the stores need?
Requirements change, so double-check the current App Store Connect and Play Console help pages before you export. As of this writing:
Apple App Store
| Device | Required? | Size (portrait) |
|---|---|---|
| iPhone 6.9" | Yes | 1320 × 2868 (1290 × 2796 also accepted) |
| iPad 13" | Only if your app supports iPad | 2064 × 2752 |
- Upload 1 to 10 screenshots per device size.
- Apple scales your largest iPhone screenshots down for smaller devices, so one set usually covers every iPhone.
- If your Expo app has
"supportsTablet": true, you need iPad screenshots too. If you don't plan to design for iPad, set it tofalseinapp.json.
Google Play
| Asset | Required? | Size |
|---|---|---|
| Phone screenshots | Yes, at least 2 (up to 8) | 16:9 or 9:16; each side 320–3840 px |
| Feature graphic | Yes | 1024 × 500 |
| App icon | Yes | 512 × 512 |
| Tablet screenshots | Recommended for tablet visibility | 7" and 10" |
A 1080 × 1920 or 1080 × 2400 phone screenshot works well for Play.
How do you capture clean screenshots?
iOS Simulator
Boot a simulator that matches the 6.9" size (an iPhone "Pro Max" model), run a release-like build, and clean up the status bar first:
xcrun simctl status_bar booted override \
--time "9:41" \
--batteryState charged --batteryLevel 100 \
--cellularBars 4 --wifiBars 3
xcrun simctl io booted screenshot home.png
Clear the override when you're done:
xcrun simctl status_bar booted clear
Android emulator
Android has a "demo mode" that cleans the status bar:
adb shell settings put global sysui_demo_allowed 1
adb shell am broadcast -a com.android.systemui.demo -e command enter
adb shell am broadcast -a com.android.systemui.demo -e command clock -e hhmm 0941
adb shell am broadcast -a com.android.systemui.demo -e command battery -e level 100 -e plugged false
adb shell am broadcast -a com.android.systemui.demo -e command notifications -e visible false
adb exec-out screencap -p > home.png
adb shell am broadcast -a com.android.systemui.demo -e command exit
Before you capture, prepare the app
- Use realistic sample data. Not "test test asdf." Seed a demo account with content that shows the app at its best.
- Hide developer UI. No dev menus, debug banners, or warning overlays. Use a release or preview build.
- Pick one theme. Light or dark, consistently across all screenshots.
How do you automate screenshots?
Retaking screenshots by hand every release gets old fast. Maestro can drive your app through a flow and capture each screen:
# .maestro/screenshots.yaml
appId: com.yourcompany.yourapp
---
- launchApp:
clearState: true
- tapOn: "Sign in"
- inputText: "demo@example.com"
- tapOn: "Password"
- inputText: "demo-password"
- tapOn: "Continue"
- takeScreenshot: 01-home
- tapOn: "Insights"
- takeScreenshot: 02-insights
- tapOn: "Settings"
- takeScreenshot: 03-settings
maestro test .maestro/screenshots.yaml
Run the status bar commands first, then the flow, once on the iOS Simulator and once on the Android emulator. You get the same set of screens for both stores in a couple of minutes, and you can rerun it whenever the UI changes.
What should go in the screenshots?
Raw screenshots work, but most successful listings add a short caption and a background. A few principles:
The first three matter most. In search results, users often see only the first few screenshots. Make sure those three explain what the app does.
One idea per screenshot. A short caption, a few words, that states a benefit: "Track every workout in seconds," not "Workout logging screen."
Order them like a story. Start with the core value, then key features, then extras like settings or integrations.
Keep text readable on a phone. If you can't read the caption at thumbnail size, it's too small.
Show the real app. Apple's guidelines (2.3) require screenshots to show the app in use. Mockups of features that don't exist, or paid features presented as free, can get the app rejected. Label paid features clearly.
A simple workflow: export raw screenshots from the Maestro run, drop them into one design file with a template for each store size, add captions, and export. Next release, replace the raw screenshots and export again.
Checklist before upload
- [ ] iPhone 6.9" set, 1 to 10 screenshots
- [ ] iPad 13" set, or
supportsTablet: false - [ ] Google Play: 2+ phone screenshots, 1024 × 500 feature graphic, 512 × 512 icon
- [ ] Clean status bar (9:41, full battery, no notifications)
- [ ] Realistic demo data, no debug UI
- [ ] First three screenshots explain the app
- [ ] Captions readable at thumbnail size
- [ ] Paid features labeled; everything shown actually exists
Wrapping up
Screenshots aren't hard, but they're easy to leave until the night before submission. Get the sizes right, capture clean frames, automate the capture once with Maestro, and treat the first three screenshots as your pitch.
Want someone else to handle screenshots, store listings, and submission? LetsDeployIt takes your app from build to live on the App Store and Google Play.
What tool do you use for store screenshots? Share it in the comments.
Top comments (0)