Sorry to raise this topic again, but I'm not getting any help from Apple or finding a solution in the documentation.
When I tried to update my application in iTunes Connect, I get the following error:
Quote:
The binary you uploaded was invalid. The key CFBundleVersion in the Info.plist file must contain a higher version than that of the previously uploaded version.
I am trying to update from 1.0(3) to 1.1(0) My current version is constructed in the Info.plist file as:
"Bundle versions string, short" (CFBundleShortVersionString) was: 1.0
"Bundle version" (kCFBundleVersionKey) was: 3
I understood these to represent a marketing number of 1.0, and a build number of (3) which combined give a version number 1.0(3).
My new version is constructed in the Info.plist file as:
Bundle versions string, short" (CFBundleShortVersionString) is: 1.1
"Bundle version" (kCFBundleVersionKey) is: 0
The result of this should be 1.1(0). This is a higher version number!
Why does this not work? Isn't it the CFBundleShortVersionString that should be higher than the last release? I spent a lot of time going through the versioning discussions, and I believe I followed the Apple recommended path correctly. Would really appreciated it if someone can point out my error. Can't push out my feature improvements till this is resolved.
Sorry to raise this topic again, but I'm not getting any help from Apple or finding a solution in the documentation.
When I tried to update my application in iTunes Connect, I get the following error:
I am trying to update from 1.0(3) to 1.1(0) My current version is constructed in the Info.plist file as:
"Bundle versions string, short" (CFBundleShortVersionString) was: 1.0
"Bundle version" (kCFBundleVersionKey) was: 3
I understood these to represent a marketing number of 1.0, and a build number of (3) which combined give a version number 1.0(3).
My new version is constructed in the Info.plist file as:
Bundle versions string, short" (CFBundleShortVersionString) is: 1.1
"Bundle version" (kCFBundleVersionKey) is: 0
The result of this should be 1.1(0). This is a higher version number!
Why does this not work? Isn't it the CFBundleShortVersionString that should be higher than the last release? I spent a lot of time going through the versioning discussions, and I believe I followed the Apple recommended path correctly. Would really appreciated it if someone can point out my error. Can't push out my feature improvements till this is resolved.
The only setting Apple use is the CFBundleVersion (or BundleVersion if you are version it in xCode as a pList file).
I woud guess Apple think your first app version was 3.0? Check in iTunes and see what version is listed?
If it is 3 then you can make the next version 3.1...
The only setting Apple use is the CFBundleVersion (or BundleVersion if you are version it in xCode as a pList file).
I would guess Apple think your first app version was 3.0? Check in iTunes and see what version is listed?
If it is 3 then you can make the next version 3.1...
Thanks for taking time to respond.
When I look at the Application in iTunes, or iTunes Connect is shows "Version 1.0". When I look at the App Details in iTunes Connect it shows: Bundle Short Version String : 1.0, Bundle Version : 3. Both are consistent with my settings in the Info.plist.
CFBundleShortVersionString (String) specifies the release version number of the bundle
Quote:
“CFBundleVersion,” which identifies an iteration (released or unreleased) of the application
I thought I was following their preferred number scheme, but perhaps I'm misinterpreting. What are others doing with their versions? Are they ignoring the BundleShortVersion all together, and just putting their entire version (e.g. 1.2.3) in the BundleVersion?
PS-Doesn't iTunes Connect check your Info.plist version against what you type in the web tool to make sure they match? How would it let me put in v1.0 in the web tool, but then interpret 3 from the plist?
I thought I was following their preferred number scheme, but perhaps I'm misinterpreting. What are others doing with their versions? Are they ignoring the BundleShortVersion all together, and just putting their entire version (e.g. 1.2.3) in the BundleVersion?
I registered just to respond to this...
I too thought the same thing about the versioning. I had previously submitted an app as 1.1(6), and neither 1.1.1(1) nor 1.2(1) worked when I just tried to update the app.
Looking at the documentation from your link, there's a little more to the CFBundleVersion specification:
Quote:
CFBundleVersion (String) specifies the build version number of the bundle, which identifies an iteration (released or unreleased) of the bundle. This is a monotonically increased string, comprised of one or more period-separated integers. This key is not localizable.
So it looks like this needs to be an ever-increasing version number and can't reset when the marketing version number changes. It seems like you could use your VCS revision number here; in my app I display the marketing version number and if the user "clicks" on it it adds the build number (CFBundleVersion) on the end. The primary purpose of this is to keep the version number clean and simple, but also allow QA and beta testers to determine the exact version of the product they're testing. The Subversion revision number would certainly help us track down the build being used, but in this case that'll be a strange version number jump for me (6 -> ~74000).
It seems like maybe we should just be using the CFBundleVersion alone rather than confusing things more. So 1.1.6 and 1.2.1 without any marketing version rather than 1.1(6) and 1.2(1). But at this point I can't switch without jumping to version 6.x or 7.x, so I may just end up incrementing the CFBundleVersion separately without regard for the marketing version number. So in my case, 1.2(7) - none of the other strategies makes much sense.
For my next project, I'll try using CFBundleVersion alone.
Just went through this process with fairly simple version numbers and here's what I found;
Original version '1.0'.
Next upgrade version '1.01' - worked fine.
Tried to submit an upgrade to version '1.1' and got the "CFBundleVersion in the Info.plist file must contain a higher version than that of the previously uploaded version" error.
After much messing around with the package including check the version in the package contents of the built program submitted as version '1.10' and it worked.
Seems like there is a problem with the string to float conversion that Apple is doing.
Just went through this process with fairly simple version numbers and here's what I found;
Original version '1.0'.
Next upgrade version '1.01' - worked fine.
Tried to submit an upgrade to version '1.1' and got the "CFBundleVersion in the Info.plist file must contain a higher version than that of the previously uploaded version" error.
After much messing around with the package including check the version in the package contents of the built program submitted as version '1.10' and it worked.
Seems like there is a problem with the string to float conversion that Apple is doing.
i had a similar problem. I had a free version of my Halloweeny app and i named it 1.1f in both itunes connect and in xcode.
the application loader kept failing on upload because of CFBundleID something another failed because of . needed positive integer or something.
basically i had to change 1.1f to 1.11 in both itunes connect and in xcode. the f had to be removed from the version number. no alphas allowed !
I had the same problem. The issue is that the version number is not interpreted as one single float number (where decimal places work like normal math). Instead, the version number is a series of integers separated by periods. For iOS version numbering 1.0 is two integers (1 and 0), not one float. So adding a 0 to the left of a number just makes it reduce to the number. If you submit version 02, it is the same as submitting version 2. The same happens to the right of the decimal delimiter. 1.02 is interpreted as the same as version 1.2 —the leading zero does not affect the value (because it is an integer). So going from version 1.02 to version 1.1 is interpreted as a step backwards: from version 1.2 to version 1.1
So the solution is to either use several decimals 1.2.1 or just increase the next version to next whole number (integer) to the right of the decimal. (In the examples above you would need to either submit version 1.3 or version 1.2.1)
Notice that this is the scheme that Apple uses when it releases iOS versions. The incremental version of iOS that follows 4.3 is not 4.31, but rather 4.3.1 And when there are too many "point releases," they don't get mathematical decimal numbers, but rather keep incrementing to the right of the decimal with integers. Example: The version that followed Mac OS X 10.4.9 was 10.4.10 (followed again by 10.4.11) Mac OS X Tiger - Wikipedia, the free encyclopedia
your problem is 1.01 is not even a real version number. The version string is not a double, it is dot separated integers. And you know that leading zeros in integers are redundant, i.e. 01 is the same as 1. Thus 1.01 and 1.1 are the same to the system.
1.0.1 is perhaps the version number you were trying to create in the first place if it was a bug fix release?
A quick update on this topic, as I see it still gets a lot of views. There are quite a few threads on the interweb that go into details on version numbering now. The short version (pun intended) is, if you want to be safe and to a large degree follow the way Apple does things in their own apps:
Make your Version (i.e. Bundle versions string, short) whatever combination of integers and dots you want. Apple appears to ignore this for app submissions and updates. Probably want to use period separated integers for user sanity and consistency.
Example: 1.0.3
Make your Build (i.e. Bundle version) an integer, with no period separations. You need to increment this by at least +1 for each update.
Example: 243
Most people increment +1 for every build they do.
So for customers, it may be the third version you shipped. For you it represents the 243 build you did (i.e. testing) to get there.
why not just do a normal versioning system like all good developers and avoid all the headaches?
I don't understand how people come up with these dumb numbering systems that don't make a bit of sense and then wonder why their apps are not getting approved.
just go:
1.0
1.1
1.2
2.0
etc.
how hard is that to do? Its not like you might run out of numbers.
why not just do a normal versioning system like all good developers and avoid all the headaches?
I don't understand how people come up with these dumb numbering systems that don't make a bit of sense and then wonder why their apps are not getting approved.
just go:
1.0
1.1
1.2
2.0
etc.
how hard is that to do? Its not like you might run out of numbers.
Your "suggestion" doesn't take into account maintenance releases, or internal build tracking. Nor does it tackle the integer versus float scenario that many people have run into.
Your average posts here are not correct enough for you to be throwing around phrases like this.
If you don't care about the thread topic, then don't post.
__________________
Do not quote questionable posts.
Do not post moderator requests in public. Report the post or send a PM. <----- Use the red flag button to report posts.
Just went through this process with fairly simple version numbers and here's what I found;
Original version '1.0'.
Next upgrade version '1.01' - worked fine.
Tried to submit an upgrade to version '1.1' and got the "CFBundleVersion in the Info.plist file must contain a higher version than that of the previously uploaded version" error.
After much messing around with the package including check the version in the package contents of the built program submitted as version '1.10' and it worked.
Seems like there is a problem with the string to float conversion that Apple is doing.
Same for me.
initial release was 1.0
Created update, and 1.1 wouldn't work (failed validation..), 1.10 worked
Can't Update App with New Version Number
Linear Mode
