Is it correct that different versions of a submitted app are compared using CFBundleVersion

1
votes

According to bullet point 3 of the accepted answer here: CFBundleVersion in the Info.plist Upload Error

Apple is supposed to be comparing the "CFBundleVersion" (i.e. "Bundle version" not the "Bundle versions string, short")

However in this posting: Difference between Xcode version (CFBundleShortVersionString) and build (CFBundleVersion)

It says Version maps to CFBundleShortVersionString and Build maps to CFBundleVersion.

Therefore that means when you submit a new version of an app to the app store, the comparison is being done on the build and not on the version that you see in the XCode summary page.

This seems the wrong way round to me - especially given the quote from the Apple documentation:

CFBundleShortVersionString represents a release version, whereas CFBundleVersion represents any build, released or not.

This means when submitting a new version of an app you need to be concerned with the build number, not the release number, which to me seems odd. Its more odd because according to this: What's the difference between "version number" in itunes connect, "bundle version", "bundle version string" in xcode?

The CFBundleShortVersionString MUST be the same as in iTunesConnect. Then why are Apple checking the CFBundleVersion and not the CFBundleVersionShortVersionString?

I have submitted an app where both the version and build were 1.0, now I want to submit a new version and have bumped both to 1.0.1, will this cause any issues when submitted?

1
iosxcodeapp-store

1 Answers

2
votes

The reports from users seem to be inconsistent. Also, the SO answers are more than 2 years old.

The section about "configuring your app" in Apple's App Distribution Guide says this:

Setting the Version Number and Build String

The version number is a two-period-separated list of positive integers, as in 4.5.2. The first integer represents a major revision, the second a minor revision, and the third a maintenance release. The version number is shown in the store and that version should match the version number you enter later in iTunes Connect. For details on possible values, see “CFBundleShortVersionString” in Information Property List Key Reference.

The build string represents an iteration (released or unreleased) of the bundle and can contain a mix of characters and numbers, as in 12E123. For Mac apps, the user can click the version number in the About window to toggle between the version number and the build string. For details on possible values, see “CFBundleVersion” in Information Property List Key Reference.

For iOS apps, update the build string whenever you distribute a new build of your app for testing. iTunes will recognize that the build string changed and properly sync the new iOS App Store Package to the device. For how to configure your app for testing, read “Beta Testing Your iOS App.”

This indicates that for the App Store what matters is CFBundleShortVersionString and it should match the value in iTunes connect. And that changes to CFBundleVersion are considered when differentiating between builds for testing.

However, this somehow contradicts what "Information Property List Key Reference" says about CFBundleVersion

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.

It isn't the first time or the last that Apple's docs have contradicting information.

Personally, I'd go with the App Distribution Guide guidelines but setting the same version number for both values seem to comply with both documentations, so you should be ok.

For my Mac OSX app, I am using a dotted version in CFBundleShortVersionString and a running integer (that corresponds to my SCM revision number) in CFBundleVersion. Submitting updates like that for years and never had a problem