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

Early Access via TestFlight: https://testflight.apple.com/join/Qsvxk5Mh What is it: https://leok7v.github.io/ChatOKF/ Open Source: https://github.com/leok7v/ChatOKF A capable AI assistant that lives on your iPhone and iPad. The model runs on your device's own chip, so nothing you type is uploaded and nothing is logged. Once a model is downloaded, ChatOKF works in airplane mode. No account. No sign-in. No subscription. No ads, no analytics, no telemetry. WHAT YOU CAN DO Ask anything: check the math on a loan, plan a week of dinners, untangle a confusing letter. Show it a picture: a photo of a menu, a street sign or a whiteboard, straight from your library. Some models also listen to audio and watch video, frame by frame. Hand it a document: a PDF, a Word file or a spreadsheet. It reads the tables inside and answers from the file, and one tap opens the page to check it. Watch it think: the stronger models reason before they answer. Read the reasoning, tap Quick Answer to cut it short, or switch thinking off for speed. Let it look things up: Wikipedia, today's headlines, the weather and web search are tools it can use, each behind its own switch. Keep going: it suggests a sensible next question; swipe right to ask it. Keep what it gives you: answers are typeset, tables and mathematics included. Search and rename your chats, share one as a PDF, and bring a deleted chat back within thirty days. Talk instead of typing: tap the microphone and speak, and have replies read aloud in one of eight voices made on your device. MEMORY YOU CAN READ Tell it to remember something and it writes a short note, and the chat says what it wrote. Later questions are checked against your notes first, whichever model is answering. Every note is listed under Memories, to read or to delete. One switch, Total Recall, turns it all off. WHERE YOUR WORDS GO Nowhere, unless it looks something up. With Wikipedia on, your question is matched to an article on your device and only that article is downloaded. With web access on, the model's search terms go to a search engine and the pages it chooses are fetched. Settings, Privacy says exactly what leaves your device for each one. PICK YOUR MODEL Several open models are offered, and the list shows only what your device can hold, so every one you see will run. Gemma 4 E2B and E4B: they see pictures, hear sound and watch video. Qwen3.5 2B and 4B: good with tools and longer answers. Ternary Bonsai 1.7B: small and fast, for devices with less memory. GOOD TO KNOW The first launch downloads a model, from about half a gigabyte to a few gigabytes. Use Wi-Fi; after that, no network is needed. Devices with more memory are offered stronger models, and newer chips answer faster. Answers are generated and can be wrong. Check anything that matters. ChatOKF is written in Swift on Metal, and its source is on GitHub. Models are provided by their authors under their own licenses, including the Gemma Terms of Use.

The UI only says "There was an error processing your request". The network response is: POST /iris/v1/betaAppReviewSubmissions → 422 ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING In Business → Agreements, all agreements are active and there is nothing left to accept. The build is processed and valid. Re-uploading, bumping the version and creating a new app version change nothing, so it looks like the account's beta contract flag didn't update after renewal. We contacted Developer Support over a week ago (Distribution → TestFlight) and haven't heard back. Could someone from Apple check the account's beta contract status or pass this to the App Store Connect team? Error ID: c9e61135-7a2f-4f52-bc39-bd3437d94440

I am trying to add testers to External Tester groups for a couple of our iOS apps and after adding them it shows "No Builds Available". This is despite the app being available to that External Tester group with other people having already installed the latest version of the app which is "Available" and not expired. Can someone please fix this? It is so frustrating the number of times I try and release apps to TestFlight and there's some issue blocking me, completely out of my control and I have to rely on someone at Apple fixing something on this terrible AppStoreConnect system.

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, I’m trying to test an independent watchOS app on an Apple Watch Series 6 Cellular that is set up for a child using Apple Watch For Your Kids (Family Setup). My current environment: Apple Watch Series 6 Cellular watchOS 26.6 The Watch is set up for a child using Apple Watch For Your Kids / Family Setup Xcode 26.6 Parent iPhone running iOS 27.0 Developer Mode is enabled on the parent iPhone The Family Setup Watch does not appear as a development device in Xcode/CoreDevice There is no Developer Mode option visible on the Family Setup Watch For comparison, I also have another Apple Watch used for normal development, and that Watch can be detected by the development environment. The issue appears specific to the child’s Family Setup Watch. I would like to understand the Apple-supported development and testing workflow for this configuration. Specifically: Is an Apple Watch set up using Apple Watch For Your Kids / Family Setup expected to be available as a direct Xcode development device? If direct Xcode deployment is not supported, can an independent watchOS app be installed and tested on a Family Setup Watch through TestFlight? If TestFlight is supported, what is the correct workflow for installing the beta on the child’s Family Setup Watch / child Apple Account? Is there another Apple-supported testing or distribution method developers should use for this scenario? I’m specifically asking about an independent watchOS app that can operate without the parent iPhone nearby, rather than a Watch app that depends on an iPhone companion app. I’d also appreciate clarification on the distinction between direct Xcode development deployment and TestFlight/App Store distribution for Apple Watch For Your Kids. Thank you.

Hi there, Recently I've created a beautiful drink logging app, Abvy. You log what you drink and it shows an estimate and a possible range of the alcohol in your system over the evening. It has plenty of disclaimers that the measurements are only estimates and to never use them for driving decisions Since 26 August I've had the same rejection six times: "marketed as a blood alcohol content calculator but does not have associated hardware... apps that rely solely on software... are not appropriate." Meanwhile Beta App Review approved all the builds submitted. I had an App Review appointment today. The rep read the same paragraph back to me and said to appeal, which I've done. It was really frustrating. The published 1.4 doesn't mention blood alcohol at all, and university and public-health apps with the same kind of estimate are on the store today (Stay in the Blue from the University of Michigan, Virtual Bar from the Foundation for Advancing Alcohol Responsibility). Not to mention dozens of other, apps who do the exact same thing but are approved. Has anyone actually got past this on the App Store side? What changed for you? What can I do to fix this? Really care about Abvy and think it's an amazing app.

SUMMARY TestFlight installation and external beta review submission are blocked for ITNRY. External submission returns ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING through both the App Store Connect website and the public App Store Connect API. Apple Developer Support case: 102968975728 Submitted: 19 September 2026 I have not yet received a response. APP AND BUILD DETAILS App: ITNRY: Private Trip Planner App Store Connect app ID: 6747810116 Bundle ID: com.c0defr1ft.ITNRY Version 5.5, build 1: Build ID: ace0e146-a828-49cd-8773-351f12dfc4b0 buildAudienceType: APP_STORE_ELIGIBLE processingState: VALID expired: false Version 5.5, build 2: Build ID: 4cb01458-8df0-44f5-810c-5a9769a2980d buildAudienceType: INTERNAL_ONLY processingState: VALID expired: false The external review submission described below uses build 1, NOT the internal-only build 2. STEPS TO REPRODUCE — APP STORE CONNECT Open ITNRY → TestFlight. Add version 5.5, build 1 to an external testing group. Complete the requested test information. Select Submit for Review. Actual result: “There was an error processing your request. Please try again later.” The failed network response contains: HTTP 422 ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING “Beta contract is missing for the app.” STEPS TO REPRODUCE — PUBLIC API Send an authenticated request to: POST https://api.appstoreconnect.apple.com/v1/betaAppReviewSubmissions Request body: { "data": { "type": "betaAppReviewSubmissions", "relationships": { "build": { "data": { "type": "builds", "id": "ace0e146-a828-49cd-8773-351f12dfc4b0" } } } } } Actual response: HTTP 422 { "errors": [ { "id": "d916bbd9-4cff-4a05-8f0c-7432ec8db5d3", "status": "422", "code": "ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING", "title": "Beta contract is missing for the app.", "detail": "Beta Contract is missing." } ] } Request ID: EYMVAZWCULILULIFKLQDUQ5DXI Timestamp: 19 September 2026, 17:32:43 UTC ADDITIONAL SYMPTOM — INTERNAL TESTFLIGHT The build is visible in TestFlight, but installation fails with: “The requested app is not available or doesn’t exist.” The iPhone’s Media & Purchases account matches the account assigned as an internal tester. TestFlight has also displayed an old email address previously associated with the same Apple Account. It is unclear whether this is related to the contract error. DIAGNOSTIC CHECKS ALREADY COMPLETED GET /v1/apps/6747810116/betaLicenseAgreement returns HTTP 200 and the following betaLicenseAgreements resource: 8289bafa-8347-4a7a-a2b4-86b580758220 Listing betaLicenseAgreements filtered by this app also returns that resource. Its agreementText was initially empty. As a troubleshooting attempt, I successfully populated it through the API and verified that the change persisted. External submission still returned the identical BETA_CONTRACT_MISSING error afterward. This establishes that the per-app betaLicenseAgreement resource exists. It does not establish whether that resource is the contract referenced by the submission error. EXPECTED RESULT An authorized internal tester should be able to install the assigned build. An eligible external build should submit for beta review, or App Store Connect should identify a specific outstanding requirement and provide an actionable way to resolve it. IMPACT AND REQUEST The issue blocks TestFlight installation and external beta review submission. Please investigate the contract validation/provisioning state for this app/account, identify which contract is reported missing, and advise whether any developer action is required. Please also determine whether the internal installation failure shares the same cause. Please link this report to Developer Support case 102968975728.

We recently completed an app transfer between two Apple Developer Program teams. Before releasing the first post-transfer version, we need to verify the update behavior from several specific historical versions signed by the previous team. Our main question is not limited to TestFlight: we would like to know Apple's recommended and supported method for reproducing this update path. Could you clarify the following? What is Apple's recommended and supported method for testing an update from a specific pre-transfer version to the first post-transfer release? Can an archived Ad Hoc IPA signed by the previous team be used as the starting version for this test? Can that IPA be updated by a post-transfer TestFlight, Development, or Ad Hoc build signed by the recipient team? Which of these methods most accurately reproduces an App Store update after an app transfer? For a manual Development or Ad Hoc update, is the previous-application-identifiers entitlement required? If it is required, how should the recipient team request a provisioning profile that authorizes this entitlement? Thank you.

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.

Hi, I'm a new Apple Developer program member and over about a 10-day period, I have been blocked from beta testing my app. I have been getting repeated 422's about a TestFlight Beta contract not attached to app 6812131455 . I submitted a Feedback Assistant ticket, FB24795679, where an engineer replied and said things were unblocked. I believe that I was able to get one more build uploaded after that but then the problem recurred and completely blocked me from sharing the TestFlight External beta link with new testers. I am uploading using the Transporter App and then trying to attach in Appstore Connect. I emailed Apple Developer support and they sent me only basic information about what 4xx HTTP status codes were, so I followed up via phone to Developer Support under ticket 102964195981. I've been calling over the past 3 days and a Senior Advisor has not picked up the ticket yet. Diagnostic information is below, including a sanitized HAR file. The error is reproducible, even with new builds, even with going through and confirming all requested data input fields are filled out and agreements are signed (to the best of my knowledge). I am developing an ad-free, free app with a focus on accessibility for the visually impaired. Can someone help me find a durable solution here? Much appreciated--I see others have had this issue. Happy to capture further debug logs to assist in a fix. captured_at_utc source build_number method url http_status error_code error_id x-apple-jingle-correlation-key x-apple-request-uuid x-responding-instance 2026-09-24T15:07:48.547415+00:00 live 116 POST /iris/v1/betaAppReviewSubmissions 422 ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING 7ef85ee6-412e-4535-b8f7-16cb8da406c8 5QSUAQZ4MOELPIGMJXUJD4UBP4 ec254043-3c63-88b7-a0cc-4de891f2817f ac-gateway-api:ac-gateway-api-main-5d674cb558-bp79n:ac-gateway-api-main-5d674cb558-bp79n:-1::::prod failures-422.md failures.jsonl failures.md session.sanitized.har

Hi, Since mid-September 2026 TestFlight is completely blocked for my account, even though my app is live on the App Store and all agreements are active. Symptoms No tester (internal or external) can install any build. TestFlight shows: "Could not install Beavo. The requested app is not available or doesn't exist." A newly added internal tester sees "No Builds Available" in App Store Connect. Submitting any build to Beta App Review fails with HTTP 422: { "errors" : [ { "status" : "422", "code" : "ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING", "title" : "Beta contract is missing for the app.", "detail" : "Beta Contract is missing." } ] } Request UUID: 911b4c7a-1c7f-5b75-5c49-bcf26292fb18 (24 Sep 2026, 16:16 GMT) What I've verified Paid Apps Agreement: Active (Jun 2026 – Jun 2027) Free Apps Agreement: Active (regenerated Aug 19, 2026) Bank account, W-9 tax form and DSA compliance: Active I'm the Account Holder / Admin Builds (1.4.0 (13) through 1.5.0 (20)) are VALID, not expired, min iOS 26.0 ITSAppUsesNonExemptEncryption = NO is in Info.plist (no Missing Compliance) Test Information complete (description, feedback email, marketing and privacy policy URLs, Beta App Review contact) The last builds approved for external testing were in July 2026; nothing since then can be submitted This looks like the same backend issue reported in threads 814565 and 815885, where the Beta Contract entity was not re-provisioned after the agreements were regenerated, and it was fixed by an Apple engineer manually. App details App: Beavo – Apple ID 6781859321 Bundle ID: com.invntio.beavo Team ID: P4C48NFAHR I've also opened a case with Developer Support. Could someone from Apple please re-provision the Beta Contract for this account/app? Thanks!

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.

I see different storefronts in StoreKit product queries and Apple’s purchase sheet when testing through TestFlight. Xcode-installed builds work normally. iPhone — iOS 26.6 (23G71), US Media & Purchases account Both StoreKit 1 and StoreKit 2 return CHN/CNY. The app displays CNY 128 for a non-consumable, but Apple’s sandbox purchase sheet shows USD 29.99 for the same product. This reproduces in a standalone 177-line Swift sample using Product.displayPrice directly, with no third-party dependencies, currency conversion, or local .storekit configuration. Reloading products and signing out of the sandbox account did not resolve it. Mac Catalyst — macOS 26.3 (25D125), China purchase account The original TestFlight app returns USA/USD. Purchasing shows “Account Not In This Store” and asks to switch to China, although the purchase account is already set to China. The Mac symptom has not yet been verified in the standalone sample. Reproduction on the affected iPhone: install via TestFlight, load products and log Storefront.current plus the SK1 storefront, open the purchase sheet for the same product, then compare currencies. No completed purchase is needed. Built with Xcode 26.1 (17B55). Has anyone found a workaround for this TestFlight-only mismatch? Should the app handle storefront updates differently, and which additional diagnostics would help distinguish a device/account-session issue from a StoreKit service issue? Feedback: FB24873070. A focused sample and diagnostic evidence are prepared for Apple Developer Technical Support. Reproduction on other devices/accounts is not yet confirmed.

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, I’m looking for some advice regarding a TestFlight Beta App Review issue. My app, MyStory, was rejected twice under Guideline 2.1(a) with the same general message: App Review was unable to successfully access all or part of the app. In the first review, Apple specifically asked us to provide a demo account with content demonstrating the app’s functionality. We followed those instructions for Build 3: • Created a dedicated demo account with sample content in all four sections. • Added the username and password under Beta App Review Information. • Added testing instructions. • Replied to App Review with the credentials and instructions. Build 3 was nevertheless rejected again under the same Guideline 2.1(a), without specifying which part of the app was inaccessible. We have tested the app and the demo account ourselves, and everything works as expected on our devices. The app can also be used without an account, and users can create an account directly within the app. We have now replied to App Review asking them to identify the specific screen, step, or functionality they were unable to access. We are currently waiting for a response. Has anyone experienced a similar situation? In particular, I would appreciate advice on how to get a more specific explanation from App Review, or whether there is an appropriate way to escalate the issue if they cannot identify what was inaccessible. I’m also wondering how reliable the 24-hour response timeframe is in practice. It has now been more than a day and a half since I replied to App Review. Should I expect a response within a few days, or can Resolution Center replies sometimes take considerably longer? Thank you.

BoltSense is a puzzle game where you tap bolts off a real 3D V8/inline-4 engine and sort them into color/shape-matched trays as it tears itself down layer by layer. Solo-built, first time opening it up to anyone outside my own family. I know this is flooded market; I got tired of pay to win platforms and wanted to build something better. Feedback I'm especially looking for: First few minutes — is it clear what to do with zero instructions? Where did you get stuck, if anywhere? Bolt shapes — can you tell hex bolts from round ones apart quickly while playing, or are you mostly going by color? Difficulty — does the first engine feel too easy, too hard, or about right for an opening puzzle? Considering that I have tested this with my 7 and 9 year old and they picked it up pretty easily following minimal instruction. Crashes, hangs, visual glitches — and what iPhone/iOS version you were on when it happened please! Public link: https://testflight.apple.com/join/YMpvN6bP Appreciate anyone willing to give it a shot — feedback straight through TestFlight works great for me. *I only have this set at 1000 testers I'm hopeful to see 10-20 maybe! Thank you!

Typical is an iOS app with a custom keyboard extension for high value salespeople: luxury real estate, yachts, cars, watches. The app stores clients, assets and conversation history. The keyboard shows the relevant client context inside WhatsApp while the user types, so they can answer specific questions without leaving the conversation. Feedback I am looking for: Keyboard onboarding: enabling the keyboard and granting Full Access. Is the warning off putting? Is the reason for Full Access clear enough? Client recap screen: is it understandable the first time it appears? Stability and performance: crashes, freezes, input lag in the keyboard. F eedback through TestFlight is preferred. https://testflight.apple.com/join/5yx5EDg5

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?

We are testing version 1.0 Build 29 through TestFlight after a Guideline 2.1(b) rejection: Purchase did not respond on iPad Air 11-inch (M3). Paid Apps Agreement is Active, and subscription price, availability, localization and review screenshot are present. Restores worked, but a fresh purchase is not yet verified. On iPhone 13, Build 29 is installed, Developer Mode is on, and Media & Purchases was signed out. The tester reports signing into Developer > Sandbox Apple Account, then trying to sign into the app. During this sequence an email verification prompt was followed by: "iTunes account creation not allowed. This Apple account cannot be used with iTunes Store at this time. Please try again later." The app uses Sign in with Apple separately from StoreKit. We have not isolated which system authentication flow produced the error. What is the supported sequence for regular iCloud/Sign in with Apple alongside a Sandbox Apple Account for TestFlight purchases? Which diagnostics distinguish account setup failure from app authentication or StoreKit failure? Should we escalate through Feedback Assistant or Developer Support, and which logs should accompany the report? We want to verify a fresh purchase on an 11-inch iPad before resubmission.