I have been investigating a recent breakage where apps being installed via Testflight are crashing on launch with no helpful crash reports, or even console-accessible logging. More detail: The app launches just fine on iPadOS 18 beta (ipad) but the same build doesn't work on iPadOS 17.6.1 At my wit's end, I checked the entire build environment - was I using XCode beta still somewhere? Well, in the XCode Cloud workflow, I had selected "Release" for the latest released version of XCode. And MUCH to my surprise, I see that XCode 16 RC is selected. Why? That's not released yet... Anyway, this is just a friendly PSA to check your XCode Cloud workflows if you choose "release" when new XCode releases are upcoming... or peg your XCode Cloud environment versions. And I still don't have an explanation why Testflight XCode 16 RC is producing builds that crash on iPadOS 17.6.1 (for us) but not the latest iPadOS 18 public beta...

I've submitted several requests for Family Controls Distribution access for all of my app targets over two weeks ago and have not gotten any response. The app I've been working on for over a year is finally ready to beta test to 200+ waitlisted users but this final roadblock is killing me! Anyone know what to do? Is there anyone else I could reach out to other than the apple request form to get help with this? Thank you!

I get the message as seen in the attached image. I recently enrolled in the Apple Developer program last month. Initially, I was working for a client and everything was working fine locally. Builds were executing fine and running as well in emulators and physical devices. But when I archive the build and distribute it to TestFlight via AppStore Connect, I always get this error message as shown below. There are no warnings or errors in the console or in Xcode. I already took care of everything and all compliance related issues. I am not sure what even is wrong at this time. I resubmitted the builds at-least 8 times but still getting same message. Moreover, as a test run, I submitted a build containing a simple "Hello World" component as well. It's getting the same error. I have wrote to Apple Support as well but haven't heard back from them yet. If anyone knows how to resolve this please please guide me. This is really annoying and frustrating now since testers are not able to test the application.

I have a Safari Extension deployed to test flight built and deployed using CLI tools in Azure Devops. It appears to be building, signing, and deploying properly. But when users try to install on TestFlight, they see an error saying something about an invalid provisioning profile. This seems to just be on the "installer" portion of the app. The extension shows up in safari settings and is otherwise useable. The users just aren't seeing the splash screen that instructs them to go to Safari Settings. I'm not really sure what's wrong here. This is what my build pipeline looks like - task: Bash@3 displayName: "Build export.plist file" inputs: targetType: 'inline' script: /usr/libexec/PlistBuddy -c "Add :method string mac-application" $(Pipeline.Workspace)/export.plist && /usr/libexec/PlistBuddy -c "Add :provisioningProfiles dict" $(Pipeline.Workspace)/export.plist && /usr/libexec/PlistBuddy -c "Add :provisioningProfiles:$(APP_IDENTIFIER) string $(InstallDistProvisioningProfile.provisioningProfileUuid)" $(Pipeline.Workspace)/export.plist && /usr/libexec/PlistBuddy -c "Add :signingCertificate string '$(InstallDistCerts.signingIdentity)'" $(Pipeline.Workspace)/export.plist && /usr/libexec/PlistBuddy -c "Add :signingStyle string manual" $(Pipeline.Workspace)/export.plist && /usr/libexec/PlistBuddy -c "Add :teamID string $(APPLE_TEAM_ID)" $(Pipeline.Workspace)/export.plist && /usr/libexec/PlistBuddy -c "Add :iCloudContainerEnvironment string Production" $(Pipeline.Workspace)/export.plist && /usr/libexec/PlistBuddy -c "Add :stripSwiftSymbols bool true" $(Pipeline.Workspace)/export.plist && /usr/libexec/PlistBuddy -c "Add :compileBitcode bool false" $(Pipeline.Workspace)/export.plist - task: Xcode@5 displayName: "Build Safari Extension" inputs: action: "archive" sdk: "macosx" packageApp: true xcodeVersion: "15" args: "-verbose CODE_SIGNING_REQUIRED=Yes CODE_SIGNING_ALLOWED=Yes" exportOptions: "plist" exportOptionsPlist: '$(Pipeline.Workspace)/export.plist' exportMethod: "mac-application" archivePath: '$(Build.ArtifactStagingDirectory)/SafariDesktopExtension.xcarchive' signingOption: "default" - script: | xcodebuild -exportArchive \ -archivePath $(Build.ArtifactStagingDirectory)/SafariDesktopExtension.xcarchive \ -exportPath $(Build.ArtifactStagingDirectory) \ -exportOptionsPlist $(Pipeline.Workspace)/export.plist displayName: 'Export Distribution-signed App' - task: DownloadSecureFile@1 displayName: "Download Provisioning Profile" name: downloadProvisioningProfile inputs: secureFile: $(PROVISIONING_PROFILE_DIST) - script: | cp "$(downloadProvisioningProfile.secureFilePath)" "$(Build.ArtifactStagingDirectory)/SafariDesktopExtension.app/Contents/embedded.provisionprofile" displayName: "Embed provisioning profile in Top-Level Executable" - script: | cp "$(downloadProvisioningProfile.secureFilePath)" "$(Build.ArtifactStagingDirectory)/SafariDesktopExtension.app/Contents/PlugIns/SafariDesktopExtension Extension.appex/Contents/embedded.provisionprofile" displayName: "Embed provisioning profile in Extension" - script: | codesign --deep --force --verify --verbose --sign "$(InstallDistCerts.signingIdentity)" --entitlements "$(rootFolder)/safari/SafariDesktopExtension/SafariDesktopExtension/SafariDesktopExtension.entitlements" $(Build.ArtifactStagingDirectory)/SafariDesktopExtension.app displayName: "Codesign" - task: Bash@3 displayName: "Package Application" inputs: targetType: "inline" script: | productbuild --sign "$(InstallInstallerCert.signingIdentity)" --component "$(Build.ArtifactStagingDirectory)/SafariDesktopExtension.app" /Applications "$(Build.ArtifactStagingDirectory)/SafariDesktopExtension.pkg" I'm sure there's a bit of garbage here as I'm new to developing in the apple ecosystem. But it appears to work and the resulting .pkg can be submitted successfully. Effectively, that's building an archive using a plist for export options, exporting the archive for distribution, copying the distribution provisioning profile for the top-level executable (the one that's not working) and the extension itself, code signing, and packaging using the installer cert. The provisioning profile (attached to a Mac distribution certificate) mentioned has the correct application identifier and matches the entitlements. I'm not really sure what's going on here and the generic "invalid provisioning profile" error isn't helping. Any help would be appreciated. I'd also love to know if this could hold up a release.

When I install and open my React Native iOS app on my iPhone device using the TestFlight app, it shows an empty white screen. But, it works fine on my XCode Simulator and my iPhone device when run through XCode on both debug or release modes. What could be the reason for getting an empty white screen when running my app on TestFlight?

My Mac is on 15.1. Xcode will not validate Mac apps — even for TestFlight. I have been patient in not doing a full reset back to 14 and then back to 15.0, assuming this will go away soon. Am I being naive? Is there a chance validating apps on 15.1 is something that is months away and I need to do the annoying work of resetting my entire Mac back to 14->15?

Hello everyone, on August 31st, all the apps in my personal developer account were suddenly expired and deleted, I have not received any response from Apple. My apps are in compliance with Apple's policies. I then uploaded a new version and sent it to the review team, but I received the following error "There was an error processing your request. Please try again later." I have contacted Apple via Email and Phone but no one cares about my problem. Has anyone had the same situation as me, I am really worried.

Is it possible to distribute apps using TestFlight with the distribution profiles created with Apple Developer Enterprise Program. If yes, can anyone provide the reference links. Thanks Abhilash Reddy

I can't seem to upload my standalone watchOS app to TestFlight. Xcode never offers me the proper distribution scheme. I only get file-based distribution mechanisms. The metadata in AppStoreConnect are present, the bundle ids are correct, this is a freshly new created project without any custom content. How is this supposed to work?

Beta testers outside the US, for our MacOS App, are being told their ID is not valid in the US Store and that they must switch to a store in their country. Yet the store switch fails Essentially beta testers outside the US cannot do testflight sandbox eCommerce for the Mac version of our app. Note that eCommerce on the Mac works for US based testers and eCommerce for the iOS/iPadOS works for testers in all territories. Many of these testers are in India, the UK and Canada. We believe that this is incorrect, that storeKit is not correctly detecting the AppStore Region for mac based testflight eCommerce. At this point we have 382 testers, most outside the US and we can only Beta Test our app with US users. Attached are images of the messages that are coming from storeKit: Here is a link to a video from a user in Canada who is demonstrating the problem (cut and paste into browser) https://youtu.be/kB818wfVld4 Here is another link to a video from a user in Canada who is demonstrating the problem (cut and paste into browser). https://youtu.be/7uAZKo8wpfU We see that there is another post with a similar problem. Similar eCommerce Problem Because eCommerce works in all territories on iOS/iPadOS but ONLY in the US for Mac we suspect that this is an error that either a DBA or a coder will need to fix. Any insights from anyone would be appreciated.

We encountered a weird situation recently. Our daily build process upload an app with a daily incremental 4-digit build number, e.g. 4000, 4001, 4002, etc. Our release build number has a specific requirement to use the date, such as 20240719. In the past I have learned that in order to upload a new build for the same version number, the new build number needs to be greater than the old one. Thus, if I have uploaded 200.1.0 (20240719), I cannot upload 200.1.0 (4001) anymore, because the daily build's build number is smaller than the release build. I have to expire the 20240719 build in order for the daily build to continue, which is fine. The problem is, yesterday I submitted 200.1.0 (20240719) for App Store review then got approved. While today's daily build is 200.2.0 (4001) and when it is uploaded, it got rejected for the following error message: This bundle is invalid. The value for key CFBundleVersion [4001] in the Info.plist file must contain a higher version than that of the previously uploaded version [20240719]. Please find more information about CFBundleVersion at https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleversion With error code STATE_ERROR.VALIDATION_ERROR.90061 for id [redacted] Asset validation failed (-19208) This befuddles me, because the 20240719 build submitted for review is in an older release version, while the daily build 4001 is using the newer release version number. It seems that TestFlight decided to compare build numbers while ignoring the version numbers?! Furthermore, after I canceled my approved submission for 200.1.0 (20240719), surprisingly the 200.2.0 (4001) can be uploaded without an error! 😲 It seems that the only factor is whether the build is submitted or not. If an older version number higher build (200.1.0 (20240719)) is not submitted, then TestFlight happily allows newer version number lower build (200.2.0 (4001)) to be uploaded. In contrast, if submitted, then 4001 is not allowed to be uploaded! Is it an expected behavior? Thank you for the patience.

I have been trying to access the test flight since yesterday but was not able to access instead it displayed the below message. "Before you can start testing, a developer has to invite you to test one of their TestFlight apps.To accept an invite, click on the link in the email or enter invitation redeem code" - Attached the scrrenshot Once I clicked on redeem there is a pop-up displayed that asked me to enter the Test flight invitation code which I did not get. - Attached the screenshot This is purely to test the Chrome beta version to test the compatibility and not any personal apps. Can someone help me out to solve this issue?

We are received the following error while uploading the application into TestFlight. **ITMS-90714: Invalid binary - The app contains one or more corrupted binaries. Please rebuild the app and resubmit. ** After sometimes we submit the same application without changing the configurations application submitted successfully into the App Store. We are using the Xcode 15.3 version.

Im building a small iphone app with StoreKit and currently testing it in testflight right on my mac, not on iphone. StoreKit part almost exactly copied from SKDemo from one of the Apple's WWDC. For some users and for myself Transaction.currentEntitlements always returns .unverified results. I double-checked Apple Connect settings, i checked my internet connection and everything is fine. Is there some pitfalls for testflight on mac? How can I find out what is causing this problem?

Does anyone know how TestFlight counts the number of installs, sessions and crashes? I'm seeing totally insane numbers. I don't understand. Right now for the latest beta it shows me: number of installs "-", number of sessions 19 and number of crashes 36. What's that supposed to mean? When I look at the individual testers, sometimes there's already complete crap there. For example, there is a user who has reached 1180 crashes in 13 runs. What? Can you imagine a person who runs an application 1180 times and it crashes? I don't. What's really best, TestFlight gives me almost no crash logs. There were a few from the early betas, but none the last few days. Do you know of any other tool from which I get consistent information on absolutely all crashes?

I had everything working with Revenue Cat. Then my app got rejected for not loading subscriptions, which was odd because a previous built was rejected for wording on that same paywall. I checked, and realised I suddenly can't fetch products in testFlight either. I can only see products in Xcode using the store kit configuration file. I've found many issues like this online and everybody point to the same solutions (that seem to work for most), but here's what I tried so far: Checked that all my agreements in App Store Connect are active Checked that ids match between Xcode / revenue cat / App Store connect Store kit config file is syncing with App Store Connect correctly I removed revenue cat and used the store kit api directly to fetch products. The array of products is empty in all environments that don't have access to store kit config file. Checked status of all subscriptions (all waiting for review -- as they were when the paywall worked) Nothing seems to work... Any suggestions? Many thanks

Since updating to 14.2 beta 2 I see the following error when trying to sign in to the TestFlight App on macOS. "Password reuse not available for account" It seems like it possibly affecting the AppStore too, from the device logs I see: Error Domain=AMSErrorDomain Code=2 \"Password reuse not available for account\" UserInfo={NSLocalizedDescription=Password reuse not available for account, NSLocalizedFailureReason=The account state does not support password reuse.}" I've tried signing out of the App Store to fix it but now I can't sign into either the store of TestFlight. I've also tried, multiple restarts and safe mode. Things seem fine on other platforms. Is this a known issue? Are others seeing it? Any ideas for how to reset things or what the error might be referring to?

We have an iOS app which is currently available in AppStore. Now we are enabling Mac Catalyst support for the Mac users. As our app is contains In App purchases and it is working fine in iOS devices. But when we try to purchase subscriptions from Mac Catalyst app using TestFlight, it gives the error “Your account is not valid for use in the U.S. store. You must switch to the Japan store before purchasing.” Then after we have checked an AppStore region and the region is already Japan. Any assistance would be appreciated.

I am trying to add one of my co-workers to the internal testing group for TestFlight. The problem is that her Apple ID is different from her email address. A few years ago she was able to change her email and now it differs from her Apple ID. She was able to accept the App Store Connect invite when I sent it to the proper email address, but when that happened, it changed her 'Email' to the Apple ID, which isn't correct. Now when the TestFlight email is sent, it's sending to that Apple ID instead of the actual email address associated with the Apple ID. How can I get around this or fix this? Seems like an oversight or bad assumption that your Apple ID MUST be the same as your email address.

when we test in app purchase feature in TestFlight, we realize that TestFlight using our real iCloud account in AppStore, but because the app installed from TestFlight, they know it is still "Testing Phase" so they purchase set to FREE. Now im asking about how to test in app purchase for CANCEL SUBSCRIPTION? I can't found in my real iCloud account, either for my sandbox account inside AppStore settings. Please any response will helpful. Thankyou.