A brief discussion on iOS version numbers: Developers on how to better use version numbers to identify applications

We have been trying to make version numbers compatible with different usage habits, but we found that many developers are unfamiliar with how to better use version numbers to identify applications. This is a basic article that briefly introduces iOS version numbers.

Glossary

• Version, commonly referred to as version number, is an identifier used when an application is promoted to users. It usually has 2 or 3 segments, such as: 2.1 , 8.1.2

Version is usually determined by the product department. Completely different updates require changing the major version number. For example, the changes in QQ 4.0 are very large, and the changes in the major version will attract more users' attention. Therefore, some applications will frequently update the major version number, such as FireFox 20.0 . The two-part minor version number includes both small function updates and bug fixes, etc. The three-part minor version number basically adds new functions and fixes major problems. The third part indicates that the stable version basically fixes bugs.

• Build, build number refers to a unique build identifier, usually an increasing integer (Android is forced to be a number, iOS can be a string)

Build is for internal use to determine a unique version. It has little to do with the Version mentioned above.

In iOS development, these two numbers can be any string or number.

The situations we are currently facing are:

• Ignore Version or Build. One of these numbers will not change for years.
• Reversed Version and Build.

The method of obtaining it is also very simple:

 NSDictionary *info= [[ NSBundle mainBundle] infoDictionary]; info[ @"CFBundleShortVersionString" ]; //Version info[ @"CFBundleVersion" ]; // Build

Why use version numbers?

1. Convenient labeling and communication

As mentioned above, version number updates will have a positive effect on promotion. So the version number should not be too long. If it is like "We grandly launch XXXX 1.7.14.19257!", it will make users feel boring and like TV shopping, and it is not conducive to dissemination. If it is "XXXX 3.0, very different!", it may produce better communication effect.

2. Convenient Bug Tracking

It is certain that an application has bugs, but quickly locating and solving the problem reflects the ability of the team and programmers. We often encounter developers who say that they submitted a version, but the version downloaded is still old. When we help them solve the problem, they themselves can't figure out which is which. If the current version can be displayed in places such as "About", it will be easier to find the problem.

Or colleagues in the test team may have several different branches of the version being tested at the same time, and they need to accurately describe a test version.

Automatically change the build number

As mentioned above, Version does not need to be changed automatically. You can manually change it according to the needs of the product or marketing department.

1. agvtool (Apple-generic versioning tool)

agvtool is Apple's command line tool and the most convenient tool integrated in Xcode. We use this method in the script to automatically compile the SDK. In fact, it only takes one line (for other advanced uses, please refer to the previous link):

 agvtool next -version

Before use, you need to do some simple configuration in Xcode, as shown in the figure:

2. SCM-based version control number

The most commonly used SCMs nowadays are Git and SVN, and there are some relatively niche ones such as hg which I will not introduce in detail here.
If you use Git/SVN to manage code (no one uses it anymore), we can use the number of code commits instead of the build number.

• Git

 REV=`git rev-list HEAD | wc -l | awk '{print $1}' `

HEAD is the branch name, representing the current branch, and can be directly replaced with other branch names, such as master , dev .
This script is placed

• SVN

 REV=`svnversion -nc | sed -e 's/^[^:]*://;s/[A-Za-z]//' `

The rest are the same:

 PlistBuddy -c "Set :CFBundleShortVersionString ${REV} " " ${TARGET_BUILD_DIR} " / ${INFOPLIST_PATH}

In this way, each time you compile the app, the version number will be automatically added to CFBundleShortVersionString key value in Info.plist

Just add the above two lines of code to "Build Phase > Run Script":

3. Based on date and time

Using the release date as the version is also a common method used by many applications because it is easy to remember and understand. Here is the code directly:

 REV= `date +%y%m%d` #输出格式141120的六位日期格式,可以根据自己喜欢改变格式

The rest are the same:

 PlistBuddy -c "Set :CFBundleShortVersionString ${REV} " " ${TARGET_BUILD_DIR} " / ${INFOPLIST_PATH}

The usage is the same as above.

How to use

As long as the version number is configured, no manual intervention is required for other things. Here are two usage scenarios.

1. Crash Collection

Collecting crashes is a necessary part of application development. By analyzing and fixing crash information, the stability of the application can be greatly improved without disappointing more users or even causing them to delete the application.
There are many collection tools, such as BugHD and Crashlytics under FIR.im.

2. User Feedback

Users who can actively report problems are excellent users. We will take their requests seriously regardless of whether they are reasonable or not.
Whether you use various SDKs or emails, you should try to include the version number and system information to facilitate confirmation of user needs. At the very least, you should allow users to find relevant version information in "About" to describe the problem.