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.