build disappears

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.

Not sure if this is what you are seeing, but for iphone17 make sure you are using the AVCaptureDevice.RotationCoordinator to get the angle to apply to the videoRotationProperty of your photo connection, so the images are oriented correctly. Look at the AVCam sample and search for RotationCoordinator to see how to use it: https://developer.apple.com/documentation/avfoundation/avcam-building-a-camera-app

However, I'm told by an engineer on the kernel team that the arm install instructions here work: https://kernelshaman.blogspot.com/2021/02/building-xnu-for-macos-112-intel-apple.html Thank you Kevin, I'll give that a try in the coming days. As for x64 vs arm, I am interested in arm since that's what I have access to.

Historically I’ve seen errors like this when different parts of your Mach-O image — so object (.o) files or static libraries (.a) — are build with different tools or different deployment targets. Make sure that: You’ve rebuilt everything with Xcode 26. Your deployment targets are consistent. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com