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.

Our account containing our 800 apps was closed down as part of anti Jewish sentiment. We have now had our 2nd account closed via cyber (made inaccessible via cyber). Sometimes it's re-opened before Shabbat starts and re-closed after shabbat to iritate. We are actively prevented from appealing our account closure, etc. We warned Apple we were having these issues over a period of around 6 months.

Hi everyone, My TestFlight build has been stuck in 'Waiting for Review' for over 32 hours and I'm hoping someone can help or share their experience. The situation: I have an External Testing group with a Public Link set up. The build was submitted for Beta App Review on March 19th but it's been over 32 hours with no update. I have 25+ testers waiting to install the app. What I've tried: Waited patiently Checked App Store Connect multiple times No rejection emails received No issues flagged by Apple Questions: Is anyone else experiencing unusually long review times for TestFlight external builds right now? Is there anything I can do to speed up the process or check if something is wrong? Has anyone successfully resolved this by contacting Apple Developer Support directly? Any advice would be greatly appreciated. Thank you! Apple Support Case ID: 102846633409

Hello, I am unable to install my app from TestFlight even though the build appears valid and is in internal beta testing. The build was uploaded successfully to App Store Connect and shows as Testing / Internal Testing. The build metadata looks valid: processingState: VALID internalBuildState: IN_BETA_TESTING qcState: BETA_INTERNAL_TESTING usesNonExemptEncryption: false minOsVersion: 15.0 deviceFamilies: IPHONE supportedArchitectures: arm64 However, TestFlight installation fails, and the App Store Connect API returns: ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING Beta contract is missing for the app. My App Store Connect agreements are all active. I checked Business > Agreements and both Paid Apps Agreement and Free Apps Agreement are Active. Bank accounts, tax forms, and compliance also appear Active. This also happens with a newly created app and a fresh build, so it looks like the TestFlight beta contract may be missing or detached on Apple’s backend. Has anyone seen this before, or is there a way to force App Store Connect to refresh the TestFlight beta contract state?

Hello, I noticed the webhook event BUILD_BETA_DETAIL_EXTERNAL_BUILD_STATE_UPDATED does not fire when a build is submitted for external beta review. It is only fired when the review completes. It would be great if we can get notified when an external beta review has started, similar to how we do get notified when a review gets started for the App Store build. Thank you for your time and consideration.

Hello Support Team, We are encountering a blocking issue while trying to submit/manage our app, Hairmakeapp. The system returns a 422 Unprocessable Entity error code preventing us from proceeding. Error Details: App Name: Hairmakeapp Error Code: ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING Status: 422 Message: "Beta contract is missing for the app. Beta Contract is missing." Full JSON Payload: JSON { "errors" : [ { "id" : "***", "status" : "422", "code" : "ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING", "title" : "Beta contract is missing for the app.", "detail" : "Beta Contract is missing." } ] } Steps Taken: Checked the "Agreements, Tax, and Banking" section in our Account, and all master agreements appear to be accepted and active. Verified that the Account Holder has signed the latest terms. Could you please verify if there is a pending or stuck Beta Agreement/Contract on your end for Hairmakeapp that needs to be triggered or refreshed? Thank you for your prompt assistance, as this is currently blocking our testing/release schedule. Best regards,

Are there issues with Testflight Beta Review process? My app (minor version update) has been sitting in waiting for review for a over 24 hours where previously it would take a few hours.

Hello, I am experiencing the exact same ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING issue. I cannot submit builds for External TestFlight review. When I click "Submit for Review" in TestFlight, App Store Connect returns: ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING "Beta contract is missing for the app." All agreements, banking information, and tax forms are Active. Completed and verified: • Paid Apps Agreement = Active • Free Apps Agreement = Active • Bank Account = Active • W-8BEN Tax Forms = Active • Compliance information completed • Account Holder role assigned correctly I have already: • Added and activated a bank account • Completed all tax forms • Uploaded new builds after activation • Waited several days for synchronization • Opened a case with Apple Developer Support Developer Support has already escalated my case to the senior team, but the issue remains unresolved. The browser console confirms: 422 ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING This issue is currently blocking External TestFlight testing. Has anyone experienced this recently? Could someone from Apple verify whether the TestFlight Beta Contract associated with the account needs to be reset, recreated, or manually refreshed? Thank you.

The status of my Mac application from TestFlight is "Complete" and "Ready to Submit". I truely don't know what is the next step to submit application to App Store Connect... Do I need invite external testers ? Is this invitation mandatory to App Store Connect or can I skip this step ? Any suggestion will be greatly appreciate.

Hi, I’m running into a persistent issue in App Store Connect related to TestFlight and app reviews, and I’m hoping someone has seen this before. From 8th of June, I started getting the following error when trying to create external TestFlight builds: ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING Since then: I cannot create any external TestFlight tests Internal TestFlight builds appear, but cannot be downloaded (“The requested app is not available or doesn’t exist”) This is an individual developer account I am the Account Holder All contracts appear active and valid The issue affects multiple apps, not just one Nothing changed on my side (no contract updates, no account changes) before this started happening. I’ve already reached out to Apple Developer Support multiple times, but unfortunately haven’t received any response so far, which makes it unclear how to proceed. Has anyone experienced this issue or found a resolution? Any insight would be greatly appreciated. Thanks!

I have a app that has both mobile and watch versions. Recently some testers report that the watch app could not be launched if the put the app in the background and then resume. And if they kill the app and try to launch again, there is no any response when tapping the app icon. I managed to export some system logs, and this info in the screenshot looks suspicious. Does anyone have the same issue? Recently the app has been transferred to another developer account, not sure if it is related, this TestFlight version was rebuilt with the new team

Hi, I really need help to resolve the issue with submitting build made with 26.2 for review to release TestFlight build to external testers. I'm always getting "This build is using a beta version of Xcode and can’t be submitted". I tried everything from cleaning DerivedData to fully reinstalling Xcode and tools to 26.2. Even tried earlier Xcode release versions and after pressing Submit for review I always face the same issue. Nothing helps and I can't share my first app with volunteers to test. By Jan 6 2026, my Xcode 26.2 is up to date with App Store and in Xcode Organizer I choose App Store Connect and press Distribute.

Can anyone help me with this error message? Beta contract is missing for the app. Error IDs: 3976de05-9ac1-41e1-9294-a8827535015e 96bfccea-8fe8-450a-8cff-fbc55b696b29 I have tried looking at agreements, there is nothing to sign or that I have not accepted. I cannot find any agreement related to this. I have tried sending my app for TestFlight review from web browser or TestFlight app in my iPhone but no help at all I get the same error message. I have tried sending request to Apple support to call me but that also ends up with error. Is there anything wrong going with Apple. How can we contact Apple? They are not replying to my emails either.

Hi, I am unable to receive any tesflight invite email in order to test on my end, can anyone assist with this issue.

To the Apple Review and Developer Support Teams, We are experiencing the same issue described in this thread: https://developer.apple.com/forums/thread/827016 Our application has been rejected under Guideline 2.1 - Performance because the subscription plans do not load during the App Review process. According to the review feedback, there's an error indicating that the In-App Purchases product list is empty. We are unable to reproduce this issue on our side. The subscription screen works correctly in TestFlight on multiple physical devices and with sandbox tester accounts. The paywall loads successfully, localized prices are returned correctly, and test purchases can be completed without errors. We have verified the following: All subscription products are attached to the submitted app version in App Store Connect. The product identifiers used in the application match the identifiers configured in App Store Connect. The relevant agreements, tax information, and banking details are active and up to date. The same build works correctly in TestFlight. The issue appears to occur exclusively in the App Review environment. This makes it difficult for us to diagnose the root cause or validate a fix. Could you please investigate whether there is an issue affecting StoreKit product retrieval during the review process? Any logs, diagnostics, or guidance on how to reproduce the App Review environment behavior would be helpful. Submission details: Date Submitted: Jun 1, 2026 at 2:01 PM Submission ID: 1260550e-ba11-4cbe-925a-7694f89ce715 Thank you for your assistance.

I deleted Build 16 from the external Test Flight review approval because I want Build 17 to be used and set up for external review. I successfully removed it and it is not showing up under external testing.. but when I try to add my Build 17, it is greyed out and says that Build 16 is still waiting for review. Can you please fix this as soon as possible so I can begin the review process for my Build 17? Please let me know what information you may need. I'm hoping to get this resolved ASAP.

I'm trying to distribute our app through TestFlight's internal testing for our QA Analysts to run some tests in the non-production environment. In this page: https://developer.apple.com/documentation/storekit/testing-in-app-purchases-with-sandbox Is stated that: "Apps that you download from TestFlight always run in the sandbox environment." But we ran into the issue from the ProximityReaderAPI requesting a Sandbox account anyway (This token requires a sandbox test account from your Apple Developer account). Is that not the case for Tap To Pay on iPhone?

I am testing a StoreKit 2 non-consumable IAP through TestFlight. Product ID: com.metabolla.plus.lifetime Type: Non-Consumable Environment: TestFlight / Sandbox Transaction.currentEntitlements keeps returning an active entitlement for this product even after: configuring a Sandbox Apple Account clearing Sandbox Purchase History reinstalling the app rebooting the device Important detail: the first TestFlight purchase was completed before configuring the Sandbox Apple Account on the device. If I temporarily change the Product ID in code, the entitlement disappears, so the issue seems tied to the original Product ID/account/receipt. Question: Can a non-consumable TestFlight purchase made before Sandbox Apple Account configuration remain associated with the original TestFlight/Apple ID identity? Is there any supported way to clear this entitlement for testing?

Hi everyone, I’ve spent the last 2 months pulling off a wild solo experiment: building a complete mobile puzzle game from scratch using Unreal Engine, where over 100k lines of code (C++ & pipelines) and thousands of 3D/UI assets were entirely generated by various AI models. Before anyone rolls their eyes—no, AI didn't replace the game designer here. AI provided the brute-force production muscle, but I gave it its soul. Every single bit of core design—the underlying math models, difficulty pacing, and counter-mechanics for the dynamic gimmick bosses—was designed and balanced by me. The game itself is a tactical, gimmick-boss driven match-3. I got tired of the usual candy-coated reskins and wanted to make something with rigid logic, irregular board topologies, and tight move economies for people who actually like strategic puzzle-solving. I’m currently running a closed beta via TestFlight on iOS to stress-test the build, and I'd love to get some brutal feedback from fellow devs. (Just a heads up: save progress won't carry over to final release). You can grab the build directly here: https://testflight.apple.com/join/VnUWvHFC I’m specifically looking for insights on: Performance & Thermals: How does the UE rendering pipeline handle on your device during heavy chain reactions? Aesthetic Cohesion: Does an all-AI asset pipeline manage to feel like a unified universe, or do you feel that "AI uncanny valley"? Balance: Do the non-Euclidean layouts and boss disruption mechanics feel strategic or just plain frustrating? I'll be hanging out in the comments. Drop any questions you have about prompt-engineering a 100k-line codebase, solo pipeline management, or UE integration. Thanks for testing!

Hi everyone, I’ve spent the last 2 months pulling off a wild solo experiment: building a complete mobile puzzle game from scratch using Unreal Engine, where over 100k lines of code (C++ & pipelines) and thousands of 3D/UI assets were entirely generated by various AI models. Before anyone rolls their eyes—no, AI didn't replace the game designer here. AI provided the brute-force production muscle, but I gave it its soul. Every single bit of core design—the underlying math models, difficulty pacing, and counter-mechanics for the dynamic gimmick bosses—was designed and balanced by me. The game itself is a tactical, gimmick-boss driven match-3. I got tired of the usual candy-coated reskins and wanted to make something with rigid logic, irregular board topologies, and tight move economies for people who actually like strategic puzzle-solving. I’m currently running a closed beta via TestFlight on iOS to stress-test the build, and I'd love to get some brutal feedback from fellow devs. (Just a heads up: save progress won't carry over to final release). You can grab the build directly here: https://testflight.apple.com/join/VnUWvHFC I’m specifically looking for insights on: Performance & Thermals: How does the UE rendering pipeline handle on your device during heavy chain reactions? Aesthetic Cohesion: Does an all-AI asset pipeline manage to feel like a unified universe, or do you feel that "AI uncanny valley"? Balance: Do the non-Euclidean layouts and boss disruption mechanics feel strategic or just plain frustrating? I'll be hanging out in the comments. Drop any questions you have about prompt-engineering a 100k-line codebase, solo pipeline management, or UE integration. Thanks for testing!

I am implementing device authentication for a macOS app. Our iOS app uses App Attest, but App Attest is not available on macOS, so we are evaluating StoreKit's AppTransaction plus AppStore.deviceVerificationID as the macOS equivalent signal. The issue: in a macOS app installed through TestFlight, AppStore.deviceVerificationID is available, but AppTransaction.shared throws StoreKitError code=2. I reproduced this in a focused standalone macOS test app with no backend and no custom dependencies. Environment: Platform: macOS Distribution: TestFlight App Store Connect app ID: 6769568350 Bundle ID: com.soundcity.AppTransactionProbe App version: 1.0 Build: 1 Observed output from the TestFlight-installed app: Bundle ID: com.soundcity.AppTransactionProbe App version: 1.0 Build: 1 deviceVerificationID available: true deviceVerificationID prefix: CA91ED5D... AppTransaction.shared threw error: StoreKitError; domain=StoreKit.StoreKitError; code=2 The relevant code path is essentially: import StoreKit let deviceVerificationID = try? AppStore.deviceVerificationID let appTransaction = try await AppTransaction.shared In the TestFlight-installed build: AppStore.deviceVerificationID succeeds. AppTransaction.shared throws StoreKitError code=2. Questions: Is AppTransaction.shared expected to work for macOS apps distributed through TestFlight? If yes, what does StoreKitError code=2 indicate in this context, and what setup might be missing? If no, is there an Apple-supported way to obtain an AppTransaction JWS, or equivalent signed App Store/TestFlight app-install assertion, for macOS TestFlight builds? For macOS apps that need a device-bound trust signal comparable to iOS App Attest, is AppStore.deviceVerificationID intended to be used without AppTransaction.shared, or should these APIs be used together? I have a focused Xcode test project that demonstrates the issue and can share it if helpful.