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.

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.

Hello. I have a problem with the FoundationModels adapter and the Apple-hosted managed asset pack via TestFlight. I have created an adapter that works fine locally by creating a model via (fileURL: URL) on a real device, but I cannot create a model using background assets by downloading the adapter via TestFlight. Every time I try to get an adapter, the creation of the adapter is interrupted by the compatibleAdapterNotFound error. The aar. archive i created using a special command - xcrun ba-package foundation-models package --adapter-path aurelius1.fmadapter --asset-pack-id fmadapter-aurelius1-9799725 --output-path ./aurelius1.aar --platforms iOS --on-demand\ after that, I replaced "OnDemand": null with "OnDemand": {} in the manifest so that the Transporter could send my archive to the App Store Connect. I followed all the recommendations in this topic - https://origin-devforums.apple.com/forums/thread/823148 ...but unfortunately unsuccessfully I would appreciate any help in solving this problem. here is the code that I use in my app -

Hi, Recently our App is facing a generic error with no error details. This error is happening once Build has been successfully uploaded to AppStore Connect through Xcode Organiser. Steps followed while uploading the build: Archive the Build through Xcode Once Archive is successful, Distributing the App through Xcode Organiser using AppStore Connect distribution method. Build Uploaded successfully to AppStore Connect After 5 min we are receiving a email with below message Hello, We noticed one or more issues with a recent delivery for the following app: AppName App Apple ID 2121111 Version 3.6.9 Build 75 Please correct the following issues and upload a new binary to App Store Connect. ITMS-90755: Invalid Binary - The following binaries in your app contains prohibited instructions: AppName.app/AppName. Remove the instructions from the binaries, rebuild and resubmit. Apple Developer Relations Solutions tried till now Updating Xcode to latest version of 16.4 Recreating new Distribution certificates and Provisioning Profiles Clearing DerivedData and cleaning Build Folder This issue seems to be occurring recently only since launch of Xcode 16.4 Other Device info Macbook Pro macOS: Sequoia 15.5 Xcode: 16.4

Hello, I am currently unable to submit builds for TestFlight testing. Whenever I attempt to process a build, I receive the following error: ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING "Beta contract is missing for the app." I have verified my account details and compliance to ensure everything is correct on my end: I am the Account Holder. My Free Apps and Paid Apps agreements are both marked as Active in App Store Connect. All App Privacy, Age Rating, and Export Compliance forms are completed. I reached out to Apple Support via email a few days ago but have not yet received a response. My Support Case ID is: 102910951543. Because there are no pending agreements on my end, it appears the TestFlight Beta contract has become detached on Apple's backend. Could a DTS engineer or support representative please manually re-provision the beta contract for my account? Thank you for your time and assistance.

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've read several topics on cancelling subscriptions in sandbox environment, but it seems to me that it could not be applied to TestFlight. I can cancel sandbox subscriptions through Settings > App Store > Sandbox account But since TestFlight does not use sandbox account I cannot cancel a sub from there. Also, TF purchase does not appear in the list of regular subscriptions (Settings > Profile > Media & Purchases). So my question is: is there any way to manually cancel auto-renewable subscription bought in TestFlight build of the app?

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.

To the Apple Review and Developer Support Teams, I am writing to request guidance and assistance regarding a persistent rejection my React Native application is facing under Guideline 2.1 - Performance (In-App Purchases). My app has been rejected multiple times with the following specific note: "The In-App Purchase products in the app still exhibited one or more bugs which create a poor user experience. Specifically, the subscription screen failed to load any subscription plans. Review the details and resources below to troubleshoot this issue." The screenshot provided by the review team shows a completely black screen where our paywall options are intended to populate, indicating that the product array is returning completely empty during the review process. The Dilemma: We are completely unable to reproduce this behavior on our end. Everything functions flawlessly within our TestFlight builds across multiple physical test devices and various sandbox tester accounts. On TestFlight, the paywall renders instantly, local pricing fetches immediately via SKProductsRequest, and test transactions process without a single error. Our Current Implementation & Verification: Product Status: All subscription products are explicitly marked as "Waiting for Review" in App Store Connect with one In-App product Rejected for not being attached with a bin but I've since submitted the app once again. All the subscriptions and the in-app product have been actively attached to this specific app submission version. Agreements: The Paid Apps Agreement is active, signed, and fully up to date within our Agreements, Tax, and Banking configurations. Identifiers: We have strictly verified that the hardcoded product identifiers in our React Native codebase match the App Store Connect product IDs exactly. Because this error only occurs within the App Review environment and never in TestFlight or local sandboxes, we are at a loss for how to debug or resolve this issue. Could the App Review team or the Developer Support technical team please clarify if there is a known environment mismatch, storefront routing discrepancy, or specific network configuration (such as IPv6 handling in the review sandbox) that would cause production-ready StoreKit products to return an empty array exclusively to the reviewer? Any direct guidance, logs, or steps on how we can successfully surface our plans to your review team would be deeply appreciated. Review Environment Submission ID: 5a35279c-1621-4972-b6c6-7c1fb202b2f0 Review date: May 20, 2026 Review Device: iPad Air 11-inch (M3) Version reviewed: 1.0.2 (8) Thank you for your time and assistance.

Hello to the community. I’m hoping someone here can help me. we have been developing our mobile app with a 3rd party contractor. I used to provide feedback through TestFlight screen shot program and it was great. Straight from my iPhone to the dev team. Screen shots with descriptions of the problem. they recently transferred the app to our account and I think since then we can no longer receive the feedback. in fact, last week I spent 2 hours reviewing the app. Sending tons of screen shot feedback with comments. Thinking they were receiving them. But nothing. when we log into our feedback portal I only see feedback from 70 days ago. And nothing from recent. I made sure that feedback is welcome ( see screen shot ) i tested individual feedback test and got nothing. here are my questions. Is there a way to recover that feedback. Where is it going ? How can I get this feature working properly again so I can effectively and efficiently review the app and provide feedback to the developers.

We have a managed iOS app, distributed to managed iPhones through Apple Business Manager, and we are offering a TestFlight version. When users install a TestFlight Version, it is relatively quickly replaced by the current release. Is there a way to prevent this?

Hello, Our iOS app’s TestFlight external testing build has been stuck in “Waiting for Review” for several days. This is for TestFlight External Testing, not an App Store public release submission. We have already provided the Beta App Review Information, including review notes, test instructions, contact information, and a working demo account. Current situation: App name: Linic Platform: iOS Submission type: TestFlight External Testing Status: Waiting for Review Submitted date: June 4 ~ June 5, 2026 Build number: 1.4.2(8)、1.4.3(9) Bundle ID: com.lincept.linny Beta App Review Information: already updated Demo account: provided in App Store Connect We would like to understand whether this is currently expected queue behavior, whether TestFlight external beta reviews are experiencing delays, or whether there is any additional information we should provide to help the review proceed. Has anyone recently experienced a similar delay with TestFlight External Testing builds stuck in “Waiting for Review”? If so, did contacting Apple Developer Support or submitting an expedited review request help? Thank you.

Hi friends, Since yesterday, I'm not able to download any of my apps from TestFlight (while I can for others developers). I'm searching since 2 days now about the reason and I think I've tried everything, so I'm asking if you might have an idea... It occured after adding subscriptions to one of my apps, then I did all of these: Check all contracts on my apple developer account Verify my apple ID in internal testers Install / Uninstall TestFlight app Remove / Re-add myself as tester Try new builds My apps are listed on the Apple Store and not removed from Sales. Did I miss something? The error is mysterious... I also contacted Apple, I'm waiting for their answer. Thank you 🙏

I’m having an issue where my TestFlight build is visible to a tester, but installation fails immediately. App details: Platform: iOS Version/builds affected: 0.3.0 (5) and 0.3.0 (6) Device tested: iPhone 14 running iOS 26.5 App status in App Store Connect: Prepare for Submission The app has not been publicly released. What happens: The tester can see the app in the TestFlight app under “Currently Testing”. The Install button is visible. However, tapping Install shows this error: “Could not install "App" Workspace. The requested app is not available or doesn’t exist.” The issue occurred with build 0.3.0 (5), then again after uploading a fresh build 0.3.0 (6). What I have already checked/tried: Build uploads completed successfully in App Store Connect. Build 0.3.0 (5) processed successfully. Build 0.3.0 (6) was uploaded as a fresh build. Build 0.3.0 (6) includes ITSAppUsesNonExemptEncryption = false in Info.plist. The build is assigned to the internal testing group. The tester invite shows as accepted. I tried using a separate Apple ID/email address that I control. The tester account can see the app in TestFlight. I deleted and reinstalled TestFlight on the device. I confirmed the device/TestFlight account is signed in with the tester Apple ID. Pricing has been set to Free. App Availability has been configured for the relevant region. The app is showing “Prepare for Submission”, not “Removed from Sale”. The build appears in TestFlight, but install still fails. Has anyone seen this state before, where TestFlight can display the app and build to an accepted tester, but install fails with “The requested app is not available or doesn’t exist”? Is there any App Store Connect availability, storefront, app version, or backend distribution state that can cause this? Any guidance on what to check next would be appreciated.

Hello, We are experiencing the exact same behavior described in the following Apple Developer Forum thread: https://developer.apple.com/forums/thread/827016 The issue appears to be isolated to the App Review environment and matches our current rejection under Guideline 2.1 - Performance. On our side, the subscription system is functioning correctly and consistently in TestFlight using the exact same build that was reviewed. We tested on multiple physical devices using Sandbox tester accounts and confirmed that: StoreKit successfully returns all subscription products RevenueCat offerings load correctly Localized pricing is displayed properly Purchases complete successfully Restore purchases also work as expected However, during App Review, the review notes indicate that the product list is empty, which causes the paywall to fail loading. We would like to emphasize that: The In-App Purchases are attached to the submitted app version Product identifiers exactly match between App Store Connect and the application code Agreements, tax, and banking information are active The products are marked as available for sale The same binary works correctly in TestFlight Because the issue cannot be reproduced outside the review environment, we currently have no reliable way to diagnose or validate a permanent fix. At this point, we suspect there may be an intermittent StoreKit product retrieval issue affecting the App Review environment specifically. If possible, could you please: Verify whether StoreKit product retrieval is functioning correctly in the review sandbox environment Share any diagnostic logs related to the failed product request Confirm whether the review device successfully connects to App Store sandbox services Provide any additional guidance for reproducing the App Review behavior locally We are fully committed to resolving the issue and ensuring compliance with App Store requirements, but currently the behavior appears environment-specific and non-reproducible from our side. Thank you very much for your assistance and support. Best regards, Mert Akgün

Anyone is experiencing this issue? Today without any reason we can think of, all of our builds were expired on Testflight. Without knowing what happened, then we tried to add a new build, that it it seems to be in good shape on Testflight, even with the mark green meaning is ready to be tested. Even though, by trying to install the app on iOS using TF, we are getting a message saying "The requested app is not available"