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 channelyou can share your TestFlight Public Links with the developer communityto gather valuable feedback on crucial elementslike technical implementationuser experiencedesignand more. To maximize the benefits of posting TestFlight Public Links in the Developer Forumshere are some best practices to keep in mind: Provide details: Give comprehensive information about your applike new features and test casesand note specific areas where you seek feedback. The more detailed your post isthe 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.

Hello, I'm sure I've probably missed a checkbox somewhere.. I have a mulitiplatform appwhen building from Xcodeand not using the testing configboth iOS and macOS show the correct App Store currency.. When I distribute a build through TestFlightmy Mac version shows a different country/currency price (the US one). I can't find anywhere to change this. My Mac is signed into the same sandbox account as my iOS device. Can anyone help?

My app has in app purchase for subscriptionsavailable in many countries. When using Sandbox App Store accounts on TestFlight with a locale different from my own in the iOS 26 RCI'm getting incorrect currency coming back from Product.products(for: identifiers)and so my app displays the wrong price for the locale. Howeverthe actual Apple Pay buy sheet shows the proper currency symbol and currency amount. This did not happen on prior versions of iOS. Is anyone else experiencing this?

I have an app clip installed via TestFlight. My AASA file is configured correctly (per 'Domain Status' in TestFlight). I want to be able to run the app clip flow (app clip card showing and app clip card launched) by invoking UIApplication.shared.open(url) from a different appor by pressing the URL from notes app. This doesn't seem to work. The only thing I am able to do is run the flow when scanning a proper QR code after configuring Local Experience with the matching parameters. But as stated abovethe flow will not work when invoking the URL from a different app. Is the proper way to fix this is to define an HTML page for that URL path that contain the element with app-clip-bundle-id attribute that will match the Local Experience configuration? Is there another way to make this flow work with TestFlight releases? what are my options?

Hello, I’d like to share an issue we recently experienced with TestFlight and ask whether this behavior is expected. Environment App version string: 1.0.0 Multiple builds uploaded via CI/CD Both external TestFlight testing and internal CI builds exist Testers had automatic updates enabled in TestFlight What happened We uploaded build 1.0.0 (2601161653) and assigned it to an external TestFlight group. Testers installed this build and were testing normally. Laterwe uploaded a newer build 1.0.0 (5) and reassigned the same external testers to this build. Testers successfully updated to 1.0.0 (5) and continued testing. After some time (without any manual action from testers)testers received a system notification saying that: “The App has been updated. Version 1.0.0 (2601161653) was automatically downloaded and installed.” When opening TestFlightthe app showed 1.0.0 (5) again as available for updatemeaning the device had already been rolled back to 1.0.0 (2601161653). Additional context There are many archived builds in App Store Connect due to CI/CD testing. Some CI builds share the same version string but differ only in build number. External test groups were only explicitly assigned to build 1.0.0 (5) at the time of the rollback. Build 2601161653 did not have any external test group assigned at that moment. No App Store release or metadata changes occurred during this time. Questions If a tester’s currently installed build becomes temporarily unavailable (e.g. due to eligibilityinternal status changesor TestFlight processing), does TestFlight automatically fall back to a previously approved build? Is this automatic rollback behavior an intended part of TestFlight’s build availability logicespecially when multiple builds with the same version string exist? Can frequent CI/CD uploads (without consistent external group assignment) influence which build TestFlight considers “eligible” or “latest” for testers? Summary From our observationit appears that when the currently tested build temporarily lost eligibilityTestFlight automatically installed a previous build that was still considered availableeven though a newer build existed. We’d appreciate any clarification on whether this behavior is expected or if there are best practices to avoid this situation when using CI/CD with TestFlight. Thank you.

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 buildsneither 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 thisinstallation 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 contactedbut 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 onceor an install failure after replacing expired builds

Hi there, When I build my app in Xcode using a synched AppstoreConnect Storekit filewhen using subscriptionsI am sent to the correct (for me) UK store to purchase a subscription. However when using the same build as a TestFlight App I am presented with the US store.. If I try to purchase a $ subscription I get the error: Account not in this store Your account is not valid for use in the U.S. store. You must switch to the U.K. store before purchasing If I try to use the presented Change App Store button - I get Unable to Complete request Error My AppStore on my Mac is set to the UK store.. How can I get the TestFlight version to present the correct store locale? Many thanks!

Hello everyone. We have an app that has been on the App Store for several yearsoriginally distributed for iOS and iPadOS only. Recentlywe enabled Mac (Designed for iPad) and started distributing macOS-compatible builds. Current situation: The app is available and downloadable from the macOS App Store and runs correctly on Apple Silicon Macs. The same app/build appears in TestFlight on macOSbut cannot be installed. TestFlight shows the message: “This app can only be tested on an iOS device.” This suggests the app itself is Mac-compatiblebut TestFlight is treating the build as iOS-only. Environment and checks performed: Mac is Apple Silicon. App Store Connect app-level availability for Mac (Designed for iPad) is enabled. The app is not Mac Catalyst; it is a UIKit iOS/iPadOS app. Distribution is done via GitLab CI. CI uploads use an App Store provisioning profile (Apple Distribution)not development or ad-hoc. iPhone and iPad TestFlight installs work as expected. Info.plist verification: UIRequiredDeviceCapabilities was originally present (armv7) and has since been: removed entirely, build number incremented, new builds uploaded to TestFlight. No other hardware capability requirements are declared. LSRequiresIPhoneOS = true remains unchanged. No other plist keys that should exclude macOS are present. CI / build considerations: The same uploaded build is accepted by App Store Connect and distributed successfully on the macOS App Store. This tells us the binary itself is valid for macOSbut TestFlight applies additional or different eligibility checks. At the moment we think that TestFlight eligibility may depend on build metadatascheme/configuration flagsor internal App Store Connect state that differs from App Store distribution. Questions: Are there known cases where a build is valid for macOS App Store distribution but not eligible for macOS TestFlight installation? Does anyone know if TestFlight applies stricter or different platform gating than the App Store for “Mac (Designed for iPad)” apps? Are there specific build settings (e.g. SUPPORTS_MAC_DESIGNED_FOR_IPADTARGETED_DEVICE_FAMILYscheme/config mismatches) that can affect TestFlight macOS eligibility independently of App Store eligibility? Is there an authoritative way in App Store Connect to inspect why a specific TestFlight build is marked as “iOS-only” for macOS? Any insight into TestFlight-specific eligibility rules for “Mac (Designed for iPad)” would be appreciatedespecially given that App Store distribution for macOS is already working. I hope we're missing something very basicand not that the app can't be tested as is for the macbecause it's useful to have our QA team test it on the mac.

SKStorefront.countryCode always returns "US" in TestFlight and sandbox, even when sandbox Apple ID is set to a different country. Is this expected behavior? Is SKStorefront guaranteed to return the correct storefront only for production App Store builds?

Hello everyoneI achieved my MacOs app and distributed for "App Store Connect" and I already have setup the Product In App Purchase in the App Store connectand I even tested the purchase flow using the local .storekit file using the "Edit Schema". And nowwhen I remove the edit scema's storekit file and archieved the app and used the Internal testing and installed the app using TestflightI see that the product is not showingan empty product array is being returned and there is no option to purchase. I don't want to sumit the full app until I test the StoreKit integration in real test

I'm using StoreKit 2 with Product.products(for:) to fetch my auto-renewable subscriptions. It works in the Xcode simulator with a local StoreKit configuration filebut returns an empty array (no error) in TestFlight. iOS 15+using async/await API Products are configured in App Store Connect Paid Apps agreement is active Sandbox tester account set up Has anyone experienced this? What am I missing?

I’m having an issue installing my TestFlight build on a Mac. The build (v1.0 build 1) uploads successfully and shows as “Complete” in App Store Connect. I can also open the build details pageand my Apple ID / tester access / group setup looks correct. Howeveron TestFlight (macOS)when I tap Install/LoadI get this error: Unable to install. The requested app isn’t available or can’t be found. Notes: The app is an iOS app (iPhone + iPad)and I enabled availability for Mac (Designed for iPad) in App Store Connect. The Mac is Apple Siliconrunning macOS Tahoe 26.1. Could you help me understand why TestFlight shows this message on Macand what I should change in Xcode/App Store Connect to make the build compatible?

Hello, I was just installing an app from TestFlight that has an Essential Asset Pack that's a few GBs in size. It appears the Call To Action inside of TestFlight doesn't take into consideration the Background Asset download status before it changes from Installing to Open. I can't test if this is also the case for apps on the App Storebut I'd expect that it is.

I’m hitting a persistent conflict between my Business (Managed) Apple ID and my personal Apple ID when trying to use TestFlight. My Business ID is correctly tied to App Store Connectbut the device always forces TestFlight to associate with my personal Apple ID. When I try to “Review” the Business ID in the App StoreI get the endless loop: “This Apple ID has not been used in the iTunes Store.” The review flow never completes. What I’ve already confirmed: Business/Managed Apple IDs cannot be activated for the App Store -Signing out of Media & Purchases doesn’t fix it -Tried on multiple devices - sign out - same behaviour -TestFlight still forces a personal Apple ID login even when everything else is configured correctly This looks like a reproducible conflict introduced by recent Apple updatesand it’s affecting Managed/Business Apple IDs across the board. Developer Support hasn’t provided a single actionable response despite multiple tickets which is unacceptable for a paid service. Has anyone found a reliable workaround solution for this problem ? THANK YOU in advance !!

Hi all, We can’t install our app from TestFlight. The app is visible in TestFlight for invited internal testersbut tapping Install fails immediately with: “The requested app is not available or doesn’t exist.” --Setup-- Distribution: TestFlight – Internal Testing Internal group created and testers added (invite accepted) Build processing status in App Store Connect: Complete TestFlight build status shows: Ready to Submit / Prepare for Submission Minimum iOS deployment target: iOS 15.0 Version/Build: 1.0.0 (1) What we tried Confirmed tester is signed into TestFlight with the same Apple ID email that was invited Removed/added testers to the internal group and resent invites Reinstalled TestFlightsigned out/in Verified build is assigned to the internal group Set and saved Monetization → Pricing and Availability → App Availability (All Countries/Regions) Question Has anyone resolved this issue? Is there a known TestFlight/App Store Connect stuck state that causes this error even for internal testing? Any recommended steps (new build numbergroup resetavailability/pricing settingsetc.)? Screenshots available (TestFlight error + App Store Connect build/group view). Thanks.

Keep getting an error saying the tester has 'an invalid name or email address and wasn't added'. Never had this problem until maybe 1 - 2 days ago. Please fix I am unable to publish new builds to my early access users.

Hello, My TestFlight build (version 1.0.4build 10) shows as "Complete" in App Store Connect but does not appear in TestFlight. here is the link: https://drive.google.com/file/d/1su6cXk35X4bx2uzLW7aXIliAKKNfDYAe/view?usp=sharing Multiple uploads were attemptedand earlier builds processed successfully. Thank you.

Hello, I am experiencing an issue with TestFlight that I have not been able to resolve. Problem description One dayI suddenly became unable to update our app from TestFlight using my tester account. Assuming it might be a permission issueI removed my tester access for the app and then re-invited the same Apple ID. After doing thisthe situation became worse: I can no longer install the app at all via TestFlight. What I have already tried I have attempted all of the following multiple times: Removing and re-adding tester access in TestFlight Deleting and reinstalling the TestFlight app Installing the app via a new invitation link Installing the app via an invitation code None of these attempts worked. Error message Every attempt results in the same error message: Unable to Load App This invitation is not associated with the Apple Account you’re currently signed in with (me [at] example [dot] com). Sign in to TestFlight with the original Apple Account (me [at] example [dot] com) or ask the developer for a new invitation. Why this seems incorrect The error message suggests that the Apple ID signed into TestFlight does not match the invited account. HoweverI am using the exact same Apple ID for: TestFlight Apple ID (device iCloud account) App Store There is no account mismatch. Everything is logged in with the same Apple ID (me [at] example [dot] com). At this pointI am completely blocked and cannot proceed with testing or updates. Question Is there a known issue where removing and re-adding tester access can permanently invalidate an Apple ID for a specific TestFlight app? Is there any way to reset or clear the tester state for an Apple ID on Apple’s side? Any guidance or insight would be greatly appreciated. Thank you.

I'm stuck in an impossible situation with DeviceActivityReportExtension on iOS 18. THE ISSUE: Configuration that works on device (iOS 18.2): Info.plist has only NSExtensionPointIdentifier Swift code uses u/main attribute App installs and runs perfectly Extension works correctly App Store validation FAILS: "Missing NSExtensionPrincipalClass" Adding NSExtensionPrincipalClass (as validation requests): Device installation FAILS with Error 3002 Error says: "NSExtensionPrincipalClass key is not allowed for this extension point" Cannot test on device Validation would likely pass ENVIRONMENT: Xcode 16.2 iOS 18.2 Extension point: com.apple.deviceactivityui.report-extension EVIDENCE IT'S WIDESPREAD: Apple Forums (3 days ago): https://developer.apple.com/forums/thread/812380 Stack Overflow (1+ year): https://stackoverflow.com/questions/77866230/ ROOT CAUSE: iOS 18 changed this extension to use u/main pattern (no NSExtensionPrincipalClass needed). App Store validation hasn't been updated and still expects iOS 17 configuration. WHAT I'VE TRIED: ✅ All deployment targets set to iOS 18.3 ✅ Code follows Apple's WWDC 2022 guidance ✅ All entitlements correct ✅ Info.plist validated ✅ Clean builds ✅ Works perfectly on device No configuration satisfies both device runtime AND App Store validation. Has anyone successfully uploaded an app with DeviceActivityReportExtension to TestFlight on iOS 18? Any workarounds? This is blocking TestFlight deployment completely.

We submitted a build to testflight and received a confirmation email it was successfully uploaded. When we open testflight on our iPhone's (X6s) we get a message of "Could not install appname" "The requested app is not available or does not exist" Where appname is the name of the app. Its very confusing because I can see the build listed in testflight on my mobile device and can view it in iTunes connect. I also can't install prior builds that had worked successfully when I try.

We're developing an Electron app for MacOS App Store. When updating our app through TestFlightTestFlight prompts "Close This App to Update"and when I click "Continue" our app would be "Terminated" for update. Now this is where things go wrong. On MacOS 15 our app seems to be gracefully terminating (We attached it with lldb and it shows that our app returns with 0 when we click "Continue") which is fine. However for MacOS 26 thoughit seems that TestFlight just directly SIGKILLs our app (indicated by lldb)which means that all of our app's child processes are left orphaned. Even worseour app is singletonwhich means that when the app relaunches it failsbecause the leftover child processes from the previously SIGKILLed session is still aliveand even if we want to kill those orphaned child processes we can't because our app is sandboxed thus cannot kill processes outside of the current sandbox. We captured output from log stream (app name redacted): 12-02 22:08:16.477036-0800 0x5452     Default     0x5a4a7              677    7    installcoordinationd: [com.apple.installcoordination:daemon] -[IXSCoordinatorProgress setTotalUnitsCompleted:]: Progress for coordinator: [com.our.app/Invalid/[user-defined//Applications/OurApp.app]]Phase: IXCoordinatorProgressPhaseLoadingPercentage: 99.454 123: Attempt to set units completed on finished progress: 214095161 2025-12-02 22:08:16.483056-0800 0x53ba     Default     0x5a5c9              167    0    runningboardd: (RunningBoard) [com.apple.runningboard:connection] Received termination request from [osservice<com.apple.installcoordinationd(274)>:677] on <RBSProcessPredicate <RBSProcessBundleIdentifierPredicate "com.our.app">> with context <RBSTerminateContext| explanation:installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N re portType:None maxTerminationResistance:Absolute attrs:[ 2025-12-02 22:08:16.488651-0800 0x53ba     Default     0x5a5c9              167    7    runningboardd: (RunningBoard) [com.apple.runningboard:ttl] Acquiring assertion targeting system from originator [osservice<com.apple.installcoordinationd(274)>:677] with description <RBSAssertionDescriptor| "installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N" ID:167-677-1463 target:system attributes:[ 2025-12-02 22:08:16.489353-0800 0x53ba     Default     0x5a5c9              167    0    runningboardd: (RunningBoard) [com.apple.runningboard:process] [app<application.com.our.app.485547.485561(501)>:2470] Terminating with context: <RBSTerminateContext| explanation:installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N reportType:None maxTerminationResistance:Absolute attrs:[ 2025-12-02 22:10:23.920869-0800 0x5a5a     Default     0x5a4c6              674    14   appstoreagent: [com.apple.appstored:Library] [A95D57D7] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} 2025-12-02 22:10:32.027304-0800 0x5ae5     Default     0x5a4c7              674    14   appstoreagent: [com.apple.appstored:Library] [BEB5F2FD] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} 2025-12-02 22:10:36.542321-0800 0x5b81     Default     0x5a4c8              674    14   appstoreagent: [com.apple.appstored:Library] [185B9DD6] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} The line "Terminating with context" seems suspicious. This line is not seen on MacOS 15only MacOS 26. Is this documented behavior? If sohow can we handle this?