Same problem here too

Hi Albert, I suspect that the architecture of the template framework may not be correct for unbounded image changes, but I'm not sure. That's why I asked my last question, hoping perhaps I had missed something or overlooked an important detail. Is there an API to evict/flush accumulated renditions for a row element (or the app)? I hope that you can shed some light on that question -- even if the answer is "no", then at least I know with certainty that the template framework will not work for my application. Right now I am in a limbo state -- I have many customers (several per day) writing to me about this experiential defect. I found a similar ticket in the forum here from another developer struggling with the same symptom. I developed a synthetic stress test (to accelerate manifestation of the problem) that can break CarPlayTemplateUIHost 100% of the time -- with the only remedy being a reboot of the iPhone. You can view stress test (movie clip) running here: https://github.com/gburlingame/ioniq-app/issues/33#issuecomment-4789048074 Running that test leads to this state: This state is clearly abusive and non-realistic, it was created to accelerate the behavior. The problem is that even with a modest coalesced rate of image changes at the low rate of 1Hz, the problem still manifests -- it just takes much longer. Once this state is reached -- all apps that use CarPlayTemplateUIHost become non-functional -- not just my app, but all other apps like Audible for example. This really strikes me as a bit of an architectural problem for this shared resource: CarPlayTemplateUIHost.

Hi Albert and team, I wanted to follow up in regard to the questions from my last post. Thank you! Greg

Hi Albert, I just noticed that FB22828125 was resolved as "Investigation complete — change required from 3rd party." I'm not seeing any other Feedback, comments, or explanation -- am I maybe not looking in the right place? What change is required? I'm happy to make a change on my side — but I haven't found the supported way to do it, so I'm hoping someone can point me at it: What is the supported way to update CPListImageRowItemRowElement images with continuously-changing content over a long session, without CarPlayTemplateUIHost accumulating unbounded rendition state and eventually falling back to the placeholder glyph? Specifically: Is there an API to evict/flush accumulated renditions for a row element (or the app)? Profiling CarPlayTemplateUIHost at the failure shows its main thread saturated in CoreUI rendition-key resolution (-[CUIMutableStructuredThemeStore renditionWithKey:] → copyKeySignatureForKey:), with the host's memory footprint climbing across the session. My app legitimately needs to present an unbounded number of distinct images over a session (live EV charging plots, telemetry information), so reducing the number of images isn't an option. Is there some other template or approach you suggest for my application? Again, I'm very happy to make changes -- I'm hoping you can point me in the right direction. Thanks! Greg

Hello - I wanted to check-in to see if there has been any progress in regards to this issue? My app IONIQ 5 Companion has been doing very well - reaching #2 in App Store Utilities in the USA. As a result, the number of incident reports of this issue manifesting have increased significantly. Yesterday, a customer sent these photos. Note how some of the graphics from IONIQ 5 Companion have appeared within the Audible application. I would very much like to get some traction with the engineering team, due to how visible this issue is when it manifests. Thank you in advance!

Thank you! Yes, I submitted feedback, here is the reference for you: FB22828125 (first submitted May 21, 2026) Three sysdiagnose logs have been added, and I have a fourth that I am about to add -- all from real testers and/or customers.

Thanks — understood on tracking status via Feedback Assistant and that you can't discuss specific reports here. Adding two findings from analyzing the captured sysdiagnose(s) to the record, since they sharpen the "process-level fault" reading from my last post. We caught a process-level fault directly. In one capture, the shared CarPlay template host (CarPlayTemplateUIHost) was killed by the watchdog: 0x8badf00d — "scene-create watchdog transgression: ... exhausted real (wall clock) time allowance of 10.00 seconds" (~10.8 s application CPU in the window). The hung thread is the host's main thread, and it's CPU-bound (TH_RUN, no lock wait — not a deadlock). Symbolicated against iOS 26.5 (23F77): -[CUIMutableStructuredThemeStore renditionWithKey:usingKeySignature:] -[CUICatalog _imageWithName:…] -[UIImageAsset imageWithTraitCollection:] -[CPImageSetAssetRegistration initWithLightImage:darkImage:…] -[CPListImageRowItemElement image] -[CPSImageRowCell configureWithImageRowItem:…] (during list population) So the host saturates the main thread inside CoreUI image-rendition resolution while building a CPListTemplate. We hand over pre-rasterized UIImages, so the cost is host-side CUICatalog / UIImageAsset resolution — which is the same code path behind both CPListItem and CPListImageRowItem surfaces. That shared path is, I think, why both surfaces fail together (my point #2 last time) and why onset is a cliff rather than a gradual fill (point #1): it's one shared component faulting, not N assets accumulating. There's also a non-crash, self-healing variant. A second capture — a different user, different device (iPhone 16 Pro), on iOS 26.6 beta (23G5028e) — shows the same glyph symptom but with NO host crash: the host ran continuously under one PID, and the glyphs self-healed after ~1 hour without a reboot. The only icon-side artifact in that capture is com.apple.iconservices logging "Failed to create placeholder image … Fallback type: public.item." Taken together: the recovery behavior spans a range — transient/self-heal in one capture, a host watchdog-kill in another, and (as others in this thread have described) reboot-required in the worst case. What's consistent across all of them is failed CoreUI image-rendition resolution, not asset accumulation — which lines up with the cliff-onset, both-surfaces-at-once, survives-relaunch shape. This is now reproduced across two devices and on both iOS 26.5 (release) and 26.6 beta, so it's present in the current beta. I'll keep the FB updated as testers capture more sysdiagnoses. One general question (not about the report status): for image-heavy CPListTemplate surfaces, is there any recommended app-side mitigation to reduce scene-create watchdog exposure or CUICatalog/UIImageAsset pressure — e.g., a supported way to hand images to the host that bypasses per-cell rendition resolution? Happy to take that to a separate thread if better.

Thank you, yes that FB was submitted earlier today. Two new pieces of data from a tester conversation today that I wanted to put on the record here, because they suggest the asset-accumulation theory may not be the whole story. 1. Cliff transition, not gradual degradation. I just spoke with one customer and he described the failure as "one second the screen was fine, the next it was gray boxes." Not a slow boil where one icon becomes the placeholder, then a few more, then most. Sudden onset, every visual at once. 2. Both CPListItem icons and CPListImageRowItemRowElement images fail. I have several list-row icons (connection status, adapter status) and the row-element images on my Driving and Charging tabs (which are CPListTemplates built with CPListImageRowItem rows). The CPListItem rasterized SF-symbol icons are quasi-static. They're gated behind state-change snapshots and only re-rasterized on actual state transitions (connectionDisplay returning a different (symbol, tint) pair, or the adapter-action row flipping between connect/disconnect). Over a multi-hour drive the set of distinct visuals shipped from those sites is small — roughly 10 unique (symbol, tint) pairs total, repeated as the user moves through states. The CPListImageRowItemRowElement images on the Driving and Charging tabs are high-churn by orders of magnitude. For example, the RPM gauges may produce hundreds of distinct bitmaps over a single drive — and there are several other continuously-varying gauges and sparklines feeding new bitmaps to other row elements several times per second. Both surfaces are CPListTemplate image surfaces and presumably share the same Apple-side rendering code path. If the theory were "table fills up," I might imagine that the high-cardinality surface might degrade first, long before the quasi-static surface with ~10 distinct visuals could possibly contribute. Instead both surfaces appear to fail simultaneously. That symptom shape — sudden onset, everything at once, survives app relaunch and CarPlay disconnect, only iPhone reboot recovers — reads more like a process-level fault on the iOS side (a crash, an XPC channel break, a watchdog trigger in carplayd or the render server) than a soft-limit being reached. I'm working with affected testers/customers -- hoping one of them can capture a sysdiagnose.

Hello! Two of the customers of my app have reported this same behavior (IONIQ 5 Companion). Both reported it happening with third party wireless CarPlay adapters, and in both cases the issue was only resolved by rebooting their iPhones. Please see: https://github.com/gburlingame/ioniq-app/issues/33 and https://github.com/gburlingame/ioniq-app/issues/28 for screenshots. These are two engaged customers, and I'm glad to work with them to help understand and resolve whatever is happening.