We make DevCove, a small developer-toolbox site that runs entirely in the browser. One of the tools we shipped this year is an App Store Screenshot Composer — the thing that turns raw phone captures into store-ready marketing images. This post is the backstory: why a team building a toolbox ended up writing yet another screenshot tool, and the tradeoffs we made along the way.
Where the idea came from
The toolbox itself started with a simple belief: developers reach for the browser for small jobs, and they usually do not want those jobs uploading their files to a stranger's server. We built format converters, validators, generators — all collected at devcove.dev, free and no account. Local processing became our default answer to "how should this work?" before anyone asked.
The screenshot composer grew out of our own release routine. When we ship one of our apps, we need App Store screenshots: real captures of the app, at Apple's exact pixel sizes, with a headline that survives a phone thumbnail. The sizes are not a suggestion. App Store Connect rejects an upload that is off by one pixel, and as of this year Apple's primary targets are the 6.9-inch iPhone and 13-inch iPad. Google Play has a flexible range instead, but strict rules about text density and alpha channels, plus a Feature Graphic that must be exactly 1024×500 with no alpha.
None of that is hard. It is just tedious enough that the tools we found were either subscriptions that wanted our captures uploaded, or templates that fell out of date the moment the spec list moved.
The obvious route we did not take
The easy path would have been to use an existing SaaS screenshot generator: drop captures in, pick a device frame, export. It works, and plenty of people ship releases that way.
We did not want to. Two reasons.
First, our product principle is browser-local. Uploading unreleased screenshots to a service — screenshots that show features nobody has seen yet — felt like the opposite of the toolbox's reason for existing. We could not in good conscience recommend a workflow to visitors that we would not use ourselves.
Second, deterministic output. When we use Figma or Photoshop templates, "export the right size" is manual and easy to miss a required slot. We wanted the layout engine and the export to agree by construction, so that what you see in the editor is what lands in the store console.
What we actually built
The composer takes up to six real screenshots, lets you paste them with ⌘V, reorder them to match your export sequence, then design one size at a time for either store.
The piece we are most happy with is the deterministic template set. Thirteen templates, and the same layout code drives both the live preview and the full-resolution Canvas export. There is no "close enough" step between what you see and what you get. That came out of a real annoyance: preview-and-export drift is how screenshots quietly ship with a headline cut off or a screenshot cropped differently than expected.
Text overflow gets a hard stop rather than a silent badge. If a headline or subtitle cannot fit its area at the minimum readable size, export refuses and tells you which screenshot and which line. For a team that has submitted with copy that wrapped badly, that single check is worth more than the sum of the templates.
We also embedded the policy rules we kept relearning, as live warnings:
- Google Play PNG output must have no alpha channel, so backgrounds get flattened.
- Text area should stay near or under 20% on Google Play; the tool estimates your ratio as you type.
- "Best", "#1", "million downloads" and hard CTAs like "Install now" get flagged, because ranking and superlative claims without context are exactly what gets listings flagged.
- Device frames are allowed but warned against on Google Play promotional surfaces, since they can reduce eligibility.
None of that replaces reading the store documentation. The presets were checked against the Apple and Google pages in mid-June, and we still point users to verify again on submission day, because the spec list moves.
The honest limits
A deterministic template composer is not a design suite. Game key art, custom illustration, and multi-locale brand campaigns still need Figma or Photoshop, and we say so on the page rather than pretending otherwise. Batch export stops at six screenshots, which matches the typical store set but not a big campaign. Those limits are deliberate; the tool is for the repeatable 90%, and being honest about the other 10% is part of the design.
We have also had to accept that a local-first tool makes some things harder. There is no account, so there is no way to recover work across machines, and no cloud storage means every new browser session starts clean unless you re-upload. That is the price of the privacy guarantee, and we think it is the right trade for our audience, but we did not get to have both.
What we observed after shipping
The most common reaction is not "nice templates". It is people asking why screenshots were so fiddly in the first place, which suggests the pain was universal and under-served. The policy warnings get more attention than the export button, which we did not predict and found encouraging: teams were worried about rejection, not about clicking.
We also learned that local-first needs to be louder than a tagline. Visitors assume online tools upload by default. Making the local-processing notice prominent, and linking it to the actual reason (unreleased features staying on your machine), mattered more for trust than any feature did.
Trying the workflow ourselves
The composer is one tool inside DevCove, which we build and maintain. It is free, needs no account, and never uploads your captures — the App Store Screenshot Composer lives at a URL you can bookmark for your next release.
If you ship mobile apps, how do you currently produce store screenshots — local templates, a subscription generator, or a designer? And if you have been bitten by a reject-after-upload, was it the pixels or the copy that got you? We are curious how your release workflow handles the spec drift between store updates.
Top comments (0)