Screenshots for an app that has no simulator

Deep Cut Atlas has had a placeholder card on this site’s homepage since day one, with a “Follow along in the dev log” link and nothing else. Building it a real marketing page was blocked on one thing: screenshots. And screenshots for this particular app turned out to be more interesting than I expected, because the obvious way to get them doesn’t work.

The obvious way doesn’t work. MusicKit, the framework Deep Cut Atlas is built on, has zero simulator support. Not “slow” or “flaky” - it returns nothing at all in the simulator. Real screenshots meant a physical iPhone, signed into a real Apple Music account, with my actual library on display in a public marketing image. I didn’t love that plan, mostly because whatever’s actually in my library at the moment I hit the shutter becomes permanent public content.

The app already had the fix, for a different reason. Since MusicKit can’t run in the simulator at all, the app already ships a mock implementation of its music-library service - MockMusicLibraryService - used for SwiftUI previews and for the unit test suite. It’s been there since early development, built to solve a completely different problem (how do you preview UI or run tests against an API with no simulator path). It turned out to be exactly what a screenshot session needed too: run the app in the simulator like normal, except the “library” is a small hardcoded fixture instead of a live account.

The one thing I had to be careful about: that fixture isn’t scratch space. The test suite asserts against it by name - specific artist and album strings drive specific test branches. Editing it in place to swap in “nicer” marketing data would have quietly broken tests that were passing for good reasons. So the swapped-in data lived on a throwaway, uncommitted branch instead - real product code never saw it.

The card said “album,” the card showed nothing. First pass at the swapped-in data rendered every album cover as a gray box with a music note icon. The app reads artwork from a URL field, and the mock’s sample data has always left that field empty - nobody had ever needed real art for tests or previews. For a marketing screenshot, a wall of placeholder icons defeats the entire point. The fix was almost embarrassingly simple: Apple’s iTunes Search API is free, unauthenticated, and returns real cover art URLs for anything in the catalog. A quick swap of the URL’s resolution segment (100x100 to 600x600) and the mock started rendering actual album covers, pulled from a public CDN, no Apple Music session required.

What shipped. Four screens - the new-release feed, an add-to-playlist confirmation, the queue, and recently-played history - each paired with a short description on a new /apps/deep-cut-atlas page. Reused every design token already on the site; nothing new to maintain. No App Store badge yet, since there isn’t a listing - the call-to-action points at this dev log instead, which felt more honest than a placeholder button pointing nowhere.

What I found along the way. Checking the new page at a narrow mobile width surfaced a real bug - text clipping on the right edge of the viewport - and confirmed it wasn’t specific to the new page. The homepage has it too. That one’s filed as its own follow-up rather than folded into this change; a marketing page for one app isn’t the place to fix a site-wide layout bug, even when you trip over it by accident while checking your own work.