What the rejection typically looks like
Guideline 2.3.3 - Performance - Accurate Metadata
We noticed that your screenshots do not sufficiently reflect your app in use. Specifically, your 13-inch iPad screenshots show an iPhone image that has been stretched or modified to appear to be an iPad image. In addition, several screenshots only show marketing artwork or the login screen.
Next Steps
Revise your screenshots so they accurately reflect the app in use on each supported device. The majority of the screenshots should highlight your app's main features and functionality. To upload screenshots for other device sizes, select "View All Sizes in Media Manager" in App Store Connect.
Paraphrased example – the exact wording in your message may differ.
What Guideline 2.3.3 actually requires
Guideline 2.3.3 belongs to 2.3 Accurate Metadata. The core rule is short: screenshots "should show the app in use, and not merely the title art, login page, or splash screen" (App Store Review Guidelines, 2.3.3). The same guideline explicitly allows text and image overlays, for example to demonstrate input such as an animated touch point or Apple Pencil.
Its sibling, 2.3.4, says app previews "may only use video screen captures of the app itself".
In practice, App Review applies three tests:
- Is real UI visible? Someone who only sees your screenshots should understand what the app does; rejection messages typically ask that the majority highlight the main features.
- Is it the right device? The iPad slot must show the app running on iPad, the iPhone slot must show iPhone UI.
- Does it match the build? Every screen shown must exist in the version under review: no design-tool concepts, no removed features.
| Usually accepted | Usually rejected |
|---|---|
| Short captions above or below a real screenshot | A set made of logos, taglines, award badges or lifestyle photos |
| Background color and an accurate device frame around real UI | Splash, launch or login screen as the main content |
| A zoomed callout of a real UI element | iPhone UI stretched, padded or framed to fill the iPad slot |
| One onboarding or login image among screens that show the app in use | Mockups that differ from the shipped UI |
Common reasons for a 2.3.3 rejection
- Marketing-first sets. The first one to three screenshots appear in search results when no preview exists, so designers turn them into ads. If the UI is tiny, cropped or missing, the set fails.
- Launch, login and paywall screens. Typical for account-based apps when whoever captured the screenshots never logged in.
- Stretched or padded iPhone screenshots in the iPad slot. The classic one for universal apps nobody ran on iPad. Scaling a 1320 x 2868 iPhone image to 2064 x 2752 distorts the UI or leaves obvious bars, and a phone layout on a tablet canvas is easy for reviewers to spot.
- Wrong device frames. An iPhone frame with a Dynamic Island inside the iPad set, a frame whose screen ratio squeezes the UI, or Android hardware such as a Pixel frame. The last one also violates 2.3.10, see our Guideline 2.3 Accurate Metadata guide.
- Outdated or idealized UI. Old designs, or polished comps showing features the build does not have.
- Captures from the wrong platform. Screenshots of your website, or of the Android build of a Flutter or React Native app with its Android status and navigation bars.
- Forgotten sizes and locales. You fix the 6.9-inch set, but an older 6.5-inch override or the German localization still contains the old images.
Rejected or stuck? Talk to an App Specialist – for free.
Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.
The iPad trap: universal apps without real iPad screenshots
If your build runs natively on iPad, App Store Connect asks for a 13-inch iPad screenshot set; as of October 2026 the specification marks it "Required if app runs on iPad". Many teams don't realize their app is universal. Cross-platform projects often are by default, for example Flutter's standard Runner target or Expo projects with ios.supportsTablet set to true. Check Xcode > Target > General > Supported Destinations or the TARGETED_DEVICE_FAMILY build setting (1 = iPhone, 1,2 = iPhone and iPad).
You have two honest options:
- Support iPad properly. Run the app on an iPad Pro 13-inch simulator, fix layouts that look like a blown-up phone (our Guideline 2.4.1 iPad guide covers the usual crashes and layout bugs), then capture native iPad screenshots. If the app uses sidebars, split view or Apple Pencil, show it.
- Ship iPhone-only. Remove iPad from Supported Destinations so the build no longer asks for iPad screenshots. This only works before the app has been released with iPad support: App Store Connect generally refuses updates that drop devices supported by the previous version.
What does not work: placing an iPhone screenshot, framed or not, on an iPad-sized canvas. Reviewers read that as an iPhone image modified to look like an iPad image.
How to fix a 2.3.3 rejection step by step
- Audit everything, not just the example. Apple often names one device class ("13-inch iPad"); check every device tab and localization anyway.
- Prepare the build and demo content. Install the build under review from TestFlight and use a demo account with content you may show, no personal data and nothing above 4+ (2.3.8 applies to screenshots even if the app is rated higher).
- Capture natively per device class. Use a 6.9-inch iPhone simulator (for example iPhone 17 Pro Max, 1320 x 2868) and, for universal apps, the iPad Pro 13-inch simulator (2064 x 2752). Save with Cmd+S in Simulator or
xcrun simctl io booted screenshot 01-home.png. Clean up the status bar first withxcrun simctl status_bar booted override --time 9:41 --batteryState charged --batteryLevel 100. - Choose screens that show the app in use. Lead with the core task: the editor with a document open, the map with results, the workout in progress. Use at most one onboarding or login image, and never as the first screenshot.
- Add overlays carefully. Captions are fine, but the UI stays dominant and frames match the slot's device class.
- Export to spec. Exact pixel dimensions from the current specification, PNG or JPEG without alpha channel. On macOS,
sips -g pixelWidth -g pixelHeight -g hasAlpha *.pngchecks a whole folder. - Replace every set. In App Store Connect open Apps > [your app] > [version], pick each language in the pop-up menu at the top right, then App Previews and Screenshots > View All Sizes in Media Manager, open the device tab and click Edit next to the size. Replace the 6.9-inch and 13-inch sets and delete outdated overrides for smaller sizes, or they keep showing the old images.
- Reply and resubmit. Screenshots are metadata, so you normally don't need a new build. If 2.3.4 was cited, fix the preview too (see below).
Screenshot sizes and device frame accuracy (as of October 2026)
Apple adds device classes regularly, so treat this table as a snapshot and verify against the official Screenshot specifications before every release. Landscape uses the same values swapped.
| Device class | Accepted portrait sizes (px) | Status |
|---|---|---|
| 6.9-inch iPhone | 1320 x 2868, 1290 x 2796, 1260 x 2736 | Main iPhone set; smaller iPhone sizes fall back to scaled versions of the larger sets |
| 6.5-inch iPhone | 1284 x 2778, 1242 x 2688 | Required if the app runs on iPhone and no 6.9-inch screenshots are provided |
| 13-inch iPad | 2064 x 2752, 2048 x 2732 | Required if the app runs on iPad |
| 11-inch iPad | 1668 x 2420, 1668 x 2388, 1640 x 2360, 1488 x 2266 | Optional; scaled from 13-inch if missing |
Each set takes 1 to 10 PNG or JPEG images without alpha channels or transparency. The page sometimes lists new device classes before App Store Connect accepts uploads for them: in October 2026 it showed an "iPhone Duo" with separate outer and inner display sizes and a note that upload support will follow later in the year.
Device frames: optional, but they must be accurate
- Frameless, full-bleed screenshots are perfectly acceptable.
- If you frame, use the device class of the slot: an iPad bezel in the iPad set, an iPhone bezel in the iPhone set. Apple's Design Resources offer product bezels; follow the linked marketing guidelines when you use them.
- The screenshot must fit the frame's screen without being squeezed or cropped into a different aspect ratio.
- Community frame sets lag behind new hardware. When we checked fastlane's frameit frames in October 2026, they went up to the iPhone 17 series, but the newest iPad Pro frame was the 12.9-inch model (2048 x 2732), with no frame for the current 13-inch iPad Pro at 2064 x 2752. Check the supported device list before you rely on it.
- Never use frames or imagery of other mobile platforms.
Guideline 2.3.4: app previews must be screen captures
App previews are optional, but they go through review like the rest of your metadata. Apple's app preview guidance says previews must show only content within the app: no footage of people using a device, such as over-the-shoulder shots or fingers tapping the screen. Games should show more gameplay than cutscenes, content must suit all ages, and you should disclose when features need an in-app purchase, a subscription or a login. Narration, text overlays, touch hotspots and simple transitions are allowed. Leave out specific prices.
Key specifications as of October 2026 (see App preview specifications):
- 15 to 30 seconds, up to three previews per device size and language.
- H.264 (.mov, .m4v, .mp4; target 10 to 12 Mbps, up to High Profile Level 4.0) or ProRes 422 HQ (.mov), max 30 fps, max 500 MB.
- 886 x 1920 portrait for the 6.9-, 6.5-, 6.3- and 6.1-inch iPhone classes, 1200 x 1600 portrait for 13- and 11-inch iPads.
- Stereo audio: 256 kbps AAC for H.264, PCM or AAC for ProRes. Simulator recordings have no sound; adding a silent stereo track, as in the command below, keeps the file in line with that audio spec.
Record with xcrun simctl io booted recordVideo raw.mov, or on a device via QuickTime Player (File > New Movie Recording, then choose the connected iPhone as the camera). Then trim and convert, for example: ffmpeg -i raw.mov -f lavfi -i anullsrc=channel_layout=stereo:sample_rate=44100 -map 0:v -map 1:a -t 28 -vf "scale=886:1920,fps=30" -c:v libx264 -profile:v high -level 4.0 -b:v 11M -pix_fmt yuv420p -c:a aac -b:a 256k preview.mp4. Pick a poster frame that shows real UI. Apple notes that if you change the poster frame of an already approved preview, you have to submit a new version of that preview.
Responding to App Review and when to appeal
- Metadata Rejected: only the metadata was flagged, not the binary. Replace the screenshots, reply in the App Review message thread in App Store Connect and resubmit. According to App Store Connect Help, screenshots can be uploaded while the version is in Prepare for Submission, Invalid Binary, Rejected, Metadata Rejected or Developer Rejected status.
- Rejected with several issues: fix the code issues with a new build and replace the screenshots in the same round, so the next review doesn't stop at 2.3.3 again.
- Bug-fix update of a live app: the guidelines' "Bug Fix Submissions" note says bug fixes for apps already on the App Store won't be delayed over guideline violations, except legal or safety issues. If a bug-fix update was rejected only over screenshots, you can reply in App Store Connect, ask to use that process and commit to fixing the screenshots in your next submission. Apple decides case by case, and once a version is approved, changing screenshots requires a new version.
- You believe the set already complies: reply and name which screenshot shows which feature in use. If that fails, you can appeal to the App Review Board, though replacing one borderline image is usually faster.
Prevention: automate screenshots in your CI/CD pipeline
A common root cause of 2.3.3 rejections is a screenshot set made by hand once and never regenerated. Automation keeps every device class and locale in sync with the build.
- fastlane snapshot: add
SnapshotHelper.swiftto your UI test target, callsetupSnapshot(app)beforeapp.launch()andsnapshot("01Editor")on each key screen. In theSnapfile, list your devices (use the exact names fromxcrun simctl list devices),languages,override_status_bar(true),clear_previous_screenshots(true)andlaunch_argumentsfor a demo-data mode. - frameit: optional frames and captions. Run
fastlane frameit download_framesand confirm frames exist for your device classes, otherwise ship unframed. Note that plain frameit output (frame only, no title) is larger than the screenshot and, per the fastlane docs, can't be uploaded to the App Store directly. Use aFramefile.jsonwith background and titles, then check the pixel dimensions again. - Upload:
upload_to_app_store(skip_binary_upload: true, skip_metadata: true, overwrite_screenshots: true)replaces old sets instead of leaving stale overrides behind. - CI gates: run the lane on a macOS runner for release branches and fail when a device folder is empty, a dimension isn't accepted or an image has alpha.
- AI-assisted plus human review: automated checks can flag images where UI covers little of the canvas, iPhone aspect ratios in iPad folders or captions naming missing features. A person should still review the final set.
If you'd rather not build this yourself, appsubmitter.io sets up your CI/CD pipeline and store listing, reviews your screenshots before submission and handles the App Review communication. Work that needs changes to your app's code, such as adding UI tests for snapshot, is discussed and quoted upfront. Start with a free consultation call.
Template: how to reply to App Review
Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.
Checklist before you resubmit
- Every set, in every device size and locale, mostly shows real UI from the build under review.
- No screenshot is only a splash screen, login form or title art, and the first one shows the core feature.
- iPad screenshots were captured natively on iPad or the 13-inch iPad simulator, with no iPhone UI or frame.
- Pixel dimensions match an accepted size on the current screenshot specifications page, with no alpha channel.
- Any device frames match the device class of the slot, show Apple hardware only and do not distort the UI.
- Captions describe only features present in this build, and all visible content is suitable for a 4+ rating.
- Media Manager shows no outdated overrides in smaller sizes, other localizations, custom product pages or product page optimization treatments.
- App previews, if present, are 15 to 30 second screen captures of the app at an accepted resolution.
- Your reply lists the replaced sizes, locales and images and whether a new build is attached.
Frequently asked questions
Can I use text overlays and marketing captions in App Store screenshots?
Do I need iPad screenshots if my app is iPhone-only?
TARGETED_DEVICE_FAMILY includes 2). iPhone-only apps still install on iPads in compatibility mode, but no iPad screenshots are needed. Check Supported Destinations in Xcode, since many cross-platform templates are universal by default.Do I need to upload a new build to fix a 2.3.3 rejection?
Can I change App Store screenshots without submitting a new version?
Which App Store screenshot sizes are required in 2026?
Is it ever okay to show the login screen in my screenshots?
Official source: App Store Review Guidelines – 2.3 Accurate Metadata (2.3.3 and 2.3.4). Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.