iPhone Screenshot Frame, Status Bar & Island 2026

Apple accepts iPhone App Store screenshots with no device frame at all. A raw 1320x2868 capture passes upload exactly as it is, because the accepted size equals the iPhone's native screen resolution [1]. The frame, the status bar, and the Dynamic Island are design decisions you control, not requirements Apple enforces.

That freedom is also where most iPhone sets go wrong. A screenshot is just an image at a fixed resolution, so the iPhone's own chrome (the status bar, the Dynamic Island, the home indicator) either gets baked into your shot or gets cropped out by choice. Get those three calls right and the set looks intentional. Get them wrong and it looks like a stray screen grab.

TL;DR:

• No frame required. Apple accepts a raw full-bleed capture. The listed sizes are the device's native screen resolution, and Apple never adds a bezel for you [1].
• Frame or full-bleed is a category call. Utility, finance, and B2B apps tend to frame for trust. Games, social, and lifestyle apps tend to bleed for emotion.
• Status bar: clean it or hide it. The convention is 9:41 with a full signal and battery and no carrier name. Or crop the bar off entirely. Never ship a real, messy one.
• Mind the safe areas. Keep hero text clear of the Dynamic Island (top inset 59 to 62 points) and the home indicator (34 points at the bottom) [3].
• Don't fake UI. Guideline 2.3.3 says screenshots must show the app in use, and 2.3 says they must accurately reflect it [2].

The exact pixel sizes are covered in the iPhone App Store screenshot sizes guide. This post is about everything inside the frame.

Table of Contents

• Do iPhone App Store screenshots need a device frame?
• What should the iPhone status bar show in a screenshot?
• Where does the Dynamic Island sit, and what does it cover?
• Frame vs full-bleed: which converts better for your category?
• Can a stylized status bar get your app rejected?
• How do you keep framing consistent across all 10 screenshots?
• Takeaways

Do iPhone App Store screenshots need a device frame?

No. Apple's screenshot specification lists pixel dimensions only, and those dimensions match each iPhone's native screen resolution [1]. A raw capture with no bezel uploads cleanly. Apple never requires a device frame, and it doesn't add one for you either. Whatever you upload is what shows in the gallery.

So the bezel is a design layer, not a compliance step. Some tools draw a current-generation iPhone frame around your screen content. Others bleed the artwork edge to edge with no device at all. Both are valid uploads. The only hard rules in the spec are the file format (.jpeg, .jpg, or .png) and an exact pixel match to an accepted size [1].

There's a tell in Apple's own spec that the captured chrome has always been part of the image, not something the store strips for you. The specification still lists older iPhones with two variants: "portrait without status bar" at 640x1096 and "with status bar" at 640x1136 [1]. That 40-pixel difference is the status bar itself. Apple has always treated the screenshot as a literal image of the screen, status bar and all, which is exactly why the framing decisions below are yours to make rather than the store's to handle.

What should the iPhone status bar show in a screenshot?

The convention is a clean status bar: the time set to 9:41, a full signal or Wi-Fi icon, a full battery, and no carrier name. It's what Apple uses across its own marketing, and it reads as deliberate instead of a screen grab caught at 23% battery with three unread badges.

The 9:41 time isn't arbitrary. It's roughly the moment Steve Jobs first showed the iPhone on stage on January 9, 2007, and it has been Apple's default marketing time ever since. Matching it is a small signal that you know the platform.

You have two clean options, and one to avoid:

• Clean the status bar. Set the time to 9:41 with a full battery and signal. The Xcode Simulator does this with a simctl status_bar override command, QuickTime device recording shows a clean bar automatically, and several screenshot tools apply one for you.
• Hide the status bar. Full-bleed designs often crop the top strip off entirely and let the headline occupy that space. Perfectly fine, and it sidesteps the Dynamic Island question below.
• Don't ship the real one. A live status bar with a half battery, a carrier name, and a stray notification dot is the fastest way to make a polished set look unfinished.

Where does the Dynamic Island sit, and what does it cover?

The Dynamic Island lives in the top status-bar region. In iOS layout terms it occupies the top safe-area inset, which is 59 points on the iPhone 16 and 62 points on the iPhone 16 Pro Max [3]. The home indicator reserves another 34 points at the very bottom of the screen in portrait [3].

Translated to a screenshot, those insets are no-go zones for anything that has to be read. At the 3x scale of a 6.9-inch capture, 62 points is roughly 186 pixels of a 2868-pixel-tall frame, so the top 6 percent or so belongs to the Island and the bottom 3.5 percent or so belongs to the home indicator. Drop a headline or a key piece of UI into either band and it collides with real device chrome.

This bites hardest on full-bleed designs. With no device frame, the Dynamic Island sits directly over your artwork as a black pill, and a caption centered too high disappears behind it. Two ways to handle it:

• Design around it. Keep your hero text and primary UI inside the central band, clear of both insets. This is the safe default for most sets.
• Work with it. A few apps deliberately compose around the Island, letting it anchor the top of the layout instead of fighting it. Higher effort, but it can look intentional rather than accidental.

If you're framing the screen inside a device bezel, the frame already accounts for these regions, so this is mostly a full-bleed concern.

Frame vs full-bleed: which converts better for your category?

Neither wins universally. Device frames signal real product and real screens, which builds trust for utility, finance, healthcare, and B2B apps. Full-bleed imagery breaks the fourth wall and sells emotion, which tends to win for games, social, dating, fitness, and lifestyle apps. The right call follows your category, not a global rule.

A useful sanity check: open the top charts in your category and look at what the leaders ship. If every competitor frames their screens and you go full-bleed, you either stand out or look out of place, and you usually can't tell which until you see your own set both ways. That's the honest part of this decision. The framing that reads best is a recognition call, not something you can spec up front, so the fast path is to generate it both ways and compare.

Can a stylized status bar get your app rejected?

It can if it misrepresents the app. Guideline 2.3.3 requires screenshots to "show the app in use, and not merely the title art, login page, or splash screen" [2]. Guideline 2.3 adds that screenshots must "accurately reflect the app's core experience" [2]. A clean status bar is cosmetic and fine. A faked interface is not.

The line is misrepresentation, not polish. Setting the time to 9:41 and topping off the battery changes nothing about what your app does, so it's expected and safe. What draws a flag is mocking up UI the app doesn't actually have, staging fake notifications that imply social proof you can't back up, or wrapping the screen in a frame for a device the app doesn't run on.

One more constraint that catches people: under Guideline 2.3.8, your screenshots have to hold a 4+ age rating even if the app itself is rated higher [2]. Whatever you show in the chrome or the content has to clear that bar. For the full list of what trips review across every device, see the App Store screenshot rejections compliance guide.

How do you keep framing consistent across all 10 screenshots?

Pick one frame treatment and one status-bar treatment, then apply both to every screenshot in the set. A set that mixes framed and full-bleed shots, or that pairs a clean 9:41 bar on frame 1 with a real 41% battery on frame 4, looks half-finished and quietly undercuts the trust the screenshots exist to build.

Consistency matters more than it sounds, because the set is read as one unit. The first two to three screenshots appear together in App Store search, so a mismatch in framing shows up side by side before anyone taps in. Decide the rules once: frame or bleed, clean bar or cropped bar, the same safe-area discipline on every shot. Then hold them across all ten.

Holding that line by hand is where manual exports drift, because every re-render is another chance to forget the status-bar override or nudge a caption into the Island. Generating the whole set in one place keeps the treatment locked. The iPhone 16 Pro Max mockup generator renders every frame at an accepted 6.9-inch size with consistent chrome, so the framing decision is made once and applied to the set, not redone shot by shot.

Takeaways

For an iPhone set shipping in 2026:

• A device frame is optional. Apple accepts a raw full-bleed capture; the listed sizes are the native screen resolution [1].
• Choose frame vs full-bleed by category. Utility and finance lean framed for trust; games and lifestyle lean full-bleed for emotion.
• Use a clean status bar or none. 9:41, full battery and signal, no carrier name, or crop the strip off entirely.
• Respect the safe areas. Keep readable content out of the top 59 to 62 points (Dynamic Island) and the bottom 34 points (home indicator) [3].
• Stay honest with review. Clean is fine; faked UI fails Guideline 2.3.3 and 2.3 [2].

The framing rules are the easy part to learn and the easy part to break across a ten-frame set. The harder question is which treatment actually makes your app look right, and that's a thing you recognize once you see it rather than something you decide in advance. Describe your app in the iPhone 16 Pro Max mockup generator, see a first draft framed on spec, then refine the chrome and layout by chatting until the set clicks. For sizing across iPad and Android too, the App Store screenshot sizes essential guide lists every dimension, and the device dimensions tool confirms any single number mid-build.