CFBundleVersion in the Info.plist Upload Error
Asked Answered
K

30

111

"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’m getting this error when I come to upload my application.

I set the updated version to 1.2 on iTunes Connect and have also updated the .plist file to 1.2.

I don’t understand why I am getting this error. Any help would be appreciated. Thanks.

Katlynkatmai answered 8/2, 2011 at 12:38 Comment(6)
Why not try and set it to, say, 1.2.1 ?Orlina
I’ve tried many combinations. None work. That error keeps coming up.Katlynkatmai
And what's the previously uploaded version (as found in the Info.plist of the currently shipping app)?Mayolamayon
Did you have this issue resolved? The same problem happened to me all of sudden. It is frustrating.Whiteman
I just got an email with this error and it turns out that one of my old builds, which was stuck in ITC as "processing" for the past week, was finally processed. When it first became stuck I resubmitted another build with an incremented build number, so when the older one finally got processed it triggered the error.Storz
https://mcmap.net/q/153188/-application-loader-error-itms-90062-the-value-for-key-cfbundleshortversionstring-must-contain-a-higher-versionStuckup
D
213

There's at least 1 known bug in Apple's upload server that they've not fixed for more than 12 months. Things to beware of:

  1. Apple deletes any leading zeroes inside the version number; i.e. the "whole string" is NOT treated as a number, instead the bits between dots are treated as SEPARATE numbers. e.g. "1.02" is treated by Apple as "1.2". So, for Apple, 1.02 is GREATER THAN 1.1
  2. Apple sometimes gets "confused" and seems to compare your uploaded-app to the version of a DIFFERENT app you've previously uploaded. It's happened to a lot of people, and I've seen it myself a few times
  3. Apple is supposed to be comparing the "CFBundleVersion" (i.e. "Bundle version" not the "Bundle versions string, short"); don't get mixed up.
  4. Frequently, the only viable solution is to bump the front number (e.g. the "2" in "2.4" -- increase it to "3")
  5. The version number you upload is unrelated to the version number that appears in iTunes - you can put anything you want there, and that's what your users will see
  6. ...except, if you also report the "actual" version number inside your app, the user will see the CFBundleVersion (usually, depends how you code it), rather than the iTunes version (which - I think - cannot be accessed from inside your app)
Dinse answered 17/5, 2011 at 20:56 Comment(7)
CFBundleVersion is what in xcode 4.5 is labeled "Build", and NOT "Version"! Version ends up labeled "CFBundleShortVersionString" in the Info.plist file. So, indeed you need to supply a higher value for Build than previously.Cuttie
+1 Helpful one. I used 1.02 for my previous version. And, fix it using this answer. Thank you.Swagman
This answer should be added in the FAQ section on how to submit an app to app store. :))Hirohito
@Adam: As I've read the CFBundleShortVersionString and the version number you provided in iTunes Connect should match. That means that if you show your version number in the app you use CFBundleShortVersionString. The CFBundleVersion should be also increased and that is the one Apple uses to determine if you are submitting an updated version of your app.Efflorescent
Apple has recently redefined what all their strings mean, in a NON backwards compatible way.Dinse
I used 1.0.7 as version number and I had to change that to 108 (without dots) and it finally worked. Maybe the recommendation could be to use an integer for version number and do not, ever, dare to play with dots.Colorific
great explanation, still hate how insane Apple made this compared to how the Play Store works, but it's Apple...Unintelligent
P
29

Update the build number. The version number is important, but the build number makes all the difference. For example I had my initial version of an app as:

version #: 1.0
build #:   1.0

However when I tried to upload the next version, i.e.

version #: 1.1
build #:   1.0

It wouldn't accept the upload. By simply incrementing the build # to 1.1 the upload was accepted.

Pozsony answered 23/12, 2011 at 15:56 Comment(1)
Perfect...changing the build # did it for me, which is great since I really wanted to keep my bundle version and iTunes version in sync.Mientao
M
9

Xcode 4 will think you want to re-upload the same version if you do not re-archive the application. Even if you change the Bundle Version and rebuild, the upload will fail. Remember to do a "Archive" in the Product menu!

Militarist answered 1/5, 2012 at 14:58 Comment(0)
W
7

Many of the answers here ultimately helped me but it wasn't until what I saw the exact "version" number that Apple was comparing.

  1. Go to iTunes Connect -> Manage Your Applications
  2. Choose the application you want to check the previous version for
  3. Click on the blue button labeled View Details
  4. Click the link labeled Binary Details
  5. Find the value given for Bundle Version

Even though I thought I had submitted version number 1.0.1, the actual number that Apple stored was 101. Some of the comments above made me believe I needed to change my version to 2.0 (20) or 1.5 (15) or 1.2 (12)—these are all less than 101 as you can see. Updating my version number 102 (without the dots) fixed the issue.

Wellfavored answered 13/2, 2013 at 1:57 Comment(0)
E
6

This article points out that the version number as seen in the app-store is not necessarily the same as the bundle version number. When you view your app's details in iTunes, there's a link named 'Binary Details'. That page shows the bundle version. One of the apps I was working on was at version 1.0, but it's bundle version was 2.0. Uploading a bundle with version 1.1 failed, but 2.1 did work.

So, there's an app version and a bundle version. This problem has to do with the bundle version.

Engenia answered 12/4, 2011 at 14:47 Comment(0)
D
5

It seems confusion is caused by the number format. The bundle version is not a decimal. It is a version (or build perhaps) so 1.11 is actually "one point eleven". Hence 1.11 is greater than 1.2. I had success using 1.20 in this case.

Disruption answered 2/11, 2011 at 3:50 Comment(0)
A
4

Usually, this may caused due to the absence of version number. So, add version number under Identity, and also check the Build number .

enter image description here

Keep Coding......... :)

Anett answered 16/9, 2014 at 8:59 Comment(0)
P
3

For me (Xcode 4.5) changing build number solved the problem. set versions to 1.0.2 ... 2.0.2 etc. then increase build # (Adam 3 point give me an idia where to look).

Proverbial answered 19/11, 2012 at 0:32 Comment(0)
C
2

You should be able to login to iTunes Connect and see the current version of the app (including any you've submitted but are not live). Check to make sure you haven't previous submitted a version with a higher (or the same) version number.

Counterproof answered 23/2, 2011 at 19:43 Comment(2)
This is misleading; Apple does NOT simply compare against the iTunesConnect version. c.f. Pieter's answer below for a more accurate answer.Dinse
@Dinse As of now (2014-05), Apple does indeed compare your iOS app's internal version number(s) with the iTunesConnect version number. If mismatched, you get this warning message (not an error): Version Mismatch - Neither CFBundleVersion ['201405030503'] nor CFBundleShortVersionString ['201405030503'] in the Info.plist match the version of the app set in iTunes Connect ['1.0.0']. But this iTunesConnect-comparison is not the cause of the problem in this Question. The iTunesConnect-comparison is a mere warning, not a show-stopping error.Eileneeilis
W
2

I spent a few hours trying to resolve this issue. I have checked with all my might to ensure the CFBundleVersion was indeed higher than the older version, by opening the info.plist on a text editor, get info of the target and read the version on the properties, asked my wife to read the version on iTunes to confirm I did not get hit by an unexpected earlier Alzheimer.

In the end, this somehow did the trick. My older version was 1.0.4. I tried 1.3.5, 1.4.5 etc.; none worked. But surprising enough, when I entered 2.0.0, Application Loader likes what it saw and uploaded it. Is this due to a bug in the Application Loader?

Whiteman answered 22/3, 2011 at 22:27 Comment(0)
O
2

In the targets summary next to the version number in xcode4 is a build, I started this at 1, I increment each time I do a binary upload, this resolved the issue for me

Overtrade answered 1/10, 2011 at 5:14 Comment(2)
This was my problem as well, the error message is very misleading!Hautboy
I also had this problem. It's incredibly frustrating that the message is so misleading. Wasted the better part of my afternoon. Thank you for the helpful answer.Saber
D
2

If the error reported is the CFBundleVersion the fix is usually pretty easy. Check/try this:

  1. Go to the top level project item in the Project Navigator and click on it.
  2. In the panel just to the right click on the application target.
  3. Click on the summary tab.

On the summary tab you will see that there are two different "versions" that can be adjusted. The first one is the "Version" field, which is used in the default "About" screen for Mac apps. The one to the right is the "Build Version." This is the one that really matters for App Store submissions!

Diabetes answered 20/3, 2013 at 13:45 Comment(0)
P
2

I know this is an old question, but I just ran into this issue. I solved it by deleting the project from the archive, then re-archiving it. Apparently the previous version of the app was sitting in there and causing confusion.

Premeditation answered 7/7, 2013 at 20:0 Comment(0)
D
2

Pay attention to the error message.

The error message contains previous bundle number in square brackets (e.g. [9]).

Thus you need to increment that bundle number (e.g. 9.1), although your new version number is 1.2

So when you update the version from 1.1 to 1.2 in iTunes Connect you need to set these values in your project

Version number = 1.2
Bundle number = [previous bundle number]++
Duckweed answered 24/1, 2014 at 21:48 Comment(1)
NOTE: if you aren't sure what the bundle # was for the last version uploaded, click on the older version and look for Binary Details (under Links). You should see "Bundle Version: #"Fattish
N
2

I had the same problem and it happened due to I haven't archived and I was using the first archive that I used for the 1.0 but with the 1.0.1. So I selected iOS device, archived and then validate. Ta-daaa, it worked!

Nicol answered 30/4, 2014 at 13:20 Comment(0)
A
1

I have a iPhone and an iPad version in my project, the infoplist for the ipad was not associated with the ipad product for some reason, Checking Target membership and associating it with the correct product solved this issue for me.

Acme answered 23/4, 2012 at 20:54 Comment(0)
V
1

I found the solution for this error in this post CFBundleVersion must be higher than previous version

hope this helps!

Vacla answered 4/3, 2013 at 22:26 Comment(0)
S
1

I made a mistake by interchanging the 'Version' and the 'Build' no.

Instead of putting the 2.3 in the Version field, I put it in the Build no.

Selves answered 16/2, 2014 at 16:31 Comment(0)
P
1

Here is how I fixed the problem (and I'm guessing this is the issue with a lot of people):

1) Click on the general tab of your projects settings (which can be accessed by clicking on your project name which is at the top of all the code files).

2) Make sure the build field matches what you put in your plist for the "Bundle Version" key.

This was the problem for me, for whatever reason they were out of sync. I think when you change Bundler Version key it's supposed to sync up (and vice versa). But it didn't happen for whatever reason - might be a bug.

Podgy answered 19/3, 2014 at 7:20 Comment(0)
R
0

I've spent two nights on a similar issue. My previous version was 1.02, and I tried validating with 1.2, 1.20, 1.1 and I always got the invalid binary message.

I solved it by entering 2.0 as the version number, and that worked. I suspect this is a bug as well. I did not get this message when recently upgrading my game from 1.0 to 1.1, but that was with xcode 3. Thanks for the tip!

Retroflex answered 28/3, 2011 at 19:26 Comment(0)
S
0

I had the same problem. Basically my previous version was 1.12 I wanted to change it to 1.2 but had the mentioned error. I did try 1.20 and it did work perfect

Shabbygenteel answered 8/6, 2011 at 19:42 Comment(2)
The second number must be between 0 and 9, so 12 is "too big"Yager
The "second number" (let me call it minor version number, just for fun) can be any integer, there is no bounds for it; so the 12 or 20 is perfect minor version number.Courcy
L
0

No set of ever-increasing version numbers worked as long as I was using Apple's "Application Loader" to upload my ipa file, but if I used XCode's "Organizer" (found under the "Window" pull-down in version 3.2.5), clicked the "Validate..." button, waited for it to approve me, then click the "Submit..." button, everything went as expected with a sane version number (one that is a single increment above that which is currently available on the app store).

Li answered 12/7, 2011 at 10:43 Comment(0)
L
0

in xcode 4.2 it seems do not register the bundle version if you modify from info.plist file. I set my new bundle version directly in xcode panel "info" and now it works!

Lanfranc answered 22/11, 2011 at 14:32 Comment(0)
S
0

I found another solution.

If you select your target>>info>>update Bundle ID.

Swellfish answered 1/8, 2012 at 7:32 Comment(0)
A
0

I had the same problem. First submitted version was 1.5.20 and wanted to update to 1.7.30.

After unsuccessfully trying versions 1.8, 2.0 and 3.0, I updated my CFBundleVersion to 10.0 and suddenly it worked.

I'm not sure what the logic behind this behavior is, but it caused me to waste about 2 days of worktime.

Alginate answered 1/9, 2012 at 19:40 Comment(0)
A
0

Check your bundle version of the previously uploaded version,you should give higher bundle version compare to the bundle version of already uploaded version.The already uploaded version can be view by itunesconnect/application/view details/binary details.

Abele answered 6/11, 2012 at 12:31 Comment(0)
O
0

I had similar problem and after spending half an hour I noticed I was increasing wrong number. Instead of increasing Bundle version I was increasing Bundleversions, string, short in Info.plist. Search "CFBundleVersion" in your project using CMD + Shift + F. You will see you need to increase CFBundleVersion number.

Onomastic answered 21/2, 2014 at 10:0 Comment(0)
D
0

Try change version="1.1.1.0" to version="1.1.1"

Dignadignified answered 11/7, 2015 at 20:22 Comment(0)
R
0

As of late October Apple requires version numbers to be less than 4 digits (1.2.3 or 1.23 as opposed to 1.2.3.4 or 1.234). This applies to libraries too!

A quick grep for the offending version number in your project directory should turn up the offending library:

grep -r "1.2.3.4" .

Ramon answered 9/11, 2015 at 5:45 Comment(0)
H
0

I had an active TestFlight beta running. Build 2020, version 407

I submitted an app for official App Store review. Build 2020, version 435, and it was approved. It is just sitting there, waiting for me to push it live into the App Store.

Without adding a complicated side story, what I wanted to do is to give my TestFlight beta users an updated version to preview the official App Store version for a few days, before making the App Store version live. Why, you ask? Because they were getting free features, there were about to cost money once the app would go live.

So, I submitted Build 2020, version 436, to TestFlight, and it was rejected.

It was rejected because I have an approved official App-Store candidate with the same build number

Solution: Change the build number of your TestFlight version. I submitted Build 20200 (I added an extra zero) version 436 to TestFlight, and it was approved. Don't worry, you can still push this build to the same TestFlight beta group, as long as you're still using the same BundleID.

Harrovian answered 3/10, 2016 at 16:39 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.