Can I show an Android phone in my App Store screenshots if my app is cross-platform?

No. Guideline 2.3.10 says not to include names, icons, or imagery of other mobile platforms in your app or metadata. An Android device frame, an Android status bar, a Material navigation bar, or a Google Play badge inside an App Store screenshot are all grounds for rejection. Capture on iOS and frame the shot in an iPhone. Your Play Store listing is where the Android artwork belongs.

Does Apple require the time in my screenshot to say 9:41?

No. 9:41 is an Apple convention from its own keynote and marketing material, not a review requirement, and no App Review guideline mandates a time, a battery level, or the absence of a carrier name. It is worth doing anyway because a consistent, tidy status bar across all ten slots looks deliberate — but a rejection blamed on it is a rejection about something else.

Will Apple reject a screenshot that isn't a raw device capture?

No. Guideline 2.3.3 explicitly allows more than a raw capture: screenshots may include text and image overlays, and Apple's own example is an animated touch point. Captions, backgrounds, and a device frame around a real screen are all normal and permitted. What is not permitted is the frame standing in for functionality that does not exist, or artwork from another platform.

Do I have to resubmit the whole build to fix a screenshot?

Usually not. Screenshots are metadata, so in most cases you can replace the images in App Store Connect and reply to the Resolution Center message on the same build. A new binary is only needed when the rejection is about the app itself rather than its listing.

Reference · App Review Guidelines · 2026

App Store screenshot rejected?

Screenshot rejections are metadata rejections, which is the good news: you can almost always fix them in App Store Connect without cutting a new build. Below is every guideline that actually comes back on screenshots, quoted from Apple, with what it means in practice.

The short version

Guideline	What triggers it	Fix
2.3.3	The screenshot doesn't show the app in use	Show a real screen, not a splash or login.
2.3.10	There's another platform's imagery in the shot	Remove all Android/other-platform imagery.
2.3.7	There's a price, a discount, or a term in the artwork	Take prices and offers out of the artwork.
2.3.2	Paid content is shown as if it were included	Mark paid content as paid.
2.3.8	The artwork isn't 4+ appropriate	Keep every slot 4+ appropriate.
2.3.1	The screenshot promises something the app doesn't do	Only show what the build really does.

Cause by cause

Each block quotes Apple’s App Review Guidelines directly, so you can paste the wording straight into a Resolution Center reply.

2.3.3 — The screenshot doesn't show the app in use

“Screenshots should show the app in use, and not merely the title art, login page, or splash screen.”

Lead with a real screen doing a real thing. A logo lockup, a sign-in form, or a launch splash is the single most common screenshot rejection, and it is also the weakest first slot you could pick commercially — so this one is worth fixing even when nobody makes you.

2.3.10 — There's another platform's imagery in the shot

“Make sure your app is focused on the experience of the Apple platforms it supports, and don't include names, icons, or imagery of other mobile platforms or alternative app marketplaces in your app or metadata, unless there is specific, approved interactive functionality.”

This is the one that catches cross-platform teams reusing an Android capture: an Android status bar, a three-button navigation bar, a Material back arrow, or a “Get it on Google Play” badge in the frame all read as another platform's imagery. Recapture on an iPhone or the iOS Simulator, and if you present the shot inside a device frame, make it an iPhone.

2.3.7 — There's a price, a discount, or a term in the artwork

“Metadata such as app names, subtitles, screenshots, and previews should not include prices, terms, or descriptions that are not specific to the metadata type.”

Strip “$4.99”, “50% off”, “Free trial”, and “Limited time” out of the caption overlays. Pricing belongs in the App Store's own price field, which Apple keeps accurate for every storefront and currency — hardcoding it into a PNG cannot be.

2.3.2 — Paid content is shown as if it were included

“If your app includes in-app purchases, make sure your app description, screenshots, and previews clearly indicate whether any featured items, levels, subscriptions, etc. require additional purchases.”

If a slot shows a premium theme, a locked level, or a Pro-only screen, label it. A small “Pro feature” mark in the caption is enough and is far cheaper than a review cycle.

2.3.8 — The artwork isn't 4+ appropriate

“Metadata should be appropriate for all audiences, so make sure your app and in-app purchase icons, screenshots, and previews adhere to a 4+ age rating even if your app is rated higher.”

The listing is browsable by everyone, whatever the app's own rating. Pick the calmest screens that still sell the app — Apple's own example is choosing images that don't depict a gruesome death or a gun pointed at a character.

2.3.1 — The screenshot promises something the app doesn't do

“…marketing your app in a misleading way, such as by promoting content or services that it does not actually offer … is grounds for removal of your app from the App Store…”

Mocked-up dashboards, invented charts, and “coming soon” screens count. Everything in the frame has to be something a reviewer can reach in the build you submitted. This is also why a real capture composited onto a device beats a hand-drawn approximation of one.

The one that catches cross-platform teams

2.3.10 is the rejection people find hardest to see, because the offending pixels are usually not the part of the image anyone was looking at. A screen captured on an Android handset carries an Android status bar and often a navigation bar; dropped into a marketing template, it sails past three rounds of internal review and straight into a rejection. The fix is unglamorous — capture the screen on an iPhone or the iOS Simulator, and if you are presenting it inside a device, present it inside an iPhone.

That is what this tool is for: drop a real iOS capture onto a real 3D iPhone, angle and light it, export the full-bleed PNG. Free, no signup, no watermark, and the screenshot never leaves your browser. Getting the dimensions right and the status bar clean are the other two halves of a listing that passes first time.

Open the studio

Questions that come up

Can I show an Android phone in my App Store screenshots if my app is cross-platform?: No. Guideline 2.3.10 says not to include names, icons, or imagery of other mobile platforms in your app or metadata. An Android device frame, an Android status bar, a Material navigation bar, or a Google Play badge inside an App Store screenshot are all grounds for rejection. Capture on iOS and frame the shot in an iPhone. Your Play Store listing is where the Android artwork belongs.
Does Apple require the time in my screenshot to say 9:41?: No. 9:41 is an Apple convention from its own keynote and marketing material, not a review requirement, and no App Review guideline mandates a time, a battery level, or the absence of a carrier name. It is worth doing anyway because a consistent, tidy status bar across all ten slots looks deliberate — but a rejection blamed on it is a rejection about something else.
Will Apple reject a screenshot that isn't a raw device capture?: No. Guideline 2.3.3 explicitly allows more than a raw capture: screenshots may include text and image overlays, and Apple's own example is an animated touch point. Captions, backgrounds, and a device frame around a real screen are all normal and permitted. What is not permitted is the frame standing in for functionality that does not exist, or artwork from another platform.
Do I have to resubmit the whole build to fix a screenshot?: Usually not. Screenshots are metadata, so in most cases you can replace the images in App Store Connect and reply to the Resolution Center message on the same build. A new binary is only needed when the rejection is about the app itself rather than its listing.

Shipping on Android too? The Google Play screenshot sizes reference covers the other store’s rules, which are stricter about dimensions and looser about content.