Hello, I am Greg, the developer of the iOS app EV Dashboard. I've had several beta testers in Belgium report the same behavior as OP @Ozy94. I've been able to reproduce their reported behaviors -- in Belgium the route polyline always draws on top of the traffic layer, whereas around Boston the traffic layer always draws on top of the route polyline. @DTS Engineer - Has there been any progress regarding this issue? Thank you! Greg

The timestamp is worth checking, though it catches a different failure than mine. A stale fix is an accurate altitude for wherever the phone used to be, which is exactly what a background wake with a cold receiver is likely to produce. But the fix that handed me 1,823.8 m was 1.2 seconds old: fresh, and wrong by 1,552 m. I log the age of every fix, unfortunately, it can't tell me whether the altitude is true. On verticalAccuracy of zero meaning a non-GPS source: I counted across every trace I have. 125,694 fixes — 113,375 from vehicles, 12,319 from the phone — and not a single zero. Nineteen accessory fixes are negative, which is the documented invalid case. So on this fleet (all E-GMP vehicles) that signal rarely fires. On WGS-84 versus MSL — I looked into that theory too, and the data does not support it. Altitude minus ellipsoidalAltitude comes out at the local geoid undulation on both phone and vehicle fixes — about 28 m in Massachusetts, 27 in Minnesota, 21 in Nova Scotia, 17 in Utah — so iOS is applying its geoid model consistently, and it applies it to the fabricated zero too: altitude 0.0 with ellipsoidalAltitude around −27, exactly what a car genuinely at sea level would produce. A frame mismatch would show as a roughly constant offset of one undulation rather than as zero. I log both values on every fix to catch that case, and no car in my fleet has shown it. Curiously, the conversion is not always applied: on some cars the majority of fixes come through as 0.0 / 0.0, on others essentially all of them carry the undulation, and every car shows both. Same car, same place, both behaviours — so it looks like a timing or availability thing inside the conversion rather than anything the vehicle is doing.

The significant-change idea is interesting. Today I cover the common case differently: the app writes its last known altitude to a small file on every fix, and at launch it adopts that value if the first fix shows the car is still within 50m of where the file was written. Park at home, drive off next morning, and the anchor is already there before CarPlay connects — no background execution needed. What that cannot cover is the case where the car moved while the app was not running. Then the stored altitude belongs to somewhere else, the position check rejects it, and the drive starts with no anchor at all — which on an affected vehicle means no altitude for the whole trip. That is exactly the gap significant-change would fill, so the suggestion is a good one. Two things give me pause, and I would rather ask than assume: First, the authorization. Significant-change delivering in the background means asking for Always, and this app runs happily on When In Use today. Asking every owner for Always so that a minority with a particular head unit get a better altitude is a tough trade, unless it can be requested only when the app has actually detected one of those vehicles. Second, the quality of what arrives. The fixes that come from that path tend to be the coarse Wi-Fi and cell derived ones, and those are the same class that handed the app 1,823.8m at a spot that is 271m. Your requestLocation() refinement is presumably the answer to that — but in practice, after a significant-change wake, does requestLocation() reliably produce a GNSS-quality fix, or does it often hand back the same coarse position that triggered the wake? If it is the latter, the tally would be full of altitudes I would not want to anchor on. If it is the former, then the shape I would build is: wake on significant change, request one good fix, keep the altitude only if it is better than what is stored, and use the barometer on the next drive.

Thank you! That workaround is in fact what the app already does. It uses CLLocationSourceInformation to tell accessory fixes from the phone's own, keeps the last altitude it trusts, and carries it with CMAltimeter between fixes. It has been with my testers for abut one week and it works well. What I have learned since is where it gets hard, in case it is useful to anyone reading this later. The anchor is the whole problem. CMAltimeter gives relative altitude, so the carry needs an absolute starting value, and the moment you would naturally take one — "before CarPlay connects" — often does not exist. On an affected car the app is frequently launched by the CarPlay connection itself, so its first fix is already the vehicle's. Across my fleet logs, 12 of 13 drives ended before CarPlay detached, so there is no phone fix at the end either. Some drives contain no phone fix at all. I now persist the last known altitude to a file and adopt it at launch if the car has not moved more than 50 m since it was written, which covers the common case of parking and driving off again. Detecting "crazy" values is also harder than it looks, because the failure mode is not jumpy. An affected head unit reports exactly 0.0, with a positive verticalAccuracy, every second, for the whole drive. It is stable, plausible, and wrong. What catches it is not the altitude itself but the barometer: if the vehicle's altitude holds at exactly 0.0 while the phone's barometer says we climbed five meters and the car has left the spot, the reading is not a measurement. That rule cannot be built on 0.0 alone, since 0.0 is correct for a driver at sea level. The phone is not always the safe source either. One tester's iPhone twice handed my app 1,823.8 m at a spot that is 271 m, with verticalAccuracy 30, the same value to the tenth of a meter five days apart — and Apple's Compass app showed the same number at the same spot. So the anchor needs its own sanity check; I now refuse a weak fix that disagrees with what the barometer has been tracking. On door seals: in practice the carry has held up better than I expected. Re-anchor drifts on real drives are typically under two meters after twenty to thirty minutes of carrying. On the DEM suggestion — agreed, and it is the direction I am heading. Measured against real drives, a 90m model agrees with a good phone fix to about 1.5m median. A worldwide set is about 7 GB, so it cannot ship inside the app, but regional tiles are a few megabytes. One thing I noticed while capturing logs with Apple's Location Services profile, which may interest you: iOS already queries a DEM on every fix and logs the ground altitude with an uncertainty of 2.40m, alongside the vehicle's own value. It even appears to calibrate the barometric filter from it. None of that appears to be exposed to apps, which is a shame — it would be very handy right now to solve this problem.

Thank you Albert. I installed the location profile on my own device, and I'm studying my own sysdiagnose logs to start with. I can see location services using a DEM. I suppose that there is no developer framework to access that DEM? I've already been considering implementing that as a solution to this problem and having an on-device DEM would certainly be handy. 😀

Thanks Albert! When you say review the location logs — which capture do you mean? On the Profiles and Logs page I see Location Services, CarPlay and iAP profiles, and I can't tell from the outside which, if any, records what the vehicle sends over the CarPlay link. If you can point me at the right one or point in the direction of who to ask, I'll get a capture from an affected car and attach it to FB24778173.

Hi Albert, Thank you for the reply. That makes sense -- a 2D fix with the altitude zeroed out would explain what I see. What I can't tell from my side is whether the zero originates in the vehicle's firmware or somewhere in the handoff, and I'd rather establish that than guess. Is there a way for me to see what the vehicle actually transmits? Are there any logs that capture the location payload coming from the head unit? I think this is a worthy exploration, because impacted testers have reported that their own vehicle's native GUI (not CarPlay) is correctly reporting altitude -- that may be a 3D fix or it could be terrain lookup approach, I don't know. I would like to rule out something on the transport side from the vehicle to CarPlay. I have a cooperative and enthusiastic EV owner community that would be glad to send any logs that I request. 😀 One more question, separate from where the zero comes from. While CarPlay is connected, is there any supported way for an app to obtain the device's own GNSS altitude? On an affected vehicle the phone knows the right value and my app receives what CoreLocation passes along from the vehicle, with no way to ask for the other. Greg

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.