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?

For a domain-specific voice assistant (not navigation, not general-purpose chat), should we integrate via the CarPlay voice-based conversational entitlement, Siri + App Intents/App Schemas, or a hybrid? What does Apple recommend?

What should be the .mode and .options ?

When using trailing scroll arrows in grid layouts with multi-row sections, scrolling does not consistently behave as expected. In some cases, scrolling becomes stuck or moves in the reverse direction. We've been able to reproduce this across multiple apps. Has this been addressed or is a fix planned?

Environment： OS: iOS 16.0 and later (up to iOS 17.x / 18 beta) Subtopic: CarPlay (Wireless / Wi-Fi & Bluetooth Link) Frameworks: WebKit (WKWebView), AVFAudio (AVAudioSession), CoreAudio Description ： We have encountered a critical audio routing and scheduling anomaly specific to Wireless CarPlay environments when a WKWebView leaves a residual AudioContext instance. In our iOS application, we embed an H5 page that utilizes the Web Audio API (AudioContext) to handle audio playback, which includes standard user-interaction-based mute unlocking logic. Under normal conditions (including standalone device playback, Bluetooth A2DP, and Wired CarPlay), if the H5 page is dismissed without explicitly invoking AudioContext.close(), the system handles resource recycling gracefully without side effects. However, exclusively under a Wireless CarPlay connection, if the H5 page is destroyed but the WebKit AudioContext instance remains active or is not explicitly closed by the frontend script, a severe system-level audio scheduling conflict occurs. This anomaly breaks the audio pipeline behavior, causing persistent stuttering, dropped frames, and intermittent audio dropping in concurrent third-party music applications (such as KuGou Music, Spotify, etc.). Observed Behavior & Technical Analysis： Wireless CarPlay Specificity: The issue cannot be reproduced on Wired CarPlay or standard Bluetooth audio routing. This suggests that the CarPlay audio server daemon over Wi-Fi (AirPlay-based transport mechanism) has a different constraint or synchronization mechanism regarding audio graph changes. AudioSession / Audio Graph Contention: It appears that when AudioContext is alive, WebKit maintains an active AVAudioSession or an unreleased node in the system audio graph. When the app switches context or destroys the webview wrapper, the system fails to force-evict or deactivate this residual context under Wireless CarPlay scheduling rules. Resource Starvation for Background Apps: The persistent, phantom audio node induces scheduling friction or thread starvation in the CarPlay audio routing daemon, manifesting as severe buffering/stuttering in whatever third-party audio app currently holds the primary AVAudioSession mixable/non-mixable slot. Questions for Apple Engineers ： Root Cause of Wireless CarPlay Routing Discrepancy: Why does the CarPlay audio routing daemon handle unreleased WebKit AudioContext nodes differently over Wireless CarPlay compared to Wired CarPlay and native device endpoints? Is there an underlying lock or stream synchronization issue within the wireless CoreAudio server pipeline? Native iOS Client Side Mitigation/Fallback: Is there an recommended pattern for the native iOS app wrapper (WKWebView container) to forcefully invalidate or tear down WebKit-initiated AudioContext sessions upon view dismissal, ensuring a foolproof fallback even if the H5 frontend fails to call .close() properly? Best Practices for Web Audio + CarPlay Integration: Are there any specific AVAudioSession.CategoryOptions or WebKit configurations we should enforce to prevent a background H5 page from interfering with the system-wide CarPlay audio scheduling? Any insights, workarounds, or documentation pointers from the CoreAudio or CarPlay teams would be greatly appreciated. Thanks!