AppScreenshots DocsPublish and maintain screenshot sets
Hand off approved files cleanly, then update the source project safely for every release or experiment.
Publish and maintain screenshot sets
The exported ZIP is a delivery artifact; the editable project is the long-term asset. Keep both, together with the short record that explains what was approved and where it was published.
Make a useful handoff package
Give the uploader or release owner a package that can be understood without reopening the editor:
| Include | Why it matters |
|---|---|
| Approved ZIP or PNG files | The exact files intended for upload. |
| Source project name | Lets the team find the editable master for a correction or next release. |
| Market and platform | Prevents an iPad, Android, or wrong-language package from being uploaded by mistake. |
| Frame order and release version | Makes the intended storefront sequence explicit. |
| Approval record | Identifies who approved copy, legal claims, localization, and visual QA. |
| Publication date or ticket | Connects the asset to the release it represents. |
AppScreenshots does not submit assets to app stores. Confirm current store requirements and complete the final upload in the relevant store console.
A safe update loop
Use this sequence whenever product UI, messaging, supported devices, or markets change:
Duplicate the approved source
In the dashboard, duplicate the last approved project. Name the new version clearly, for example 2026-09 iOS 3.2 — English master. This preserves a recoverable record of what was live before the change.
Replace product proof first
Update every device screen that shows changed UI, content, prices, or claims. A beautiful layout with a stale product screen is still incorrect.
Update the story and localizations
Confirm whether frame order, headline, or supporting copy must change. Then update each approved locale and perform the visual review again.
Review, export, and archive
Run the export checklist, hand off the resulting files, and record the new version, approval date, and publication location.
When a screenshot set should be refreshed
Refresh the source project when any of the following becomes true:
- A major product surface has changed or the proof in a frame is no longer current.
- The app’s positioning, pricing, subscription language, or approved claims have changed.
- A destination changes its image dimensions, file count, policy, or available device classes.
- Brand type, color, logo, campaign visual system, or legal text has changed.
- A new language or market is added.
- A conversion experiment has a clearly approved hypothesis.
Run experiments without losing the control version
Keep one approved master untouched and create one duplicate per experiment. Change one meaningful variable at a time—such as the first-frame headline, a feature order, or device scale—then label the project with the hypothesis and release window.
| Record | Example |
|---|---|
| Hypothesis | “Showing the weekly plan first makes the value clearer for new runners.” |
| Variant | A: progress dashboard, B: weekly plan |
| Audience / market | US iPhone |
| Date range | 2026-09-01 to 2026-09-21 |
| Decision | Keep, revert, or test again with a new hypothesis. |
Measure results in the appropriate store or analytics system. AppScreenshots helps create controlled creative variants; it does not determine store conversion results on its own.
Keep the asset library healthy
- Store release-specific screenshots in Project Assets and reusable brand assets in Brand Assets.
- Keep the raw app capture that was used in an approved delivery; it makes later device or size changes much faster.
- Retire outdated logos, screens, and campaign imagery from the active working set so they are not selected accidentally.
- Never rely on a PNG export as the only editable source.
See Manage projects and backups for safe project housekeeping, or Related tools when the same story needs mockups or extra sizes.