“build disappears”

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

Thanks so much for the reply and the detailed information. Yes, looks like the resigning will cause the issue you have described. I still recommend you to test against your devices to make sure the AASA file get downloaded and works well before sending the build to the App Store. You are correct that we do not offer a native provisioning flag to bypass AASA validation. Apple’s AASA file specification fully supports listing multiple App IDs (Team ID + Bundle ID) for a single domain. You can also use TestFlight to distribute your app to test devices. Wish you luck. Looking forward to your app. Albert Pascual
  Worldwide Developer Relations.

Same exact issue. Cannot submit a new build for review because of this

Thanks for your post. This is interesting. 🧐 Do you mind filing a report using Feedback Assistant that I can share with the relevant engineering team? Share as much details as you can about affected platforms and versions. I would love to know if this started happening with a specific update or has always been there. As for workarounds, you can try handling the animation directly instead of letting it be handled implicitly or under the hood. For example, you can disable the animation entirely with .animation(.none, value: sectionExpanded) or create your own custom Section with a dropdown and animating content. You can also build the sidebar content in AppKit and display it with SwiftUI using NSViewControllerRepresentable Once complete, reply with the FB number below. Thank you.  Travis

I opened a support ticket to find out why my builds were not appearing in TestFlight or the Distribution tabs, and after a few days, a support engineer responded. My application included an extension widget. I had inadvertently used an incorrect bundle identifier key (EXExtensionPointIdentifier) instead of NSExtensionPointIdentifier. This caused my upload to fail plist validations. It appears those validations silently fail. Once I fixed the identifier key and uploaded a new build, all my builds appeared in the list; but now I have 3 or 4 builds sitting in Pending status. So for future readers, in case you upload a build and it never appears, maybe randomly check things like plist keys.

This is happening to us too. The app store connect UI wiped all of our existing app clip configuration (image, subtitle, title), and trying to upload a new image to fix it doesn't work, nothing happens in the UI. Tapping 'subtitle' shows the same error as the original poster. It also blocks us from submitting a new build, since the UI complains about the app clip fields being required.