Is there support (current or planned) for multiple navigation buttons in the top-right corner of CPNowPlayingTemplate? If multiple buttons are supported, what is the maximum number, and can they use icons instead of (or in addition to) text labels?

We build a call-screening app for VoIP-forwarded calls. Inbound calls are forwarded to our service, screened, and surfaced to the user via CallKit (reportNewIncomingCall) with includesCallsInRecents = true and a CXHandle(type: .phoneNumber, …) carrying the real caller number. Because the call is forwarded at the network before it reaches the handset, the user's native carrier call log never records it — CallKit is the only way the call appears in Recents. The gap: When the user taps "call back" on one of these entries (in the native Phone app or in CarPlay), iOS delivers an INStartCallIntent to our app. Our app's only way to then place a normal cellular/PSTN call is to open a tel: URL, which requires the app to be foregrounded. On the phone this works (with an app launch + the system "Call?" confirmation). On CarPlay it cannot work at all, because CarPlay does not foreground third-party apps or open tel: URLs, and there is no API to initiate a PSTN/cellular call from the background. There is currently no way for an app-logged (CallKit) call to be called back as a native PSTN call — the callback is always routed back into the app, and the app has no sanctioned PSTN-dial path on CarPlay. Requested enhancement (any of these would solve it): A way to mark a CallKit-logged call (e.g., a flag on CXProviderConfiguration or per-call on the handle) such that calling it back from Recents/CarPlay dials the cellular line directly (treating it like a native carrier-logged number), instead of routing INStartCallIntent to the app; or An API to write a call to Recents as a native, PSTN-dialable entry associated with the cellular line; or A sanctioned way, when handling the callback INStartCallIntent on CarPlay, for the app to request a PSTN cellular callback (with the standard user confirmation) rather than only a VoIP call. Why existing APIs don't suffice: CXHandle(type: .phoneNumber) + includesCallsInRecents correctly display the number, and INStartCallIntent correctly delivers the callback — but the callback can only become a VoIP call (via CXStartCallAction) or an app-foregrounded tel: open. Neither yields a native PSTN call on CarPlay. Routing the callback through VoIP is not viable for us: it would present our trunk's caller ID (or require per-user STIR/SHAKEN caller-ID verification), so the user's own number would not appear to the person they call back. User impact (safety & accessibility): Our users skew older (55–65) and rely on the app to screen scam/spam calls. A user driving with CarPlay currently cannot safely return a legitimate screened call — they must pick up the phone, wait for the app to open, and tap a confirmation. This defeats the hands-free safety purpose of CarPlay for exactly the population most exposed to phone scams. For comparison: On Android, a self-managed ConnectionService with EXTRA_LOG_SELF_MANAGED_CALLS lets a screened call appear in the system dialer and be carrier-dialed back with a single tap from Android Auto, no app launch and no confirmation — preserving the user's own caller ID natively. iOS has no equivalent for app-logged calls. Steps to reproduce (current behavior): App reports an incoming call via CallKit with includesCallsInRecents = true and a .phoneNumber handle. End the call so it lands in Recents. In CarPlay, open Recents and tap the entry to call back. Observed: the callback is delivered to the app as INStartCallIntent; the only PSTN path (tel:) cannot open on CarPlay, so no call is placed. Expected: a native PSTN/cellular callback (one confirmation at most), as with a carrier-logged number. Wondering...can this be considered for a future update?

I was looking into testing the new video playback feature but see that some cars doesn't show it. Will it be a future update that pushes support for all vehicles or will it be up to the manufacture

Why can't you include a custom toolbar item on the parent view of a Tab? I got around this by inserting a bespoke item at the top of my list template to represent the action that would have gone in the toolbar item, and then on all subsequent child views I display the toolbar item as intended. This works, but it feels a little clunky. Any guidance here? Thanks!

Are there plans to ever open up any more categories of apps in CarPlay? In particular, while Calendar.app is allowed in CarPlay, there is no accepted category that a third party calendar app could fall under to have the ability to do the same thing?

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!

I work on an ambient sound mixer (looping nature sounds that play continuously, often for hours). There's no meaningful track duration, so a progress bar doesn't represent anything real. I'm aware of MPNowPlayingInfoPropertyIsLiveStream, but our content is continuous rather than live, and the LIVE treatment seems semantically wrong for local looping audio. Three questions: Is isLiveStream the sanctioned way for continuous-but-not-live content to opt out of the scrubber? We'd want to toggle it off when a play timer is active (showing the sleep-timer countdown in the progress bar). Is flipping that flag mid-session supported? Is there a better-fitting presentation I'm missing? Thanks!

Is there a comprehensive list of all CarPlay framework changes in iOS 27 beyond what appears in the public release notes? Are there any new or updated CarPlay components in iOS 27 that are not yet reflected in the SDK headers or documentation?

When a voice assistant needs clarification or disambiguation, is spoken dialog alone sufficient under the rule that voice-based conversational apps must not show text or imagery in query responses? or is there an approved pattern (action buttons, short lists) within the template depth limits?

Are there any restrictions/advice/suggestions on how CarPlay supports the Siri changes in iOS 27?

For apps that display significant points of interest for a specific category, say breweries, or the places the user frequently visits, what is the best category to submit against the entitlement form? These apps are not quite navigation as they invoke Apple Maps, and they’re not for finding “parking” but a different type of map item category. The app would display specific markers for these map items, voice to search, and then link to Apple Maps for directions. This compliments existing iOS apps. I don’t want to encourage phone usage and being voice search and positional awareness to nearby POI that matter to the CarPlay screen.

CPListTemplateDetailsHeader supports action buttons for entity pages (e.g., playlist or album detail views). Currently, it appears that the header supports a limited number of trailing action buttons. What is the officially supported maximum number of action buttons on CPListTemplateDetailsHeader? If currently limited to one, is there a plan to support two action buttons to cover common media patterns like Play + Shuffle? Are there alternative patterns the team recommends for presenting multiple primary actions on entity pages within the current template constraints?

Is the video playback feature in CarPlay available only to 2026 models or does it depend on the manufacturer

We've observed inconsistent behavior when users interact with CarPlay via physical hardware controls (rotary knobs, d-pads, and physical buttons) on various head units: Focus navigation through grid and list items can behave unpredictably when using the rotary encoder, particularly when scrolling through sections with mixed item types or transitioning between sections. Selection via the physical button/knob press sometimes does not register on the expected item, especially after rapid scrolling. Hardware back/menu button behavior doesn't always align with the template navigation stack in certain edge cases. Are there known issues with hardware control input handling in the current CarPlay SDK, particularly with grid templates? Are there best practices we should be implementing to improve hardware control responsiveness?

Can Siri’s conversational features in CarPlay invoke third-party App Intents without the user opening that app’s CarPlay tile? e.g. “Hey Siri, ask [App Name] …”?

What does Apple look for when approving carplay-voice-based-conversation for a vertical, task-focused assistant (not a general AI chatbot)? Are there specific driving-safety expectations, and can subscription-gated actions be enforced inside perform()?

The current limit of 24 items per grid section forces us to split large collections (e.g., user playlists) across multiple sections, leading to layout inconsistencies across different screen sizes. List templates allow up to 200 items. Is there a plan to increase the grid item limit, or is there a recommended pattern for presenting larger collections in grid layouts?

What's the simplest way to programmatically detect the iPhone is connected to CarPlay? (not necessarily having your app launched)

Condensed grid sections currently use a fixed two-column layout. On larger or higher-resolution head units, this underutilizes the available screen real estate. Is there support (or planned support) for adaptive breakpoints that expand to three or more columns on wider displays?

With the restrictions on conversational apps in iOS 26.4... are there any suggestions on how to integrate location services with iOS 27?