Build & Version In Identity Of App For IOS
(The build version that identifies an iteration of the bundle)
This key is a machine-readable string composed of one to three period-separated integers, such as 10.14.1. The string can only contain numeric characters (0–9) and periods.
Each integer provides information about the build version in the format [Major].[Minor].[Patch]:
- Major: A major revision number.
- Minor: A minor revision number.
- Patch: A maintenance release number.
You can include more integers but the system ignores them.
You can also abbreviate the build version by using only one or two integers, where missing integers in the format are interpreted as zeros. For example, 0 specifies 0.0.0, 10 specifies 10.0.0, and 10.5 specifies 10.5.0.
This key is required by the App Store and is used throughout the system to identify the version of the build. For macOS apps, increment the build version before you distribute a build.
(The release or version number of the bundle)
This key is a user-visible string for the version of the bundle. The required format is three period-separated integers, such as 10.14.1. The string can only contain numeric characters (0–9) and periods.
Each integer provides information about the release in the format [Major].[Minor].[Patch]:
- Major: A major revision number.
- Minor: A minor revision number.
- Patch: A maintenance release number.
This key is used throughout the system to identify the version of the bundle.
CFBundleShortVersionString gives you the version of your app. It’s typically incremented each time you publish your app to the App Store. This is the version that is visible on the “Version” section for the App Store page of your application.
CFBundleVersion gives you the build number which is used for development and testing, namely “technical” purposes. The end user is rarely interested in the build number but during the development you may need to know what’s being developed and fixed on each build. This is typically incremented on each iteration of internal release. And you can use continuous integration tools like Jenkins to auto-increment the build number on each build.
The two numbers do not depend on each other but it is a good idea to keep them parallel to avoid confusion. Keep in mind that once your app has passed the App Store review you need to increment the build number like Phil and likeTheSky have stated, regardless of whether you publish it or not.
Use case: Let’s say, you have a well-tested build, ready for submission. It is version number is 1.0.0 and build number is 1.0.0.32. Once you submit your app, you need to update the version as 1.0.1 and build number as 1.0.1.0.
