Seeing the exact same issue - why it says "UICollectionView.." is beyond me, probably a bug. But did you figure this out? It does work if you set a symbolic breakpoint for NSCollectionViewFlowLayoutBreakForInvalidSizes

I've got the same issue in our app. We get infrequent crashes in scrollWheelWithEvent and we have absolutely no idea how to prevent them.

Were you able to find a solution to this?

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

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.

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

Bug ID: FB8914737

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".

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.

Any luck?

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.

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

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.

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.

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