ASOShot, a no-cost editor that runs in the browser for App Store and Google Play screenshot graphics, was built and launched by a developer who wrote about it on dev.to; the site is asoshot.com. Because the author labels the piece as the maker's own explanation of the product's rationale instead of an independent review, each capability mentioned below is a product claim attributed to that maker and not a result confirmed through testing.
The stated problem is repetition rather than a shortage of design tools. The author argues general-purpose design software can produce good store assets, but maintaining a matrix of screens, store sizes and languages without drift is the hard part. That framing matters for freelancers who bill store-asset work: the pitch is about reducing rework across a matrix, not about replacing a design tool.
ASOShot's central design idea, per the author, is splitting decisions into two groups. Shared decisions — background, typography, device model, frame color and overall composition — live in a Global Studio. Per-screen exceptions, such as a longer German headline or a different crop, are stored only as the properties changed for that screen. The author says a frame with a custom rotation can still inherit a later global color or shadow change.
That inheritance model is the concrete mechanism the post documents. The author contrasts it with copying artboards, which works for a first version but becomes harder when a later change should reach every screen except a few intentional overrides. For anyone maintaining localized screenshot sets, the claim to evaluate is whether partial inheritance actually holds up on a real release.
Regarding how data is handled, the author describes a local-first design: canvas rendering and imported screenshots remain inside the browser, while projects may be stored in browser storage or exported as a portable JSON backup. Translation forms the exception, per that account — only caption text plus the chosen languages travel to the configured translation endpoint when that feature is used, and no images are transmitted for translation. According to the author, that boundary is significant for apps that have not yet been released.
Export fidelity receives the most technically detailed treatment. A DOM-to-image method served as the initial renderer, the author says, and while it handled ordinary layout, realistic perspective frames broke it: browsers composite CSS 3D layers at the current display size, so scaling that output up for a store-resolution export may reveal soft edges and a discrepancy between the preview and the downloaded file.
According to the author, the present export route renders straight onto a 2D canvas. The same geometry used in the preview governs backgrounds, captions, badges, shadows, device edges and screen images, while perspective devices are projected and drawn in slices rather than by capturing the editor DOM. Export, the author says, runs at the target's native pixel dimensions even as the preview remains fluid.
Today's feature set is enumerated by the author: templates across 15 categories; export targets for iPhone, iPad and Android; device frames in flat and perspective styles; multiple frames per screen, cross-screen layouts included; captions covering more than 20 locale presets; PNG and JPEG export at full resolution; batch ZIP export spanning chosen screens, sizes and locales; plus JSON project backup and restore. These remain the maker's feature claims and have not been independently confirmed.
The author also states plainly what does not exist: there is no public screenshot-generation API or MCP server, and ASOShot is currently an interactive browser editor. The post says the author prefers stating that rather than advertising a roadmap item as a finished feature — a useful signal for developers who might otherwise assume an automation hook.
A sequential workflow is what the author describes: choose a template that comes close to the app's visual category; then select the store sizes that will genuinely be submitted; upload actual product captures; write a single clear benefit for each screen; inspect frame placement and text at every chosen size; add locales and check the automatic translations prior to publishing; finally, export the resulting matrix as a ZIP.
A scope caveat relevant to release planning is offered by the author: since asset requirements are revised by Apple and Google, checking their current documentation before a release is still necessary, and the editor does not replace that step. Once those targets are known, the stated goal is to eliminate repetitive composition and export labor.
For freelance designers and developers who take on store-asset work, the practical implication is narrow but real. If the inheritance model behaves as described, the recurring cost of a late global change across many locales and sizes drops, and the local-first rendering claim reduces the friction of handling screenshots for unreleased apps. That is editorial interpretation of the author's claims, not a measured outcome.
The tradeoffs are visible in the same account. A browser editor with no API or MCP server means no scripted pipeline integration, so teams that generate assets programmatically would still need their own tooling. The author also frames the product as complementary to store documentation rather than authoritative about current size requirements.
Several things remain unknown from the supplied evidence. There is no stated pricing beyond the word free, no release date, no version number, no independent verification of export fidelity, and no information on how translation endpoints are configured or which provider is used. The post is a maker's account, so claims about preview-versus-export accuracy rest on the author's description alone.
The author closes by inviting specific feedback about which screen size, frame arrangement or localization step slowed a real release down. For working freelancers, the honest position is that ASOShot is worth evaluating against an actual submission matrix — with the caveat that the evidence here is the maker's own description, and the store requirements still need checking separately.