Yeah we're getting the same errors. Also stuff like this:

This seems to be related to the fix on 'Thread Performance Checker': https://developer.apple.com/documentation/xcode-release-notes/xcode-15_3-release-notes#Thread-Performance-Checker If I disable it on the running scheme, the CPU spike is gone. Since the backtrace seems to be all internal to the OS (no calls to our app are being logged), it doesn't look like there's anything I can do until Apple fixes it internally, right?

Okay ignore me. Apparently Xcode Cloud recently changed and added a 'Manual Build' trigger option. We were using a disabled workflow before with the trigger on a branch changes. We were starting builds manually by running one on them and picking the branch we want. The moment I removed that trigger and replaced it for the 'Manual Build' one, the branches started appearing again!

I sort of fixed it by nuking everything. One one of the apps, I clicked on 'Delete Xcode Cloud Data'. Then I recreated the workflows because everything is gone (we just had one, so it was simple to do on that one) and now it shows new branches again. Is there no way to fix this other than re-configuring the whole thing? The other apps I mentioned have much more complicated workflows that will be really painful to re-create again...

I'm having the same issue.

This seems to have resolved itself.

After half a day working, we've seeing that this is intermittent. We've changed nothing and some builds succeed and some fail. Looks like a check on AppStoreConnect somehow is flaky, hopefully it'll be fixed soon. For now we're just re-triggering the builds that fail and they end up succeeding at some point.

I saw on the Fastlane docs that they mention a daily 150 binary limit, but we're definitely very far from that → https://docs.fastlane.tools/actions/deliver/#limit Does anybody know if it's recently been lowered to ~20 or something like that?

Looks like the issue is happening after the build finishes and the artifacts need to be uploaded:

I would love to be able to do this automatically!

Same, would love to be able to do this!

I'm having the same issue in the work project, but on personal projects Xcode works fine (same machine). I'm sure that there's some configuration issue somewhere making this trip (we use Cocoapods with ~20 dependencies on the work project). I haven't been able to find exactly what's going on, any tips are much appreciated!

Apparently this has been removed on purpose, which I don't understand why because I use it very often. https://developer.apple.com/documentation/xcode-release-notes/xcode-14-release-notes

I've found a hack since AppDelegate.applicationShouldHandleReopen(_:hasVisibleWindows:) is not called as explained in the comment above. Apparently AppDelegate.applicationWillBecomeActive(_:) is called when you click on the Dock app icon if the window is miniaturized, so inside that method simply add this and seems to be working as expected (macOS 12.4): func applicationWillBecomeActive(_ notification: Notification) {     (notification.object as? NSApplication)?.windows.first?.makeKeyAndOrderFront(self) }

I've been digging how to implement this manually and seems that AppDelegate.applicationShouldHandleReopen(_:hasVisibleWindows:) would've done the trick, but even if you implement the @NSApplicationDelegateAdaptor(AppDelegate.self) var appDelegate, that method is never called. Found another example of the same issue online: https://www.reddit.com/r/SwiftUI/comments/u5srtt/applicationshouldhandlereopen_is_not_called_in