The canonical use case for this control in our application is an NPS score, which goes from 0 to 10. We've added an accessibility hint that says "Where 0 is not at all likely and 10 is extremely likely". So the user is given context (assuming they haven't disabled accessibility hints). In the medium term we plan to make this a custom control, so thank you for the tip about accessibilityRowRange!

At first glance this looks like a straightforward out-of-memory situation. EXC_BREAKPOINT points to a Swift runtime error, and 16 lines into the swift_slowAlloc method it calls a crash method if malloc (or one of its variants) returns a non-truthy value. (https://github.com/apple/swift/blob/aaff37ffb872117cc2697920f85d8743b26a06cc/stdlib/public/runtime/Heap.cpp#L102)

IMO this definitely should be marked @MainActor (reported as FB14256770) but thanks for the workaround!

My hunch is that the UNUserNotificationCenter code hasn't gotten the Swift 6/strict concurrency checking treatment by Apple yet. I encountered a similar problem with QLPreviewControllerDelegate and learned of a syntax where you can prepend @preconcurrency to the protocol conformance: final class NotificationServiceDelegate: UIResponder, UIApplicationDelegate, @preconcurrency UNUserNotificationCenterDelegate ... This will let you remove the nonisolated from the protocol methods and fix (or at least silence) the error. A side note for those reading, you'll want to use the async versions of User Notification methods in Swift 6 code where available. The completion-handler-based methods can crash with a __dispatch_queue_assert assertion.

Figured it out thanks to some help from another engineer: You now have to select "Apply Once to Folder" as the value for Build Rules in the file inspector.