ITunes Connect 中的“版本号”、 Xcode 的“捆绑版本”和“捆绑版本字符串”有什么区别？

苹果的文档本可以更清楚地说明如何提交更新版本。

正如题目中所问, 这两者有什么区别

  1. Itunes connect 中的版本号(在提交更新时必须提供该版本号)
  2. 在 xcode 中的 bundle 版本
  3. 捆绑版本字符串，短

他们之间有什么联系吗？

75850 次浏览
小开
最佳答案

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.

小开

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.

小开

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

小开

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.

小开

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.

小开

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.


提交答案