Did you find a workaround?

Unbelievable - all our widgets broke because of this.

Note that NSFetchRequest will always read from disk, which explains why it's working for you. NSFetchedResultsController uses a cache where possible (as the documentation explains). You can purge the cache if you wish: https://developer.apple.com/documentation/coredata/nsfetchedresultscontroller?language=objc

🤦‍♂️ Release notes say bit code is no longer supported. Got it.

Down again - it's happened twice this week. What are developers to do if we have an urgent fix to post and cannot notarize the builds?

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

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

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

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.

Seeing this for our app. FB9970868

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

Same here

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

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

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