Thank you for your reply, I will certainly investigate the issues you mention. For my use case it definitely does feel like the diffing is the issue, I have a large number of items (tens of thousands) and a large number of sections (100+) which becomes slow for large numbers of sections quite quickly. For the curious, it turns out there is a way to get the section snapshot collapse/expansion to be triggered from an arbitrary queue and that is to use the sectionSnapshotHandlers. I have been able to override shouldExpandItem and shouldCollapseItem to make the necessary snapshot changes from my background queue using the expand() and collapse() methods on NSDiffableDataSourceSectionSnapshot, doing this avoids the thread confinement warnings.

The key is to register a custom category identifier for CarPlay, make sure you include .allowInCarPlay in the category options, and .carPlay to the list of options when requesting authorization: enum CategoryIdentifier: String { case carPlay } let category = UNNotificationCategory(identifier: CategoryIdentifier.carPlay.rawValue, actions: [], intentIdentifiers: [], options: [.allowInCarPlay]) notificationCenter.setNotificationCategories([category]) notificationCenter.requestAuthorization(options: [.alert, .sound, .badge, .carPlay]) { (success, error) in } and then use the same category when scheduling a notification: let content = UNMutableNotificationContent() content.title = "Hello!" content.subtitle = "This is a test notification." content.categoryIdentifier = CategoryIdentifier.carPlay.rawValue let components = Calendar.current.dateComponents([.year, .month, .day, .hour, .minute, .second], from: Date()) let trigger = UNCalendarNotificationTrigger(dateMatching: components, repeats: false) let request = UNNotificationRequest(identifier: UUID().uuidString, content: content, trigger: trigger) notificationCenter.add(request) { (error) in }

I'm experiencing the same issue due to generated selectors found in Core Data classes.