107

Apple's doc could have been more clear on how to submit an update version.

As asked in the title, What's the difference between

  1. version number in itunes connect(which you have to supply when you submit an update)
  2. bundle version in xcode
  3. bundle versions string, short

Are they related in any way?

pkamb
  • 33,281
  • 23
  • 160
  • 191
eugene
  • 39,839
  • 68
  • 255
  • 489

6 Answers6

150

Yes, they are related. They all refer to the version of your application.

  • iTunes Connect
    This is the version number shown in the App Store; This must be a pure version number like 1.2.3

  • Bundle Version (CFBundleVersion)
    This doesn't need to be a pure version number. This can be something like 12345 or 1.2.3 (Build 12345AB). This is shown in the About window for Mac OS X apps for example and is often more a "Build Number" than a "Version Number".

  • Bundle Version String (CFBundleShortVersionString) This value is used as the "real" version number. This must be the same string as used for the version in iTunes Connect.

Update:
As pointed out by @snlehton, the CFBundleVersion has to be a pure version number like 1.2.3 when you want to upload your application to the (iOS) App Store.

Fabian Kreiser
  • 8,307
  • 1
  • 34
  • 60
  • @Kreiser, one more question, when testing an update version, do I increment bundle version or bundle version string? well, I could increment both, but which one is the one that counts? – eugene Sep 02 '11 at 09:30
  • 3
    For **testing** you set the bundle version string to the final version number like `1.2.3` and then increment the bundle version for each build. – Fabian Kreiser Sep 02 '11 at 12:58
  • 21
    **THIS IS WRONG** CFBundleVersion needs to be in for x.y.z, otherwise uploading a build will fail! [link](http://www.dribin.org/dave/blog/archives/2006/08/02/versioning_os_x_apps/) – snlehton Feb 15 '13 at 08:37
  • When uploading to iTunes Connect? This change must be new, but a version string of "1.2.3 (Build 12345AB)" *is* possible. From your link: `Effectively, LS expects the following format: nnnnn[.nn[.nn]][X] where n is a digit 0-9, square brackets indicate optional components, and X is any string not starting with a digit. X is ignored when present.` – Fabian Kreiser Feb 15 '13 at 09:11
  • 2
    I recently submitted a build with CFBundleVersion with "1.0.2 RC3" and it bounced with error message: "The bundle is invalid. The key CFBundleVersion in the Info.plist file must be a period-separated list of non-negative integers." I think the nn.n.nxnnn is the correct format to use, but haven't tried it out yet. – snlehton Feb 21 '13 at 07:48
  • 1
    Also, CFBundleShortVersionString does NOT need to match the iTunes Connect version, but really it should. We accidentally submitted a build with version 1.0.3 in the iTunes and 1.0.2 in the CFBundleVersion and CFBundleShortVersionString. Now it displays 1.0.3 in the store and 1.0.2 in the install, which is really stupid. But it didn't bounce, oddly enough. – snlehton Feb 21 '13 at 07:49
  • Thanks for the info, I've updated my answer. Regarding the iTunes Connect version: I've submitted an app where the version in iTunes Connect didn't match the version specified in the Info.plist and the Application Loader complained about it. It'd be interesting to know when and why Apple changed that. – Fabian Kreiser Feb 21 '13 at 08:07
  • 3
    CFBundleVersion of 1235 here, no problems – Piotr Tomasik Aug 15 '13 at 20:31
  • Is CFBundleVersion visible to end-users on iOS? – funkybro Sep 11 '13 at 15:36
  • Yes, `CFBundleVersion` is the version displayed in the iTunes page for the app. It is also shown as the version when displaying your app in the App Store app on device. – progrmr May 27 '14 at 22:03
  • 2
    No, only CFBundleShortVersionString will be shown in iTunes and on the device. – Fabian Kreiser May 28 '14 at 07:17
  • 6
    The confusion here is because the CFBundleShortVersionString is optional and when it is set it changes what the CFBundleVersion is used for. If only including CFBundleVersion then it must be the public version number, e.g. 1.0. However if both the CFBundleVersion and CFBundleShortVersionString are set then the CFBundleShortVersionString must now me the public version number, e.g. 1.0. And now the CFBundleVersion changes to be the build number, which is normally a single integer e.g. 374629. Hopefully this clears it up. – malhal Feb 23 '15 at 16:40
  • So if it's optional why can't I now just leave it away. I'm going nuts on this version stupidity. Instead of telling me on upload "wrong number, please" it starts that silly process and sends me two mails. Even Mickeysoft could not design worse >:-( Just removed the "optional" and it now croaked upon upload "Unable to...." – qwerty_so Jun 29 '15 at 16:39
  • What version number are you using? See the answer below (http://stackoverflow.com/a/28679170/322548) for clarification on how iTunes Connect behaves when omitting the optional value. – Fabian Kreiser Jun 30 '15 at 14:23
37

Yes they are related but their definition depends on how they are used.

  • iTunes Connect Version

    Always must be a version number, e.g. 1.0

Usage mode 1 - Only CFBundleVersion is set

  • Bundle Version (CFBundleVersion)

    Must be a version number, e.g. 1.0. Must match the iTunes Connect Version.

Usage mode 2 - Both CFBundleVersion and CFBundleShortVersionString are set

  • Bundle Version (CFBundleVersion)

    Must be a build number, e.g. a single integer like 435163.

  • Bundle Short Version String (CFBundleShortVersionString)

    Must be a version number, e.g. 1.0. Must match the iTunes Connect Version.

Usage mode 2 is the best way to go. Here are some example numbers for an app's upgrade path:

CFBundleShortVersionString CFBundleVersion 
1.0                        1
1.0.1                      2
1.0.2                      3
1.2                        5  (build 4 was a beta and never released publicly)
1.2.1                      6

An extra note on version numbers: If you submit a minor update (e.g. bug fix) to your app you must never miss out periods in the version number, e.g always use 1.0.1 and NEVER 1.01 or you will risk not being able to use certain version numbers in the future because it won't be possible to increment them.

malhal
  • 26,330
  • 7
  • 115
  • 133
14

Yep, they all are related.

Version Number in itunesconnect is the version number you need to supply. For example, 2.1.1 or 3.1.2 etc. This also should be equal to the CFBundleShortVersionString.

Bundle Version In Xcode (CFBundleVersion) represents just the Build number which identifies an iteration (released or unreleased) of the application.

Bundle versions string, short (CFBundleShortVersionString) is a number comprising of three integers separated by dots. First one represents any major updates of the application, such as updates that implement new features or major changes. The second integer denotes revisions that implement less prominent features. The third integer represents maintenance releases.

mayuur
  • 4,736
  • 4
  • 30
  • 65
  • 3
    Actually, "Bundle versions string, short" doesn't need to be THREE numbers separated by dots. I think "1" and "1.1" are also valid. – Nicolas Miari Nov 10 '14 at 11:36
  • actually from my testing Version Number in itunesconnect is completely indipendent from CFBundleVersion and ShortVersion. So you can even have them different – Marco Pappalardo Sep 20 '17 at 08:47
10

Be careful about CFBundleVersion. It's not only a production build number. This value is checked by Apple during binary upload process, and it can fail it.

Be sure you set CFBundleVersion with the value of CFBundleShortVersionString when you build your release to submission.

See this post about it

Community
  • 1
  • 1
aponaute
  • 201
  • 2
  • 7
  • 3
    This is correct info, the accepted answer actually has it wrong. – snlehton Feb 15 '13 at 08:38
  • 10
    This is not correct, `CFBundleVersion` does not have to match `CFBundleShortVersionString`. For example, if you look at the current .ipa file for Chrome (in the app store now) they have "34.0.1847.18" for `CFBundleVersion` and "34.1847.18" for `CFBundleShortVersionString`. – progrmr May 27 '14 at 22:06
  • 7
    There is no documentation saying that CFBundleVersion and CFBundleShortVersionString should be the same. – Toydor Nov 27 '14 at 23:39
8

The accepted answer is the way to go -- just adding this as an example.

For our last release, the "Bundle Version String, short" was required, and I went ahead and matched it with the Bundle version number (1.2.8 for our app).

I then enabled Testflight, and made the version pending Apple review (1.2.8) available to our internal testers. A tester however found an issue that required fixing, and we deleted the binary in place. When uploading a new build, we got an error indicating the build version was already uploaded.

After reading a few SO links and Apple docs, my understanding was to make the bundle version: 1.2.8.001, while maintaing bundle-version-short the way it was. If a new build is required, we increment bundle-version to 1.2.8.002.

Note: the upload was accepted, and the build shows up as "1.2.8.001" under pre-release. The version number remains 1.2.8.

ahash
  • 510
  • 7
  • 12
4

The accepted answer of this link contains good details :: Which iOS app version/build number(s) MUST be incremented upon App Store release?

From apple docs

CFBundleVersion ( Bundle version )

CFBundleVersion (String - iOS, OS X) specifies the build version number of the bundle, which identifies an iteration (released or unreleased) of the bundle. The build version number should be a string comprised of three non-negative, period-separated integers with the first integer being greater than zero. The string should only contain numeric (0-9) and period (.) characters. Leading zeros are truncated from each integer and will be ignored (that is, 1.02.3 is equivalent to 1.2.3). This key is not localizable.

CFBundleShortVersionString (Bundle versions string, short)

CFBundleShortVersionString (String - iOS, OS X) specifies the release version number of the bundle, which identifies a released iteration of the app. The release version number is a string comprised of three period-separated integers. The first integer represents major revisions to the app, such as revisions that implement new features or major changes. The second integer denotes revisions that implement less prominent features. The third integer represents maintenance releases.

The value for this key differs from the value for CFBundleVersion, which identifies an iteration (released or unreleased) of the app. This key can be localized by including it in your InfoPlist.strings files.

Community
  • 1
  • 1
muzz
  • 4,324
  • 2
  • 24
  • 14