I'm having the same issue.

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

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!

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?

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

We're experiencing the same issue. Started like 4 hours ago and doesn't seem resolved yet. Not all builds fail, but the majority do.

After more digging, it looks like List is doing the correct thing, but @Query seems to be loading all data up-front. I've enabled the SQL debug logging and I see the following when I tap on the All menu item: CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZISOPTIONA FROM ZITEM t0 ORDER BY t0.Z_PK CoreData: annotation: sql connection fetch time: 0.0025s CoreData: annotation: fetch using NSSQLiteStatement <0x60000622dd60> on entity 'Item' with sql text 'SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZISOPTIONA FROM ZITEM t0 ORDER BY t0.Z_PK' returned 15000 rows But then if I add a print statement on the init of what would be the row view of each List item, it only calls the init for as many times as rows fit on-screen. So, my final question is: If the fetch to the database is pretty much instant, and List only loads the cells that are visible on-screen, why there's such a massive hang? If instead of using @Query I simply pass 15_000 Items, there's no hang. But the fetch seems extremely fast, so I'm really confused at where's the problem. Gist with the code: https://gist.github.com/xmollv/e682ad6c22ac0bfd4b410e9fdb6db5c4

Hey @DTS Engineer, thanks for your response! I do believe this should work as expected (no hang whatsoever) without the need for pagination. On UIKit + CoreData you don't need pagination, using an NSFetchedResultsController allows you to display as many items as you wish on a UITableView/UICollectionView without any hangs whatsoever. I've filed FB15507372 and put up the project for anyone to download and run here so it's easily reproducible: https://github.com/xmollv/SlowData

Turns out, this was my own issue! I was passing the schema on both ModelConfigurations, when I should be passing a different Schema for each configuration, and then a Schema that contains everything to the ModelContainer init. I made such change, and now it works as expected, only the LTRLink appear on iCloud's console!

We started facing the same issue today. Builds are queued up for over 30 minutes and they run forever with no end. Our builds usually take ~12 minutes to complete, so I guess something's broken on Xcode Cloud. Hoping for a quick fix because we rely on it to ship updates! 🤞

This has started happening again today, we're observing builds queued for > 30 minutes right now. @Developer Tools Engineer

Just updated to Xcode 16.3 and indeed, the networking on the iOS 16.4 simulator is broken. Not sure if the suggested are enough, since it seems that the SDKs we use are also affected, and we can't change the settings for their internal URLSession usage...

@marcosatanaka I'm observing the same issue, it works fine on iOS but that code is never called on macOS. Did you figure out a solution or it's simply broken?

I'm facing the same issue, not it looks like I can't run the app on any simulator. Works fine if I run on device and from builds coming from Xcode Cloud, would love to know of a workaround so I can keep using the simulator 😭

Greg de J. found a solution. Turns out this only happens if you call some of the WKWebView APIs, see: https://mastodon.social/@quicheindustries/114590816761623008 He found out that the issue came from calling WKWebView.createPDF. In my case, I was using WKWebView.createWebArchiveData, which also triggers the issue. Until it's solved by Apple, the easiest fix is to compile out this code on the simulator using the #if !targetEnvironment(simulator) directive. Changing my code to this, let's the app run on the simulator without issues: #if !targetEnvironment(simulator) webView.createWebArchiveData { _ in } #endif