“build disappears”

Same issue here. It started about 24 hours ago and I haven’t found a solution yet. Things I have already tried: • Rebuilding the app multiple times via GitHub Actions • Regenerating certificates / Match secrets • Waiting 24 hours after upload • Deleting the app and reinstalling • Deleting and reinstalling TestFlight • Restarting the phone multiple times • Verified I’m assigned to the internal tester group in App Store Connect • Confirmed the build status is Complete in App Store Connect The build installs and runs on my phone, but when I open the app page in TestFlight it shows “Couldn’t Load App – TestFlight is currently unavailable.” Also noticing the Apple Watch companion app will not install (stuck installing).

Are these for distribution or testflight? I've been waiting weeks for my app to be reviewed for testflight. The first build didn't get any attention and I was ironically talking about it with an employee whilst visiting and Apple Store, the guy builds apps himself and mentioned about resubmitting it (this is my first ever app) and still 4 days later nothing. He mentioned his testflight approvals are generally approved within 30-60 minutes. Can anyone confirm if this is how testflight approvals are versus distribution approvals?

I'm just joining in with a me too. If you have the MetalToolchain installed (even if you're not using it) this warning seems to appear for every MacCatalyst build. I don't have a workaround, yet. Very annoying.

I had the same issue for about a week or so. I tried contacting apple support through the email option in the contact us page but there was no response from them. Then after a while I was able to request a call back from apple and only then did they ask me more details for verifying my identity and organization. I submitted the documents but then was again in the endless waiting loop. Then after a few days I had to request a call back from them again, told them I submitted all the documents and that's when I was able to proceed to making the payment for the program. You can find the phone/call option here Contact us. Although this call button keeps appearing and disappearing at very random times. So i'd suggest you to keep looking at it from time to time.

Same here, though just uploaded a build for a different app and that one is working fine 🤔

It errors out almost immediately, but it's writing to the logs. Congratulations! Having been through this many times, I'm well aware of the mixed joy of FINALLY getting a driver to the point where it can log its own failure. I had been using automated signing, so I manually created and downloaded a profile, and received the same wildcard in it, even though we had requested and gotten approved for the vendor ID capability request with the specific vendor ID. My post here has all the background and the ultimate solution, but the summary is that you'll be using this for development builds: * ...and then resigning DEXT builds with the numeric value you were approved for once you're ready to distribute code. I wouldn't bother trying to sort out that process now, just keep in mind that you'll need to revisit this issue once you get closer to shipping. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Thanks for all that extra info. So, it’s definitely correlated with iOS 26.3. Which is strange, because I can’t think of any iOS 26.3 aligned change to local network privacy that would affect this. You could file a bug about this issue, but I’m not sure it’d get traction. As you noted in your first post, this whole process is a bit of a kludge, and it’s hard to argue that we should fix this (in contrast to FB12846267, which we definitely should fix, but haven’t yet). But if you do file a bug, please post your bug number, just for the record. At this point I think it might be worth considering different approaches. I zenned on that a bit today and I wasn’t able to come up with anything I’m truly happy with. One approach that I like is to have your UI test use some sort of IPC mechanism to the app, have the app connect to the accessory under test, and then proxy the UI test’s requests to that accessory. Unfortunately I couldn’t think of a good way to do that. It is possible to set up an IPC channel between apps