I have consulted the documentation here: https://developer.apple.com/documentation/coredata/nspersistentcloudkitcontainer/event?changes=latest_minor however there is no information that describes how this event works, can I expect documentation in the future?

Try this, for now: extension NSToolbarItem.Identifier { 	 static let primarySeparator			 = NSToolbarItem.Identifier(rawValue: "NSToolbarPrimarySidebarTrackingSeparatorItem") 	 static let supplementarySeparator = NSToolbarItem.Identifier(rawValue: "NSToolbarSupplementarySidebarTrackingSeparatorItem") }

Yep, beta 4 seems to fix these. Now getting some weirdness when using the toggleSidebar item in that the window title appears in the primary column rather than the supplementary column, and the toggleSidebar item moves to the far right within the overflow item. This must be a bug, toggling the toolbar into icon + label mode and back to icon only mode seems to fix it temporarily.

Try something like this: let infoButton = UIButton() infoButton.showsMenuAsPrimaryAction = true infoButton.menu = UIMenu(options: .displayInline, children: []) infoButton.addAction(UIAction { [weak infoButton] (action) in 	 infoButton?.menu = infoButton?.menu?.replacingChildren([new items go here...]) }, for: .menuActionTriggered)

Neither of these identifiers seems to work as of macOS Big Sur Beta 6, anyone have any workaround?

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

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 }

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.