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.

Were you able to find a solution to this?

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.

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

Seeing the same thing. We're using automatic provisioning though. Anyone figured out a fix?

It fails when we try and export an archive from within Xcode too. I'm on macOS 11.5.2 with Xcode 13 RC.

It seems it's happening only for Swift classes that extend NSObject.

Same here

Downgrade to Xcode 13.1 for now as this seems to be the only solution till they release another fix.

Seeing this for our app. FB9970868

I've gone through every single framework / plugin / binary in the app bundle with otool -L and found nothing. What's annoying is how these emails about "ITMS-90562: Invalid Bundle" do NOT in fact tell us what's invalid in the bundle - if you (i.e. the processing server) are aware, why not just tell us in the same email? I've tried it with Xcode 13.2.1 as well and it still gets rejected. I have no idea what's going on as another one of our apps is submitting fine.

Unfortunate indeed, I've reported it on Feedback Assistant: FB9971366, you should too.

We're seeing the same issue - our Mac Studio Ultra is 0% faster than MBP M1 Max for all our ObjC projects. This isn't an issue with the studio - it's being under utilized it seems by Xcode / clang. We've got a fairly large project, it takes around 200 seconds to compile on a M1 Max and exactly the same time on a Mac Studio Ultra. What's more annoying to see is that the Mac Studio seems to prefer using the 4 Efficiency cores instead of the Performance cores, even though it's presumably got unlimited power draw compared to the macbook pro. In my opinion I believe the Mac Studio should never need to use the efficiency cores other than for background processing, yet I see the 4 cores utilized (in Activity Monitor) plus a couple of Perc cores, while the rest sit there doing nothing most of the times during compilation. I've also tried to use a RAM disk to eliminate any I/O delays but I've had minimal overall gains. I would recommend you open a Feedback with Apple (using the Feedback Reporter) as I have too: FB9970366

See: https://forums.swift.org/t/using-enableswiftbuildsystemintegration-on-m1-max-vs-m1-ultra/