淺談 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]//'`

後面都是同樣的:

/usr/libexec/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的六位日期格式,能夠根據本身喜歡改變格式

後面都是同樣的:

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

使用方法同上.

怎麼使用

只要配置好了版本號, 其餘的事情就不須要人工干預了, 這裏介紹2種使用場景.

1. Crash 收集

收集 Crash 是應用開發必要的環節, 經過分析和修復 Crash 信息能夠大大提升應用的穩定性而不會讓更多的用戶失望甚至刪除應用.
目前有不少收集工具, 好比 FIR.im 旗下的BugHD, Crashlytics等.

2. 用戶反饋

能主動反饋問題的用戶都是極品用戶, 無論要求是否是合理咱們都要認真對待. 不論是用各類 SDK 仍是用 Email 都要儘可能的帶上版本號, 系統信息, 方便確認用戶需求.最不濟也要在"關於"裏面能讓用戶找到相關的版本信息以便描述問題.