Posting here in case other CarPlay developers are hitting the same thing, and to give Apple engineers a forum-side reference for the radar. Filed as FB22828125. Symptom In a CarPlay app using CPListTemplate, UIImage instances assigned to CPListItem.image start rendering as the system placeholder glyph after extended CarPlay use (several hours to a few days of cumulative session time). Text labels and accessory chevrons still render correctly — only the leading image is affected, and it affects every visible template surface at once. Known recovery Once the failure starts, it survives: Killing and relaunching the app Force-quitting and relaunching from CarPlay itself Disconnecting and reconnecting CarPlay The only known recovery is rebooting the iPhone. After reboot, the same code path renders correctly again — until the failure reoccurs. App-side ruling-out UIImage instances passed to CPListItem.image are non-nil at failure time (verified by assertions) Each template rebuild calls UIGraphicsImageRenderer afresh from UIImage(systemName:) — no caching of UIImage across rebuilds Images are baked via withTintColor(_:renderingMode: .alwaysOriginal) then rasterized, so CarPlay receives a finished bitmap rather than a template image relying on its tinting pipeline Same code path renders correctly on launch and for hours afterward — the input bytes are identical before and after the failure boundary Because the failure survives both the app process and the CPTemplateApplicationScene teardown, the corrupted state appears to live in an iOS system process rather than in the app or the CarPlay session. Question for the forum Is there a known workaround on the app side — a different image-supply API, or a way to force the CarPlay rendering pipeline to invalidate its cache without an iPhone reboot?

CarPlay template images falling back to the generic placeholder glyph I have a template CarPlay app (CPTabBarTemplate → CPListTemplates, with tabs use CPListImageRowItem with ~6–7 CPListImageRowItemRowElement chips per row, each a UIGraphicsImageRenderer bitmap we update on a dirty-checked ~2 Hz loop). Customers intermittently see every tile image revert to the system music-note placeholder while text labels keep rendering. From submitted sysdiagnose files, I've isolated two paths to it and want to know if I'm doing something wrong or if this is a framework bug: After extended sessions, all template images go blank and stay blank across app force-quit and even delete-and-reinstall — only an iPhone reboot restores them. That points at persistent carplayd-side state surviving my process. Is there a public-API signal to detect this degraded state, or a way to force the daemon to rebind my images, short of asking the user to reboot? At connect, I have sometimes hit a scene-create watchdog kill (0x8BADF00D, 10 s wall-clock) building the image-row tab; the host respawns and shows placeholders during the ~20 s rebuild. The hung main-thread stack bottoms out in CUICatalog / CUIMutableStructuredThemeStore renditionWithKey: reached via CPListImageRowItemElement.image, and I see "CUIThemeStore: No theme registered with id=0" once per launch. Is reconfiguring one element re-resolving the whole row's images expected behavior? What's the recommended pattern to populate images into CPListImageRowItem template at connect without tripping the scene-create watchdog? Thanks for your help!