I got tired of re-screenshotting my app every time I made a change . So I built a workflow that does it for me.

Tom den Boon — Mon, 06 Apr 2026 11:37:29 +0000

Ship a mobile app and suddenly you need screenshots everywhere. App Store listings. Your website's feature pages. FAQs. Social media. Each one lives in a different place, and each one goes stale the moment you push an update.

My app's theme engine (powered by Monkeytype) supports 190 themes. I'm working towards making the website available in all of them, which means every screenshot on every feature page needs a variant per theme. That's 50 screenshots across 13 features. At 190 themes, that's 9,500 screenshots total. And that number grows with every new feature and every new theme added.

I needed the screenshots to live in the codebase, regenerate on demand, and flow into everything downstream without me touching Canva or Figma.

The Setup: A TypeScript Monorepo

The prerequisite is a monorepo. Mine is TypeScript with a React Native app alongside a web app, but the principle applies anywhere your mobile code, web code, and asset pipeline can share context.

The relevant structure looks something like this:

monorepo/
├── apps/
│   ├── mobile/       # React Native app
│   ├── web/          # Website
│   ├── remotion/     # Remotion compositions
│   └── maestro/      # Test flows + screenshot automation
├── packages/         # Shared UI, themes, config
└── assets/           # Screenshots, icons, media

The important bit: themes, typography tokens, SVG assets (muscle illustrations, exercise videos, etc.), and the component library are all importable from anywhere in the project. That matters later.

Maestro

Maestro is a mobile UI testing framework. I use it for testing, but it has a feature most people overlook: it can take screenshots as part of any test run.

Here's what I did:

Wrote a flow for every feature in the app.
Added screenshot commands at the key moments in each flow.
Built a deterministic seed that makes every screenshot consistent and reproducible.

Flow used for the cover image:

appId: com.tom.logro
---
- launchApp
- runFlow: ./setup/seed-data.yaml

- tapOn:
    id: "tab-progress"
- takeScreenshot: screenshots/features/progress-dashboard/${THEME_ID}/dashboard

The Seed

The seed is what makes this work. Before any flow runs, a setup script populates the app with deterministic data: specific exercises, programs, workout history, and stats. Because the data is idempotent, screenshots come out identical every run. Same numbers, same layouts, same everything.

Each flow opens the app with a deep link that triggers the seed and sets the theme:

appId: com.tom.logro
---
- openLink: "volm://?seed=true&theme=${THEME_ID}"
- waitForAnimationToEnd:
    timeout: 60000
- assertVisible:
    id: 'tab-home'

The seed=true parameter tells the app to populate itself with deterministic data on launch. THEME_ID is passed in when running the suite, so the same flows produce screenshots for any theme.

This also means the screenshots look good, because the data was designed to look good. You're not screenshotting a blank app or a test account with three entries.

For theme switching, I pass a theme parameter when running the flows. Maestro runs the full suite once per theme, and I get a complete set of screenshots for each.

Now when I update a screen, I run the Maestro flows and everything updates:

App Store screenshots regenerate automatically.
The website pulls the same images for feature pages and FAQs, across all 190 themes.
Everything stays in sync because there's one source of truth: the flows.

No re-screenshotting. No re-exporting. No "wait, is this the latest version?" I trigger this manually for now. It's not wired into CI. But even running it by hand saves a stupid amount of time. I can be genuinely confident in this part of the pipeline.

Caveat: Seeded Data Doesn't Always Look Real

The tricky part is that the flow has only been running for seconds. So your "active workout" screenshot shows a timer at 0:10 because Maestro literally just navigated there. Real users don't have a workout that's ten seconds old. You can work around some of this with clever seed design, but certain screens will always betray the fact that no human was actually using the app. It's a trade-off I'm fine with, but worth knowing.

Remotion

Remotion is a React-based framework for generating images and video programmatically. Because compositions are just React components, they can import everything from the monorepo: design tokens, components, and those Maestro-generated screenshots.

So far I've used it for:

App Store screenshot slides. Composing the raw screenshots into device frames with marketing copy.
One social media post. A branded carousel for Instagram. I've only made one so far, so I can't claim this is a proven workflow, but I was happy with how it turned out.
The cover image for this post. The Maestro flow above ran once per theme, Remotion composed all 190 screenshots into a single grid sorted by color.

Remotion without an LLM in the loop is painful compared to visual tools. The feedback cycle is just too slow. Where it works is when you point something like Claude Code at your repo and iterate on compositions, because the LLM already has access to your actual tokens and assets. That makes the loop fast enough to be worth it. Without that, I'd probably just use Canva.

The real value isn't the output quality. It's that the assets are generated from the same source as everything else. Update the app, run the flows, regenerate the Remotion compositions. Nothing drifts.

The Pipeline

Here's how it connects:

One repo. One set of screenshots. No duplicated assets. Update anything upstream, everything downstream regenerates.

Trade-offs

Maestro setup is a real investment. Building deterministic test data and configuring flows for every screen took serious time. Keeping the seed up to date as the app evolves is ongoing work too. This is infrastructure, not a weekend project.

Remotion is only practical with AI tooling. If you're not using an LLM to write and iterate on compositions, the feedback loop is too slow compared to Canva or Figma. They exist for a reason.

It's not in CI yet. I run this manually when I need fresh screenshots. I'll wire it into a deploy pipeline at some point, but even running it by hand cuts out most of the work.

The ROI is in reuse. You won't see the payoff from the first asset you produce. You'll see it the fifth time you add a feature and everything updates without you thinking about it.

Who This Is For

If you're a solo developer or small team and your screenshots keep going stale across multiple surfaces, this is worth the setup cost. If you're already in a TypeScript/React monorepo, you have most of the foundation.

Start with Maestro. Get your screenshots automated and seeded. That alone will save you more time than you expect. Remotion can come later if you want it. App Store slides are a good first project.

See the results on the feature pages, Play Store / App Store, and Instagram / TikTok.

DEV Community: Tom den Boon