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, 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 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!

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 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!

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. Please assist. I have my launch date coming up that can't be canceled. Thank you.

I submitted my app update(A Slight Chance of Sawblades - 6444032878) for approval for beta testing on the 29th and it was rejected yesterday with just one sentence describing the issue: "Specifically, the app automatically closes after launch." Details about the device type and OS version were left blank. Interestingly, through testing with an internal group via TestFlight, I was unable to reproduce the stated issue, and was able to run the app across a variety of devices, OS versions and accounts without problems. I am writing this post in the hopes to expedite the review and get to the bottom of this problem, because my users are expecting a patch soon to address a specific bug (and I also need the app to match the Apple Arcade version). I'm also recompiling and submitting a fresh build, just in case. Thank you very much.

I’m trying to upload an iOS app to TestFlight for an existing organization team, but I’m stuck in an agreement/access loop. What I see: • App Store Connect lists my account as “Account Holder, Admin” for the organization. • Our existing apps are visible in App Store Connect. • A banner says the Account Holder must accept the updated Apple Developer Program License Agreement. • Following the account link opens developer.apple.com/account, but that page only shows “Join the Apple Developer Program” and “Enroll today.” • There are no membership details, organization team selector, or agreement acceptance button. • Certificates, Identifiers & Profiles shows “Access Unavailable.” What I’ve already tried: • Confirmed that I’m using the same Apple Account on both websites. • Signed in again using a fresh Chrome Incognito session — same result. • Signed back into Xcode. The organization team appears, but access to Certificates, Identifiers & Profiles is still unavailable. App Store Connect also shows the Free Apps Agreement as “Active (New Agreement Available).” I haven’t been able to verify the actual membership expiration date because the Developer portal does not show membership details. The app builds successfully without code signing, but I cannot complete provisioning and upload it to TestFlight. I’ve already opened a case with Apple Developer Support and am awaiting a response. Has anyone resolved this exact situation? Was it a membership renewal issue, an account-to-team association issue, or something else? Is there an official way to access the agreement or membership details when the Account Holder sees only the enrollment page? Any experience or guidance from Apple staff would be appreciated.

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.

We're testing In-App Purchases for our app distributed via TestFlight, using Sandbox Apple Accounts. We observe two device-dependent behaviors and have two questions. (App-specific details, including the bundle ID, are in our Feedback report FB24632077.) Observation 1 — Consumable second purchase fails with DuplicateTransaction on some devices The first purchase of a consumable succeeds and the transaction is finished. A second purchase of the same consumable then fails with PurchaseFailureReason.DuplicateTransaction ("This In-App Purchase has already been bought") on some devices. It correlates with sandbox session persistence: on devices where the purchase prompts for password only (e.g., iOS 26.x, iPadOS 18.4.1) the second purchase succeeds; on devices where it prompts for the account (email) + password every time (e.g., iOS 18.3.2, iPadAir2 15.6), the second purchase fails. The same Sandbox Apple Account behaves differently on different devices. An Ad Hoc (development-signed) build with the same account succeeds. Observation 2 — Product price sometimes returns USD instead of the storefront currency With the same Sandbox account (region: Japan), prices are shown in JPY on iOS 26.2 but in USD on iOS 18.3.2. The App Store app shows JPY, but SKProductsRequest / StoreKit 2 Product metadata returns USD. Question 1: Are these known Sandbox/TestFlight limitations? If so, what is the recommended way to reliably test repeat consumable purchases (and to get the correct storefront currency) in TestFlight across many devices and OS versions? Question 2: For TestFlight IAP testing, are there environmental differences between (A) using the device's real Apple ID (signed into Media & Purchases; automatic sandbox) and (B) signing out of Media & Purchases and using a Sandbox Apple Account — with respect to: reliability of repeat consumable purchases, authentication / session persistence (password-only vs account + password each purchase), storefront / currency resolution for product metadata, ability to clear purchase history? Which approach do you recommend for a consistent, reliable TestFlight IAP QA environment? Environment: TestFlight (App Store distribution), Sandbox tester region = Japan. (App-specific identifiers such as bundle ID are in our Feedback report FB24632077.) Repro: buy a consumable once (succeeds, finished) → buy the same product again → DuplicateTransaction on affected devices. Thanks!

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.

I'm struggling to get past the following error from Transporter. I've tried everything I can think of and I'm not sure what else to do. WARNING ITMS-90885: ""Cannot be used with TestFlight because the executable “${executable}” in bundle “${bundle}” is missing a provisioning profile but has an application identifier in its signature. Nested executables are expected to have provisioning profiles with application identifiers matching the identifier in the signature in order to be eligible for TestFlight."" Setup I'm using electron with a main.app and nested helper apps (e.g. Main.app/Contents/Frameworks/Main Helper (Renderer).app) I'm trying to upload to the Mac App Store I'm codesign-ing the contents with Apple Distribution: ... and signing the pkg installer with 3rd Party Mac Developer Installer: ... I'm using osx-sign to manage the code signing for me: basically it's doing a whole bunch of this: codesign --sign {40-char-hash} --force --timestamp --options runtime --entitlements "$CHILD_PLIST" "packages/mas-universal/{APP_NAME}.app/Contents/Frameworks/{APP_NAME} Helper (Renderer).app"

Hello everyone, We submitted a major update for our social networking app, Yuppi, on October 23, 2026. Both our TestFlight and App Store submissions are still in "Waiting for Review" status. Following a previous consultation with Apple's App Review team, we carefully addressed their feedback, completely redesigned our app, and introduced several new features. We fully understand and respect Apple's review procedures and standard timelines. However, our main priority at this stage is TestFlight. We would love to give our existing users the opportunity to experience and test our new design and features before the official App Store release. We completely understand that the App Store review may take additional time, and we have no concerns about following the standard process. We would sincerely appreciate any guidance from the Apple App Review team regarding whether our TestFlight submission could be reviewed first. We would also love to hear from other developers who have experienced similar TestFlight review delays. How long did your review take, and was there anything that helped move the process forward? Thank you all for your time and support.

Hi, We cannot distribute any build via TestFlight. Both internal and external testing fail. This appears to be a server-side beta contract issue on the account. SYMPTOMS Builds upload and process successfully. All 8 builds show status "Testing" in App Store Connect with 84-90 days remaining. In the TestFlight app on device, the build appears with an Install button. Tapping Install fails immediately with: "Could not install [App]. The requested app is not available or doesn't exist." This happens for INTERNAL testing as well, which does not require Beta App Review — indicating the problem is not in the review pipeline. In App Store Connect, the "What to Test" step fails with: "There was an error processing your request. Please try again later." BROWSER CONSOLE EVIDENCE Repeated failures on the beta review submission endpoint: Failed to load resource: the server responded with a status of 422 https://appstoreconnect.apple.com/iris/v1/betaAppReviewSubmissions Also observed: 404 NOT_FOUND — /iris/v1/appTaxCategories/[app id] "There is no resource of type 'appTaxCategories' with id '...'" ACCOUNT STATUS — all verified Active Free Apps Agreement: Active (Oct 19, 2026) Paid Apps Agreement: Active (Oct 21, 2026) Bank account: Active Tax forms (Certificate of Foreign Status, W-8BEN): Active (Oct 21, 2026) Digital Services Act: Active (Oct 22, 2026) Apple Developer Program membership: current Account Holder accepted the Oct 13, 2026 Developer Program License Agreement This is a newly enrolled account; all agreements became Active Oct 19-22, 2026. BUILD CONFIGURATION Version: 1.0.0, builds 6 through 15, uploaded Oct 22 and Oct 28, 2026 — all AFTER the agreements became Active Processing status: Complete / Ready to Submit App Availability: configured, no territories stuck in "Processing" Encryption: ITSAppUsesNonExemptEncryption set in Info.plist History: First release cycle; app has never been removed from sale ALREADY TRIED Multiple new builds, removing and re-adding testers, new testing groups, reinstalling TestFlight, verifying Apple IDs match invitations, multiple devices and multiple Apple IDs. No change. QUESTION Could the beta contract for this account be re-provisioned on the App Store Connect backend? Per previous threads this appears to require internal action. Apple Support Case ID: 103005208314 Bundle ID: com.tirtik.tirtik This is a server-side issue, not device-side. A sysdiagnose can be provided on request. Thank you.

New organization account. Since accepting the Free Apps Agreement on Oct 27, 2026, TestFlight stopped working for all our apps: All builds are marked Expired within days of upload, without anyone expiring them. Internal testers get "The requested app is not available or doesn't exist" when installing. External submission returns HTTP 422 ENTITY_UNPROCESSABLE (no sub-code) from /iris/v1/betaAppReviewSubmissions. TestFlight worked on Oct 21–22 (builds installed by testers). Membership and agreements are active; app metadata, privacy and export compliance are complete. App Apple ID: 6825263720 Developer Support case: 103012517274 Feedback: FB25359930 Could someone from Apple check whether our team's TestFlight beta contract needs to be re-linked? Thank you.