TestFlight Public Links are a great way to share beta versions of your apps with other members of the Apple Developer Program. With this new channel, you can share your TestFlight Public Links with the developer community, to gather valuable feedback on crucial elements, like technical implementation, user experience, design, and more. To maximize the benefits of posting TestFlight Public Links in the Developer Forums, here are some best practices to keep in mind: Provide details: Give comprehensive information about your app, like new features and test cases, and note specific areas where you seek feedback. The more detailed your post is, the better equipped the community will be to provide insight. Select platforms: Select the platforms that your beta app supports. Enter categories: Enter the App category you’ve selected or plan to select for your app on the App Store. Categories are critical to ensuring your post can be easily found by interested users. Stay connected with notifications: Enable web and push notifications so you’ll know when you receive feedback on your post. Note: The TestFlight app is still the most comprehensive way to gather feedback. This space is meant as a helpful secondary channel.

I'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 (X, 6s) 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 TestFlight, TestFlight 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 though, it 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 worse, our app is singleton, which means that when the app relaunches it fails, because the leftover child processes from the previously SIGKILLed session is still alive, and 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: IXCoordinatorProgressPhaseLoading, Percentage: 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 15, only MacOS 26. Is this documented behavior? If so, how can we handle this?

My app has never been associated with my personal Apple ID - this is exactly why I use a Business/Managed Apple ID for all development‑related work. However, after the most recent apple updates, TestFlight has started creating conflicts between these accounts. Current situation: The App Store is correctly linked to my personal Apple ID, as expected. TestFlight, which should be tied to our Business/Managed Apple ID for internal testing, is now incorrectly linked to my personal Apple ID. App Store Connect and our developer account remain correctly associated with the Business/Managed Apple ID. I should not be required to sign out of my personal Apple ID on the device just to use TestFlight with the Business/Managed Apple ID. This has never been required before, and signing out risks data loss if a full backup hasn’t been done. Attempting to switch accounts inside TestFlight results in an “internal error,” making it impossible to redeem TestFlight codes or continue our testing workflow. I’ve already tried deleting our app, deleting and reinstalling TestFlight and removing all personal email accounts associated with Apple Developer. TestFlight still forces the personal Apple ID. If anyone has any recommendations other than signing out of my personal account, I would really appreciate it. Thank you!

I recently submitted an app for external testing via TestFlight, but it has been stuck at the "Waiting for Review" status for several weeks. This delay is blocking our testing process and impacting our development timeline. Could you please look into this issue and provide an update on the review status? Thank you for your support.

Hi, I really need help to resolve the issue with submitting build made with 26.2 for review to release TestFlight build to external testers. I'm always getting "This build is using a beta version of Xcode and can’t be submitted". I tried everything from cleaning DerivedData to fully reinstalling Xcode and tools to 26.2. Even tried earlier Xcode release versions and after pressing Submit for review I always face the same issue. Nothing helps and I can't share my first app with volunteers to test. By Jan 6 2026, my Xcode 26.2 is up to date with App Store and in Xcode Organizer I choose App Store Connect and press Distribute.

Hello, I am unable to submit ANY of my apps for External TestFlight review. Every time I try to add a build to an external group and press "Submit for Review", I immediately get this error: "There was an error processing your request. Please try again later." This happens on multiple apps in the same account: LM Mobile (Apple ID: 6755979316) TPM Mobile (newly created app) All of the following have been verified and are active: Paid & Free App Agreements Banking & Tax forms App Privacy (Published) Test Information is fully completed Multiple clean builds uploaded (1.0.0 build 1 and 2) Correct distribution via App Store Connect selected in Xcode Admin + Account Holder role This clearly confirms that the problem is ACCOUNT-LEVEL on the backend. Case Number: 102766190091 Could an Apple engineer please check and reset the stuck External TestFlight submission state on the server side? Thank you.

Hello guys I’m unable to delete the Test Information and Beta App Information sections on Apple Store Connect. I need to remove them because the app transfer process requires it. I’ve already expired all builds, removed all testers and groups, and tried every possible solution I could find online, but nothing worked. I also contacted Apple Support, but the issue hasn’t been resolved. What should I do next?

Hello everyone, I achieved my MacOs app and distributed for "App Store Connect" and I already have setup the Product In App Purchase in the App Store connect, and I even tested the purchase flow using the local .storekit file using the "Edit Schema". And now, when I remove the edit scema's storekit file and archieved the app and used the Internal testing and installed the app using Testflight, I see that the product is not showing, an 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

Hello, I sent this in as a feedback several weeks ago about watchOS 26.2 beta 2 but since the issue is still active now that watchOS 26.2 is in production I'm reposting here for the community. I would also like to submit a DTS about this issue but honestly don't know the best way to go about it and would appreciate advice about that. There seems to be an issue with VPP distribution for our app on watchOS 26.2. When our watchOS companion app is launched after being installed through VPP to a supervised iPhone, it encounters a dyld error before main() or any application code is even called. The same app launches correctly in every other circumstance we could imagine and test: – Installed through VPP on supervised devices running watchOS 26.1. – Installed from the app store (using an apple id) on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2. – Installed through Testflight on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2. – Installed through the app store on unsupervised devices running watchOS 26.1 and 26.2. This strongly appears to be a VPP signing issue because we even did the following experiment: Install iPhone and Watch apps through the App Store on a supervised device pair running public iOS 26.2 beta 2 / watchOS 26.2 beta 2. Verify that both apps launch successfully. Use an MDM command to install from VPP over the existing installations Verify that the watch app fails to launch (the iOS app is unaffected) My feedback included some crash logs which I won't be reposting publicly here. Any feedback or ideas appreciated.

Hello- I'm new to this so I'm in need of some help. I've attempted to upload a number of versions of tiny apps I've been making to beta test with friends. However I am unable to install the app via TestFlight on my own phone and iPad. As I get the error message "The requested app is not available or does not exist." I've seen a lot of posts with the same problem but no fixes. I've been going through the Apple documentation and I can't figure out what I'm missing. Has anyone had this problem and solved it? I'm uploading to App Connect. I guess I'll try the straight to TestFlight option next. Any help is appreciated.

I have a Apple Developer accounts for development purposes only and that is also used for testing builds via TestFlight. Is the Age Ratings Responses updates due by the end of January 2026 still required even to send builds to TestFlight?

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?

Here are some tips from App Review for a smooth review experience. We’ve split them into two categories: Before You Submit and After You Submit. We’ve also made an easy-to-follow Submission Guide you can save and reference at any point on your App Store journey. Before You Submit Tips Enable a complete review. Make sure you’ve provided demo accounts or implemented an account demonstration mode before you submit. We’ll need to review the entire app experience, both with and without an account. Provide up-to-date demo account login credentials in the App Review Information section on the app version page in App Store Connect. If your app has multiple account types (such as admin and general users), use the Notes field to provide additional demo account credentials for each account type. If your app requires an authentication code in addition to the login credentials, provide the code in advance in the Notes field. Otherwise, a call may be required to complete the review. Apps that handle sensitive user information, or operate in highly regulated industries, can implement demonstration modes that exhibit full features and functionality while using demonstration data. Use the Notes field in App Store Connect to provide information to App Review. The App Review Information section of App Store Connect includes a Notes field. Provide any information that could be relevant to your submission’s review: Submitting a new app? Tell us about your app's concept, business model, and if your app is designed to only operate in certain locations. Submitting an update? Tell us about what’s changed and where to locate significant new content or features. Connecting to hardware? Attach a video, not a screen recording, that shows both the hardware and the app running on a physical Apple device as they pair and interact. Test your app on physical devices before submitting for review. Use TestFlight to distribute your app for beta testing. App Review evaluates apps the way your users will use them: installed on real devices and connected to networks with real-world conditions. Make sure your pre-submission testing includes running the app on each device platform where it could be used. Users expect the app to function on all the devices where it’s available. TestFlight will help you do quality assurance and beta testing on real devices. Share your beta app with internal testers on your Apple Developer Program account or to external users via an email invite or public link. Configure In-App Purchases for review in the sandbox environment. App Review assesses In-App Purchases in the same sandbox environment Apple provides for testing them. The sandbox lets us use real product data and server-to-server transactions, without incurring any financial charges. Take these steps to prepare your In-App Purchases for review: Accept the Paid Applications Agreement in App Store Connect. Submit the In-App Purchases in App Store Connect that you’d like reviewed. Follow the steps in TN3186: Troubleshooting In-App Purchases availability in the sandbox if your app fails to display your In-App Purchases. Note: In-App Purchases don’t need prior approval from App Review to function in review. Join a Meet with Apple event if you need assistance before you submit for review. Request an App Review appointment through Meet with Apple to chat with an App Review expert about how to prepare for review, ask questions about specific guidelines, and discuss other topics related to the review process. Appointments are subject to availability during your local business hours on Tuesdays and Thursdays. After You Submit Tips Contact App Review if you need assistance with an ongoing submission. If your submission doesn’t pass review and you have questions, contact App Review directly by clicking Reply to App Review in App Store Connect. You’ll receive a reply from a review specialist who’s familiar with your app. You can also use the Reply to App Review message window to request a call with an Apple representative. Include your preferred time and language for the call and we’ll do our best to accommodate your requests. Use the Bug Fix Submissions process to quickly deliver bug fixes and resolve other issues on the next submission. If an update includes bug fixes and is rejected, you will be given the option to resolve the issues on your next submission, as long as there are no legal or safety concerns. App Review will let you know if your submission is eligible by including this note at the top of the rejection message: Bug Fix Submissions The issues we've identified below are eligible to be resolved on your next update. To accept this offer, simply reply to the rejection message in App Store Connect and let App Review know you’ll resolve the issues on the next submission. Share ideas with Apple about how to improve or clarify the App Review Guidelines by submitting guideline feedback. Just as the App Store is always changing and improving to keep up with the needs of customers, the App Review Guidelines may be revised to provide new and updated guidance. If you have ideas for improving or clarifying our requirements you can suggest guideline changes. If your submission was rejected but you believe it follows the App Review Guidelines, consider submitting an appeal to the App Review Board. If your submission didn’t pass review but you have reason to believe it follows the App Review Guidelines, you can submit an appeal to the App Review Board. You can also file an appeal if you think we misunderstood your app or the review was unfair. The App Review Board will contact you as soon as they complete their investigation.

We are getting the above mentioned error while uploading to TestFlight. We have used a Swift Class to request for the Age Range via DeclaredAgeRange Framework. We have exposed Swift class and a helper function to be available in Objective-C layer. We have enabled the following build settings SWIFT_OBJC_INTERFACE_HEADER_NAME = "Common-Swift.h"; SWIFT_OBJC_BRIDGING_HEADER = "Common-Bridging-Header.h "; ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES Also we are compiling the application using latest available Xcode release 17C52 Is there anything else we need to do to resolve the error?

Hi all, I'm new to TestFlight and Apple Store Connect. I have pushed a build and it says "waiting for review". Do I have to do anything to put it into review? I'm trying to get this build out to external testers.

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 Store, but I'd expect that it is.

I am developing a simple watch app and I use my personal watch for development with Xcode. Personal watch is series 10 gps only. I have two other watches that I want to use for testing the app, but not needing them to be connected to Xcode. The test watches have cellular option, and I need a cell plan per watch because the watches need to be standalone, not counting initial setup. To get the standalone cell plan the watches need to be configured using AWFK. Here is what I have tried/current issues. I switch between all three watches on my phone using the watch app. Originally tried to put test watches in developer mode, thinking I would connect to Xcode, developer mode is not available when watch is setup using AWFK. Pushed the watch app to apple connect, setup TestFlight group, added the test users and my phone user, accepted invites TestFlight is installed on my phone, I see the testflight setup for the watch app I set a test watch using watch app on the phone, run install for the test app from TestFlight on the phone, spinner moves for awhile then goes back to Install. I am not able to get the watch app installed on the test watches from the phone. Is what I am attempting to do supported? I haven't found much specific documentation on this. If I pair the test watches as regular watches, set them to developer mode, can I pair them again as AWFK and will developer mode survive the switch? Or is there something really simple that I'm overlooking? Appreciate any help that can be extended.

There seems to be a problem to a specific Apple Developer Account regarding Xcode Cloud Distribution (Signing). The Xcode Cloud Error Invalid Signature. Code failed to satisfy specified code requirement(s). The file at path “XcodeCloudTest.app/XcodeCloudTest” is not properly signed. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose “Clean All” in Xcode, delete the “build” directory in the Finder, and rebuild your release target. For more information, please consult https://developer.apple.com/support/code-signing. Investigation Apple Developer Forums This issue seems to be known: https://developer.apple.com/forums/thread/746210 Debugging by ourselves We setup an example Xcode project from a default iOS Xcode app template to rule out any project issues. This example project failed with the same error as stated above. In the next step we tried the same example project with a different Apple Developer Account and it successfully distributed the example App through Xcode Cloud. Conclusion It seems like there is no setup issue on developer-side, because our example project works out-of-the-box on a different Apple Developer Account. Our only hope is that Apple will have a look on our Developer Account. Maybe there is some internal setting.