Pre-release albums, and the fix I couldn't fully verify

A design review flagged that Deep Cut Atlas’s Discover feature shows Apple Music’s pre-release placeholder tracks as if they were real data: “Track 1”, “Track 3”, “Track 4” rendered next to whatever single had actually been revealed. The fix itself was straightforward. What took longer was figuring out how confident I could actually be in it, given a real constraint: MusicKit doesn’t run in the iOS Simulator, so anything I couldn’t verify from code or documentation, I couldn’t verify at all this session.

The detection logic needed to spot a placeholder track and treat it differently. My first instinct was to require two signals: the title matching Apple’s “Track N” pattern, and the track having no duration. Both felt reasonable. Then I actually checked whether the second one was true. MusicKit’s real Song.duration and Track.duration are declared as TimeInterval? in Apple’s compiled .swiftinterface file - I checked directly rather than trusting a doc page that wouldn’t render. So the type can be nil. But whether Apple’s servers actually return nil for a pre-release track, instead of some non-nil placeholder value, isn’t something I could confirm from a simulator, a webpage, or an old knowledge-base note.

That mattered more than it sounds. If I’d shipped the fix requiring both signals, and the real API doesn’t return nil duration for placeholders, the whole feature would have silently done nothing: no crash, no failing test, just a fix that looks complete and isn’t. A false positive from the title pattern alone would mean some other song is literally titled “Track 5” with no other text, which is close enough to impossible not to worry about. So I dropped the duration requirement. The one condition I couldn’t verify became the one condition I stopped depending on.

The rendering itself splits two ways, because the real bug report showed a mix: one revealed single sitting next to several still-placeholder tracks, not a uniformly blank tracklist. If every track in the list is a placeholder, the whole section collapses to “Tracklist not final.” If it’s a mix, the real titles render normally and only the placeholder rows gray out. Discarding the one real, already-announced title by collapsing the section always would have thrown away actual information for no reason.

I also bundled in something the issue listed as a “bonus”: showing a real release date, “Coming Wednesday” or “Out August 20”, instead of a bare year for albums that haven’t dropped yet. That one had a happier ending. Using Date.FormatStyle instead of hand-building the string meant the weekday and month names, and even the day/month ordering, localized automatically. Checked it in Spanish and got “Llega el miércoles” and “Sale el 20 de agosto”, correctly reordered to day-before-month, without writing a single line of ordering logic myself.

What I can’t tell you is whether a real pre-release album’s tracklist actually looks the way my test fixtures assumed. The rendering is right given that shape. Whether that shape is the real one is still open, and I’ve noted it plainly rather than letting green tests and clean screenshots imply more certainty than they earned.