Direct answer
Listing assets need version control for the same reason code does: the store consoles keep only the live version, so the moment something goes wrong β a rejected submission, a conversion drop after an edit, a locale overwritten by mistake β the first question is "what exactly changed, and what did we have before?" and the consoles cannot answer it. A working system needs four properties: one canonical home per asset (not "the newest file in the shared drive"), a snapshot of the full package at every submission, a change log that records who changed what and why, and a tested way to restore any previous package. None of this requires heavy tooling β it requires deciding that the listing package is a versioned artifact, not a pile of latest drafts.
What to version
| Asset | Why history matters | Restore scenario |
|---|---|---|
| Metadata per locale (title, subtitle, keywords, descriptions) | Ranking or conversion drops need a diff to diagnose | Revert after a failed experiment |
| Screenshot sets per locale and device class | Rejections and redesigns reference prior sets | Resubmit the last approved set |
| Screenshot source files and text layers | Locale swaps and edits need editable sources | Rebuild one frame without redesigning five |
| Submission package snapshots | "What was live in March?" has one answer | Rejection appeals, before/after analysis |
| Change log with reasons | The why disappears in weeks without it | Diagnose which change moved a metric |
Recommended flow
1. Declare one canonical home per asset type
Every asset gets exactly one authoritative location; everything else is a copy. The moment two "current" versions of a subtitle exist β one in a doc, one in the console β the system has already failed, silently.
2. Snapshot the full package at every submission
Before each submission, capture everything as submitted: all locales, all fields, all image files, tagged with date and release. This is the artifact that answers rejection questions and enables true rollbacks. Store snapshots somewhere durable and separate from working files.
3. Log changes with reasons, at edit time
A change log entry is thirty seconds when written at edit time and unrecoverable three weeks later. Minimum fields: date, asset, who, what changed, why. The "why" is what turns the log from bookkeeping into diagnosis material.
4. Keep sources editable and paired with exports
Flattened screenshot PNGs are what you ship; layered sources are what you maintain. Version them together β a source that drifted from the shipped export is a trap for the next editor.
5. Test the restore path before you need it
Once, deliberately: take last quarter's snapshot and walk through restoring one locale's package. If the restore requires a person who left or a tool nobody has licenses for, you have backups, not recoverability.
6. Back up on a schedule that matches release cadence
Snapshots at submissions cover most needs; a scheduled export of console state (quarterly, or before bulk edits) covers the rest β including changes made directly in the console that bypassed your process, which happen everywhere.
Common failure modes
The shared drive is the version control
Folders named final, final2, final-approved-NEW are not versions; they are a memory test that everyone eventually fails. Canonical home plus dated snapshots replaces the guessing.
Snapshots without the why
Teams that keep files but not reasons can restore anything and explain nothing. When a metric moved, the log's "why" column is the difference between diagnosis and archaeology.
Console edits outside the system
The quick console fix during launch week never makes it into the log, and the next diff against your records is wrong. Rule: console changes get logged the same day, no exceptions β or better, they go through the same pipeline as everything else.
Versioning only the primary locale
The English package is versioned; other locales exist only as whatever is live. Locale incidents β overwrites, stale assets, wrong-market uploads β are exactly where restore requests come from.
Version control checklist
- One canonical home declared per asset type, all locales.
- Full package snapshot at every submission, tagged and stored durably.
- Change log with date, asset, owner, change, and reason.
- Layered sources versioned alongside shipped exports.
- Restore path tested once on a real snapshot.
- Scheduled console-state export to catch out-of-band edits.
Operating rule
If you cannot produce last month's exact listing package for any locale in ten minutes, you do not have version control β you have optimism.
Why this matters in App Store Helper
App Store Helper makes the listing package a first-class versioned object: metadata, screenshot assets, and locale variants live in one project with edit history, review checkpoints, and recorded reasons for changes. "What was in the package we submitted, and why" stops being a reconstruction exercise.