Hi, We are seeing Apple-hosted Managed Background Assets download failures on macOS 26.6.1 and would appreciate confirmation of whether this is a known issue or a configuration problem. Environment macOS app using Apple-hosted Managed Background Assets Apple Silicon Macs: M1 and M4 App version: 1.0.2 (build 10) App and downloader extension are sandboxed and use the same App Group No ba-serve development URL override is configured: xcrun ba-serve url-override reports that no override is set. Observations On the same M1 Mac: On macOS 26.5.2, Background Assets began transferring an asset pack successfully. The log recorded 136,586,876 bytes received before I manually cancelled the download. After upgrading to macOS 26.6.1, Background Assets reaches manifest resolution and download scheduling, but the asset transfer fails. The macOS 26.6.1 logs show: NSURLErrorDomain -1200 The certificate for this server is invalid / secure connection failed kCFStreamErrorDomainSSL -9816 server closed session with no notification NSURLErrorDomain -3007 Download decoding failed A separate M4 Mac running macOS 26.6.1 also reproduces the issue. One relevant variable: both the working 26.5.2 log and the failing 26.6.1 log show the Background Assets traffic passing through a local HTTP/S proxy at 127.0.0.1:6152. I am now testing a direct route for odr.itunes.apple.com and amp-api.apps.apple.com, but this proxy path was also present in the 26.5.2 transfer that started successfully. The asset pack IDs in the two captured logs are not identical, so this is not a strict same-pack A/B comparison. However, the failure is reproducible for Apple-hosted packs on 26.6.1, while the pre-upgrade log shows a real transfer on the same M1 Mac. Has anyone seen either of these on macOS 26.6 / 26.6.1? NSURLErrorDomain -3007 (Download decoding failed) for Apple-hosted Background Assets TLS error -1200 / kCFStreamErrorDomainSSL -9816 during a Background Assets pack transfer A change in support or behavior for HTTP/S proxy routing of Apple-hosted asset-pack downloads I have filed Feedback Assistant report FB24301118 with the relevant logs and diagnostic attachment. Thanks.

I tried to upload my build into testflight with XCode -> Product -> Archive -> Distribute App but this error keeps showing up: "No Team Found in Archive, Use the Signing & Capabilities editor to assign a team to the targets and build a new archive." However, my Apple ID IS connected and the bundle ID is the same as in my App Store Connect. What can I do? I tried deleting all archives, restarting Xcode & my Mac, still nothing happend. I can't get it to upload...

Hi all, I want to put the raw numbers somewhere public, because after five days of looking at this I still cannot find an explanation that involves anything on my side. On 2026-08-12, 59 builds across 10 apps on Team ID 8N867LSZDP were marked expired. Not gradually. Inside four seconds: 06:32:56 PDT 22 builds 06:32:57 PDT 9 builds 06:32:58 PDT 18 builds 06:32:59 PDT 10 builds Those 59 builds were uploaded between 2026-05-09 and 2026-08-11, so their own upload dates have nothing to do with when they died. The reason I am sure this is not normal expiry is that normal expiry is visible in the same account, in the same export. Twelve other builds expired between 2026-08-07 and 2026-08-11, each exactly 90 days after its own upload, one at a time, the way the documentation describes. Both groups sit in one table. One follows the rule. The other was written in a batch. It was not only the date, either. buildBetaDetail for all 59 now reports internalBuildState EXPIRED and externalBuildState EXPIRED, so the beta state machine moved with it. Then the second half, which is the part that actually blocks me. The next day, 2026-08-13, I uploaded two fresh builds to one of the affected apps. App Store Connect is perfectly happy with them: processingState VALID expired false expirationDate 2026-11-11 (correct 90-day window) internalBuildState IN_BETA_TESTING internal group hasAccessToAllBuilds = true tester 1, state ACCEPTED Installing either one fails instantly, for the tester and for me on my own device: "Could not install [app]. The requested app is not available or doesn't exist." App Store Connect says the build is in beta testing. TestFlight says the app does not exist. Two Apple systems reading one record and disagreeing about it. Five days on, nothing has moved: those builds are still unexpired and still uninstallable. One detail that might narrow this down for whoever ends up looking at it. I have seen the theory going around that this gets triggered by removing external testers. That is not what happened here. This account has never had external testing configured at all. All fifteen beta groups are internal, publicLinkEnabled is null on every one of them, and each group contains exactly one tester, me. There were no external testers to remove. So whatever runs this batch job does not need that trigger. Checked before posting: membership active, distribution certificate valid through 2027-05-15, provisioning profiles ACTIVE, agreements reviewed, testers removed and re-added, device restarted, app deleted and reinstalled, TestFlight reinstalled, builds re-uploaded twice. Production uploads and App Store review are unaffected, which is what makes this look like the beta path specifically rather than the account as a whole. Developer Support case 20000136966070. The reply I got linked me to Xcode build configuration documentation and suggested I try DTS. I have asked for escalation. The per-app identifiers and the full 74-build export are already attached to that case, so anyone at Apple who needs the specifics has them without me listing my apps here. I also filed it in Feedback Assistant as FB24388441 (Developer Tools & Resources, area TestFlight, Incorrect/Unexpected Behavior), with the same export attached. That part I would ask other people to copy. Feedback Assistant groups duplicates and shows a Recent Similar Reports count, and a forum thread has nothing equivalent. If you are stuck on this, filing one takes ten minutes, and it is the only mechanism I have found that turns a pile of separate complaints into something countable. Thread 813703 carries the same signature going back to January, so this is neither new nor one account. If anyone has actually come out the other side of this: what changed, and how long did it take?

Hello, Apple’s documentation appears inconsistent about which App Store Connect API should be used to submit an Apple-hosted Background Asset version for external TestFlight review: In WWDC25 “Discover Apple-Hosted Background Assets”, Apple says that the asset pack version can be submitted using the POST /v1/betaBackgroundAssetReviewSubmissions. In Uploading and versioning Apple hosted background assets, the external beta review instructions link to “Submit an app for beta review,” which uses POST /v1/betaAppReviewSubmissions. These two resources have different behavior. betaBackgroundAssetReviewSubmissions I called the public API with the same resource structure used by the App Store Connect web UI: POST https://api.appstoreconnect.apple.com/v1/betaBackgroundAssetReviewSubmissions { "data": { "type": "betaBackgroundAssetReviewSubmissions", "relationships": { "backgroundAssetVersion": { "data": { "type": "backgroundAssetVersions", "id": "<BACKGROUND_ASSET_VERSION_ID>" } } } } } The public API returned 404 PATH_ERROR: The resource 'v1/betaBackgroundAssetReviewSubmissions' does not exist. However, the App Store Connect web UI uses the private endpoint below with the same payload and receives HTTP 201: POST https://appstoreconnect.apple.com/iris/v1/betaBackgroundAssetReviewSubmissions The public endpoint is also absent from the current App Store Connect OpenAPI specification. betaAppReviewSubmissions I also tested the public POST /v1/betaAppReviewSubmissions endpoint. When I supplied a backgroundAssetVersion relationship, the API returned 409: 'backgroundAssetVersion' is not a relationship on the resource 'betaAppReviewSubmissions'. You must provide a value for the relationship 'build'. The build relationship only accepts the builds resource type, not backgroundAssetVersions. Therefore, betaAppReviewSubmissions can submit an app build but cannot submit a Background Asset version. Could Apple please clarify: Which public API should be used to submit a Background Asset version for external TestFlight review? Is betaBackgroundAssetReviewSubmissions intended to be exposed through the public App Store Connect API? Is the link to betaAppReviewSubmissions in the Background Assets documentation incorrect? When will the public documentation and OpenAPI specification be updated? Thank you.

Hello, I am experiencing a serious TestFlight issue that began immediately after I removed some testers from an External Testing group. Right after removing those external testers, all existing TestFlight builds for my app were suddenly marked as Expired, even though they were still within the normal 90-day TestFlight validity period. I did not manually expire any build. Removing an external tester should only revoke that tester’s access and should not affect the status of any TestFlight build. After the mass expiration, I uploaded a replacement build. The new build uploaded and processed successfully in App Store Connect, but I could not add or submit it for External TestFlight Beta App Review. App Store Connect incorrectly displays the following message: Before you can use TestFlight to distribute beta builds of your app, you must renew your Apple Developer Program membership. However, my account currently shows: Account type: Individual — Account Holder Apple Developer Program membership: Active Apple Developer Program License Agreement: Accepted Free Apps Agreement: Active No pending Apple Developer Program agreements Replacement build uploaded and processed successfully I inspected the failed App Store Connect network request and found the actual backend error: POST /iris/v1/betaAppReviewSubmissions HTTP 422 Unprocessable Content { "errors": [ { "status": "422", "code": "ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING", "title": "Beta contract is missing for the app.", "detail": "Beta Contract is missing." } ] } The exact sequence was: External testers were removed from the External Testing group. All existing TestFlight builds suddenly became Expired. A replacement build uploaded and processed successfully. The build could not be submitted for External Beta App Review. The backend returned ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING. I have found reports from other developers describing the same sequence after removing external testers, including all TestFlight builds unexpectedly expiring and TestFlight distribution no longer working. This appears to be an account or team-level TestFlight backend issue in which the Beta Contract or distribution state becomes detached after modifying external testers. I have already contacted Apple Developer Support and provided the private account, app, request, and error identifiers through my support case. Could an Apple engineer please confirm whether this is a known backend issue and whether the TestFlight Beta Contract needs to be re-provisioned or re-attached? Has anyone else experienced this exact issue after removing external testers? If Apple resolved it, what action was required on the backend? Thank you.

I'm stuck on what looks like a backend / account-level TestFlight issue and want to ask if anyone has seen the same pattern. Symptoms (reproduced across three consecutive builds) App Store Connect ingests and processes each build successfully; it shows as "Testing" in TestFlight with no compliance warnings. Internal TestFlight install fails instantly on every tester device with: ▎ "The requested app is not available or does not exist." Device console (itunesstored) at install time: FAILED: TFBundleInstallation serverFailureReason="Error Downloading Install Data" userFailureReason="Requested app not available or does not exist" buildGroup=(null) phase=Failed previousPhaseDescription=ProcessingInstallInitiateResponse serverCode 200 Submitting the same build for external Beta App Review returns: 422 ENTITY_UNPROCESSABLE code: BETA_CONTRACT_MISSING buildGroup=(null) for builds that visibly show as "Testing", plus a persistent BETA_CONTRACT_MISSING, suggests the beta-contract / build-group record for the app is missing or corrupted on the backend. Already verified clean on the developer side Distribution certificate and provisioning profile valid; entitlements match the binary; codesign --verify --deep --strict passes. Free and Paid Apps Agreements both Active; no pending tasks (Banking, Tax complete). App Information, Pricing & Availability, Age Rating, Content Rights, Test Information all complete; build page shows no warnings. Reproduced with multiple testers on multiple iOS 17+ devices, in a fresh internal testing group, after device-side cleanup (sign-out / reinstall TestFlight). Re-uploading a fresh build does not clear it — so it is not bound to a specific binary. Questions Has anyone seen Error Downloading Install Data + buildGroup=(null) + BETA_CONTRACT_MISSING together on a single app? How did you resolve it? 2. Why does ProcessingInstallInitiateResponse return serverCode 200 while still failing with "app not available", for a build that shows as "Testing"? 3. Is there a documented path to request that engineering regenerate a corrupted beta-contract / build-group record, beyond a standard support case? Any pointers appreciated — happy to share device logs / sysdiagnose if useful.

Hi, I have deployed my app on Test Flight, I have two subscriptions, monthly and yearly. User can have one of them at a time and upgrade, downgrade to the other. Upgrade, downgrade, cancel from the Apple Settings worked fine in the sandbox environment when testing locally. Now when I have deployed the app on TestFlight, I was able to purchase the subscription successfully from my app. Now when I want to cancel my subscription from the Apple Settings it gives me the following error after confirming cancellation, 'Your request is temporarily unable to be processed. Please try again later.' Also the other subscription offer (yearly) is also not shown to which I could upgrade, even though in the sandbox I was able to upgrade downgrade from the settings. Another thing I have noticed is that the app Icon or name is not shown anywhere in settings with the subscription. Instead of app icon only empty square is shown. Even though app icon shows fine everywhere else. Can someone please help me figure out this issue?

Hi guys, my app (Apple ID 6797333844) has been awaiting review since August 2nd. When I first submitted it, I was told the review would normally take 48 hours. This is the initial review for my app, which is small and simple. I’m wondering if this is normal for a first release or if I did something wrong. However, I don't think that's the case, as I published another app a few months ago. Thanks for your time.

Hi! I'm observing a problem with ASC webhooks. I have a webhook with all event triggers enabled, and I verified it works: events such as buildUploadStateUpdated and buildBetaDetailExternalBuildStateUpdated are delivered. However, when a screenshot feedback is submitted from an external testing group, no webhook is dispatched (confirmed it does not appear in "Recent deliveries"). The screenshot feedback is submitted successfully, the screenshots appear in the ASC dashboard. Basing on the documentation, I think this event should trigger the BETA_FEEDBACK_SCREENSHOT_SUBMISSION_CREATED webhook.

I’m experiencing what appears to be a team/account-level TestFlight backend issue, and it is currently blocking my development workflow. Team ID: TJ6F83PA4W What happened All existing TestFlight builds across my apps suddenly became Expired / unavailable. This happened across the developer team rather than to one particular app or build. I then uploaded a completely new build to determine whether the previous builds had simply been reset or invalidated. Test app: RESON | See the frequency. Apple ID: 6799940431 Version: 1.0.0 Build: 2 The new build: Uploaded successfully Processed successfully Appears normally in TestFlight Shows a fresh 90-day testing period Has an active Install button But installation immediately fails with: Could not install RESON | See the frequency. The requested app is not available or doesn’t exist. So this does not appear to be normal build expiration. A completely new and successfully processed build is also affected. Troubleshooting / support I have already opened an Apple Developer Support case: Case ID: 20000133520102 I’ve contacted Developer Support multiple times by email and also requested/spoken through phone support, but the issue remains unresolved and is now blocking my TestFlight workflow. I have intentionally not started changing certificates, provisioning profiles, Bundle IDs, or repeatedly uploading replacement builds because the symptoms affect the entire team and appear to occur at the TestFlight distribution stage. I’ve also seen reports from other developers describing similar symptoms, including references to BETA_CONTRACT_MISSING / missing Beta Contract backend state. I cannot confirm that this is the cause on my account, but the symptoms appear similar. Question for Apple / other developers Has anyone experienced this exact combination? All TestFlight builds unexpectedly expire → new builds process successfully → builds appear available for 90 days → installation fails with “The requested app is not available or doesn’t exist.” If someone from App Store Connect / TestFlight engineering sees this, could you please advise whether the Beta Contract / TestFlight distribution provisioning state for the Developer Team needs to be checked or re-provisioned server-side? Any confirmed workaround or escalation path would be greatly appreciated.

Hi. 6-7 years ago i was invited to the testflight with an email address (with the same apple id). 2 years ago my email changed and i also changed the apple id. Now my testflight invitation was over and i want reinstall it. "failed to redeem testflight..." This invitation cannot accept because apple account (my new emai) is already associatad with this app at an adress (my old email) by means of a sent invitation. what can i do with it? how can i solve this problem? Thanks

I uploaded a build to testflight and released it to Internal testers, however when the testers tried downloading the app a alert dialog shows the following: Could not install [App] The requested app is not available or doesn't exist. Also tried to submit it via external testers but getting another error.

Could not install Reflex Ring: Fast Finger. The requested app is not available or doesn't exist.

I’m having a strange TestFlight issue with one of my builds. Version 1.0.0 has two builds. Build 1 works normally in TestFlight, but Build 2 is unavailable to every tester I’ve tried. Build 2 was uploaded successfully, and App Store Connect shows it as “Testing”. I also received Apple’s email saying version 1.0.0 (2) is available to test. However, Build 2 still can’t be accessed through internal testing, external testing, or a public link. For internal testing, I assigned only Build 2 to the group, but TestFlight shows “No Builds Available”. I tried the same with an external testing group and got the same result: “No Builds Available”. The public link is enabled with no device or OS restrictions, but new testers see “This beta isn’t accepting any new testers right now.” I’ve already tried removing and re-adding testers, recreating testing groups, removing and re-adding Build 2, disabling and re-enabling the public link, resending invitations, removing the app from the device, stopping testing in TestFlight and joining again, and testing with Build 2 as the only build assigned. None of that changed the result. Build 1 still works normally for the same app. Build 2 details: Version: 1.0.0 Build: 2 Minimum iOS version: 15.0 Device family: iPhone Architecture: arm64 The test device meets the compatibility requirements. There is also an upload warning: 90737: Missing Document Configuration The same warning appears on both Build 1 and Build 2, but Build 1 is distributed normally. Has anyone seen a TestFlight build that shows as “Testing” and generates Apple’s “available to test” email, but still isn’t available to internal testers, external testers, or public-link testers? Could there be some server-side TestFlight distribution state or App Store Connect setting causing this? Thanks.

Hello Apple Developer Community & Support Staff, I am writing this out of sheer desperation. Our app has been stuck in the overall review process for nearly TWO MONTHS. Regarding our latest submission: Submission ID: aec29b9a-fbdf-41f3-b617-d593c2e29f70 Date Submitted: August 3, 2026 We completely understand that as a dating app, our submission requires strict adherence to UGC guidelines, robust user reporting/blocking mechanisms, and thorough content filtering. We have meticulously implemented all of these safety features and addressed every single issue previously raised by the review team. Recently, the status of this August 3rd submission finally changed to "In Review," which gave us hope. However, it inexplicably rolled back to "Waiting for Review" shortly after, with ZERO communication, messages, or explanations provided in the Resolution Center. We are hemorrhaging funds daily on server costs, delayed marketing campaigns, and operational expenses due to this silent, indefinite hold. If our app was escalated to a specialized team, or if there is a system glitch, we at least deserve to be informed. Could an Apple representative here please look into this specific Submission ID? We urgently need someone to manually check why this rollback happened and help us move forward. We are 100% ready to cooperate. Thank you.

We are experiencing an issue with our TestFlight build The build was successfully uploaded to App Store Connect and is available for internal testing. Our internal testers can see the build in TestFlight, but when they attempt to install it, they receive the following error: "Could not install Game. The requested app is not available or doesn't exist." This issue occurs for all internal testers. The build upload completed successfully, and the build is assigned to the internal testing group. We are unable to determine the cause of this issue. Could you please help us identify whether there is any missing configuration or any other requirement that could be preventing the app from being installed?

Hello guys I’m unable to delete the Test Information and Beta App Information sections on Apple Store Connect. I need to remove them because the app transfer process requires it. I’ve already expired all builds, removed all testers and groups, and tried every possible solution I could find online, but nothing worked. I also contacted Apple Support, but the issue hasn’t been resolved. What should I do next?

Hello, For several months, I have been unable to install any TestFlight build submitted by my Apple Developer team. All builds archive, upload, and complete processing normally. They appear as Valid in App Store Connect and are visible in TestFlight with an Install button. However, tapping Install fails immediately with: “Could not install [app name]. The requested app is not available or does not exist.” Current example: App: TopGestor Cliente Apple ID: 6799197509 Bundle ID: com.topgestor.cliente Version / build: 0.1.0 (3) Platform: iOS, arm64 Minimum iOS: 15.1 This is not limited to this app; it also affects other apps submitted by the same team. Reinstalling TestFlight, restarting the device, and submitting fresh builds did not resolve it. Could an Apple engineer please verify whether there is an account-level TestFlight distribution, build availability, or beta contract association issue on the backend? I have also opened an Apple Developer Support case.

WeatherKit consistently fails with the following error: WDSJWTAuthenticatorServiceListener.Errors Code=2 This happens on a physical device regardless of the troubleshooting steps I try. After the error occurs, the app uses a third-party fallback provider successfully. The issue appears similar to failures reported by other developers on iOS 26, even though the WeatherKit entitlement and signing configuration seem valid. I have verified the following: • The signed application binary contains the WeatherKit entitlement. • The embedded provisioning profile contains the WeatherKit entitlement. • The application identifier and team identifier match the provisioning profile. • The WeatherKit capability was disabled, saved, enabled again, and saved. • Xcode automatic signing generated a new provisioning profile after resetting the capability. • The project was cleaned and a fresh build was installed on the physical device. • Both the application and the device were restarted. • Location permission is granted and the app receives valid coordinates. • Network connectivity works correctly. • A non-Apple fallback weather provider successfully returns a forecast for the same coordinates. Despite this, every WeatherKit request still fails with WDSJWTAuthenticatorServiceListener.Errors Code=2. Has anyone identified the cause of this error on iOS 17 or 26 or found an additional signing, entitlement, App ID, or provisioning step required to resolve it? Environment: • iOS version: iOS: 26.6 (23G71) • Xcode version: 26.5 • Device: iPhone 14 Pro • WeatherKit API used: WeatherService.shared • Distribution method:TestFlight

Hello Apple Support Team, I'd like to kindly request an update regarding our latest app submission, which has remained in Waiting for Review since July 30, 2026. As of today (August 5), it has been 6 days without entering the review process. App Information App Name: Dora - AI Video Generator 2 Apple ID: 1604739131 Item for Review: App Version This submission is a major UI/UX revamp that significantly improves the overall user experience. After a long period of maintaining and iterating on the product, we redesigned many core user flows to provide a much more seamless and intuitive experience for our users. Our app continues to receive a large number of daily active users, so having this build remain in Waiting for Review is preventing them from accessing these important improvements and new experiences. The prolonged delay is having a meaningful impact on our users as well as our product rollout. We completely understand that review times can vary, but given the circumstances, we would greatly appreciate it if the review could be prioritized or expedited whenever possible. Thank you very much for your time and support. We truly appreciate the work of the App Review team and look forward to your response. Kind regards,