Xcode Cloud outages like this are frustratingly common, and usually regard a broken linkage between the build system and App Store Connect. @DTS Engineer Albert, I would discourage you from asking developers to spend time troubleshooting their projects. The problem is on Apple's end 99% of the time, especially when there are multiple reports. Nor would I point to the Developer System Status page as evidence that the system is working. These frequent outages are rarely acknowledged there. Committing to an Xcode Cloud workflow means that these outages are not just an annoyance, they're often a show-stopper. Xcode Cloud is in need of rapid and accurate communication between devs and Cloud engineers, which is objectively not happening. Reports through Feedback assistant often take several days to be acknowledged. Posts here, even when scores of devs pile in, seem to take a day or more to get the attention of the right person. At the very least, could we get an acknowledgement here that "We know and we're working on it"?

working now

Several other threads reporting the same issue, always with the macOS target.

Reported as FB21158967

Reported as FB21158967

This same problem has hit a few others in the last day discussion

Same here. All other platform archives work except macOS. No project changes since the last successful archive. A typical Xcode Cloud -> App Store issue, but they're usually fixed sooner than this, or at least acknowledged on Developer System Status

@FrankSchlegel found this bug in Photos in early 2024, still not fixed in macOS Tahoe. Photos is supplying a URL ending in .jpg, while the temporary file ends in .jpeg See Frank's detailed report here.... https://developer.apple.com/forums/thread/744408

Thanks for finding this @FrankSchlegel , it was driving me crazy. This bug in Photos still exists in macOS Tahoe 26.1

I learned directly from an Apple Engineer that the owner of a share does not count against the CloudKit 100 participant limit, so 101 total individuals can collaborate.

Same. A rebuild might randomly work, or might not. I've seen this for over a week, have reported it in Feedback Assistant. I noticed that last week that the System Status page showed issues with App Processing, now fixed, but it didn't fix it for me.

Found the cause and fix, though I don't 100% understand why it's happening. The views in the VStack (PostView in the code above) contained a @SceneStorage property. Removing the @SceneStorage allows the list to scroll quickly, even with .scrollTargetLayout(). No excessive calls to .body. I'm guessing that as the scrolled views come and go, that the @SceneStorarge var was getting marked as changed, even though it wasn't, causing all other cached views to be invalidated? But how does .scrollTargetLayout cause this? Anyway, elevating the @SceneStorage to the containing view, and passing into PostView as a binding, fixed scrolling, and still gives access to that @ScensStorage var.

So sorry, I really misunderstood something. The objects are not being reinitialized. It's just that scrollTargetLayout() with this configuration causes a tremendous amount of re-rendering. My bad. Still a problem though. It still makes scrolling unusably slow, even with a small data set.

@RichLogan I see that Xcode 16.2 has been pulled from cloud configs, so Latest Version is 16.1 again. Your Mac builds should work now, as mine are.

Same here. MacOS build only. Quite an inconvenience. We want to love you #xcodecloud, please do better.