“build disappears”

Has anyone experienced an app disappearing from App Store Connect? Any advice on escalation would be appreciated. There have been a couple of cases where the app was automatically removed from the store after a software update even though the status said it was ready for distribution. It happened in March 5th. I've asked Apple, Inc. But there has been no explanation.

I uploaded the update build, edited the screenshots, and clicked submit for review, but a warning message saying Screenshot upload is still in progress appeared, and it hasn't progressed for several days.

[quote='820155021, alex_strong, /thread/820155, /profile/alex_strong'] I've had issues getting the dmg signed by the Apple notary service [/quote] That text suggests that you’ve misunderstood how notary works. The notary service doesn’t sign your product. Rather, you present it with a distribution-ready product, one that’s already signed, and the notary service checks it and, if all is well, issues a signed ticket. See Notarisation Fundamentals for more about how this process works. As to why the notary service is refusing to notarise your product, it’s hard to say without more info. It sounds like you were able to submit the product and get a response, but the status is Invalid, indicating a problem with your submission. In that case the next step is to look at the notary log. What does it say? See Fetching the Notary Log for info on how to get the log. [quote='820155021, alex_strong, /thread/820155, /profile/alex_strong'] The only big change we made this time was switching to Maven [/quote] Ah, Java. Notari

I want to be clear about terminology here: A load-time import is one that’s statically declared in the binary via the LC_LOAD_DYLIB load command. A run-time import is one that you do from code, using dlopen or some API layered on top of that. Beyond that, I’m going to use the terms from an An Apple Library Primer, and you should read before continuing. [quote='820251021, vd02, /thread/820251, /profile/vd02'] What is the recommended approach on macOS for this kind of explicit dynamic loading … ? [/quote] My recommendation is that you not do this. Apple platforms generally prefer load-time imports because it enables optimisations in the dynamic linker. Specifically, the dynamic linker can build and cache a closure for an app, reusing that closure the next time the app launches. Note We discussed this in detail in WWDC 2017 Session 413 App Startup Time: Past, Present, and Future. Sadly, it’s no longer available from Apple, but the core info is still available from third-party sources. I don’t think this

yes, same here. until a month ago all was as usual. Now our builds take more than a week to be reviews for the App Store and I canceled by Testflight build for external users after 1 week and submitted a new one. this app is 2 years old and there's nothing new in that build that could explain it. They must be experiencing a tsunami of reviews requests by vibe coders I suppose. Meanwhile we can't work properly. Our testers can't be reached with all our hard work.

For 2 years our app was reviewed under 2 days. This time after a week we asked an urgent review because it contained important fixes. The worst part is that Apple is also blocking our work in Testflight. even after a week it is still under review. I submitted a new build and asked to review that one instead. Still nothing after two days. To me it seems Apple is having internal issues and we are powerless and can't work properly with our Testers.

In a threaded comment, @kambala said: right now CI (GH Actions) produces iOS builds as well as the .symbols files (which are generated from dSYM using symbols command), but I upload builds manually from my Mac (this will be changed in the future to upload from CI directly). I can of course also store dSYM as a build artifact, but wondered if it's possible to avoid that and store the minimal amount of artifacts on CI. As I said above, you should be keeping the entire Xcode archive, which includes the original dSYM file for any build that you ship to your customers. There's a few things that underpin this advice, including the ability to symbolicate any crash report coming from the field on any version of your app in active use, but also the ability to export your app for different types of distribution, which can enable some further testing and debugging workflows. I can't speak to the storage details of your particular CI system, but for Xcode Cloud, you are provided with t

There is potentially one detail I jumped over that is relevant — are you expecting clients of your library to build from source, or to consume a pre-compiled library? I had assumed it was a pre-compiled library based on the .a file mention. I think that's accurate, but it would be good to confirm that. If the library is intended to be a pre-compiled asset, then what you'd deliver to the client is an XCFramework. This is meant to be a single container that has everything a library client needs — copies of a built binary for each platform and simulator your library supports, plus the header files. While you can hand your clients the XCFramework so they can drag-and-drop it in their Xcode project, one nice vehicle you can use for distribution is a Swift package, which will point to a compressed (zipped) copy of the XCFramework, along with a checksum for verifying its integrity. This way, it's easy to ship updates of the library to your clients. Distributing binary frameworks as Swift packages has the de

Hi, Thank you for the follow-up and for confirming the AASA multi-App ID support, that is a useful detail. Just to make sure we fully understand the recommendation: are you suggesting we add the testing platform's Team ID + Bundle ID to our AASA file so that their re-signed build is also a trusted app for our domain? If so, we want to understand the security implications of listing a third-party signing identity in our AASA file before going down that path. Regarding TestFlight, we are already using it for manual pre-release testing and it works well for that purpose. Our challenge is specifically with automated UI testing in a cloud device farm, where TestFlight distribution is not part of the workflow. We also wanted to ask about a hybrid distribution approach we are considering, and whether it is permitted under Apple's terms: Use the Apple Developer Enterprise Program to distribute the app internally to our cloud-based testing infrastructure, allowing their re-signing process to work under an Ent