I have exactly the same problem (also IOS 14 only and working in iOS 13). I found that NSMetadataQuery is broken. If you set up a NSMetadataQuery for a file in an ubiquitous container on iCloud, iOS14 will not receive the NSMetadataQueryDidUpdate notification, when you e.g. delete or modify the file with Finder. Even changes made from the iOS app that is running the query are NOT notified. Again : IOS 14 only. I think this is a VERY SERIOUS problem which should be solved asap. It renders iCloud sync across devices completely useless ! Furthermore the NSFilePresenter protocol is also broken. If you set up a FilePresenter to monitor an iCloud ubiquitous file, the presentedItemDidChange() never gets called under iOS14. In iOS 13 it works as intended. Please note that file changes using a file NSFileCoordinator initiated by iOS 14 are propagated to iOS 13 devices that are registered as presenters, but not vice versa. I think both problems are highly related. I have already submitted a TSI and reported a bug in feedback assistant, but nobody cares ! @Others: Please submit these bugs as well so that we receive awarenesses for this serious problem ! @Apple: Please help ASAP Finally here my posts for both problems on SO: https://stackoverflow.com/questions/64444494/ios-14-nsmetadataquery-not-updating-no-notifications-are-sent-works-on-ios13 https://stackoverflow.com/questions/64446024/ios-14-nsfilepresenter-not-getting-callbacks-notifications-works-on-ios13

Please do use one of your TSIs, since this would produce more credibility that this problem really exists !!! I also did submit one of my TSIs.... Meanwhile I am in communication with an Apple engineer, but the problem is, he is claiming the problem does not occur on his side. I am still insisting and providing a test project that clarifies the problem and I have also made a video that they can see what is happening live. Tho whole thing did cost me way too much time and still the bug is not at all confirmed by Apple. So please support my request by creating a bug report and submitting an TSI. Maybe you could change the title of this thread to "NSMetadataQueryDidUpdate", which is the official name of the notification. It might increase the probability that people find this thread. Thanks

Any news on this ?

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

@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

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

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 !

Same here ! Did you find a solution ?

[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).

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 !

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 ?

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 ;-)

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