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.
TestFlight
RSS for tagTestFlight within App Store Connect allows you to invite and manage testers who can install and beta test your iOS, iPadOS, tvOS, and watchOS apps using the TestFlight app on the App Store.
Posts under TestFlight tag
200 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
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.
Hi can i get the test flight invitation code
We had send an app to Appstore. It was live. We removed it. After a year we decided to change the name, the name is updating in Appstore web, Invitation email received from Testflight is also new name. But when we tap on [View in TestFlight] in the email or the app name in TestFlight iOS app still shows the old name. We update the app info and all the other places. Different name in Appstore and Testflight app for the updated name.
Hi,
Do we have any known issue with internal builds not being tagged properly as internal on TestFlight? Is anyone else having the same issue?
Our team is not being able to do internal builds anymore since the last week or so. The last build we have that was successfully tagged as internal was on Wed Jul 3 00:15:40.
After that mark, we can upload the builds and they show up on TestFlight, but they are not marked as internal and they can technically be used for a public release even though they shouldn't.
We thought this could be an issue with our CI workflow, as we did some changes around that time, but we tried reverting everything or building from an older commit and the problem isn't solved. We even tried building and uploading directly through Xcode, without going through our CI or any external tools, and even selecting the TestFlight Internal Only distribution method, the builds are still releasable (not internal).
On the CI side, we have confirmed multiple times that our ExportOptions.plist contains the expected key/value pair:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>destination</key>
<string>export</string>
<key>generateAppStoreInformation</key>
<false/>
<key>manageAppVersionAndBuildNumber</key>
<true/>
<key>method</key>
<string>app-store-connect</string>
<key>provisioningProfiles</key>
<dict>
<key>(redacted)</key>
<string>(redacted)</string>
<key>(redacted)</key>
<string>(redacted)</string>
</dict>
<key>signingCertificate</key>
<string>Apple Distribution</string>
<key>signingStyle</key>
<string>manual</string>
<key>stripSwiftSymbols</key>
<true/>
<key>teamID</key>
<string>(redacted)</string>
<key>testFlightInternalTestingOnly</key>
<true/>
<key>uploadSymbols</key>
<true/>
</dict>
</plist>
We're unsure on what else to do about it, but we definitely would prefer to have internal builds not being releasable to avoid human error.
Any ideas on what else we might be missing? Or if is this an actual TestFlight issue?
Thanks
Hello,
I am trying to upload a build using XCode 16 beta 3 and visionOS 2 SDK beta 3, which are the latest available betas.
But the build isn't accepted by App Store Connect. This message is shown:
Unsupported SDK or Xcode version. Your app was built with an SDK or version of Xcode that isnβt supported. Although you can use beta versions of SDKs and Xcode to build and upload apps to App Store Connect, you need to use the latest Release Candidates (RC) for SDKs and Xcode to submit the app. For details on currently supported SDKs and versions of Xcode, visit: https://developer.apple.com/news/releases.
What can I do to upload to App Store just for Test Flight Internal Only build?
Do I need to downgrade to a non-beta XCode and use non-beta visionOS SDK?
I'm experiencing an issue where in-app purchases work correctly in both profile and debug modes. However, when I upload the app to TestFlight, the in-app purchases are not functioning as expected. How can I resolve this issue?
I'm experiencing an issue where in-app purchases work correctly in both profile and debug modes. However, when I upload the app to TestFlight, the in-app purchases are not functioning as expected. How can I resolve this issue?
Hello colleagues, this is the first time this has happened to me, and I don't know what to do, I have done research and I have not found a solution for this, I am compiling my application only for iPhone, and when it is up to send it for review, it tells me that it is also for iPhone/iPad, and I'm frustrated, because my application has never been uploaded for iPad.
In my xcode, I put in the Target Device, iPhone only, and it uploads as if it were compatible with iPad. Did it happen to someone else?
Hello,
I recently encountered an issue following the transfer of my app between Apple Developer accounts and would appreciate any insights or solutions.
Here's a summary of the situation:
App Transfer: I transferred an app from one Apple Developer account to another. The app's bundle ID remained unchanged during this process.
App Update: After the transfer, I integrated a new feature into the app and pushed the updated version to TestFlight under the new account.
Installation Issue: When I installed the TestFlight version of the app from the new account on my device, which already had the app installed from the old account, the app logged out the user. It appears that the UserDefaults data was not retained, resulting in the loss of stored user data.
My hypothesis is that the transfer between accounts caused the user defaults to reset, leading to the data loss.
Has anyone else experienced this issue, and if so, are there any recommended solutions or best practices to prevent UserDefaults from resetting during such transfers?
Thank you in advance for your assistance.
While using the iOS 18 Beta, I encountered the following bugs and have some feedback:
Bugs:
Notifications: Notifications sometimes appear very small, making them difficult to read and manage. Additionally, notifications occasionally disappear completely or get placed at the bottom of the screen, where they are hard to notice. This causes issues in keeping track of important information.
Feedback
Passwords: It is not possible to view the personal hotspot password and QR code in the passwords application. This is particularly problematic when someone wants to share their hotspot with others, as the password must be entered manually.
Please investigate these issues so they do not persist in the final release.
An app I'm developing uses a text data file to access some words. The app runs fine in all simulators and when directly hard-wired from my Mac to my iPhone. When I download it to App Store Connect and run the app in TestFlight the app runs fine except when it tries to access the data file. The error it gives me is that it can't access the same data that I access when running the app in the simulators.
Hi, Im trying to upload my app to testflight and keep getting the following errors. I'm unsure of what to do. Would really appreciate any help!
Asset validation failed
Invalid MinimumOSVersion. Apps that only support 64-bit devices must specify a deployment target of 8.0 or later. MinimumOSVersion in 'AppName-App.app/Frameworks/FirebaseAnalytics.framework' is ''. (ID: 5c2f4b25-3b18-4417-8ea1-3fbe1819b235)
Asset validation failed
The bundle 'Payload/AppName-App.app/Frameworks/FirebaseAnalytics.framework' is missing plist key. The Info.plist file is missing the required key: CFBundleShortVersionString. Please find more information about CFBundleShortVersionString at https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring (ID: bdd9b49c-beb4-4aa0-b44e-39ca394523c6)
Asset validation failed
Invalid Bundle. The bundle AppName-App.app/Frameworks/FirebaseAnalytics.framework does not support the minimum OS Version specified in the Info.plist. (ID: 32b88c27-d56f-44f9-a478-4d93edf94356)
Asset validation failed
Invalid Bundle. The bundle AppName-App.app/Frameworks/GoogleAppMeasurementIdentitySupport.framework does not support the minimum OS Version specified in the Info.plist. (ID: 941946b9-a781-4890-9cda-3485a7ce7854)
Is this possible? Here's what I'm trying:
I'm making an app that reads from a CloudKit database. That's working fine.
I made a second "admin" type app to update the database. But, of course, I don't intend to release the admin app to the public.
So it was all working fine while testing in the development environment, but now that my public app is in TestFlight, and I have updated the necessary stuff that should allow me to write to production, but every attempt successfully writes to development, not production.
I'm wondering if I submitted my admin app to TestFlight if it would work then. But that doesn't seem like a long term solution, since I think I would have to re-upload every 90 days... just doesn't seem ideal or correct.
Do I HAVE to write the admin functionality in to the public app and hide it?
What are better ways I could write to production other than manually through the console?
Thanks everyone!
Hello,
We experience a TestFlight-related bug with devices limit.
When I try to remove authorized devices for testing nothing happens in macOS and iOS app respectfully. Could be backend-related issue.
Please look into FB14094008, thanks.
Hi,
We are developing react native app, and we are having issue with ATS policy in production build distributed to TestFlight internal testing, requests to https are being killed. The preview build ad-hoc distribution is working fine. (I am testing the app on physical device)
I will described what I've tried and supply you with logs from different tools.
I tried to disable ATS - requests are working
enable ATS (no change to default config) - requests are failing with following error
Task <55618987-64A8-4C04-9B00-2EFF074D796C>.<1> finished with error [-1022] Error Domain=NSURLErrorDomain Code=-1022 "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." UserInfo={NSLocalizedDescription=The resource could not be loaded because the App Transport Security policy requires the use of a secure connection., NSErrorFailingURLStringKey=<private>, NSErrorFailingURLKey=<private>, _NSURLErrorRelatedURLSessionTaskErrorKey=<private>, _NSURLErrorFailingURLSessionTaskErrorKey=<private>, NSUnderlyingError=0x30127bb10 {Error Domain=kCFErrorDomainCFNetwork Code=-1022}}
I tried to check server if it had met ATS requirements and ran ats-diagnostic
./TLSTool s_client -connect api.rankacy.com:443
* input stream did open
* output stream did open
* output stream has space
* protocol: TLS 1.2
* cipher: ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
* trust result: unspecified
* certificate info:
* 0 + ecPublicKey 256 ecdsa-with-SHA384 'api.rankacy.com'
* 1 + ecPublicKey 384 sha256-with-rsa-signature 'E6'
* 2 + rsaEncryption 4096 sha256-with-rsa-signature 'ISRG Root X1'
nscurl https://api.rankacy.com/ --verbose --ats-diagnostics
Starting ATS Diagnostics
Configuring ATS Info.plist keys and displaying the result of HTTPS loads to https://api.rankacy.com/.
A test will "PASS" if URLSession:task:didCompleteWithError: returns a nil error.
================================================================================
Default ATS Secure Connection
---
ATS Default Connection
ATS Dictionary:
{
}
Result : PASS
---
================================================================================
Allowing Arbitrary Loads
---
Allow All Loads
ATS Dictionary:
{
NSAllowsArbitraryLoads = true;
}
Result : PASS
---
================================================================================
Configuring TLS exceptions for api.rankacy.com
---
TLSv1.3
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionMinimumTLSVersion = "TLSv1.3";
};
};
}
Result : PASS
---
---
TLSv1.2
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionMinimumTLSVersion = "TLSv1.2";
};
};
}
Result : PASS
---
---
TLSv1.1
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionMinimumTLSVersion = "TLSv1.1";
};
};
}
Result : PASS
---
---
TLSv1.0
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionMinimumTLSVersion = "TLSv1.0";
};
};
}
Result : PASS
---
================================================================================
Configuring PFS exceptions for api.rankacy.com
---
Disabling Perfect Forward Secrecy
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionRequiresForwardSecrecy = false;
};
};
}
Result : PASS
---
================================================================================
Configuring PFS exceptions and allowing insecure HTTP for api.rankacy.com
---
Disabling Perfect Forward Secrecy and Allowing Insecure HTTP
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionAllowsInsecureHTTPLoads = true;
NSExceptionRequiresForwardSecrecy = false;
};
};
}
Result : PASS
---
================================================================================
Configuring TLS exceptions with PFS disabled for api.rankacy.com
---
TLSv1.3 with PFS disabled
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionMinimumTLSVersion = "TLSv1.3";
NSExceptionRequiresForwardSecrecy = false;
};
};
}
Result : PASS
---
---
TLSv1.2 with PFS disabled
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionMinimumTLSVersion = "TLSv1.2";
NSExceptionRequiresForwardSecrecy = false;
};
};
}
Result : PASS
---
---
TLSv1.1 with PFS disabled
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionMinimumTLSVersion = "TLSv1.1";
NSExceptionRequiresForwardSecrecy = false;
};
};
}
Result : PASS
---
---
TLSv1.0 with PFS disabled
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionMinimumTLSVersion = "TLSv1.0";
NSExceptionRequiresForwardSecrecy = false;
};
};
}
Result : PASS
---
================================================================================
Configuring TLS exceptions with PFS disabled and insecure HTTP allowed for api.rankacy.com
---
TLSv1.3 with PFS disabled and insecure HTTP allowed
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionAllowsInsecureHTTPLoads = true;
NSExceptionMinimumTLSVersion = "TLSv1.3";
NSExceptionRequiresForwardSecrecy = false;
};
};
}
Result : PASS
---
---
TLSv1.2 with PFS disabled and insecure HTTP allowed
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionAllowsInsecureHTTPLoads = true;
NSExceptionMinimumTLSVersion = "TLSv1.2";
NSExceptionRequiresForwardSecrecy = false;
};
};
}
Result : PASS
---
---
TLSv1.1 with PFS disabled and insecure HTTP allowed
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionAllowsInsecureHTTPLoads = true;
NSExceptionMinimumTLSVersion = "TLSv1.1";
NSExceptionRequiresForwardSecrecy = false;
};
};
}
Result : PASS
---
---
TLSv1.0 with PFS disabled and insecure HTTP allowed
ATS Dictionary:
{
NSExceptionDomains = {
"api.rankacy.com" = {
NSExceptionAllowsInsecureHTTPLoads = true;
NSExceptionMinimumTLSVersion = "TLSv1.0";
NSExceptionRequiresForwardSecrecy = false;
};
};
}
Result : PASS
---
I am running out of ideas. Also it's hard to test because the preview ad-hoc build is working fine. So only after submitting the app to TestFlight I am having this issue
Looking for your response
Martin
I updated my MacBook and iPhone(both 13 and 15pro) to the latest beta 2 version system. I could successfully open the iPhone Mirroring App on MacOS and go through the password verification step, but the app displays stuck on the "Connecting" step, and could not go further.
Greetings to all!
I recently developed an called DANZUB, the hub for dancers using the Adalo no-code tool. The App from adalo was directly imported into TestFlight on App Store Connect. When I released it for review, I got a rejection that app was not supported (display scale issue) on Ipad. I have primarily designed for IPhones and I do not know how I can adjust to IPads as well. I don't have this option on Adalo.
Some said I could change the settings in XCode. But I don;t have the file, because the file was directly exported from Adalo to App Store Connect. I am unable to download the file.
Please help, I am new to developing. So close yet so far. Thanks all!!
Recently started hitting the following error when trying to install the latest version of app I admin for in TestFlight:
"The app couldn't be installed because your Apple ID or password is incorrect. Try Again"
I've attempted to sign out / in of my Apple ID to no avail.
I uploaded several build on my testflight and all of them seemed to work. so I made update to my app version 1.0.7 and deployed it to testflight and it crashed. So decided to make a new update for the app resolving the crash issues and when I tried to install the app update was told "could install [app name] the profile can't be installed. Try again