Hello, I'm Greg, the developer of EV Dashboard, an app for electric vehicle owners. I'm extending it with features that help drivers understand their efficiency, including elevation and grade along a drive. It works for most of my beta testers, but two behaviors have me stuck, and they raise the same question: both hand my app an altitude that is wrong by hundreds or thousands of meters while reporting a small, positive verticalAccuracy, so I have no field I can test to distinguish a measurement from a value that is not one. Both also reproduce in Apple's Compass app on a tester's phone, with none of my code in the path. A 35-second screen recording he sent me, at the same spot in Eagan, Minnesota, shows Compass reading 889ft (the true elevation, 271m), then 5996ft for about a second, then 889ft again, and then 0ft at the moment the "CarPlay - AirPlay Connected" banner appears. Screenshots attached. Setup in my app: one CLLocationManager per active scene, desiredAccuracy kCLLocationAccuracyBestForNavigation, standard location updates (not significant-change), authorization When In Use or Always depending on the tester. Elevation comes from CLLocation.altitude, with CMAltimeter relative altitude used to carry a known altitude between fixes. Case 1: accessory fixes under CarPlay report altitude 0.0 with a positive verticalAccuracy (FB24778173) On several vehicles, every fix whose sourceInformation.isProducedByAccessory is true arrives with altitude exactly 0.0 and a verticalAccuracy that is positive and constant for the whole session (19.0 on the cars I have traces from). In the same drives, the phone's own fixes read the true altitude, around 1,345m on one tester's route. ellipsoidalAltitude does not distinguish them either: it comes back as the geoid correction applied to the 0 (-16.5 to -17.4), so both fields agree on sea level. This is not fleet-wide, which is what makes it testable. Other vehicles deliver real altitude on accessory fixes, on the same app build, with verticalAccuracy 9.5 and values that agree with the phone within a few meters. So it appears to depend on the head unit, and an app cannot ask iOS for the phone's own fix while CarPlay is connected. The Compass recording above is the same behavior in a first-party app: 889ft before the connection, 0ft after it. Case 2: a fix with an altitude about 1,550m too high The same tester's iPhone has twice delivered fixes with altitude 1823.8 where the true elevation is about 271m, an error of roughly 1,552m, with verticalAccuracy 30.0 and horizontalAccuracy 5. These fixes report no speed and no course. The same value appeared on two separate days five days apart, at the same coordinates, identical to the tenth of a meter in both altitude (1823.8) and ellipsoidalAltitude (1796.4). Both times it was the first fix after a location manager started, with the vehicle at rest. Every other fix at that spot in his logs, 76 of them across a week, reads between 269.2m and 272.6m, most with verticalAccuracy 3.0. Compass showed 5996ft (1,827.6m) at that spot in the recording, within 4m of the value my app receives. Because the value repeats exactly across days, it does not look like a measurement. What I'm asking Are either of these known issues? My reading of the documentation is that a positive verticalAccuracy means the altitude is valid, with that value as one standard deviation. In both cases the error is 50 times the stated accuracy or more. Is there any supported way to recognize an altitude that CoreLocation did not measure? Should an accessory that supplies no altitude produce a negative verticalAccuracy, as an invalid altitude does elsewhere in CoreLocation? Is a fix with no speed and no course a reliable signal that it is not a live GNSS solution, and are cached or non-GNSS positions expected to carry an altitude at all? More generally, is there current guidance for obtaining elevation along a drive that I may have missed, particularly how CLLocation.altitude and CMAltimeter are intended to be combined, and what to expect from accessory-produced fixes under CarPlay? Happy to provide traces, the recording, or sysdiagnose for either case. Thanks, Greg

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!