在 Info.plist 上传错误中的 CFBundleVersion

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.

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?

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!

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.

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)

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

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).

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

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.

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!

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.

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.

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!

I found another solution.

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

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.

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.

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).

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.

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

hope this helps!

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!

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.

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]++

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.

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.

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.

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!

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

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

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

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" .

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.