Using Device Frames in App Store Screenshots Responsibly

You do not need a device frame to publish an app on the App Store or Google Play, but using one can instantly provide context for how your software sits in the physical world. However, wrapping your user interface in a hardware mockup reduces your readable canvas space by 15% to 25%, and using incorrect hardware can trigger a rejection under Apple Review Guideline 2.3.1 for inaccurate metadata.

I built the LaunchShots screenshot editor to give developers clean, accurate device frames, but I frequently see developers slap realistic frames onto screenshots where they actively hurt conversion. Here is how to use device frames responsibly, adhere strictly to Apple and Google guidelines, and calculate whether a frame helps or hurts your listing.

Apple and Google Rules for Device Mockups

Both Apple and Google allow device mockups in screenshot uploads, but both platforms enforce strict guidelines regarding how their hardware is depicted.

Apple publishes explicit hardware presentation rules in their App Store Marketing and Advertising Guidelines. If you include hardware frames in your App Store listings, Apple requires that:

• The hardware must be current: You cannot show a modern iOS 18 app inside an iPhone 8 frame with a physical Home button. If you are uploading to the 6.7-inch or 6.9-inch display slots, the frame must reflect contemporary bezel profiles and Dynamic Island geometry.
• Do not distort or tilt Apple products: Apple specifies that promotional hardware images must not be stretched, skewed, or placed at unnatural angles that obscure the screen surface. App Store screenshots must showcase the app experience directly.
• Guideline 2.3.1 (Performance - Accurate Metadata): Under section 2.3.1 of the App Store Review Guidelines, screenshots must show the app in use. If your frame obscures core navigational elements, or if you place an Android status bar inside an iPhone frame, reviewers can and do reject the build.

Google Play takes a similar stance in their Play Console Listing Guidelines. While device frames are permitted in your screenshot slots (up to 8 screenshots per device type, saved as 16:9 or 9:16 PNG or JPEG files between 320px and 3840px), Google specifically notes that feature graphics should avoid realistic hardware frames because they clutter smaller display viewports in the Play Store app.

The Spacing Math: How Frames Shrink Your UI

The primary cost of using a device frame is canvas space. When a prospective user browses the App Store or Google Play on a mobile phone, they see your screenshots as miniature cards in search results before they ever tap onto your product page.

Consider the pixel math on standard iOS assets:

• A full-bleed iPhone screenshot uploaded for a 6.7-inch display measures 1290 x 2796 pixels.
• If you place that screen inside a realistic device mockup, you must add outer margins so the frame does not touch the edges of the card. A standard design leaves at least 90px of padding on each side.
• The hardware bezel of the phone frame consumes roughly 35px to 40px on each side.
• Your active UI width is reduced from 1290px down to roughly 1040px: 1290 - (2 * 90) - (2 * 35) = 1040px.

That is an immediate 19.4% reduction in linear scale. When displayed in App Store search results, where three portrait screenshots sit side-by-side across an iPhone screen at roughly 110 points wide each, body copy rendered at 15 points inside your app shrinks down to roughly 2 to 3 points in physical screen rendering. It becomes an illegible blur.

Before you commit to a framed design, run your draft through the App Store Search Preview tool to check whether your primary value proposition and interface text can actually be deciphered at search result scale.

Worked Example: Framing a Habit Tracker UI

Say you ship a habit tracker. Your most compelling screen is a weekly streak view containing a progress ring, a calendar grid of completed days, and a checklist of five daily habits.

If you take a raw simulator export (1290 x 2796) and place it inside a complete phone frame centered on the canvas:

1. The top of the frame sits 450px down the canvas to make room for your marketing headline.
2. The bottom of the frame sits 150px above the bottom edge.
3. Your checklist items—which looked clean at full resolution on your Mac monitor—now shrink down so small that the habit titles cannot be read in search cards. The user sees a phone shape, but cannot see what your app actually does.

To use device frames responsibly in this scenario, crop and offset the hardware:

1. Enlarge the device frame so it scales up to 125% of canvas width, letting the left and right hardware bezels crop naturally off the screen edges.
2. Position the phone frame anchored to the bottom edge, letting the bottom of the device bleed off-screen.
3. Keep the Dynamic Island or top notch visible only if it frames your headline without pushing your core content down.
4. By allowing the frame to crop off the canvas edges, your internal app UI width stays close to 1200px, preserving the legibility of your checklist text while still providing the physical cue of a phone frame.

The "Double Bezel" and Status Bar Collision Problem

The most common amateur mistake with device frames is stacking status bars and home indicators. When you take a screenshot via Xcode Simulator (using File > Save Screen or Cmd + S), the simulator captures the software status bar (time, Wi-Fi icon, battery level) and the bottom Home Indicator bar.

If you drop that raw capture into a mockup template that also includes an artificial status bar or a graphic notch, three things break:

• Double time displays: You end up with two clock readouts or an offset battery indicator.
• Notch clipping: In-app headers designed to clear safe area insets get doubled up, pushing your navigation bar 100px lower than it sits in production.
• Home indicator overlap: A rendered home bar in the capture overlaps the bottom curve of the device frame.

To avoid this, either clean your simulator export using Xcode's default clean status bar settings before capturing, or ensure your editor crops the native safe areas when snapping your capture into a hardware frame.

# Set a clean 9:41 AM status bar on your booted iOS simulator
xcrun simctl status_bar booted override \
  --time "9:41" \
  --dataNetwork "wifi" \
  --wifiBars 3 \
  --cellularBars 4 \
  --batteryState "charged" \
  --batteryLevel 100

Run that command in your terminal before capturing simulator screens. It sets the official Apple marketing time (9:41 AM) and full signal bars, preventing awkward notification icons or low-battery warnings from appearing inside your frames.

Checklist: Pre-Submission Device Frame Audit

Run through this audit before uploading assets in App Store Connect (under My Apps > [App Name] > Distribution > iOS App > Version) or Google Play Console (under Grow > Store presence > Main store listing):

1. Hardware Accuracy: Does the frame match the slot? Do not upload iPhone 14-style notched frames into the 6.9-inch iPhone 16 Pro Max slot.
2. Clean Status Bar: Is the clock set to a uniform time without personal carrier names or messy battery percentages?
3. Text Legibility: Zoom out your image until it is 100 pixels wide on your screen. Can you identify the purpose of the screen without zooming in?
4. Contrast Compliance: Does the device frame color blend into the background? Use a neutral frame (dark graphite or silver) or verify edge separation using the LaunchShots Contrast Checker.
5. Platform Integrity: Ensure no Android navigation triangles appear inside an iPhone frame, and no iOS Dynamic Island appears on your Google Play listing.
6. Safe Area Clearance: Confirm your marketing captions sit completely outside the device frame bounding box with at least 60px of breathing room.

When to Drop Device Frames Completely

Device frames are helpful for utility apps, financial tools, and productivity software where physical context builds trust. However, there are categories where frames almost always hurt conversion:

• Games: Both Apple and Google recommend full-bleed landscape or portrait gameplay captures. Framing a game inside a plastic or aluminum bezel cuts out the immersive artwork and shrinks UI action buttons.
• iPad Listings: An iPad frame inside a 2048 x 2732 pixel canvas leaves massive amounts of empty dead space on the sides. Full-bleed iPad captures showing multi-column split views perform far better because the interface itself fills the tablet viewport.
• Dense Dashboards: If your app is a developer tool or analytics client showing complex graphs, shrinking the UI by 20% to fit a bezel makes the data unreadable. Present the UI full-bleed, edge-to-edge.

You can run your current listing through our free Screenshot Grader to evaluate whether your text hierarchy and visual framing meet standard store benchmarks.

FAQ

Will Apple reject my app for using device frames in screenshots?

No, Apple does not reject apps simply for using device frames. However, they will reject your submission under Guideline 2.3.1 if the frame distorts the software UI, uses outdated hardware that misrepresents the target device, or displays non-Apple hardware on the iOS App Store.

What resolution should my screenshots be when including a device frame?

Your exported file must still match Apple's exact screenshot upload dimensions. For modern iPhones, export at 1290 x 2796 pixels (6.7-inch display) or 1320 x 2868 pixels (6.9-inch display). The frame and background graphics sit inside that canvas.

Should I use clay mockups or photorealistic device frames?

Minimalist clay or wireframe mockups are popular because they do not distract from your software UI and do not age as quickly when new hardware releases. Realistic frames provide more tactile authenticity, but you must update them whenever Apple or Google introduces noticeable bezel or hardware alterations.

Do I have to include a device frame on every screenshot in my set?

No. Many successful listings use a device frame on the first one or two screenshots to establish context, then switch to cropped feature close-ups or edge-to-edge UI captures for subsequent cards to highlight specific tools.

Next Steps: Audit Your Current Frames

If your screenshots currently use device frames, open your listing on a physical phone right now and search for your primary keyword. If you cannot read the in-app text inside your mockup at search result size, your frame is working against you.

Jump into the LaunchShots screenshot editor to test your screens with edge-to-edge crops, adjust your frame padding, or switch to minimal clay frames that keep the focus directly on your product.