The App Store screenshots nobody updated for two weeks

Deep Cut Atlas is mid-resubmission to App Review right now (a separate rejection fix, different story). While I was looking at the resubmission checklist, I asked a throwaway question: are the App Store screenshots actually still good? Nobody had asked that in two weeks.

They were not good.

Two directories, two different jobs

The repo has two screenshot folders that look like they should be interchangeable and aren’t: design/app-store-screenshots/ and design/marketing-screenshots/. The marketing set got refreshed recently for the imperfectsystems.com product page. I almost assumed that covered the App Store listing too, since they show the same four app screens. They don’t share a git history at all, and it turned out the App Store set had exactly one commit ever, the original submission from two weeks and roughly a dozen shipped UI changes ago.

Worse, even if I’d wanted to reuse the marketing set, the resolution is wrong. Apple’s App Store Connect wants an exact pixel match for your device class, 1320x2868 for the current flagship iPhone size. The marketing screenshots were captured through a mirrored physical-device window and came out at 406x890, nowhere close. Different problem, different constraint, no shortcut between them.

Getting real artwork into fixture data

The screenshots get generated from a Simulator run with mock data, since MusicKit doesn’t work in Simulator at all. The existing test fixtures are fine for unit tests and terrible for a screenshot: every album had a nil artwork URL, so the whole feed rendered as a wall of gray placeholder tiles. Simulator has full network access though, so I pulled real cover art from Apple’s public iTunes Search API and wired the URLs into the fixtures temporarily, capture, then revert. Same throwaway-branch pattern the original launch screenshots used, just never permanently checked in, since the app itself never needs real artwork baked into its test data.

One iTunes lookup handed back a completely wrong cover, a different artist’s remix with a similar title. I caught it by comparing HTTP headers side by side against a known-good URL rather than assuming the first search hit was right. Worth the extra minute.

The cache that outlived the rebuild

After wiring in the new artwork, most albums picked up real covers immediately. A few stubbornly kept showing blanks, on the exact same rebuild. Turned out the app has its own on-disk JSON cache for the Discover feed, and it survives a plain rebuild-and-reinstall completely untouched, because the binary changes but the app’s data container doesn’t. Only a full simctl uninstall actually clears it. That one cost some genuine confusion before I traced it, so it’s now written up as its own note rather than something I’ll have to rediscover next time.

Even “correct” wasn’t good enough

First pass at the Discover screenshot: real artwork loading everywhere it should. Looked done. Then came the obvious follow-up question I should have asked earlier: don’t we need these screenshots for the submission in the first place? Fair, and it made me double check my own claim that the marketing-screenshot refresh covered this, which it hadn’t.

Second pass, after fixing that: the feed’s default sort put two intentionally-fictional “coming soon” albums right at the top, both blank by design since they don’t exist yet. Technically accurate, still a bad first impression for a screenshot whose entire job is looking good. Switched to a different, completely real sort mode the app already ships (Artist A-Z) rather than hack the data, and two real albums that happen to start with the right letters landed at the top instead.

Third pass: one placeholder was still visible a few rows down, same pre-release albums. That’s when it clicked that a marketing screenshot doesn’t owe anyone a demo of every edge case the app handles. Pulled the fictional pre-release entries out of the feed for this capture entirely. Zero placeholders, first try that actually earned “good.”

Three rounds of “looks done” that weren’t, each one catching something the last pass had missed. None of the individual fixes were hard. Getting there took being willing to keep saying “not quite” instead of accepting the first plausible-looking result.

One I couldn’t automate

The Pro-unlock screenshot needed the real StoreKit purchase button with its live price, and StoreKit’s test configuration only loads when you run the app from Xcode itself, never from a command-line build. That’s a hard tooling wall, not a preference. That one screen had to be run once from Xcode by hand, then the automation took over again for navigation and the actual screenshot capture once the right build was live. Small moment, but a clean example of where automation’s honest boundary sits: it’s a StoreKit config loading behavior, not a permissions or UI-automation issue, so no amount of cleverness substitutes for the one environment that actually loads it.

All four screenshots shipped in the end, current UI, real everywhere it should be. Filed as its own issue rather than bundled into the resubmission fix, since it’s really a separate lesson: verify assumptions about “already done” work before staking a resubmission on them.