TestFlight Public Links are a great way to share beta versions of your apps with other members of the Apple Developer Program. With this new channel, you can share your TestFlight Public Links with the developer community, to gather valuable feedback on crucial elements, like technical implementation, user experience, design, and more. To maximize the benefits of posting TestFlight Public Links in the Developer Forums, here are some best practices to keep in mind: Provide details: Give comprehensive information about your app, like new features and test cases, and note specific areas where you seek feedback. The more detailed your post is, the better equipped the community will be to provide insight. Select platforms: Select the platforms that your beta app supports. Enter categories: Enter the App category you’ve selected or plan to select for your app on the App Store. Categories are critical to ensuring your post can be easily found by interested users. Stay connected with notifications: Enable web and push notifications so you’ll know when you receive feedback on your post. Note: The TestFlight app is still the most comprehensive way to gather feedback. This space is meant as a helpful secondary channel.

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

We are experiencing an issue when inviting a user to join our Apple Developer Program team through App Store Connect Users and Access. The purpose of adding this user is to include them as an internal TestFlight tester after the invitation is accepted. The invited user received the Apple Developer invitation email and clicked the "Accept invitation" link. The invitation link opens the following page: https://appstoreconnect.apple.com/activation_ds?key=... The page displays "Sign in to accept your invitation" and asks the user to sign in with an Apple Account. After the user signs in successfully, the page redirects back to the same sign-in page and asks the user to sign in again. The invitation cannot be accepted, and the user cannot join the Apple Developer Program team. Steps to reproduce: Go to Users and Access in App Store Connect. Add a new user and send an invitation to join the Apple Developer Program team. The invited user receives the Apple Developer invitation email. The invited user clicks the "Accept invitation" link. The page opens appstoreconnect.apple.com/activation_ds. The user signs in with an Apple Account. After signing in, the page redirects back to the same sign-in page. Repeating the sign-in process results in the same redirect loop. Expected result: The invitation should be accepted after the user signs in, and the user should be added to the Apple Developer Program team. Actual result: The page keeps redirecting back to the sign-in page, and the user cannot accept the invitation. Troubleshooting already tried: Safari and Chrome Private browsing mode Clearing browser cookies Signing out of Apple ID before opening the invitation link again Opening the link directly in the browser instead of an email app embedded browser The issue still occurs.

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.

Hi, I’m experiencing a TestFlight issue affecting multiple apps in my account. Issue summary: • Several TestFlight builds across all of my apps expired at the same time. • After uploading new replacement builds, neither I nor my testers are able to install them. • Installation fails with the message: “Could not install {App Name}. The requested app is not available or doesn’t exist.” • The build shows as processed and available in App Store Connect. • Testers are already invited and active. • No redeem code is required. I am seeing the same issue on my own device as well. What I’ve tried: • Uploading new builds (incremented version + build number). • Confirmed builds are visible and available in App Store Connect. • Removing and re-adding testers. • Logging out of the app. • Deleting the app from the device. • Restarting the device. • Reinstalling directly from TestFlight. • Restarting TestFlight. Despite this, installation consistently fails with the “requested app is not available or doesn’t exist” error. Expected behavior: • New TestFlight builds should be installable once processed and available. • Testers (and the developer) should be able to install directly from TestFlight. • Expired builds should not block installation of newly uploaded builds. Additional context: • This started immediately after multiple TestFlight builds expired across my apps. • All affected apps were previously installing and testing without issue. • Apple Developer Support has been contacted, but I wanted to check whether others are seeing the same behavior or if there is a known workaround. Has anyone else encountered TestFlight builds becoming unavailable across multiple apps at once, or an install failure after replacing expired builds

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 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, I am unable to use TestFlight for any app (existing or new), while production uploads work normally. All TestFlight actions fail with: ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING There are no pending agreements in App Store Connect. This is an older account that previously used TestFlight successfully. This appears to be a missing or detached TestFlight Beta contract on Apple’s backend. Could this be manually reattached or re-provisioned? This is time-sensitive, as I need a TestFlight external testers link to submit an app for an upcoming hackathon. Apple Support case ID (for reference): 102817552619 Thank you.

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,

[Foxify] Version 1.1.1 (13) Review Hello Apple Support Team, My app's new app version and In-App Purchase appear to be stuck in the review process, and I'd like to check whether there might be an issue with the submission. App Information App Name: Foxify AI - Make Your Own Song. Apple ID: 6761515837. Items for Review: New App Version and New Consumable In-App Purchase. Timeline Submitted: July 21, 2026, at 10:57 AM. As of today (July 27), both the app version and the In-App Purchase have remained in "Waiting for Review" for 7 days. Context We submitted a new app version after addressing the issues raised during the previous review. At the same time, we submitted our first new consumable In-App Purchase, which requires the binary build to test the purchase flow, which has also been stuck for a while and has been rejected a few times due to build rejections and the item itself without a clear reason, so the Apple Review team could test the updated purchase flow together with the new IAP. Normally, both our app updates and In-App Purchases are reviewed within 1–2 days, so this delay seems unusual. Please kindly review the submission. Any guidance or assistance would be greatly appreciated. Thank you for your time and support.

Hello Apple Developer Forum, We have implemented the Declared Age Range API exactly as described in Apple's documentation. Our implementation checks isEligibleForAgeFeatures before calling requestAgeRange, as recommended. We have been testing with different users located in Texas (US) and Brazil. However, for all users, isEligibleForAgeFeatures consistently returns false, so the Declared Age Range prompt is never displayed. We would appreciate some clarification on the following: Under what conditions does isEligibleForAgeFeatures return true? When is the Declared Age Range prompt expected to be shown? Besides the user's region, are there any additional eligibility requirements, such as whether the Apple ID has a verified payment method (credit/debit card), verified identity or address, account age or a phased rollout? Since all of our test users are in supported regions (Texas and Brazil), we expected at least some users to be eligible. However, all four test accounts consistently return false. Could you please clarify how Apple determines eligibility for the Declared Age Range feature and when developers should expect the prompt to appear? Thank you for your guidance.

Our iOS app uploads successfully to App Store Connect and appears in TestFlight, but it crashes immediately on launch. App name: Axioma Pay Bundle ID: uk.co.axiomapay.app Distribution: TestFlight Framework: Expo / React Native Device tested: iPad via TestFlight The app installs, the icon appears, but tapping Open causes an immediate crash. One earlier build displayed this runtime message: Cannot read property 'ErrorBoundary' of undefined Crash logs show the app aborting on the React Native ExceptionsManagerQueue with SIGABRT / EXC_CRASH. We do not currently have a focused minimal Xcode sample project because this is an Expo/EAS React Native production build. We can provide .ips crash logs and App Store Connect/TestFlight build details. Can Apple help confirm whether this crash appears to be caused by: App Store/TestFlight processing, provisioning/signing/entitlements, an iOS runtime issue, or an app-side React Native JavaScript startup exception? Latest TestFlight build crashes immediately after launch.

Across two completely separate App IDs under the same Apple Developer Team, calling registerForRemoteNotifications() (via a standard push-notification plugin wrapping this exact API) resolves successfully — but afterward neither application(:didRegisterForRemoteNotificationsWithDeviceToken:) nor application(:didFailToRegisterForRemoteNotificationsWithError:) is ever called. No token, no error. Registration just stalls permanently. Environment Xcode 26.4.1 Distribution: TestFlight (App Store distribution profile → production APNs environment) iOS on all test devices: current release The key finding This isn't specific to one app. I reproduced the identical failure on: Our primary app's App ID, which has existed for a while and had Push Notifications enabled after initial creation. A brand-new, throwaway App ID created from scratch specifically to test this, with Push Notifications capability checked at creation time (no toggling after the fact, no history at all). Both show the exact same symptom: register() resolves, then silence — no callback of either kind, ever. Since this reproduces identically on an App ID with zero prior history, it rules out anything specific to one app's configuration or App Store Connect record, and points at something at the Team level with APNs backend authorization. What I've ruled out Entitlements/provisioning are correct and matching, verified via direct inspection of the signed binary: codesign -d --entitlements :- MyApp.app and the provisioning profile's own entitlements: security cms -D -i MyApp.app/embedded.mobileprovision | plutil -extract Entitlements xml1 -o - - Both show identical, correct values — aps-environment: production, correct application-identifier, correct team-identifier. Reproduced identically across: 2 separate App IDs (one long-standing, one brand new) 2 different physical iPhones 2 different WiFi networks 2 different accounts/user sessions within the app Already tried with no change in behavior: Enabling Push Notifications after initial App ID creation, vs. checking it at creation time on the fresh App ID Toggling the capability off/on and regenerating the provisioning profile Generating multiple fresh App Store distribution profiles Confirmed the Distribution certificate referenced is correct and valid Client code confirmed correct via instrumented logging at every step (permission check → permission request → listener attachment → register() call). Every step up to and including register() resolving completes exactly as expected. The stall is strictly after that point, entirely on the OS/APNs side. What I'm trying to determine Given this reproduces on a completely fresh App ID with no history, I believe this points at something about how APNs backend authorization is provisioned for this Developer Team as a whole, rather than any individual App ID's configuration. Has anyone seen this exact symptom — registration call succeeding but zero callback of either kind — and found a resolution that wasn't visible from anything in the Developer Portal or Xcode? Filed as Apple Developer Support case 20000117948923 — happy to share any additional diagnostics.

所请求的app不可用或者不存在