Skip to content
Development

Featured albums, real MusicKit data, and a test that lied about passing

By Victor Da Luz
iosswiftmusickitdev-logdeep-cut-atlas

Deep Cut Atlas surfaces “deep cuts” - catalog albums by artists in your library that you don’t already own. The next question was obvious: when an artist has ten albums you haven’t heard, which one first?

Apple Music has an “Essentials” section on artist pages, so I assumed there’d be a matching API flag - some isEssential on Album I could sort on. There isn’t. MusicKit’s Artist type exposes twelve relationship views and none of them is “essential albums.” The “Essentials” you see in the Music app is a curated song playlist (artist.featuredPlaylists), not an album-level signal at all.

What does exist is artist.featuredAlbums - Apple’s editorial album picks, present for artists Apple has actually curated and nil for everyone else. I renamed the feature “Featured” instead of “Essential” to match the API instead of the UI label, added an isFeatured flag to LibraryAlbum, and reordered the “More from artist” list to float featured releases to the top.

Simulator testing with mock data looked right: the badge showed up, the sort worked. But the mock data is fake - MusicKit doesn’t run in the simulator at all, so nothing in that pass touched the real featuredAlbums API. The only way to know if Apple actually returns useful data here was a physical device.

It did. Querying Bad Bunny’s catalog on-device returned 3 of 25 albums flagged as featured: Un Verano Sin Ti, YHLQMDLG, OASIS - all real, all sensible editorial picks. Good sign the feature works against live data, not just my mock fixtures.

Then the full test suite, run as part of the same device-verification pass, caught something the simulator run hadn’t: a pre-existing sort test asserting strict newest-first order for a Khruangbin discography where one album - Con Todo El Mundo - had been marked isFeatured: true in the mock fixture as part of this same change. The test never got updated to expect it first. It had been “passing” only because nobody had re-run the suite since the fixture changed.

Nothing about that is exotic - it’s just what happens when a fixture and its test drift in the same change and nobody runs the tests before merging. The fix was one line, but it’s a reminder that “the code compiles and the simulator looks right” and “the tests actually pass” are two different claims, and only running the second one catches the drift.

Related reading