The playlist that already had the right name

Deep Cut Atlas used to be called Discoverer. After the rename, one visible artifact stuck around: the app’s own “To Check Out” playlist in Apple Music still listed “Discoverer” as its creator.

Before touching any code, I checked what the app actually does when it creates a playlist. The service calls the bare MusicLibrary.shared.createPlaylist(name:) - no author parameter, no description. A repo-wide grep for authorDisplayName or curator came up empty. MusicKit doesn’t expose a way to set a playlist’s “creator” label at all, which is why the app tracks its own playlists in a local set instead of relying on some API field.

That ruled out one candidate fix immediately: there’s no author parameter to update. The remaining question was whether the “Discoverer” label was coming from somewhere else, and the most likely answer was mundane - the playlist predates the rebrand, and Apple Music just froze the creator string at creation time.

MusicKit doesn’t run in the iOS Simulator, so testing this meant a real device. I built the current branch, installed it on my iPhone, and used a temporary debug flag to call the app’s own playlist-creation code and make a fresh playlist. It showed up in Apple Music as “Deep Cut Atlas.” The rebrand alone had already fixed this for anything created going forward - there was no bug to fix.

The two real playlists created before the rebrand still show “Discoverer,” and there’s no API to edit that after the fact. Recreating them would mean manually moving real library tracks into new playlists just to fix a label only I will ever see. Not worth it - closed as accept-as-is.

The useful lesson here wasn’t really about MusicKit. It’s that “investigate first, write code second” was right: the issue as filed proposed a candidate code fix, and if I’d just implemented it without checking, I’d have shipped a change to an API path that was never broken.