How to Put a Screenshot in an iPhone Mockup (Mac)

A bare app screenshot posted on its own looks like a bug report. The same screenshot inside a phone body reads as a product. Nothing about the pixels changed — the frame just tells the viewer what they are looking at.

Here are four ways to do it on a Mac, from a free browser tool to a scripted pipeline, with the trade-offs each one carries.

Quick comparison

Get the screenshot right first

Every method below inherits whatever you feed it, and two mistakes at capture time cannot be fixed afterwards.

Capture at 2x. On macOS, screenshots of a Retina display are already 2x. From an iOS Simulator, they match the simulated device's native resolution. If you resize down before framing you throw away detail you will want back; frame first, resize last.

Match the aspect ratio to the device. An iPhone 15 Pro screen is 1179×2556 — roughly 19.5:9. A screenshot at a different ratio gets cropped or letterboxed inside the frame. Capture from a Simulator set to the device you plan to show, and this solves itself.

Clean the status bar. A real device screenshot shows your actual time, battery and carrier. For anything published, use a Simulator with a clean status bar — 9:41, full battery, full signal — which is what Apple expects on App Store material anyway.

Method 1: Shots.so

The fastest route when you do not already have a tool installed.

Step 1 — open shots.so in a browser and upload the screenshot.

Step 2 — pick an iPhone frame. Current models are available.

Step 3 — choose a background. The library covers glass, gradient, abstract and desktop wallpapers, and there are generated options that pull colours from your image.

Step 4 — adjust padding, rotation and shadow.

Step 5 — export.

Good for: one image, no install, any operating system. The free tier covers occasional static mockups.

Bad for: your file is uploaded to a server. For a public marketing screenshot that is a non-issue; for an unreleased feature it is a decision worth making deliberately. Also no video, and browser export has a lower ceiling than a native app.

Method 2: Screenify Studio

A macOS app. It records screens, but Open Media means it also opens a still image and treats it like footage — which covers this job.

Step 1 — open the image from the welcome screen. PNG, JPG, WebP and HEIC all work. Drop several and they queue.

Step 2 — turn on the device frame in the Mockup tab and pick a model. There are 47 flat iOS device models, or a 3D stage if you want perspective and lighting.

Step 3 — set how the image sits: cover, contain or fill. With a correctly sized screenshot, cover is right.

Step 4 — add a background — a wallpaper, or a Realistic Mockup that places the phone inside an actual photograph matched to its perspective.

Step 5 — optionally draw a Dynamic Island on models that lack one, so an older frame still reads as a current phone.

Step 6 — export.

Good for: everything stays on your Mac, and the same project handles video later if the screenshot turns into a demo. Frames, backgrounds and photo scenes are all in the free plan.

Bad for: macOS only. And for a single static image, installing an app is more friction than opening a browser tab — that is a fair criticism.

Method 3: Rotato

Reach for this when you want the phone at an angle rather than flat.

Step 1 — import the screenshot. There is also a Figma plugin if the source is a design.

Step 2 — choose from 30+ 3D devices and set colour and material.

Step 3 — rotate and position with real camera controls: focus, lens, reflections.

Step 4 — set the background, or export with transparency if the mockup will be a layer elsewhere.

Step 5 — export, up to 8K.

Good for: hero images where the device itself is the subject. The 3D control is deeper than anything else here, and it is a one-time purchase.

Bad for: overkill for a flat frame. And a phone at a dramatic angle makes on-screen text hard to read — beautiful, but not if the screenshot needs to be legible.

Method 4: ImageMagick, scripted

For App Store screenshot sets, marketing pages with a dozen mockups, or anything you will regenerate.

Step 1 — get a device PNG with a genuinely transparent screen area.

Step 2 — find the screen rectangle:

magick frame.png -alpha extract -threshold 50% -format "%@" info:
# → 880x1908+104+112   (width x height + x + y)

Step 3 — composite:

magick frame.png \
  \( shot.png -resize 880x1908^ -gravity center -extent 880x1908 \) \
  -geometry +104+112 -compose DstOver -composite out.png

The ^ makes the resize fill rather than fit, and -extent crops the overflow — the equivalent of "cover".

Step 4 — batch it:

for f in shots/*.png; do
  magick frame.png \( "$f" -resize 880x1908^ -gravity center -extent 880x1908 \) \
    -geometry +104+112 -compose DstOver -composite "out/$(basename "$f")"
done

Good for: repeatable, identical output across a whole set. Free, and it runs anywhere.

Bad for: no shadows, no reflections, no 3D. The device is a flat sticker. And every visual change means editing numbers rather than dragging something.

Method 5: CleanShot X

Worth knowing about because it collapses two steps into one: it takes the screenshot and frames it, without an export in between.

Step 1 — capture with CleanShot X instead of the system shortcut.

Step 2 — in the editor that appears, apply a background and padding, and a device frame where one applies.

Step 3 — annotate if the screenshot needs callouts or arrows, which is where CleanShot is genuinely strongest.

Step 4 — copy straight to clipboard or save.

Good for: anyone who takes screenshots all day. The capture-to-shareable loop is the fastest of anything here, and the annotation tools are excellent.

Bad for: the mockup side is shallow. Backgrounds and padding, yes; photoreal 3D device staging, multi-device scenes and photo compositing, no. If a frame is a finishing touch it is plenty; if the mockup is the deliverable it is not.

Flat frame or 3D angle?

This choice matters more than which tool you pick, and it comes down to one question: does the reader need to read the screen?

Use a flat, straight-on frame when the content is the point. Documentation, a feature announcement where the UI matters, a comparison table, anything a reader will study. A flat frame adds context without costing legibility, and it holds up when the image is scaled down to a thumbnail or a feed preview.

Use a 3D angle when the impression is the point. Landing page heroes, launch posts, anything where you want the product to feel like an object rather than a page. The trade-off is real and often underestimated: rotate a phone fifteen degrees and body text on its screen stops being readable. That is fine if the screen is showing a chart or a bold headline, and a problem if it is showing a settings panel.

Photo scenes sit between the two. A phone held in a hand or a laptop on a café table reads as lifestyle rather than product documentation. Good for social, weak for anything where a reader is trying to learn something.

A practical compromise for a landing page: a 3D hero at the top, flat frames further down where you actually explain features. The hero sets the tone; the flat frames do the work.

Getting a whole App Store screenshot set out at once

If you are producing five or six screenshots for a listing, the per-image workflow falls apart quickly and this is where the scripted route earns its setup cost.

A reasonable structure: keep your raw Simulator captures in one folder, a device frame PNG next to them, and a single script that writes framed copies into an output folder. Rerun it whenever the UI changes and every image regenerates identically — same padding, same alignment, same background — which is exactly what a store listing wants and exactly what hand-placing images fails to deliver.

Two details that save time later. Name the raw captures in listing order (01-home.png, 02-search.png) so the output is already sorted. And keep the raw captures in the repo, not just the framed output, because the next UI change means re-framing from source rather than reverse-engineering what you did.

One caveat worth repeating: framed mockups are usually not what Apple wants in the main screenshot slots. Check the current App Store requirements before assuming a framed image is acceptable there. Framed mockups belong on your own site and in social posts.

Troubleshooting

The screenshot is blurry inside the frame. You are scaling up. A 1x screenshot stretched onto a 2x device screen has half the pixels it needs. Recapture at native device resolution.

Black bars appear inside the phone screen. Aspect ratio mismatch. Switch from contain to cover, or crop the source to the device's ratio.

The notch or Dynamic Island covers content. Your screenshot includes the status bar area, and the frame's cutout now sits on top of it. Capture from a Simulator matching the device so the safe areas line up.

The frame looks dated. A current app inside a three-year-old phone reads as old. For evergreen pages, prefer a recent model, or a flat frame without an obvious silhouette.

The exported PNG is several megabytes. Gradient backgrounds dither badly in PNG. Export WebP at quality 85 — usually under 100 KB for the same image with no visible difference:

cwebp -q 85 mockup.png -o mockup.webp

The status bar shows my real battery and time. Only fixable before capture. Use a Simulator with a clean status bar.

Text inside the mockup is unreadable at post size. Test at the size it will be seen, not in your editor. If it fails, crop into the part that matters rather than showing the whole screen.

Backgrounds: the part that decides whether it looks designed

The frame is the easy half. Most homemade mockups fail on what surrounds the device, and there are only a few ways it goes wrong.

Too busy. A photographic or heavily patterned background competes with the screenshot for attention, and at thumbnail size the two blur into each other. If the screenshot has a lot going on — a dashboard, a table, dense UI — the background should be nearly plain.

Too little contrast. A dark phone on a dark background disappears. A white iPhone on a white gradient does the same. The device silhouette needs to separate from what is behind it, which usually means a mid-tone background for a black device and a darker one for a white device.

Padding that is too tight. A device jammed against the edges looks cropped by accident. A useful default is padding of roughly ten to fifteen percent of the image width on each side. It feels like a lot in the editor and looks correct everywhere else.

A gradient in the wrong direction. A gradient running the same direction as the device's own shading flattens it. Running it across, or placing the light side of the gradient behind the dark side of the device, keeps the object separate from the field.

Colour that fights the product. A background pulled from your brand palette usually works. A background pulled from a template gallery usually does not, because it was chosen to look good behind a generic screenshot rather than yours. Tools that generate a background from the colours in your image sidestep this neatly.

One test that catches most of these: shrink the finished mockup to about 400 pixels wide and look at it. If the device stops reading as a device, or the screen turns to mush, the background is doing too much.

FAQ

Do I need Photoshop? No. All four methods above work without it, and two of them are free.

Can I put a screenshot in an iPhone mockup for free? Yes. Shots.so has a free tier, Screenify Studio's free plan includes device frames, and the ImageMagick route costs nothing at all.

Which iPhone frame should I use? Whichever matches the device you captured from. Mixing an iPhone 15 screenshot with an iPhone 12 frame produces a subtly wrong aspect ratio that people notice without being able to say why.

Can I do this with a video instead of a screenshot? Yes — see how to add a device frame to a video you already recorded.

What about iPad or Mac frames? Same process. Screenify Studio's flat frame library covers iPhone and iPad; the 3D stage adds MacBook, iMac, iMac Pro and Pro Display XDR.

Are these mockups OK for the App Store? Apple has specific requirements for screenshot dimensions, and a framed mockup is usually not what the store wants for the main screenshot slots. Framed mockups belong on your website and social posts. For store assets, follow Apple's spec.

Does the image get uploaded anywhere? With Shots.so, yes — it is a web app. Screenify Studio, Rotato and the ImageMagick route all process locally.

Can I add a shadow under the phone? Shots.so, Screenify Studio and Rotato all do shadows. ImageMagick can, but you compose it manually.

When a mockup is the wrong choice

Framing is not free, and there are cases where it actively hurts.

Bug reports. A framed screenshot in an issue tracker wastes space and hides detail. Whoever is fixing it wants the raw capture at full resolution, ideally with an annotation pointing at the problem. Frames are for persuasion; bug reports are for information.

Documentation of a specific control. If the sentence is "click the gear icon in the top right", the reader needs a tight crop of that corner, not a whole phone. A frame pushes the useful pixels down to a fraction of the image.

Anything printed. Device frames date fast and print poorly. A flat UI screenshot survives both.

Comparison grids. Six framed phones side by side become six tiny illegible screens. Drop the frames and let the screenshots breathe.

When the screen is nearly empty. An onboarding screen with a headline and one button, inside a phone, inside a gradient, is a lot of image carrying very little. Either crop in tight or pick a screen with something on it.

The general rule: frame when you are selling, crop when you are explaining. A landing page sells. A help article explains. Most people default to framing everything because it looks nicer in isolation, then wonder why the docs feel hard to follow.

Which one to use

One screenshot, right now, no install: Shots.so.

A set of screenshots you will regenerate: the ImageMagick script.

A hero image where the device is the subject: Rotato.

The screenshot might become a video, or the file should not leave your machine: Screenify Studio — free to start, frames and photo scenes included.

Related reading: Turn app screenshots into an App Store preview video · Device mockup generators compared · Shots.so alternative for Mac