“build disappears”

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

I'm experiencing the exact same issue! My tvOS build has been stuck in review for several days as well.

I'm experiencing the exact same issue! My tvOS build has been stuck in review for several days as well.