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 everyone, I'm stuck with a TestFlight issue affecting ALL apps on my developer account: New internal testers show "Invited", but never receive the invitation email. "Resend Invite" does nothing. Existing testers get notified about new builds, but installing fails with: "Could not install [App]. The requested app is not available or doesn't exist." I've contacted Apple Support but no answer yet. Has anyone had this recently? How did you fix it? Thanks!

I’m testing the first in-app purchase for an iOS app. It is a non-renewing subscription that grants 12 months of access. On November 9, a physical iPhone running our TestFlight build reproduced the same issue twice in the China mainland Sandbox storefront. Setup checked at the time The annual product was Ready to Submit in App Store Connect, with China mainland availability, a CNY 98 price, and a Simplified Chinese localization. The annual product identifier matched the identifier requested by the app. The explicit Bundle ID matched App Store Connect and had In-App Purchase enabled. The Paid Apps Agreement was active, and banking and tax records were in place. We used a mainland-China Sandbox tester and called the native StoreKit 2 Product.products(for:) API. The request included the configured annual product and an old monthly identifier that has no corresponding product in App Store Connect. Steps and results Install the app from TestFlight on a physical iPhone and open the purchase screen in Sandbox. Refresh the available products. We expect the annual product and its localized price to appear. Product.products(for:) completes with an empty array. Device logs show an HTTP 200 response from the China mainland Sandbox catalog followed by Ignoring empty product response. After the 600-second cache lifetime, the query received a different server correlation key and still returned no products. This occurs during product lookup, before any purchase call. TN3186 says that Sandbox testing can take place before submission for review. Has anyone reproduced this specifically with a non-renewing subscription? Is there another way to verify Sandbox catalog visibility for the configured annual product or diagnose why it is omitted? An annual-only StoreKit query would be a useful follow-up test. We can share the exact app and product identifiers, request correlation keys, and device diagnostics with Apple through Feedback Assistant.

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

For approximately one week, we have been unable to send TestFlight internal testing invitations. Invited users appear with the status "Invited", but no invitation date is displayed, and no emails are received. We have already tried recreating groups, resending invitations, using Safari, uploading different builds, and inviting users individually. All email addresses, user roles, and account requirements are correct. Interestingly, we also tested the same process using another developer's App Store Connect account, and invitations were delivered successfully. The issue only occurs with our account.

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.

Hi, Since October 24, 2026, TestFlight has been unusable for all three apps in our account (EmlakBase Pro, EmlakBase, BirSitem). Developer Support case: 103007291888 (opened October 24, 2026; follow-ups sent October 29 and November 8). I haven't received a reply yet, and phone support has been unavailable whenever I tried (November 9 and 10). 1) Internal testing Every internal tester sees the app in TestFlight, but tapping "Install" fails immediately with "The requested app is not available or doesn't exist." This also happens for a tester with the Admin role who accepted the invitation. New builds uploaded on November 6 show "Testing" in the internal group, yet no tester can install them. 2) External testing Submitting a build to Beta App Review always fails with "There was an error processing your request. Please try again later." The request (POST /iris/v1/betaAppReviewSubmissions) returns 422 ENTITY_UNPROCESSABLE. The build is VALID, export compliance is set, its external state is READY_FOR_BETA_SUBMISSION, and the test information, review contact and demo account are complete. What I've already checked or changed Membership is active. I accepted the latest Program License Agreement and the Free Apps Agreement. Certificates and provisioning profiles are valid, and builds process successfully. Testers have the App Manager or Admin role, and their Apple Accounts match their invitations. App availability is set to all countries or regions. I cancelled an old App Store submission that was still open (Guideline 2.1, Information Needed). The 422 error continues. Since this affects every tester across three separate apps, it looks like an issue with our account or app records on Apple's side. Could someone from Apple look into case 103007291888 or escalate it to the TestFlight team? Thank you.

Renewed my Apple Developer account a couple of weeks ago and I still can't log into App Store Connect. I get the error message: "Your Apple Account isn't enabled for App Store Connect." I've tried emailing multiple times and there is no response.

Hello, We would appreciate some guidance regarding an unexpected StoreKit currency result in a TestFlight build. Our iPhone language and region are both set to France. The Sandbox tester is also configured for France, and our subscription products have French availability and pricing configured in App Store Connect. In the TestFlight build we diagnosed, StoreKit reports the current storefront as France with EUR: storefront=FRA/143442/EUR However, all 10 subscription products are returned with USD product metadata: products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE Example: formatCurrency=USD locale=fr_US_currency_USD localeCurrency=USD display=1,99 $US price=1.99 We first observed this through Flutter's in_app_purchase integration. To determine whether the Flutter plugin was involved, we added a native StoreKit 2 diagnostic to the same TestFlight build. The native result was identical: receipt=sandboxReceipt storefront before=FRA/143442/EUR storefront after=FRA/143442/EUR products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE The issue appears specific to the TestFlight distribution. When the application is installed directly from the development computer, prices are returned in euros on the same device. We also tested with the regular Media & Purchases account signed out and a French Sandbox tester connected. Once the products loaded successfully, StoreKit still returned USD metadata. In another configuration, the application displayed the USD price while Apple's purchase sheet displayed the price in euros. We are using the price and formatting information returned directly by StoreKit. We do not want to infer the currency from the device region or perform a client-side currency conversion, because StoreKit should remain the authoritative source. Could you please help us understand: Is it expected for Storefront.current to report FRA/EUR while Product.priceFormatStyle.currencyCode, its locale currency, and Product.displayPrice use USD? Could a TestFlight or App Store Connect configuration cause product metadata to use a different currency from the current storefront? Is there another account, availability, pricing or distribution setting that we should verify? Is there a recommended way to refresh or invalidate the product metadata used by a TestFlight installation? We have already filed Feedback Assistant report FB24723329, which is currently under investigation. Thank you very much for any clarification or additional diagnostic steps you can suggest.

We are experiencing the same issue with two independent native iOS apps on an iPhone running iOS 27.0.1, using TestFlight in France. Our annual subscription displays US$34.90 instead of €39.90, and our non-consumable purchase displays US$5.99 instead of €6.99. Both apps displayed the correct EUR prices during local Xcode testing. In TestFlight, Apple's native purchase sheets still show the correct EUR prices, and both purchases work successfully. We have contacted Apple Developer Support (case 103017935062). As this issue is delaying the time-sensitive release of our educational app, could Apple confirm whether a workaround is available or whether a fix is planned? https://developer.apple.com/forums/thread/845478 Thank you.

New individual account (Team ID UTH8X8R54P). App ID 6825129426, bundle com.lichooo.inercia. Since Oct 20, every processed build (latest 1.3.0 (7), uploaded Nov 2) fails to install for internal testers with "The requested app is not available or does not exist", including the account holder, whose Apple ID matches the one on the device. Submitting any build for external beta review returns 422 ENTITY_UNPROCESSABLE "Please try again later" (error IDs a82b110f-0641-44db-af8e-7452cb4bf93c and 4115b133-61c0-4135-9306-ba4bbe51514e). Already checked: Latest Program License Agreement and Free Apps Agreement accepted (Active) EU DSA trader status completed Export compliance answered (no non-exempt encryption) Test Information complete (description, feedback email, privacy policy, contact, review notes) Internal tester status Accepted, internal build state IN_BETA_TESTING Re-uploading builds and reinstalling TestFlight didn't help Support cases 103003383660 and 103004342314 are open with no resolution, and phone support is currently unavailable. Could someone from the TestFlight team check whether the account is missing the beta agreement (BETA_CONTRACT_MISSING) or has a backend flag? Thank you.

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.

Hello, My app uploads and processes successfully in App Store Connect, but nobody can install it from TestFlight, including me as the account holder. Tapping Install/Update fails with: “Could not install [App Name]. The requested app is not available or doesn’t exist.” Trying to add the build to external testing also fails with a message saying a technical issue occurred and to try again later.

Hi everyone, We are currently preparing the release of our Flutter-based iOS application and are experiencing an unusual StoreKit 2 storefront issue that only occurs when the app is installed through TestFlight. The problem When our application is installed through TestFlight, StoreKit 2 consistently returns the United States storefront (USA), and all six auto-renewable subscription products are displayed with USD prices. However, both the regular Apple Account and the Sandbox Apple Account are configured for Germany. We have verified the following: All six subscription products are correctly configured in App Store Connect with EUR prices for Germany. The subscriptions are available in Germany, Austria, and Switzerland. We created a completely new Sandbox tester with Germany selected during account creation, using an email address that had never previously been used for sandbox testing. The issue occurs on two different physical devices (iPhone and iPad). No local StoreKit configuration file is used. Our application does not override the storefront, modify localized prices, or contain any hardcoded USD fallback. Controlled comparison We performed additional tests using the same application code on the same iPhone. The results were: Installation method Storefront Currency Local Debug build via Xcode/Flutter DEU EUR Local development-signed Release build via Flutter DEU EUR TestFlight Release build USA USD The locally installed Release build successfully retrieves all six subscription products with their correct German prices. For example, StoreKit returns the following values for one of our subscriptions: Local Release build: Storefront.current.countryCode = DEU Product currencyCode = EUR Product.displayPrice = 6,99 € TestFlight build: Storefront.current.countryCode = USA Product currencyCode = USD Both builds use the same StoreKit 2 integration and product identifiers. Technical environment Framework: Flutter StoreKit integration: StoreKit 2 Flutter plugin: in_app_purchase_storekit 0.4.11+2 Devices: Physical iPhone and iPad iOS/iPadOS: 26.6.2 Subscription products: Six auto-renewable subscriptions Expected storefront: Germany (DEU) Actual TestFlight storefront: United States (USA) We have traced the storefront country code directly to StoreKit 2’s Storefront.current.countryCode and the localized prices to the product information returned by Product.products(for:). There is no application-level storefront override or price conversion. Questions Why would StoreKit 2 return a different storefront in TestFlight compared with a locally installed development-signed Release build on the same physical device? Could TestFlight use a different sandbox storefront or Apple Account context than a locally installed build? Is there a recommended way to diagnose or reset the storefront association used by TestFlight? Has anyone experienced similar behavior where TestFlight consistently returns USA despite using a German Apple Account and newly created German sandbox testers? We have already contacted Apple Developer Support and followed their recommendation to create a completely new German sandbox tester, but the issue persists. Any guidance from Apple engineers or developers who have encountered similar behavior would be greatly appreciated. Thank you!

Hi everyone, We are currently preparing the release of our Flutter-based iOS application and are experiencing an unusual StoreKit 2 storefront issue that only occurs when the app is installed through TestFlight. The problem When our application is installed through TestFlight, StoreKit 2 consistently returns the United States storefront (USA), and all six auto-renewable subscription products are displayed with USD prices. However, both the regular Apple Account and the Sandbox Apple Account are configured for Germany. We have verified the following: All six subscription products are correctly configured in App Store Connect with EUR prices for Germany. The subscriptions are available in Germany, Austria, and Switzerland. We created a completely new Sandbox tester with Germany selected during account creation, using an email address that had never previously been used for sandbox testing. The issue occurs on two different physical devices (iPhone and iPad). No local StoreKit configuration file is used. Our application does not override the storefront, modify localized prices, or contain any hardcoded USD fallback. Controlled comparison We performed additional tests using the same application code on the same iPhone. The results were: Installation method Storefront Currency Local Debug build via Xcode/Flutter DEU EUR Local development-signed Release build via Flutter DEU EUR TestFlight Release build USA USD The locally installed Release build successfully retrieves all six subscription products with their correct German prices. For example, StoreKit returns the following values for one of our subscriptions: Local Release build: Storefront.current.countryCode = DEU Product currencyCode = EUR Product.displayPrice = 6,99 € TestFlight build: Storefront.current.countryCode = USA Product currencyCode = USD Both builds use the same StoreKit 2 integration and product identifiers. Technical environment Framework: Flutter StoreKit integration: StoreKit 2 Flutter plugin: in_app_purchase_storekit 0.4.11+2 Devices: Physical iPhone and iPad iOS/iPadOS: 26.6.2 Subscription products: Six auto-renewable subscriptions Expected storefront: Germany (DEU) Actual TestFlight storefront: United States (USA) We have traced the storefront country code directly to StoreKit 2’s Storefront.current.countryCode and the localized prices to the product information returned by Product.products(for:). There is no application-level storefront override or price conversion. Questions Why would StoreKit 2 return a different storefront in TestFlight compared with a locally installed development-signed Release build on the same physical device? Could TestFlight use a different sandbox storefront or Apple Account context than a locally installed build? Is there a recommended way to diagnose or reset the storefront association used by TestFlight? Has anyone experienced similar behavior where TestFlight consistently returns USA despite using a German Apple Account and newly created German sandbox testers? We have already contacted Apple Developer Support and followed their recommendation to create a completely new German sandbox tester, but the issue persists. Any guidance from Apple engineers or developers who have encountered similar behavior would be greatly appreciated. Thank you!

I am preparing the first release of my iOS game, Ippon Battle, and testing it on my own physical devices through TestFlight. I am looking for a supported workaround or further diagnostics for inconsistent product prices, and guidance on whether the same behavior can occur in production. Feedback report: FB25378742 (filed October 31, 2026; currently Open). Apple Developer Support directed me to Feedback Assistant for bug reporting and these forums for technical help. The feedback report includes screenshots and the app-specific identifiers. Environment and observations iPhone 15, iOS 27.0.1 (24A446). App version 1.7.11; raw catalog diagnostics were captured in TestFlight build 41. Two non-consumable products: ipponbattle.fighters5 (Japan: JPY 300) and ipponbattle.story (Japan: JPY 400). The Sandbox account is configured for Japan. The iPhone diagnostic reported Storefront country JPN and currency JPY. Japan prices were independently read-verified through the App Store Connect API on October 21, 2026. I have not changed prices as a troubleshooting step. For each exact product ID, native StoreKit calls returned: Product.products(for:): price = 1.99, priceFormatStyle.currencyCode = USD SKProductsRequest: price = 1.99, priceLocale currency = USD This occurred for BOTH products, despite their different configured Japanese prices. The original in-game shop displayed $1.99 for each. The fighter pack's Apple purchase confirmation sheet showed JPY 300. On a second physical device, an iPad running TestFlight build 44, a screenshot shows the story product at $1.99 in the shop behind Apple's purchase sheet showing JPY 400. The sheet explicitly identifies it as a test purchase with no charge. I did not capture raw storefront/API diagnostics on that iPad, so I am not assuming its internal storefront state was identical to the iPhone trace. Both products were successfully test-purchased in earlier tests. Restoration and ownership after relaunch also worked. The issue is the product metadata price/currency, rather than an inability to complete a purchase. Reproduction procedure Install the app through TestFlight and use the Japan-configured Sandbox account. Request the two product IDs with Product.products(for:) and inspect the returned product IDs, price, priceFormatStyle.currencyCode, and displayPrice alongside the current Storefront. Independently request the same IDs through SKProductsRequest and inspect price and priceLocale. Compare those values with the configured Japan prices and Apple's purchase confirmation sheet. Checks and mitigation Signing out of the Apple account did not resolve the problem. Product data is matched by product ID, not response order. There is no fixed USD fallback or persistent price cache in the app. The TestFlight build does not use a local StoreKit configuration file. These are native API results, not simulated UI test responses. The app refreshes product information when the shop opens and clears old quotes on refresh, failure, or storefront changes. StoreKit 1 is used only to cross-check catalog data. Purchases, transaction verification, and restoration remain on StoreKit 2. As a temporary mitigation for this Japan-only app, prices that cannot be verified as JPN/JPY are hidden. I do not relabel USD amounts as yen, convert them, or substitute hard-coded JPY prices. This prevents the misleading display but does not solve retrieval of the correct catalog prices. Questions Is a mismatch between StoreKit product metadata and the purchase sheet a known TestFlight/Sandbox behavior? Is there any supported way to determine whether production is affected before a first public release? What supported recovery or refresh procedure should I try to retrieve prices consistent with the purchase sheet, beyond re-requesting products and signing out/in? What additional diagnostics, logs, or reproduction details would help the StoreKit team investigate FB25378742? I found a similar report, but I do not know whether it has the same cause. I have not isolated the cause to the catalog service, OS, or account. Thank you.

To Apple Engineers, I don't seem to get any updates or responses so I will keep trying to reach out here. Please work with me on what is needed to get my app approved. it is truly important to get it deployed as soon as we can so I can begin to launch and promote the app in App Store. It has already been live on the Google Play Store for a couple weeks. My app: XmasMaps has been going from "Waiting for Review" to "Rejected". I would fix the mistakes right away which would put XmasMaps back into "Waiting for Review". This App would be a useless App after November. Our app, XmasMaps, has been stuck in "Waiting for Review" since September 29th, 2026 (Submission ID: 1ced2377-575b-4bdd-812f-2852a23c2ffc). Timeline of previous actions: Sept 29, 2026: Initial submission Oct 8 & Oct 11, 2026: Resubmitted fixes following rejections Oct 14, 2026: new build resubmitted, currently stuck in "Waiting for Review" Oct 16, 2026: Expedited review request submitted Oct 19, 2026: Support customer inquiry submitted Android is already live, and we are hoping to clear iOS review so users can access the platform ahead of the upcoming holiday season. Oct 24, 2026: Rejected again for something already built into my latest build. i resubmitted right away and now put back into "waiting for review" when I would expect that the engineer who rejected it would take it back and finalize my app. Oct 28, 2026: As of today, I opened multiple app requests for an update and update the forum multiple times until I can try to get a response. Submission ID: 1ced2377-575b-4bdd-812f-2852a23c2ffc Support Case ID: 102982950152 / 103008467960 Team ID: 34WAQXFJHP I ask, please assist and review my app. I really need it live on both platforms to promote it. Please let me know if any additional information is needed from my side. Thank you.

My first app (watchOS) has version 1.0, build 16, approved by App Review and set to manual release, so it is Pending Developer Release. It has never been released. Since then I've added features (Apple Health workout recording) in build 17. I don't want build 16 released. I'd like to: Upload build 17 and test it with internal TestFlight testers. Submit build 17 for review and release it as the app's first public version. Questions Can build 17 be uploaded as version 1.0 while version 1.0 (build 16) is Pending Developer Release, or will the upload be refused with ITMS-90062 ("must contain a higher version than that of the previously approved version")? If it's refused, what's the right path: reject build 16 myself (Developer Rejected) and then submit build 17 under 1.0, or change the version to 1.0.1 for build 17? Can the version number of the existing 1.0 record be edited after a rejection, or do I need a new version? Is it safe to try the TestFlight upload before doing anything to build 16? I don't want to lose the current approval by mistake. Thanks for any guidance.

I’m validating the officially supported distribution path for an independent watchOS app. Target device Apple Watch Series 6 GPS + Cellular watchOS 26.6 Configured using Apple Watch For Your Kids / Family Setup The Watch belongs to a child Apple Account Managed from the parent/guardian’s iPhone 11 running iOS 27.0 The child does not have their own iPhone Direct development deployment from Xcode is not available in this configuration on my setup. The Family Setup Watch does not appear as a development destination / CoreDevice device and does not expose Developer Mode. Main question Does TestFlight officially support installing a watchOS-only or independently installable watchOS app onto an Apple Watch configured with Apple Watch For Your Kids / Family Setup? If yes: Is installation initiated from TestFlight on the parent/guardian iPhone that manages the Family Watch? Should the Family Setup Watch appear as an eligible Apple Watch target inside TestFlight? Should the child Apple Account or the parent/guardian Apple Account be added as the TestFlight tester? Are there any additional restrictions or requirements specific to Apple Watch For Your Kids / Family Setup? Is Developer Mode required on the Watch for TestFlight installation? I’m specifically asking about an officially supported TestFlight/App Store Connect distribution path, not Ad Hoc distribution, manual IPA installation, private APIs, or unsupported workarounds. Thank you.

Does Xcode 27 or TestFlight support installing a watch-only beta on an Apple Watch For Your Kids device? I want to test my watch only standalone app on my kids apple watch as that is the only device I have. Is it possible to use that watch for testing standalone apple watch application. The watch is setup as kids watch on my iphone.

Hello, I'm having trouble installing my app via TestFlight. Current Status: The app build has been successfully uploaded and processed in App Store Connect. The build status currently shows "Ready to Submit" All export compliance questionnaires have been completed. The Issue: Even though everything looks ready on the dashboard, I cannot install the app on my phone via TestFlight. • (Specifically, the app is visible but throws an error when I click install-‘this app doesn’t exist or not available’). What I've Tried: • Checked that the testing group is properly linked to the build. • Re-signed into the TestFlight app on my device. Could App Store Connect Team Adviser help me with this issue please as soon as possible!