Introduction

A raw iOS Simulator screenshot captures the app display, but App Store images and marketing mockups often need the device frame as well. The important distinction is that simulator capture and framed presentation are usually two separate steps. Once you understand that split, the workflow becomes predictable.

Know What the Simulator Actually Captures

The Simulator can save the current display quickly, either from the menu or from the command line.

xcrun simctl io booted screenshot /tmp/app-screen.png

That command captures the screen contents of the booted simulator device. It is excellent for automated UI testing, documentation, and CI pipelines because it produces a clean PNG without desktop clutter.

What it does not guarantee is a marketing-style hardware frame around the image. For that, you usually need a different step.

Two Reliable Ways to Get the Frame

There are two practical workflows.

1. Capture the simulator window itself, with the bezel visible.
2. Capture a raw screenshot and apply a frame afterward.

The first option is quick for one-off use. In the Simulator app, enable the visual device bezel and then use the macOS screenshot tool to capture the window. That records what you see on screen, including the frame, status bar, and any visible chrome.

The second option is better when you need consistent assets across many screenshots.

Capture Raw Screenshots for Automation

For reproducible results, start with raw screenshots from simctl.

xcrun simctl list devices
xcrun simctl boot "iPhone 15"
xcrun simctl io booted screenshot screenshots/home.png

This keeps the screenshot pipeline deterministic. You know the exact device, exact screen contents, and output path. That is much easier to automate than a manual window capture.

Raw screenshots are also easier to crop, version, and regenerate after UI changes.

Add Frames After Capture

A common approach is to frame the exported screenshots afterward with a separate tool. Fastlane is often used for this because it fits well into iOS release workflows.

lane :framed_screenshots do
  frameit(path: "./screenshots")
end

Then run it from the project directory.

bundle exec fastlane framed_screenshots

This workflow is useful when you need multiple locales or multiple devices with matching output. It also separates app rendering from presentation styling, which keeps the process easier to debug.

Use Window Capture for Quick Manual Results

If you only need one screenshot with a frame, manual capture is simpler than building a framing pipeline.

A practical sequence is:

• run the app in the desired simulator device
• make sure the device bezel is visible in the Simulator window
• use the macOS screenshot shortcut to capture that window
• crop any extra margins in Preview if needed

This gives you the real visible hardware frame, but it depends on screen scale, desktop layout, and window position. It is fine for ad hoc work, but not ideal for repeatable batches.

Separate Development Screenshots from Store Assets

Many teams mix up two different goals.

• Development screenshots are for bugs, docs, or test evidence.
• Store or marketing screenshots are polished visual assets.

For development, a raw simctl screenshot is usually better because it is clean and scriptable. For store assets, framed output often looks better, but it should usually be the last styling step rather than the capture step.

Keeping those workflows separate saves time. You do not need frames for every engineering screenshot.

Watch Out for Resolution and Scaling

Framed screenshots are only useful if the base image resolution matches the expected device output. If you resize the simulator window manually and then capture the whole window, you can end up with inconsistent scale between screenshots.

That is another reason raw simulator capture is a stronger foundation. It starts from the simulator's native rendered screen instead of from whatever size the window happened to be on your desktop.

Common Pitfalls

• Expecting simctl io screenshot to behave like a full marketing export tool.
• Capturing the simulator window manually and getting inconsistent scale across different screenshots.
• Forgetting that a visible bezel in the app window is different from a framed post-processing workflow.
• Using desktop screenshots in CI, where a deterministic command-line capture would be more reliable.
• Treating App Store imagery and engineering screenshots as if they had the same requirements.

Summary

• Raw simulator screenshots and device-framed screenshots are usually different steps.
• 'xcrun simctl io booted screenshot is the reliable way to capture screen contents.'
• For one-off framed images, capture the simulator window with the bezel visible.
• For repeatable framed assets, capture raw images first and apply frames afterward.
• Choose the workflow based on whether you need automation or quick manual output.