Skip to main content
Screenshot Design
Design & UI/UX

App Store Screenshot Shadows: Skip Them on Frames 1-3

Device shadow, glow, and reflection are contrast decisions dressed as polish. What each costs at search size, and where shadow actually earns its place.

By AppScreenshotStudio Team, App Store screenshot tooling for solo indie devs9 min read

Summarize this article with AI

App Store Screenshot Shadows: Skip Them on Frames 1-3

Drop the device shadow on your first three App Store screenshots. Shadow, glow, and reflection all spend the same currency: the contrast that separates your device from its background. Apple shows the first one to three images in search results when no app preview is available [1], at a fraction of full size, and that's precisely where a softened edge stops reading as a phone.

The table below prices each treatment against the one constraint that decides it, and the last section covers the one place a shadow genuinely earns its keep inside a screenshot.

TL;DR:

  • Shadow is a contrast cost, not a polish bonus. A soft shadow feathers the device silhouette into the background. WCAG puts the floor for identifying a component's boundary at a 3:1 contrast ratio [3], and a feathered edge is the first thing to fall under it when the image shrinks.
  • Reflection is the most expensive of the three. A 6.9-inch iPhone frame is 1260 x 2736 pixels [2], more than twice as tall as it is wide. A mirrored copy below the device takes vertical space from the dimension the frame has least of.
  • Glow adds a second light source. Most sets already run a gradient background. A glow behind the device fights it, and two light sources in one frame read as a rendering artifact.
  • Shadow belongs on overlays, not on the device. A card floating over the screen needs a shadow to say it's floating. The device itself doesn't.

Table of contents

What do device shadow, glow, and reflection actually do?

Device treatment is everything you add around the device that isn't the device: a drop shadow beneath it, a glow behind it, a mirrored reflection below it. All three simulate depth by implying a light source and a surface. They're a separate decision from the device's angle, which is about how the phone is rotated rather than how it's lit.

Every mockup tool ships these as one-click finishes, and nearly every tutorial frames them the same way: shadow adds depth, makes the export feel like a product photo instead of a screengrab. That's true at full size on a landing page. The store is not full size.

Here's the cost of each, measured against the frame that has to survive the shrink:

TreatmentWhat it simulatesWhat it spendsFrames 1-3 verdict
Drop shadowDevice lifted off a surfaceEdge contrast between device and backgroundSkip
ReflectionDevice standing on a glossy surfaceVertical area, the scarcest dimension in a portrait frameSkip
GlowDevice backlit or emittingBackground separation, adds a competing light sourceSkip
No treatmentDevice sits flat on the backgroundNothingDefault

The pattern is the same one that governs the angle decision. Treatments that read as premium at poster size read as mud at thumbnail size, which is the argument the mockup style guide makes for keeping frames 1-3 flat.

Why does a drop shadow cost you edge contrast?

A drop shadow works by placing a soft dark gradient where the device meets the background, which is exactly the boundary a viewer uses to recognize the shape as a phone. WCAG sets 3:1 as the minimum contrast ratio for "visual information required to identify user interface components" [3]. A feathered edge pushes that boundary toward the background it's supposed to stand apart from.

Scale is what turns this from a non-issue into a real one. A 40-pixel shadow blur on a 1260-pixel-wide frame is barely 3% of the width, invisible as a problem when you're reviewing the export at full size. Shrink that frame to search-result width and the blur doesn't shrink as a perceptual quantity in the same way the device's distinguishing details do. The bezel, the corner radius, the screen content all compress toward each other. The soft halo is one of the few things still occupying meaningful area, and now it's occupying it right where the silhouette needs to be crisp.

There's a specific case where the opposite is true, and it's worth naming because it gets conflated constantly. A shadow or outline behind caption text genuinely improves legibility, especially over a busy or photographic background, because there the shadow is creating separation between two overlapping layers. That's a different job. On the device, nothing is overlapping: the shadow isn't separating the phone from something in front of it, it's just softening the phone against empty background.

Why does a reflection cost the most in a portrait frame?

A reflection is the most expensive treatment because it consumes vertical space, and the App Store frame is short on exactly that. The 6.9-inch iPhone screenshot is 1260 x 2736 pixels [2], a ratio of more than two to one. Every pixel of mirrored device below the real one is a pixel the real screen doesn't get.

Think about what a reflection actually contains. It's a flipped, faded, usually blurred copy of the bottom third of your screen. That region is typically a tab bar or the least informative part of the UI, so you're spending scarce vertical area to show a degraded duplicate of your least persuasive content. The trade only makes sense if the frame has area to burn, and a portrait store frame with a headline above the device does not.

The math gets worse on iPad. A 13-inch iPad screenshot is 2064 x 2752 pixels [2], closer to square, so the device sits wider and shorter in frame. A reflection there eats a larger share of the remaining height, and iPad screenshots already fight to make UI legible because the interface is denser to begin with. If you're building both, the iPad mockup generator output is the one where a reflection hurts fastest.

Why does a glow fight your background gradient?

A glow places a bright halo behind the device, which only reads as depth when the background is dark and even. Most App Store screenshot sets run a gradient background, and a gradient already establishes a direction of light. Adding a glow introduces a second, contradictory one.

The result isn't dramatic. It's subtly wrong in a way most people can't name: the frame looks slightly over-rendered, like a template applied rather than a composition designed. Two light sources in a flat 2D composite have no physical explanation, and the eye is good at registering that something is off even when it can't articulate what.

Glow also has a failure mode the other two don't. It tends to reduce contrast against light backgrounds while increasing it against dark ones, so a glow tuned on a dark preview breaks the moment you rebuild the same set on a light background for a seasonal or category variant. A treatment that only survives one background is a treatment you'll be re-tuning every time the set changes.

When is device treatment the right call?

Treatment earns a slot in two places: later frames in the store set, and anywhere outside the store entirely. Frames 4 and beyond are seen by readers who already swiped, meaning they're viewing at full width with intent, so a shadow costs far less there than it does on the frame competing for the tap.

Off the store is where these treatments genuinely belong. Your landing page hero, an ad creative, a press kit image, a social card: all of them display large, uncropped, and against a background you control completely. A device with a considered shadow reads as premium in those contexts for exactly the reason it fails in search results, which is that the effect needs area to be legible as an effect.

This is the same conclusion the isometric projection breakdown reaches from the geometry side, and it's worth stating as one rule rather than three: any treatment whose value depends on being seen large is an off-store treatment. Frames 1-3 are the ones that decide whether anyone sees frame 4 at all, which is the whole argument in the first three frames playbook.

If you want to test the difference honestly, build the set flat first and add treatment only to the later frames, then look at both versions at roughly 250 pixels wide before deciding. Our screenshot builder renders device frames flat and shadowless by design, so the flat version is the default you're comparing against rather than something you have to construct.

Where does a shadow genuinely belong in a screenshot?

Shadow has one legitimate job inside a store frame: separating an element that genuinely floats above another element. A rating badge sitting on top of the screen, a feature chip overlapping the device, an achievement card laid over the UI. Those overlap something, so a shadow communicates real layering rather than decorating an edge.

The distinction is whether the shadow is doing semantic work. An overlay card without a shadow looks pasted into the screen, ambiguous about whether it's part of the app's UI or part of your marketing. A shadow resolves that ambiguity instantly, which matters because Apple expects screenshots to reflect the app accurately and a marketing element mistaken for real UI works against that. The metric badge layout is built around exactly this: a card floating over the upper screen, where the shadow is what makes the float legible.

That's why our builder applies shadow to panels and chips but not to device frames. It's not a missing feature, it's the same rule expressed in code: shadow marks overlap, and a device sitting on a background isn't overlapping anything.

Ship frames 1-3 grounded and flat

Default to no device treatment on the frames that appear in search. Add shadow only where one element genuinely sits on top of another, save glow and reflection for your landing page and ad creative, and check any treated frame at roughly 250 pixels wide before you commit to it.

The angle decision runs on the same logic, and the mockup style guide covers flat, tilted, and perspective on the same thumbnail-first basis. When you're ready to build the set, the screenshot builder ships flat and grounded by default, so getting this right takes no configuration at all.

References

  1. App Store Product Pagedeveloper.apple.com
  2. Screenshot specificationsdeveloper.apple.com
  3. Understanding SC 1.4.11: Non-text Contrastw3.org

Related Posts