App Store Screenshot Requirements and Why Yours Got Rejected
If your app runs on iPhone, Apple needs at least one screenshot at a 6.9-inch size — 1320 x 2868, 1290 x 2796, or 1260 x 2736 pixels in portrait — and it scales that image down for every smaller iPhone automatically. If your app runs on iPad, it needs a 13-inch set at 2064 x 2752 or 2048 x 2732. Google Play needs at least two screenshots, each side between 320 and 3,840 pixels, with the long side no more than twice the short side, plus a 1024 x 500 feature graphic. Those are the numbers, taken from Apple's screenshot specifications and Google's graphic asset requirements as of September 2026.
Getting the pixels right is the part everyone worries about, and it is the part that fails least often. Upload the wrong size and App Store Connect rejects the file at upload time, before a human ever sees it. You lose a minute. The rejections that cost you a full review cycle come from what is inside the frame, and those rules are written down in a place most first-time app owners never look.
The sizes, and why you only need two of them
Apple used to want a separate set for every screen size it had ever shipped. It does not any more. Supply the largest display in each family and App Store Connect derives the rest.
For iPhone that means the 6.9-inch class, which covers iPhone Air, iPhone 17 Pro Max, iPhone 16 Pro Max and Plus, iPhone 15 Pro Max and Plus, and iPhone 14 Pro Max. Three portrait sizes are accepted at that class — 1260 x 2736, 1290 x 2796, and 1320 x 2868 — and any one of them satisfies the requirement. If you skip 6.9 entirely, Apple falls back to requiring a 6.5-inch set at 1284 x 2778 or 1242 x 2688.
For iPad it means the 13-inch class at 2064 x 2752 or 2048 x 2732 portrait. This set is only required if your app is actually listed as running on iPad. Plenty of small business apps are iPhone-only on purpose, and that is a legitimate choice rather than a gap to apologise for.
You can upload one to ten images per device class, in JPEG or PNG, and Apple will not accept a file with an alpha channel or transparency. That last one bites people who export from a design tool with a transparent background still switched on. Google Play has the same no-alpha rule and asks for 24-bit PNG or JPEG.
Google's spec is a range rather than a fixed size, which sounds easier and quietly is not. The practical target is 1080 x 1920 portrait: it sits inside the range, hits the 9:16 ratio Google recommends for its larger promotional placements, and matches what most Android devices actually capture. You need a minimum of two screenshots and can upload up to eight per device type.
Our free App Store Screenshot Generator exports at these dimensions directly, with caption overlays, so you are not resizing by hand in an image editor and hoping the crop was right. It runs in the browser and needs no account.
The four rules that actually get screenshots rejected
Apple's App Review Guidelines are the source here, and section 2.3 is short enough to read in full. Four clauses do most of the damage.
Your screenshots must show the app in use. Guideline 2.3.3 says screenshots "should show the app in use, and not merely the title art, login page, or splash screen." A set that opens with your logo screen and a login form is a rejection, not a style choice. If a reviewer cannot see what the app does from the images alone, you have failed the test. Text and image overlays on top of a real screen are explicitly allowed — that is how every polished store listing is built — but the content inside the device frame has to be your actual running app.
The UI has to be the shipped UI. Retouching a screenshot after capture to fix spacing, swap in nicer sample data, or show a feature you have not built yet all fall foul of the same accuracy requirement. This is the trap for anyone who hands screenshots to a designer late in the project. The designer improves the layout, the layout no longer exists in the build, and the reviewer notices.
No other platforms in your metadata. Guideline 2.3.10 tells you not to include "names, icons, or imagery of other mobile platforms or alternative app marketplaces" in your app or its metadata. An Android status bar visible in an iOS screenshot, or a "Get it on Google Play" badge tucked into a marketing frame, is a rejection. If you build for both stores, keep the two screenshot sets genuinely separate rather than recolouring one into the other.
Metadata is held to a 4+ standard regardless of your rating. Guideline 2.3.8 requires icons, screenshots, and previews to "adhere to a 4+ age rating even if your app is rated higher." Almost no small business app trips this, but if yours shows user-generated content, be deliberate about which sample content ends up in the frame.
Google Play does not publish a screenshot-accuracy clause with a number you can cite the way Apple does, but its policy on deceptive store listings covers the same ground in substance. Assume anything Apple would reject will eventually draw attention on Play as well.
What this costs you when it goes wrong
A screenshot rejection is not catastrophic and it is not free. You fix the images, resubmit, and go back into the review queue behind everything submitted since. In practice that is a day or two on a normal week and longer around a major OS release, when the queue fills with apps chasing a launch. If you have told customers a date, that is the date that moves.
The version that hurts more is the one you never get told about, because it is not a rejection at all. Screenshots are the single largest thing a browsing user sees before deciding whether to tap Get, and a set that leads with a splash screen and a login form converts badly even when it passes review. Apple's rule and good marketing point in the same direction here, which is unusual and worth using.
An honest sequence looks like this: first image shows the single thing your app is for, mid-action. Second and third show the two next most useful screens. Anything after that is optional, and a short set of strong images beats ten weak ones. Write the caption before you take the screenshot, so the screen you capture is the one that proves the caption.
Where this fits in a launch
Screenshots are one line item on a submission checklist that also includes an icon at every required size, a privacy policy, a data disclosure form, and store copy. They are worth doing in that order rather than last, because the screens you choose to show tend to expose whether your first release is actually coherent. Our App Launch Checklist covers the whole set, and the step-by-step publishing guide walks through what happens after you hit Submit.
Here is where we are the wrong fit. If you have a finished app and you only need someone to produce compliant store images, hiring us is poor value — the free generator does that job, and a freelance designer with your build in front of them will do a better creative pass than an agency engagement is priced for. What we are useful for is the case where the screenshots keep failing because the app itself is not resolved: no clear primary screen, features half-built, a first release with nothing obvious to photograph. That is a product problem wearing a metadata costume, and no image editor fixes it.
If you are staring at a rejection notice and cannot tell which of the four rules you broke, the notice itself names the guideline number. Look it up in Apple's guidelines, fix the specific thing, and resubmit. If you would rather have someone read it with you, a free intro call is thirty minutes and costs nothing.
Your app. In the stores. Done for you. US APP Team designs, builds, and launches your iOS and Android app for a fixed price. Start your app brief or book a free intro call — both are free.
Want to poke around first? Every tool in our free tool library runs in your browser with no signup: an app cost calculator, an app name generator, and a privacy policy generator.
