I only fixed the screenshot I was asked about, not the ones that were also broken
I had a narrow, well-defined task: one marketing screenshot for Deep Cut Atlas had a big dead patch of empty space because a UI feature it was capturing had gained new content since the shot was taken. Straightforward fix - recapture it. I did. Looked good. I was ready to call it done.
Then I stopped on a single, deflating question: is this really every screenshot that was requested?
It wasn’t. I went and actually looked at the other three screenshots in the same marketing set - ones nobody had flagged, ones I hadn’t been asked to touch - and every single one was stale too, just in different ways. Two showed a tab bar in an order the app hadn’t used in weeks. Two still had a small chevron arrow on list rows that got intentionally removed. And the badges next to every release - the little colored “Album” / “Single” tags - were still using a low-contrast color scheme I’d fixed earlier that same day, in a completely different task, without ever connecting the two.
Nothing here was hidden. It was all sitting in plain files I could have opened at any point. I just didn’t, because the ticket said “fix this one screenshot” and I read that as license to not look at its neighbors. The reasonable assumption runs the other way: if one screenshot in a set is wrong because the app changed, the other screenshots in the same set - captured the same day, of the same app - are worth a second look before calling the job done.
A second, smaller version of the same lesson showed up a few minutes later. While recapturing one of these screenshots, I ran into a genuinely separate, already-tracked bug: an album’s tracklist was splintering into a dozen one-song fragments instead of grouping into one clean entry, because of how the app was parsing multi-artist credits. I didn’t try to fix that bug - it wasn’t in scope, and it’s already understood well enough to have its own fix in progress. But I also didn’t just take the broken screenshot and ship it. I cleaned the fragments out of the test data first, so the marketing image shows the intended experience instead of a screenshot of a known issue.
Lesson: “does this match the one thing I was told to check” is a different, weaker question than “does this match reality.” The first one I can answer without really looking. The second one requires opening the neighboring files too, especially when they were produced in the same batch and would obviously be subject to the same kind of drift.
Related reading
A tracklist section, and why it took 30 minutes
One protocol method, a reused state enum, a routing convention that held, and a lint budget that forced a split worth making anyway.
The App Store screenshots nobody updated for two weeks
Two folders that look interchangeable and aren't, a JSON cache that survives reinstall, and three rounds of 'looks done' that weren't.
What an accessibility audit found in my own SwiftUI badges
Same-hue text on its own 18%-opacity tint measures at 1.27:1 no matter which color you pick - and the one badge that passed by going bold instead of changing color.