CarPlay: CPListItem.image degrades to placeholder glyph mid-session, only iPhone reboot recovers — FB22828125

Question

Created 2h

Replies 1

Boosts 0

Participants 2

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?

Boost

Answer 1

DTS Engineer OP

Apple

27m

Thanks for the FB number, looks like was submitted today?

You can see the status of your feedback in Feedback Assistant. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label "Resolution." We're unable to share any updates on specific reports on the forums.

For more details on when you'll see updates to your report, please see What to expect after submission.

Every time you generate a brand new bitmap via UIGraphicsImageRenderer and pass it to a CPListItem, the system treats it as a unique asset and sends a new bitmap. Over several hours of template rebuilds, the remote CarPlay process I would implement an app-side cache a simple dictionary for your images. If you need a specific icon with a specific tint, generate it once, cache it, and pass that exact same UIImage pointer to the CPListItem on subsequent rebuilds. The system is much better at optimizing identical object.

You mentioned you are baking the tint color into a bitmap using UIGraphicsImageRenderer Instead of rasterizing, apply the color. When you pass a symbol-configured UIImage to CarPlay, the XPC payload is tiny. It just sends the string name of the symbol and the color parameters, and the system daemon renders it natively on the CarPlay side.

Moving away from continuous bitmap generation and relying on cached images or native SymbolConfiguration payloads is in my opinion the best way to do this.

Albert   Worldwide Developer Relations.

0