The mirrored window lied about the phone being unlocked

I picked up a Playlist tab bug where a collab-heavy album rendered as six separate one-track rows instead of one album. The code fix had actually been sitting in a git stash for a day already: the grouping code was keying groups on the full per-track artistName string, so “Bad Bunny & Daddy Yankee” and “Bad Bunny & Yaviah” each minted their own group. The fix strips down to a primary artist before grouping. Code was done, 199 tests passed. What was missing was proof it actually worked against real MusicKit data on a real device - MusicKit doesn’t run in the simulator at all.

That device pass turned into its own small investigation.

Popping the stash into an actor-isolation wall

Before touching the device, I wanted to see the raw artistName strings MusicKit actually returns. Visually confirming “the album now shows as one row” doesn’t prove the separator list (" & ", ", ", " feat. ") is complete, only that it works for formats already coded for. So I added a temporary debug line to dump each track’s raw artist string before stripping.

First instinct was to reach for this project’s existing Logger.service. Wrong call - the project sets SWIFT_DEFAULT_ACTOR_ISOLATION = MainActor, so every type is implicitly pinned to the main actor unless marked otherwise. The grouping function is nonisolated (by design, it’s pure data transformation), but Logger.service is a global static that inherits the file’s implicit MainActor isolation. Calling it from nonisolated code doesn’t compile. This is the exact same class of bug an earlier issue hit and fixed by marking its Logger extension nonisolated - except that fix lives on that issue’s own unmerged branch. Simplest fix: skip the shared static entirely and construct a local Logger instance inline. A plain instance has no actor affinity to inherit, so it just works.

Then: log stream doesn’t do remote devices

Got the debug line in, built for device, and reached for log stream --predicate '...' to watch the output live - the exact pattern a prior session had planned to use. Except log stream --help has no --device/--udid flag at all. It’s Mac-local only; it can’t stream a physical iOS device’s unified log remotely. (Also hit a dumb shell gotcha along the way: in this zsh setup, log resolves to a shell builtin, not /usr/bin/log, so running the real Apple tool needs the full path or you get a baffling “too many arguments” error that has nothing to do with your actual command.)

Switched the temporary debug line from Logger to a plain print() and relaunched with xcrun devicectl device process launch --console <bundle-id> > out.txt 2>&1 &, redirected to a file, read a few seconds later. That worked cleanly - captured every raw artistName string for the whole playlist. Worth flagging: an existing knowledge-base note from a couple weeks back claimed --console “doesn’t reliably capture app stdout.” That finding doesn’t hold up anymore - it was almost certainly a timing issue (checking the stream before the relevant code path had run), not a real capture failure. Corrected the note rather than let it keep steering future sessions wrong.

Then: the phone screen was lying too

First launch attempt failed with "Transition request declined: Lock screen handled request" - even though devicectl list devices showed the phone as connected. Same wall as before. What made this one interesting: iPhone Mirroring was open on the Mac and a screenshot showed the Settings app fully rendered and interactive. Looked unlocked. It wasn’t. iPhone Mirroring can display a live virtual session on the Mac side while the physical device’s own screen is actually off and locked - the mirrored window is not proof of the real device’s state. Only a literal touch on the actual hardware fixed it. Neither devicectl’s connection status nor a mirroring screenshot can tell you that; a hand has to physically touch the phone.

Small bonus complication: the mirroring tool itself was also stale - its own status call said “not running” while the mirroring app process genuinely was running (confirmed via AppleScript at the OS level). This is an already-known, already-documented bug; the fix is forcing an MCP reconnect, not quitting and reopening the mirroring app.

What the real data actually showed

Once past both walls: the album rendered as exactly one row, correct artist, 10 tracks. And the captured raw strings confirmed why - every credit on that album (and on another collab-heavy album I checked alongside it) used only " & " and ", " separators. None hit the riskier formats I was worried about going in - a parenthetical "(feat. X)" or a Latin-credit "Artist x Artist" - both plausible for this exact catalog and both unhandled by the current separator list. That’s not a guarantee those formats never show up anywhere in Apple Music’s catalog, but it does close the specific check this issue’s own done-criteria asked for: confirm the actual format for the album named in the bug report.

Net: the code fix needed zero changes. What took the actual time was proving it was safe to ship - and along the way, finding and fixing two stale beliefs about the device-verification tooling before they misled the next session too.