浅谈 iOS 版本号

FIR.im 一直在尽可能兼容不一样使用习惯的版本号形式, 可是在使用中咱们发现好多开发者对怎么更好的用版本号来标示应用很陌生. 这是篇基础文章, 简单介绍 iOS 的版本号.

名词解释

• Version, 一般说的版本号, 是应用向用户宣传说明时候用到的标识. 通常有2段或者3段式, 如:2.1,8.1.2

Version 通常由产品部门肯定, 彻底迥异的更新须要改变主版本号, 好比 QQ 4.0 的变化很是大, 主版本的变化会更加吸引用户的眼球,因此有的应用会频繁的更新主版本号, 好比 FireFox 20.0 . 两段式的副版本号既包含小功能更新也会包含 bug 修复等,三段式副版本基本都是新功能添加和大问题修复,第三段则表示稳定版本基本都是修复 bug

• Build , 编译号指一次惟一编译标识, 一般是一个递增整数(安卓强制为数字, iOS 能够是字符串)

Build 都是给内部使用, 用来肯定一个惟一版本. 与前面提到的 Version 不会有太大联系.

iOS 开发中,这个2个号码均可以任意字符串或数字.

咱们目前遇到的状况有:

• 忽略了 Version 或 Build. 这两个号中的一个常年的不会发生变化.
• 颠倒了 Version 和 Build.

获取方法也很简单:

NSDictionary *info= [[NSBundle mainBundle] infoDictionary];

info[@"CFBundleShortVersionString"]; //Version info[@"CFBundleVersion"]; // Build

为何使用版本号

1. 方便标示和沟通

前面提到 版本号更新会给推广产生必定的积极做用. 因此版本号不要太长, 若是像这样 "咱们隆重推出了 某某某 1.7.14.19257 !", 这个会让用户感受很乏味很像电视购物,并且也不利于传播. 若是是 "某某 3.0, 大有不一样 !"可能就会产生更好的沟通效果.

2. 方便追踪 Bug

一个应用有 Bug 是确定的, 可是很快的定位解决问题却体现出团队和程序员的能力. 咱们常常遇到有开发者说我提交一个版本, 可是下载下来有仍是旧的. 咱们帮他解决问题的时候,他本身都搞不清哪一个是哪一个了, 若是能在"关于"之类的地方显示当前的版本, 就会容易找到问题.

或者是测试团队的同事, 可能手里同时有几个不一样分支的版本在测试, 他们须要精确的描述一个测试版本.

自动改变 Build 号

前面提到, Version 是不须要自动变化的, 根据产品或者市场部门的需求,适时的手动改一下就好.

1. agvtool (Apple-generic versioning tool)

agvtool, 是苹果的命令行工具, 也是集成在 Xcode 中最方便的工具. 咱们在自动编译 SDK 的脚本中用的就是这个方法. 其实就用了一行(其余的高级用法能够参考前面的连接):

agvtool next-version

使用前须要在 Xcode 里简单配置一下, 如图:

2. 基于SCM的版本控制号

SCM 如今经常使用的有 Git 和 SVN, 还有一些相对小众的好比 hg 这里就很少作介绍了.
若是用 Git/SVN 来管理代码(相信已经没有人不用了) 咱们能够用代码的提交次数来代替Build号.

• Git

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

其中 HEAD是分支名, 表明当前分支, 能够直接替换成其余分支名, 好比master,dev.
这个脚本放到

• SVN

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

后面都是同样的:

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

这样每次编译app的时候就自动把版本号加到Info.plist的CFBundleVersion键值下

把上面2行代码 加到 "Build Phase > Run Script"就能够了:

3. 基于日期时间

用发布日期做为版本好也是许多应用经常使用的方式, 由于好记好理解. 这里直接附上代码:

REV=`date +%y%m%d` #输出格式141120的六位日期格式,能够根据本身喜欢改变格式

后面都是同样的:

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

使用方法同上.

怎么使用

只要配置好了版本号, 其余的事情就不须要人工干预了, 这里介绍2种使用场景.

1. Crash 收集

收集 Crash 是应用开发必要的环节, 经过分析和修复 Crash 信息能够大大提升应用的稳定性而不会让更多的用户失望甚至删除应用.
目前有不少收集工具, 好比 FIR.im 旗下的BugHD, Crashlytics等.

2. 用户反馈

能主动反馈问题的用户都是极品用户, 无论要求是否是合理咱们都要认真对待.
不论是用各类 SDK 仍是用 Email 都要尽可能的带上版本号, 系统信息, 方便确认用户需求.最不济也要在"关于"里面能让用户找到相关的版本信息以便描述问题.

做者：Travis 本文为FIR.im团队原创，转载请注明出处！