build disappears

Steps to reproduce: create default Xcode ARKit RealityKit template app open Reality Composer Pro, create new project, choose a folder somewhere in the above created app add RealityKitContent as dependency under Frameworks, Libraries, and Embedded Content drag the example Usdz into the reality composer project, maybe add it to base scene setup Xcode cloud basic build Result would be the above error. Additionally it always takes > 2min to fail: If I remove the *.usdz file it works (so it's not like the metal toolchain isn't installed or realitytool not working) Here's the example file, I shared it via dropbox since I can't attach usdz's here. It's just the monkey head from blender exported as usdz and crushed using usdcrush https://www.dropbox.com/scl/fi/f7b7dsyspby1zabk26932/monkey_crushed.usdz?rlkey=feilrul7gx6naxkbun7oaezv0&st=8afj5ewt&dl=0

Running the mentioned command, I still get the same error: iOS 23A339 is not available for download. ec2-user@ip-XX-XX-XX-XX ~ % xcversion selected Xcode 26.0 Build version 17A324 ec2-user@ip-XX-XX-XX-XX ~ % xcodebuild -downloadPlatform iOS -exportPath ~/Downloads -buildVersion 23A339 Finding content... iOS 23A339 is not available for download.

Thanks for the link. I was able to build a bootable Kext Collection as instructed in the post you referenced. I was then able to boot into a KASAN instrumented kernel on my Apple Silicon machine. On reproducing a kernel panic via a UAF I got the following symbolication, which I didn't find useful in identifying the source of a UAF in my KEXT. % symbolicateKernelPanicBacktrace.sh ~/2025-09-24-114045.kernel.core.kasan.myfs.uninstrumented.log /System/Volumes/Data/Library/Developer/KDKs/KDK_12.5.1_21G83.kdk/System/Library/Kernels/kernel.kasan.t8101 ASCII text panic(cpu 2 caller 0xfffffe0024926790): KASan: UaF of quarantined object 0xfffffe167506f880 handle_debugger_trap (in kernel.kasan.t8101) (debug.c:1431) kdp_trap (in kernel.kasan.t8101) (kdp_machdep.c:363) sleh_synchronous (in kernel.kasan.t8101) (sleh.c:854) fleh_synchronous (in kernel.kasan.t8101) + 40 DebuggerTrapWithState (in kernel.kasan.t8101) (debug.c:662) panic_trap_to_debugger (in kernel.kasan.t8101) (debug.c:1074) Assert (in kernel.kasan.t8

While I absolutely agree that it makes sense to talk to App Review about this directly, I want to address this point specifically: [quote='801940021, JE-H, /thread/801940, /profile/JE-H'] the … build output (inside Contents/MacOS/) may still contain Steam-related dynamic libraries … and metadata/configuration files … [/quote] Contents/MacOS/ is not the right place for dynamic libraries or configuration files. Placing content in a bundle is very clear about this. It also has this warning: If you put content in the wrong location, you may encounter hard-to-debug code signing and distribution problems. These problems aren’t always immediately obvious. IMO you should follow the rules from that document regardless of what distribution channel you’re using. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi, We are experiencing the very same behavior and working with our transcoding partner trying to resolve this, but been unsuccessful. However on ipad (10th gen) we had the same issue until we upgraded to iPadOS 26, then the issue disappeared and it's now working on ipad. Unfortunately the issue is still present on iphone 13 with OS26, although with longer gaps between the freezing. But since this issue has been resolved by OS26 update on ipad, it clearly signals that this is a Fairplay issue that has to be resolved by Apple. The issue was introduced in IOS 18. Can someone at Apple pleas acknowledge this and inform us if you are working on solving this?

My build showed up 4 hours and 10 minutes after it was uploaded.

I can also confirm the same behavior on my iPad-only app. I have 2 other universal apps where the problem does not occur. I did not use the Icon Composer or change anything related to my icon, I simply created and uploaded a new build from Xcode 26.0.1 to support iPadOS 26.

Oh, and one of my colleagues pointed out that another of my colleagues wrote up this: Resolving Tap to Pay on iPhone errors when building for App Store or TestFlight distribution. I’d still like to get your Team ID though. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Same here - I've been waiting for 2 hours already and my build isn't showing up either in the TestFlight tab or when I try to add it to the version for submission.

In addition to what @DTS Engineer said, see Resolving Tap to Pay on iPhone errors when building for App Store or TestFlight distribution.