“build disappears”

Happening for us as well. We were testing a new build of one of our apps all morning and just started getting the Unable to Verify App message about an hour and a half ago. How do we know Apple is aware of the problem when the status page shows all green?

I just have an one theory, maybe Apple reviews ignored builds without Liquid glass. @AdamKP Do you upload build with Liquid Glass?

Same here, not able to run Firebase AdHoc apps as well as xcode builds on my device

Okay I found this post after 30min trying find out the problem in my code. Because it's happened in exact same time when I decided to clone my app into other folder and tried to build cloned app on my iPhone/

I am having this issue as well. No devices will build the app. 3 different iphones, 3 different computers. Any idea what is going on?

The application could not be launched because the Developer App Certificate is not trusted. Same here. Can't sign mobile app builds from xCode.

Thanks for the post. Very interesting question about that API! What do you mean for staleness check? Once a Network Extension is installed, authorized by the user, and saved to the system preferences via its respective manager, the configuration is owned by the OS. The OS will continue to invoke the extension binaries as needed, regardless of whether the main app has been force-quit or hasn't been launched in months. I’m interested on the behavior you are seeing is almost certainly caused by a secondary factors. Has the user has offload unused apps? I believe when an app is offloaded, its extension binaries are deleted along with the main app. The VPN profile or Hotspot configuration will still appear in iOS Settings, but the OS will silently fail to invoke the NEHotspotHelper or fail to connect the NEPacketTunnelProvider because the executable no longer exists. You have mentioned 90 days? If this app is being distributed to internal testers or beta users via TestFlight, the app and its extensions will comple

I don't know anything about your app or what you've submitted. All I can tell you is that there are some items that are required by the automated flow. The system will prevent you from submitting without them. But then there are still other items that are also required and app review will check for those and reject your app if they're missing. I would assume that screenshots are required for submission and that the system would display an error on a submission without them. But I'm not going to try that to test. And maybe you're talking about an update given the context of your first question? But generally speaking, once you submit, all you have to do is wait. But if you're concerned that your review might take a long time and ultimately end in rejection, then perhaps you have valid reasons for those concerns. Maybe be proactive. Reject the build yourself and resolve any lingering concerns. When you're 100% confident that your submission will be approved, then resubmit. It's always possible that you

If an app shows with this: https://imgur.com/31rdIAj (see screenshot) it means i have nothing else to do, only wait right? And it will be reviewed (my new build), despite no screenshot was added in the draft submission? Btw the draft submission shows this: https://imgur.com/kvldqvb the submit is grayed out, its because I already sent a build. So without any item , it will still be accepteds right? Thanks

Based on the above I tried reproducing this with a test project. And lo! it’s trivial to reproduce: I started with Xcode 26.3 without the Metal Toolchain 26.3 component installed. I created a new project from the iOS > App template. In the General tab of the target editor, I removed the Mac (Designed for iPad) destination. And added the Mac (Mac Catalyst) destination. I selected My Mac (Mac Catalyst) as the run destination. I chose Product > Build; the project built without any warning. In Xcode > Settings > Components, I installed the Metal Toolchain 26.3 component. I chose Product > Clean. And then Product > Build. I now see a build warning: ld: warning: search path '/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.7003.10.hJke6J/Metal.xctoolchain/usr/lib/swift/maccatalyst' not found Given the above, I can only conclude that this is a bug. I did some digging and was unable to find any more backstory (for example, I thought that

[quote='878914022, captadoh, /thread/808917?answerId=878914022#878914022, /profile/captadoh'] Could me passing a closure that throws to NetworkListener.run(_:) be the cause of my issues? [/quote] That’s unlikely. I mentioned it purely because it’s one of the various random issues I’ve bumped into during this process. But if you’re worried about this, I recommend that you make your closure non-throwing like so: listener.run { do { … your code here … } catch { … log the error … } } Sadly, I’ve still not made relevant progress on your main issue. I think I need to just bite the bullet and create a minimal test project, rather than try to build something ‘correct’. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Cool. I consider this to be a problem with Xcode’s build system, but it’s an understandable one. Xcode knows that your tool depends on this library — because it adds an import of it — but, being a command-line tool, it doesn’t have anywhere to embed the library. It should embed it in the container app, but it’s clearly not doing that. I think it’s worth filing a bug against Xcode about that. And if you do, please post your bug number, just for the record. As to a workaround, there’s a couple of ways to approach that. The first is the obvious one we’ve been discussing here: Add a dummy use of Subprocess within your app. Xcode will embed libswiftCompatibilitySpan.dylib, because it knows that your app needs it, and your tool can pick it up from there The other option is to embed the library explicitly. This is complicated by the fact that the library exists within a toolchain, so it’s not clear how to reference it [1]. For the moment I recommend that you go with the first option. I’m going to talk to so

[quote='818269021, anonymousdev332299, /thread/818269, /profile/anonymousdev332299'] is both a Developer ID certificate and Apple notarization required on current macOS versions? [/quote] Yes. Developer ID signing has been required for a long time (10.8?). Notarisation for apps has been required since 10.14. [quote='818269021, anonymousdev332299, /thread/818269, /profile/anonymousdev332299'] Is [ditto] necessary to properly preserve the app bundle structure and extended attributes? [/quote] Yes and no. If you compress with the Finder then extended attributes get sequestered, which is not good. See Extended Attributes and Zip Archives. The ditto tool doesn’t do that by default. However, in an ideal world this wouldn’t matter because your code signature should not depend on extended attributes. If you find that it does, that suggests your have a bundle structure problem. We talk about this more in TN3126 Inside Code Signing: Hashes and Placing content in a bundle. As to what’s actually happening here, it’s hard