On iOS 27, an app of mine that plays both its own audio and Apple Music tracks has two Now Playing clients in MediaRemote, as any app using ApplicationMusicPlayer.shared does: its own process's MPNowPlayingInfoCenter.default(), and MusicKit's player hosted out of process by com.apple.MediaPlayer.RemotePlayerService.
MediaRemote elects between them correctly - the client whose process is making sound becomes active - and both the Lock Screen and the CarPlay dashboard follow the change. My CPNowPlayingTemplate does not. It stays on whichever client it was on when the change happened, so during an Apple Music track the car shows my own (now stale) entry with the clock frozen and a play glyph while music is audible; in some sessions the reverse, where my own audio after a track gets a blank template whose play presses are delivered to MusicKit's empty player and interrupt playback.
From mediaremoted on iOS 27, handlePlaybackQueueRequest from CarPlayTemplateUIHost returns for <app> (pid) > default throughout a track, and no contentItemChange for the RemotePlayerService path is ever posted to CarPlayTemplateUIHost, though it is posted to springboard, CarPlayApp and MediaRemoteUI. On iOS 26.6.1 with the same build, the same template host reads and commands RemotePlayerService/<app> during the track and <app> > default afterwards. So the routing of commands to the active client is not what changed - what the template reads and sends to is.
Filed as FB24840951 with mediaremoted captures from both OS versions, full sysdiagnose archives and screen recordings of the car screen beside the Lock Screen.
Two questions:
Is there a supported way for an audio app to tell CPNowPlayingTemplate which of its Now Playing clients to display? MPNowPlayingSession looks like the intended mechanism but accepts only AVPlayer instances, so it cannot represent either an AVAudioEngine graph or MusicKit's player; tested with a dormant AVPlayer it reported isActive == true every time and moved the template on some tracks and not others. Does the new MiniPlayer affect this? WWDC26's "Rev up your CarPlay app" says the MiniPlayer is new in iOS 27 and appears automatically for every app that shows now playing. Since the template was reworked in the same release this regressed in, does CPNowPlayingTemplate.shared.allowsMiniPlayer = false change which client is read? I have not tested it yet and will report back either way. Meanwhile the only thing that moves the car is republishing my own entry once a second as a new content item, which the template does re-read, so the clock steps instead of freezing. That ships in PodMelody 1.1.4, a workaround for an OS bug rather than a fix - and it doesn't resolve the mismatched play/pause glyph.
If you have an audio app using ApplicationMusicPlayer and CarPlay, I would be glad to know whether you see the same thing, and in which car - duplicates on the Feedback are what get these prioritised.