Weird, a reboot fixed it.

We're unable to reproduce this but we get this a LOT and have no idea why. We've also received 6,500 crash reports from just 1 users in three days. This is for a "helper" app bundled with our main app, and it seems it crashes, the OS spawns it off again, and it crashes again and that seems to be happening every few seconds. We're swamped with crashes from many users but no idea what's going on. Here's the full stack trace (seems to be on macOS 10.11):Crashed: com.apple.main-thread 0 Flavours2RuntimeLib.dylib 0x10a2f7fc3 (Missing) 1 Flavours2RuntimeLib.dylib 0x10a2f7d8d (Missing) 2 Flavours2RuntimeLib.dylib 0x10a305f02 (Missing) 3 Flavours2RuntimeLib.dylib 0x10a3008d3 (Missing) 4 Flavours2RuntimeLib.dylib 0x10a3007be (Missing) 5 libdispatch.dylib 0x7fff8ef6f40b _dispatch_client_callout + 8 6 libdispatch.dylib 0x7fff8ef6f303 dispatch_once_f + 67 7 Flavours2RuntimeLib.dylib 0x10a300796 (Missing) 8 Flavours2RuntimeLib.dylib 0x10a2fea4a (Missing) 9 libdispatch.dylib 0x7fff8ef7a93d _dispatch_call_block_and_release + 12 10 libdispatch.dylib 0x7fff8ef6f40b _dispatch_client_callout + 8 11 libdispatch.dylib 0x7fff8ef82c1c _dispatch_main_queue_callback_4CF + 1685 12 CoreFoundation 0x7fff8b7da949 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 13 CoreFoundation 0x7fff8b79982d __CFRunLoopRun + 1949 14 CoreFoundation 0x7fff8b798e28 CFRunLoopRunSpecific + 296 15 HIToolbox 0x7fff9a36e935 RunCurrentEventLoopInMode + 235 16 HIToolbox 0x7fff9a36e76f ReceiveNextEventCommon + 432 17 HIToolbox 0x7fff9a36e5af _BlockUntilNextEventMatchingListInModeWithFilter + 71 18 AppKit 0x7fff9330edf6 _DPSNextEvent + 1067 19 AppKit 0x7fff9330e226 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 454 20 AppKit 0x7fff93302d80 -[NSApplication run] + 682 21 AppKit 0x7fff932cc368 NSApplicationMain + 1176 22 libdyld.dylib 0x7fff89da85ad start + 1

That hasn't helped me. I've rebuilt my libraries (forked existing libraries that weren't supported anymore, imported them into Xcode 11.4) - I can still run the app just fine on the device but building for the simulator fails every time with the same error.

The new additions to SwiftUI are marked iOS 14+ only - you mentioned they're backward compatible, any particular source for this?

That's a little disappointing. Each year, with newer controls and improvements, one would need to bump the supported OS version, which isn't always feasible. I'm hoping moving forward people would probably just stay on the latest and greatest version of macOS but it may become an issue with iOS. Adoption can still be slow at times.

Thanks - I think I may end up doing everything in UIKit and use Catalyst to port it over to the mac in the end. Being able to use SwiftUI controls here and there (along with the UIKit swift only code) would aid just enough to be able to write controls that somewhat work on all platforms without additional work (simpler controls there an #if os() directive isn't necessary). I actually spent a few weeks in SwiftUI earlier this year, only to come to the conclusion @OOPer did - it soon becomes incredibly difficult to get around SwiftUI limitations that are otherwise a few lines of code of UIKit. There are other issues with UIHostingcontroller that seem to be still present in iOS 14 - bugs around safe area insets, especially when you mix UIKit CollectionViews and SwiftUI content views. Sometimes your content will get safe-areas added (via the UIHostingController) that aren't easy to remove without relying on swizzled methods and other ugly hacks. This year's SwiftUI brings a boat load of improvements, but yes, I think it would make more sense to wait for SwiftUI 4 or so before I consider it again. Our application in question is a pretty non-traditional, highly customized app with almost everything about the UI a custom look. SwiftUI may not be the right choice here since it abstracts away a lot of the complexity at the cost of flexibility. We've got an Obj-C mac app that we're considering to re-write, perhaps now in UIKit and later port it to macOS 11 only via Catalyst.

I've got the same issue - any luck solving this?

I'm seeing this in a normal app using Core Data CloudKit sync. The app seems to hang for 20 to 30 seconds and I see this in the console.

Any luck?

Same here. Our users on Intel macs are reporting that they can no longer install our app / updates as they get this prompt. I've been unable to figure out what's going on. One user said re-installing Big sur fixed it for them but others have had no luck doing that.

Do we have an update on this? Same issue here. Users on 10.11 cannot install our app. Moreover, Big Sur users are getting other weird errors such as "This app cannot be opened".

Bug ID: FB8914737

Same here. 3rd party frameworks that worked fine up until 12.2 have stopped building / code signing. Going to have to downgrade to 12.2

Truly fed up of the productivity killer called Notarization. Frequently we find that it can take up to an hour at times. Frustrating to say the least as we need to urgently prepare a bug fix after a public release and suddenly notarization won’t complete within a reasonable period of time.

That doesn't work. AppKit still seems to handle any mouse movement over a NSTextField even if there's another view on top.