Automated App Store Screenshot Recapture
For iOS launches and redesigns, it reruns templated simulator flows to produce App Store screenshots across devices and languages.
When an indie developer is preparing to launch or update an iOS app, they provide their existing screenshot templates, simulator project, and a few fixed click paths. A path might go from the home screen to a scanning screen, enter demo data, and open a results screen. Each path maps to an App Store screenshot and a line of product copy.
The product follows those paths in an isolated simulator, waits for loading and animations to settle, captures the screen, and applies the device frame, headline, safe-area treatment, and brand layers from the template. Developers can generate previews across iPhone sizes, languages, and light or dark modes in one run instead of replacing source images one by one after every redesign.
When a screen or its copy changes, they simply rerun the same path. If a button cannot be found, the UI is in the wrong state, or localized text overflows, the job stops on the failing screen with a screenshot attached; after fixing the issue, the developer resumes from that step. Approved assets can be exported to fastlane or assembled into an App Store Connect upload package.
The first version supports only developer-designated, stable demo accounts and screen paths. It does not fabricate user reviews, subscription data, or feature outcomes. The product automates repetitive screenshot capture; developers remain responsible for verifying that the claims are true.
Why now
On July 27, an indie developer who said they had launched 25+ iOS apps reported switching to mature templates for store screenshots. S1 As of July 30, the post had accumulated 296 likes, 16 reposts, and 26,631 views; the repeated work of replacing headlines, colors, devices, and localized assets after a redesign is becoming a topic of discussion among similar developers. S1
Target user
Primary users are indie developers maintaining multiple iOS apps, along with small teams without a dedicated designer. The trigger is just before a new version is submitted, after the UI or copy has changed. Existing screenshots are then outdated, while several devices and languages need updating at once. Near review submission, they are willing to rerun fixed paths in exchange for consistent assets and a clear failure location.
Minimal entry point
Run specified Xcode and simulator versions in an isolated macOS executor. Convert click paths into XCUITest steps and locate controls with stable accessibility identifiers. Source capture can use fastlane snapshot; reuse frameit for device frames and localized titles, then export results in fastlane directory structure. S2S3 The template layer stores only screenshot slots, copy keys, safe-area settings, and brand assets, not a freeform canvas. On failure, preserve the current simulator and record the last successful step, element tree, and error screen. Limit the first release to fixed demo accounts and deterministic data. Generate light and dark modes, languages, and a small set of device combinations through a queue.
Punching above its weight
The first users are indie iOS developers already maintaining fastlane scripts. Publish a working example repository that shows recapture after a UI change, error diagnosis, and asset export end to end. Offer the local runner as a free CLI entry point so developers can validate one path on their own Mac. Real failure screenshots and fewer manual steps make strong version-update retrospectives for ongoing acquisition in iOS developer communities.
Competitors & gaps
- fastlane snapshot, frameit, and deliverGoogle
- fastlane already provides a deep pipeline for capturing source screenshots. snapshot can run UI tests by device and language, wait for network requests to finish, and generate an overview page. frameit can add device frames, backgrounds, and localized titles, while deliver can handle upload. S2S3 For teams with an existing UI-test setup, this combination is inexpensive and can run in CI. Its configuration, however, centers on test code, Snapfiles, and Framefiles. Developers must map product messages, screen states, and template slots themselves. When a run fails, snapshot either leaves that device without a screenshot or stops immediately, depending on configuration. S2 It lacks store-asset-specific step checks, error-page context, and a visual way to resume a run. The new product should remain compatible with fastlane directories and focus its value on orchestration and diagnostics; otherwise, it will be difficult to persuade fastlane users to switch.
- AppScreensGoogle
- AppScreens already covers template editing, responsive sizes, localization, bulk import, and direct store upload. A single project can preview multiple devices and languages and generate the files required for store submission. S4 For developers who do not want to write scripts, it handles most layout and delivery work. Its public workflow starts with selecting a template and adding existing app screenshots, then moves to preview and upload. S4 Reaching the right screens, preparing demo data, and recapturing the live UI therefore remain work for the developer. After an app redesign, users still need to supply fresh source screenshots for every screen. The opening is to bind click paths to template slots and stop on the failed screen. The product should also allow export to AppScreens rather than force users to redo their designs. A product that only offers templates and multi-size exports would compete directly with AppScreens' strengths.
How it makes money
Monthly subscription priced by number of active apps, including the local runner, template versioning, and a set amount of cloud execution; additional runs are usage-based.
The case against
Simulator flows can break because logins expire, system permission prompts appear, networks fluctuate, or animation timing changes. One bad capture can feed a loading state or stale data into an entire template set, then spread across every device and language. Reducing false positives requires maintained wait conditions, retry rules, and screen assertions. Preserving the failure environment also requires fixed Xcode, simulator, and app-build setups. Cloud execution would handle demo accounts, keys, and unreleased screens, so isolation and security documentation are essential. Localized text overflow is also difficult to detect reliably with pixel rules and often needs human review. For users with stable UI-test and fastlane workflows, the time saved may not justify migration costs.