The app store pre-submission checklist for screenshots and metadata

June 2, 2026 · 9 min read

A store submission usually fails at the edges, not at the center. The app works, but the reviewer cannot log in. The phone gallery is polished, but the tablet slot is empty. One locale still has an old price in a screenshot. The feature graphic is the right idea at the wrong dimensions.

Use this preflight after the build and listing are complete, but before anyone presses Submit. It is designed to catch mismatches between the product, the metadata, and the files that the stores actually received.

1. Freeze the release candidate

• Record the version and build number that the screenshots represent.
• Test the exact build on supported device classes, not only in a development shell.
• Confirm production backend services are live and reachable for review.
• Remove placeholder text, test URLs, debug menus, and temporary account states.
• List every paid, gated, region-limited, or hardware-dependent feature shown.

Apple's official before-you-submit guidance calls for a stable build, complete and accurate metadata, working backend services, current contact information, and full review access. Treat that list as release work, not administrative cleanup.

2. Verify reviewer access

• Provide an active demo account or a fully featured approved demo mode.
• Test the credentials from a clean device without an existing session.
• Disable one-time setup that could leave the reviewer in an exhausted account state.
• Include sample QR codes, test hardware instructions, or other required resources.
• Explain non-obvious features and in-app purchases in the review notes.

Google's publishing guidance also requires valid login information when access is restricted. A correct password is not enough if two-factor authentication, an expired invitation, or an empty workspace blocks the actual workflow.

3. Audit every claim against the build

• Read the app name, subtitle, descriptions, release notes, and screenshot headlines.
• Open the exact screen that proves each claim.
• Remove roadmap features, old navigation, expired promotions, and unsupported awards.
• State when a depicted item requires a subscription or in-app purchase.
• Use fictional account information, never a customer's real data.

Apple's accurate metadata rules require descriptions, screenshots, and previews to match the app's core experience. Google warns that a discrepancy between the listing and the product can cause rejection. Truthfulness is a visual QA task as much as a copy task.

4. Check Apple screenshot slots

• Confirm every file uses an accepted resolution, JPEG or PNG format, and no alpha channel. Apple allows one to ten screenshots per supported slot.
• Provide the required iPhone set if the app runs on iPhone.
• Provide the required iPad set if the app runs on iPad.
• Keep orientation and visual order intentional across device classes.
• Make sure screenshots show the app in use, not only a splash, login, or title screen.
• Inspect the first image separately because it must communicate without the full row.

Accepted sizes change as Apple adds display classes. Compare the export against the live App Store Connect screenshot specifications during every release, even if last quarter's files uploaded successfully.

5. Check Google Play preview assets

• Include at least two screenshots across device types to publish the store listing, and no more than eight for any supported device type.
• Use JPEG or 24-bit PNG without alpha. Keep each dimension between 320 and 3,840 pixels, with the long side no more than twice the short side.
• For recommendation eligibility for apps in screenshot-led formats, provide at least four screenshots at a minimum 1080-pixel resolution. Use 9:16 portrait or 16:9 landscape.
• Show the actual app experience and keep real UI prominent in the first three images.
• Write unique, useful alt text for each screenshot.
• Check the feature graphic separately: exactly 1024 × 500, JPEG or 24-bit PNG without alpha, with focal content kept away from likely cutoff areas.

Google maintains these rules in its preview asset requirements. Requirements differ for Wear OS, Android TV, Automotive, and Android XR, so audit every form factor selected in the release.

6. Review the gallery as a user sees it

• Confirm filenames and console order match the intended story.
• Preview at phone size and read every headline without zooming.
• Check that devices, shadows, and content stay inside the canvas.
• Look for repeated screens, repeated claims, and sudden style changes.
• Open every image individually, including the middle of a panoramic set.
• Download one asset back from the console and verify its dimensions and appearance.

7. Complete every locale

• Match the screenshot count and order across locales unless the market needs a change.
• Check translated copy for clipping, awkward wrapping, and unsupported glyphs.
• Confirm dates, currencies, units, maps, and example names make sense locally.
• Remove English-only promotional claims from translated images.
• Verify localized support, privacy, and marketing URLs.

Google recommends separate screenshots and promotional videos for each supported language when the images contain text. A translated description under an English screenshot set is technically incomplete even when the console accepts it.

8. Finish privacy and listing administration

• Confirm the privacy policy URL is public, current, and specific to the app.
• Reconcile store privacy answers with the release build and every included SDK.
• Check age rating, category, content declarations, and export compliance.
• Verify support contact details and ownership of all logos, images, fonts, and claims.
• Confirm pricing, territories, release timing, and availability settings.

Google requires developers to describe their apps' data collection and handling in the Data safety form. Do not reuse an old answer set without checking the current build's libraries and data flows.

9. Preserve submission evidence

• Archive the submitted build, screenshots, metadata, and locale folders together.
• Save the final console preview or screenshots of the submitted gallery order.
• Record who approved brand, product accuracy, privacy, and release settings.
• Keep review notes and demo-account instructions with the release record.
• Write down any manual console edits so the next automated upload does not erase them.

Storeboard handles the asset side of this preflight: exact store sizes, complete device sets, real-UI compositing, headline checks, and locale-specific exports. That leaves the release owner with a shorter list centered on product truth, reviewer access, privacy, and the final Submit button.