How to Automate App Store Screenshots With Claude Code

Automating App Store screenshots means replacing a manual routine (open the simulator, take a screenshot, drop it into Figma, add a device frame, type a caption, export, repeat for every size) with a script you run once per release. It does not mean an AI generates your screenshots from nothing. The pipeline has three layers: capture the raw screens from a real build, composite them with a device frame and caption text, then export the exact pixel sizes each store size class needs. Each layer is a separate, ownable script, and Claude Code is good at writing and rerunning all three once you describe the screens you want.

The payoff is not speed on day one, it is speed on every release after that. The first time you build this pipeline takes about the same effort as a manual pass through Figma. The second time, and every time after, it takes one command.

For a one-off screenshot, the built-in simulator command is enough: xcrun simctl io booted screenshot raw.png captures whatever is on screen in your booted iOS simulator, in PNG by default. That works fine if you are grabbing a single frame by hand.

For a repeatable pipeline, you want something that drives the app to each screen and takes the shot automatically, because 'open the app, log in, navigate to screen four, screenshot' is not something you want to do by hand every release. Maestro is the tool for this: it runs plain YAML flows against your simulator or device, and its takeScreenshot command writes a PNG straight to a folder you point it at with MAESTRO_TESTS_DIR. Expo's own EAS Workflows examples reach for Maestro for exactly this, so it plugs into a build pipeline you may already have started.

A raw simulator capture is not a store-ready screenshot. It needs a device frame and, usually, a caption line above or below it. The long-standing tool for this is frameit, a fastlane action: it reads each raw PNG, matches it to the right device frame automatically based on resolution, and can composite a background color and marketing text around it. It leans on ImageMagick under the hood, and the device frames themselves download automatically the first time you run it.

If you want more control over the caption typography and layout than frameit's defaults give you, the alternative is a small Node script using the sharp image library: load the raw screenshot, place it inside a device-frame PNG at the right offset, draw your caption text on a canvas layer above it, export. This is a script Claude Code can write end to end once you show it one target screenshot mockup and describe the caption copy for each screen. Either path works. Pick frameit if you want speed and are fine with its defaults, write the sharp script if your caption design needs to match a specific brand look.

This is the layer most indie builders get wrong, usually by uploading too many redundant sizes because that is what older tutorials describe. Apple simplified this: for iPhone, you only need to supply the largest current display size and Apple scales it down automatically to populate the listing on smaller and older phones. As of 2026 that primary size is the 6.9-inch class at 1320x2868 pixels. If your app supports iPad, you also need the 13-inch iPad size at 2064x2752 pixels. Older fallback sizes (6.5-inch at 1284x2778 or 1242x2688, and 12.9-inch iPad at 2048x2732) are still accepted if you already have them, but they are no longer required from a fresh pipeline.

Build your export step to output the two required sizes by default, and only add the legacy fallbacks if you have a specific reason (an existing listing that already carries them, for example). A shorter export list is fewer files to keep captioned and current every release, and it is exactly what Apple asks for now, not what it asked for two years ago.

None of this requires living in a raw terminal. Claude Code's desktop app runs shell commands and reads your project the same way the CLI does, so you can hand it a plain description ('run the Maestro flows, then run the compositing script, then export at both required sizes') and watch it execute each step, showing you the output as it goes. The terminal is there if you want to poke at a single command yourself, but nothing about this pipeline requires you to have written a line of YAML or a compositing script before today. You describe the screens and the caption copy, Claude Code writes and runs the three scripts.

Once the pipeline exists, rerunning it after a UI change is one prompt: 'the dashboard screen changed, recapture screenshot 01 and recomposite it.' That is the actual return on building this instead of doing screenshots by hand every release: the second release is nearly free.

A scripted pipeline captures, frames, and exports faithfully. It does not decide which six screens tell your app's story, and it does not write captions that convert a browser into an install. Those are the two decisions that move App Store conversion, and they stay entirely yours. Automate the mechanical repetition, keep the taste calls.