I am having the exact same problem. I can confirm that it is not working since macOS 15.1. Please see also the post here: https://stackoverflow.com/questions/79126345/macos-15-1-mfmailcomposeviewcontroller-cansendmail-returns-false-always

Thanks for re-guiding me to your post. Indeed @Sendable solved the problem with the speech recognition permission. Now another problem probably related to Apple Watch WCSession has occurred. The crash stack is nearly the same. However, I was not able to further isolate the problem. Here is a crash stack: libdispatch.dylib`_dispatch_assert_queue_fail: 0x102588230 <+0>: pacibsp 0x102588234 <+4>: sub sp, sp, #0x50 0x102588238 <+8>: stp x20, x19, [sp, #0x30] 0x10258823c <+12>: stp x29, x30, [sp, #0x40] 0x102588240 <+16>: add x29, sp, #0x40 0x102588244 <+20>: adrp x8, 63 0x102588248 <+24>: add x8, x8, #0xe83 ; "not " 0x10258824c <+28>: adrp x9, 62 0x102588250 <+32>: add x9, x9, #0x6b6 ; "" 0x102588254 <+36>: stur xzr, [x29, #-0x18] 0x102588258 <+40>: cmp w1, #0x0 0x10258825c <+44>: csel x8, x9, x8, ne 0x102588260 <+48>: ldr x10, [x0, #0x48] 0x102588264 <+52>: cmp x10, #0x0 0x102588268 <+56>: csel x9, x9, x10, eq 0x10258826c <+60>: stp x9, x0, [sp, #0x10] 0x102588270 <+64>: adrp x9, 63 0x102588274 <+68>: add x9, x9, #0xe52 ; "BUG IN CLIENT OF LIBDISPATCH: Assertion failed: " 0x102588278 <+72>: stp x9, x8, [sp] 0x10258827c <+76>: adrp x1, 63 0x102588280 <+80>: add x1, x1, #0xe1d ; "%sBlock was %sexpected to execute on queue [%s (%p)]" 0x102588284 <+84>: sub x0, x29, #0x18 0x102588288 <+88>: bl 0x1025c3d60 ; symbol stub for: asprintf 0x10258828c <+92>: ldur x19, [x29, #-0x18] 0x102588290 <+96>: str x19, [sp] 0x102588294 <+100>: adrp x0, 63 0x102588298 <+104>: add x0, x0, #0xe88 ; "%s" 0x10258829c <+108>: bl 0x1025bfed4 ; _dispatch_log 0x1025882a0 <+112>: adrp x8, 101 0x1025882a4 <+116>: str x19, [x8, #0x1c0] -> 0x1025882a8 <+120>: brk #0x1 I think the problem here is very related. However there are no closures where I could add @Sendable ;-)

Requesting speech recognition authorization is still a problem. The following code crashes right away when in Swift6 mode: Task { SFSpeechRecognizer.requestAuthorization { status in switch status { case .authorized: Task { @MainActor in // do something } break case .denied, .restricted, .notDetermined: Task { @MainActor in // do something } break @unknown default: Task { @MainActor in // do something } } } } The crashlog is very similar to what @Artecoop has posted. @DTS Engineer : How can we fix that ? Is there any workaround ?

I found the issue. For some reason the provisioning file for Catalyst was not correctly updated when adding the app group. After deleting the Xcode managed profiles and rebuilding them the app group entitlement also appeared for the Catalyst app and the requester is gone. Thanks for your response anyway !

[quote='813262022, DTS Engineer, /thread/768254?answerId=813262022#813262022'] Using a group. prefix is fine in a Mac Catalyst app. [/quote] Thanks for your feedback. I tried this, but there are 2 issues. If I use group.* I get this annoying requester at every launch of the catalyst app (I am running macOS 15.1), and the widget isn't able to access Userdefaults. The widget comes up always with default settings despite what is set in Userdefaults. I don't know why ... (in iOS it works).

Same here ! Did you find a solution ?

I can confirm this behaviour. We need urgent fix for this, because as of now programmers don't know when the recogniser has finished previous segment and is starting a new segment. Thus a continuous transcription is impossible !!! Furthermore on some older Macs the recogniser is NOT setting the segment confidences to greater than 0 when a segment is finished. So this is also NOT a solution for knowing when a segment is finished. This is a severe problem ! Pls fix asap !

I have the same issue. Did you investigate this further ? Is only sandbox affected by this ?

@Maven: Yes of course @ivancnatorino: No, apple engineers were committed but didn't offer a solution As of 2021-03 the bug seems to be fixed in macOS 11+. but still exists in macOS 10.15+ In essence that means that no Catalyst app using audio will exist for macOS Catalina ! That's a pitty Regards Chris

Did anybody find workarounds for this ? I have the same problem !