Version vs build in Xcode
I have an app that I developed with Xcode 3 and recently started editing with Xcode 4. In the target summary I have the iOS application target form with fields: identifier, version, build, devices, and deployment target. The version field is blank and the build field is 3.4.0 (which matches the version of the app from when I was still editing with Xcode 3).
My questions are:
What is the difference between the version and build fields?
Why was the version field blank after I upgraded to Xcode 4?
Apple sort of rearranged/repurposed the fields.
Going forward, if you look on the Info tab for your Application Target, you should use the "Bundle versions string, short" as your Version (eg, 3.4.0) and "Bundle version" as your Build (eg, 500 or 1A500). If you don't see them both, you can add them. Those will map to the proper Version and Build textboxes on the Summary tab; they are the same values.
When viewing the Info tab, if you right-click and select Show Raw Keys/Values , you'll see the actual names are CFBundleShortVersionString (Version) and CFBundleVersion (Build).
The Version is usually used how you appear to have been using it with Xcode 3. I'm not sure on what level you're asking about the Version/Build difference, so I'll answer it philosophically.
There are all sorts of schemes, but a popular one is:
{MajorVersion}.{MinorVersion}.{Revision}
Then the Build is used separately to indicate the total number of builds for a release or for the entire product lifetime.
Many developers start the Build number at 0, and every time they build they increase the number by one, increasing forever. In my projects, I have a script that automatically increases the build number every time I build. See instructions for that below.
Other developers, including Apple, have a Build number comprised of a major version + minor version + number of builds for the release. These are the actual software version numbers, as opposed to the values used for marketing.
If you go to Xcode menu > About Xcode , you'll see the Version and Build numbers. If you hit the More Info... button you'll see a bunch of different versions. Since the More Info... button was removed in Xcode 5, this information is also available from the Software > Developer section of the System Information app, available by opening Apple menu > About This Mac > System Report... .
For example, Xcode 4.2 (4C139). Marketing version 4.2 is Build major version 4, Build minor version C, and Build number 139. The next release (presumably 4.3) will likely be Build release 4D, and the Build number will start over at 0 and increment from there.
The iPhone Simulator Version/Build numbers are the same way, as are iPhones, Macs, etc.
Update : By request, here are the steps to create a script that runs each time you build your app in Xcode to read the Build number, increment it, and write it back to the app's {App}-Info.plist file. There are optional, additional steps if you want to write your version/build numbers to your Settings.bundle/Root*.plist file(s).
This is extended from the how-to article here.
In Xcode 4.2 - 5.0:
/bin/bash . Copy and paste the following into the script area for integer build numbers:
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"
As @Bdebeez pointed out, the Apple Generic Versioning Tool ( agvtool ) is also available. If you prefer to use it instead, then there are a couple things to change first:
Note that with the agvtool method you may still periodically get failed/canceled builds with no errors. For this reason, I don't recommend using agvtool with this script.
Nevertheless, in your Run Script phase, you can use the following script:
"${DEVELOPER_BIN_DIR}/agvtool" next-version -all
The next-version argument increments the build number ( bump is also an alias for the same thing), and -all updates Info.plist with the new build number.
And if you have a Settings bundle where you show the Version and Build, you can add the following to the end of the script to update the version and build. Note: Change the PreferenceSpecifiers values to match your settings. PreferenceSpecifiers:2 means look at the item at index 2 under the PreferenceSpecifiers array in your plist file, so for a 0-based index, that's the 3rd preference setting in the array.
productVersion=$(/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" "$INFOPLIST_FILE")
/usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:2:DefaultValue $buildNumber" Settings.bundle/Root.plist
/usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:1:DefaultValue $productVersion" Settings.bundle/Root.plist
If you're using agvtool instead of reading the Info.plist directly, you can add the following to your script instead:
buildNumber=$("${DEVELOPER_BIN_DIR}/agvtool" what-version -terse)
productVersion=$("${DEVELOPER_BIN_DIR}/agvtool" what-marketing-version -terse1)
/usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:2:DefaultValue $buildNumber" Settings.bundle/Root.plist
/usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:1:DefaultValue $productVersion" Settings.bundle/Root.plist
And if you have a universal app for iPad & iPhone, then you can also set the settings for the iPhone file:
/usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:2:DefaultValue $buildNumber" Settings.bundle/Root~iphone.plist
/usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:1:DefaultValue $productVersion" Settings.bundle/Root~iphone.plist
(Just leaving this here for my own reference.) This will show version and build for the "version" and "build" fields you see in an Xcode target:
- (NSString*) version {
NSString *version = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleShortVersionString"];
NSString *build = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleVersion"];
return [NSString stringWithFormat:@"%@ build %@", version, build];
}
In Swift
func version() -> String {
let dictionary = NSBundle.mainBundle().infoDictionary!
let version = dictionary["CFBundleShortVersionString"] as? String
let build = dictionary["CFBundleVersion"] as? String
return "(version) build (build)"
}
The Build number is an internal number that indicates the current state of the app. It differs from the Version number in that it's typically not user facing and doesn't denote any difference/features/upgrades like a version number typically would.
Think of it like this:
CFBundleVersion ): The number of the build. Usually you start this at 1 and increase by 1 with each build of the app. It quickly allows for comparisons of which build is more recent and it denotes the sense of progress of the codebase. These can be overwhelmingly valuable when working with QA and needing to be sure bugs are logged against the right builds. CFBundleShortVersionString ): The user-facing number you are using to denote this version of your app. Usually this follows a Major.minor version scheme (eg MyAwesomeApp 1.2) to let users know which releases are smaller maintenance updates and which are big deal new features. To use this effectively in your projects, Apple provides a great tool called agvtool . I highly recommend using this as it is MUCH more simple than scripting up plist changes. It allows you to easily set both the build number and the marketing version. It is particularly useful when scripting (for instance, easily updating the build number on each build or even querying what the current build number is). It can even do more exotic things like tag your SVN for you when you update the build number.
To use it:
agvtool new-version 1 (set the Build number to 1) agvtool new-marketing-version 1.0 (set the Marketing version to 1.0) See the man page of agvtool for a ton of good info
上一篇: 组合静态库
下一篇: 版本vs构建在Xcode中