My app has two versions. 1.0(1.8) and 2.0(1.0)
For internal testers I need to switch to version 2.0(1.0)
When I switch version to 2.0 and the build 1.0 fro that version and save. iTunes Connect warns me that the version 1.0 will be unavailable. I continue to save.
But after the processing the version switch back to 1.0 with a very previous build selected. I can't able to switch to version 2.0. Is there any known bug or am I doing something wrong?
EDIT
Ok one way to make the version change for internal testers is to make all other versions unavailable.
Moreover in External Testers when I try to add a new build I get the following error:
This version can’t be tested because you have reached the maximum number of apps allowed for testing at once.
From documentation I see that one end user can have the same TestFlight account on no more than 10 devices. But how is this even concerned with the end user?
The version of your app is 1.0(1.8). This means
CFBundleShortVersionString: 1.0
CFBundleVersion: 1.8
You need to increment CFBundleVersion on each iteration of alpha testing. So You should set CFBundleVersion larger than 1.8.
ref. Which iOS app version/build number(s) MUST be incremented upon App Store release?
Related
I have a problem with fastlane when I publish on TestFlight a new bundle that uses the usual version (ex: 1.0.2):
Error This bundle is invalid. the value for key
CFBundleShortVersionString (1.0.2) in the Info.plist file must contain
a higher version than that of the previously approved version [1.0.2]
It seems like I need to publish a new version, but I want to publish a new build instead, keeping the same version ... how is that possible?
Edit Response:
ok, I understand ... although unlike Android, I don't see the usefulness of blocking a new build if there is the same approved version ... but thank you all!
There is no way to upload new build of the previously approved version. So in this situation you should have to create new version in iTunes Connect and then and then you can able to upload new build in Testflight.
Few cases arise:
If you want to keep same version, remove current app from app store and publish your current version.
Now there is already app with same version so you cannot allow to do this, either increase the version or go with point 1, how ever be careful with this point. You need to analyse cases, because it is already on appstore.
You can upload the same version to TestFlight with increased build number. Eg: 1.0.2(1) and 1.0.2(2) Simply increase the build version from Project settings.
Here is my scenario:
We recently created a iTunes app record for our new app which is not yet available to public. So, by default iTunes shows an app(1.0) with status as 'Prepare for Submission'. (I assume we can change this default version number from v1.0 to v1.0.0 on the app record. but for clarity I am leaving it as default in my below explanation)
Now, I uploaded my first build with v1.0.0(0) to TestFlight and after 4 revisions/build uploads, I made the build v1.0.0(4) available for external testers. Now we got few bugs from the external testers and fixed them. Since we did the bug fixes, I want to change the version to v1.0.1(0) in TestFlight. Below are my questions struggling to find an answer for:
1) Since the app is not yet released and the default app record version is still v1.0, can I still upload a new version i.e. v1.0.1(0) on TestFlight ?
a) If I can do the above point(1), will it go through the beta review process again (or) will it simply process and appears on iTunes ?
b) If I can do the above point(1), lets say after 2 revisions again like when version is at v1.0.3(0), can I finally push this build to the AppStore as my first release....I mean will it override the default version v1.0 to v1.0.3 ?
2) If I cannot achieve the above point(1), then what would be the other approach?
Please suggest me how to proceed...
First, yes you can submit your new version (1.0.1) but it will still have to pass through the apple process to get approved for external test.
If I can do the above point(1), lets say after 2 revisions again like when version is at v1.0.3(0), can I finally push this build to the AppStore as my first release....I mean will it override the default version v1.0 to v1.0.3 ?
Yes, when you publish your app, you can specify the version displayed in the store so you can display v1.0!
Every time you want to make a new build available to your external tester, Apple need to approve it!
I have developed app and so many times I have uploaded on iTunes connect (TestFlight). Like :
Version Build
1.5 —> 1.0 This build is live — on App Store
1.4 —> 1.9
1.4 —> 1.8
1.4 —> 1.7
1.4 —> 1.6
……….
1.3 —> 1.9
1.3 —> 1.8
……..
and so on…..
Now I need to update one change and want to give for testing to my other friends, So I am trying to upload new version `1.5 —> 1.1’ on iTunes connect (TestFlight) through Xcode, but it gives error like : Version must be higher than the existing version on iTunes connect.
Before making live, I have uploaded so many build for the same version and same via Xcode , at that time it is done successfully uploaded.
Then why it gives me error now ?
What it means to say ?
How can I upload on TestFlight for testing ?
Please suggested me, what should I do.
It could be due to your app has become Live (Ready For Sale) on the AppStore.
I think Apple consider the version life cycle completed once the version is available to public users via AppStore.
In your case, 1.5 (1) is Live on AppStore which means version 1.5 life cycle completes with final version being 1.5 (1).
So, you would not be able to add any further new build with 1.5 version. Instead, you should create a new version higher than 1.5, i.e., 1.5.1, 1.6, and then upload the builds to that newly created version.
This is just my assumption, not 100% sure.
For me.. i regularly updating build(not version) and uploading the it to testflight and works, even i have uploaded it today just 1 hour ago and it worked fine. I think, you should clean->build and do same process again. Sometimes after changing build number, you might not have build the target and directly archived, in that case, such a errors are thrown by Apple.
So the probable solution is to just
clean->build -> archieve .... do same process again and upload it to appstore.
I had the same Issue. I released 1.0 build 5 to App Store(live). Had to make some quick changes, so tried to change the build number and released to Test Flight through iTunes Connect. I got no warnings or any errors. However, when I login to iTunesConnect and check in Activity tab the build number for that specific version says "The build is invalid" with a red exclamation.
Solution: Just increase the version no, not the build no if the app is already live.
I have an iOS app that uses semantic versioning to tag shipped builds. I'm also using Apple's TestFlight to push internal builds to the team for testing/QA.
Pushing an internal build requires uploading a build to iTunes Connect. There's no distinction between a test build and release build to iTunes Connect, and iTunes Connect does not allow overwriting previously uploaded versions. So every time I want to push a new build for internal testing, I have to bump the version number (well, the patch (X.X.X) number).
This works fine, except to our users it looks like our version numbers jump around a lot in between updates. For instance, if this is our build history:
v1.0.0
v1.0.1 (bug was found in testing)
v1.0.2
v1.1.0 (bug was found in testing)
v1.1.1 (bug was found in testing)
v1.1.2
...then the users are only seeing the bold releases, and our release history looks odd:
v1.0.0
v1.0.2
v1.1.2
I thought a good way to avoid this is to use beta versions, like v1.1.0-beta for the test builds, but iTunes Connect rejects any version strings that aren't X.X.X.
Is there a way to continue using TestFlight for internal testing/QA and avoid the appearance of a gap-filled version history to users?
I use an internal 4th number in the build version, I believe iTunes still accepts this.
e.g. it might be version 1.0.0 but the build could be 1.0.0.87 indicating 87th internal build to test. You can choose to lop off the last number when displaying it in the App, but people do not usually care.
I have found this easy to understand and accepted in most places.
Build number as compared to version number is not given enough credit.
Use the build number.
Simply sequentially increase the build number.
We just use a simple integer 523, 524, etc.
Don't change the version number for test flight because...
If you change the actual version number, you will pointlessly trigger another automated test delay for that upload! Simply increase the build number.
Basically the versioning has below rules.For example if existing version is v1.0.0 then the next release will be:
v1.0.1 For bug fixes & minor changes.
v1.1.0 For major changes but the App is still compatible with
older versions. The user can still run the old version of app.
v2.0.0 For major changes but the App is NOT compatible with
older versions. The user cannot run the old version of app.
v1.0.0.1(beta) For internal testing
Each time I attempt to publish an update to an app I receive this automated email response moments later:
We have discovered one or more issues with your recent delivery for "App Name".
Your delivery was successful, but you may wish to correct the following issues in your next delivery:
Version Mismatch - Neither CFBundleVersion ['9.1'] nor CFBundleShortVersionString ['9.1'] in the Info.plist match the version of the app set in iTunes Connect ['2.41'].
I understand why the message is being generated but I would like to resolve the issue without having to compromise the version # by making it higher than it actually is.
Being the first app I had ever developed, I was pretty clueless when it came time to publish the app and in frustration of the process I mistakenly defined the version number to some extreme value because I was, at the time, getting stuck with another error that was preventing me from completely the process .. the other error which I've since forgotten exactly, was related to the version number being incorrect. So I finally thru my hands in the air, set the version number to 8 and was able to complete the process.
Since then, I'm still pretty clueless but I've learned a thing or two, and the current version of the app is 2.41. When I prepare an update on iTunes Connect I set the version to 2.41. But if I define 2.41 in CFBundleVersion or CFBundleShortVersionString, Xcode outright refuses to upload the binary and demands a version greater than the previous version which has now surmounted to 9.1.
Obviously, any users of the app would be quite confused if the version jumped from 2.41 to 9.1 overnight.
It was you who defined the new version as 2.41 in iTunes connect. Any new version should be higher than the last one. So the straightforward solution is removing the 2.41 version from iTunes Connect and add a new 9.1 version. Then iTunes Connect and your binary will be in accordance and you will be able to upload the new version.