在產品工作中，經常要對產品APP進行迭代升級。本文作者根據自己的工作經驗，對APP版本升級管理這個問題展開了深入的思考，希望對你有幫助。

移動端功能開發測試完成后，需要引導用戶安裝新版本，針對用戶量級較大的APP這個過程中會分為兩個階段：灰度階段和正式階段。

灰度階段是面向部分用戶投放應用，目的是驗證應用包的可用性及兼容性問題。正式階段是面向全量用戶投放正式的應用，目的是引導用戶升級到新的版本。

實施方式：

灰度階段有兩種方式：APP灰度——全量功能APP分發給部分用戶試用。功能灰度——部分功能由后臺控制開關供部分用戶使用正式階段（全量開放）：經檢驗沒有問題的APP上傳到各應用市場，同時引導老用戶進行版本升級

本文僅針對正式階段，面向全量用戶進行新版本升級引導的APP版本升級管理進行展開討論。

版本升級流程：

版本升級總共分為兩步：安裝包發布到官網，引導用戶升級到新版本。

流程圖如下：APP官網投放、iOS需要上傳appstore審核，安卓可依據需求投放不同應用市場。

特別說明：因為App Store存在審核時間長的特性（3-14天不等），如果需要兩端同步發布一般是需要先將iOS端進行提審，再講安卓提審（安卓應用市場審核周期為一天左右），等到應用包已經上架應用商店后，接下來就是引導已經安裝APP的老用戶進行升級到新版本各應用商店有自己的應用升級方式。

但是升級過程會很被動（比如用戶關閉自動升級，新版本存在功能不兼容導致用戶不能使用），所以需要我們自己開發管理后臺去控制各版本之間的升級方式

運營配置升級流程：

引導用戶升級需要在后臺做兩步：配置需要升級的安裝包信息，設置升級方案。

第一步：填寫安裝包信息

不同渠道的安裝包需要填寫的安裝包信息不同，iOS之所以分為三種發布類型是可以理解為兩個用途：appstore用于正式安裝包配置，企業分發/testflight為內部測試升級使用。

testflight是蘋果提供給開發者專用的測試方式，用戶需要測試之前需要安裝蘋果提供的一個testflight工具，然后會收到開發者的測試升級邀請，或者通過開發者開放的一個公開鏈接去下載測試包。

testflight這種方式一是測試人數有上限（9999人），二是需要額外安裝工具。

內部測試的話，也可以通過企業證書打包的方式，企業證書是面向企業內部員工使用的APP的開發者證書。開發者只需要將應用打包，生成應用下載二維碼，這樣用戶就可以直接掃碼安裝。

兩者可以依據現實情況考慮，不是必要選項。

第二步：設置升級方案

這里面有兩種主流升級方式：依據最新版本升級方式引導升級，依據用戶當前所用版本升級方式引導用戶升級。

依據最新版本升級方式引導用戶升級：不管用戶當前所用版本，所有版本都是依據最新版的升級方式來升級的。

優點：引導性強，可以快速引導全量用戶升級到最新的版本。

缺點：影響范圍廣，比如本次新版功能只針對上個版本用戶做了bug修復，需要強制升級，但是其他版本用戶雖然沒受到影響也需要跟著一起強制升級。

依據用戶當前使用版本的升級方式引導用戶升級：新版發布時，為每個歷史版本配置該版本的升級模式，比如新發布2.0.0版本，為1.2.0版本配置提示升級，為1.1.0版本配置不提示升級，為1.0.0版本配置強制升級。

優點：針對性強，可以兼容歷史版本，用戶影響范圍小。

缺點：維護成本高，隨著版本數量增多，會存在需要維護的歷史版本多的情況所以升級方案參考了上面的兩種升級方式，采用第一種依據最新版本升級方式，但又補充了最小兼容版本，盡可能在用戶體驗及維護成本中平衡，先看下用戶端的升級判斷邏輯。

提醒用戶升級方式有四種：

升級策略的觸發條件除了最新版本配置的升級方法外，考慮到了歷史版本兼容性問題，增加了最小兼容版本的這個字段，就能滿足在固定版本以前無法正常使用，需要強制升級的邏輯場景。

最小兼容版本就是，最新版本升級邏輯僅支持的最小版本號，小于該版本的歷史版本均采用強制升級，保障用戶的基本使用體驗，其余版本則遵循最新版配置的升級邏輯。

版本管理列表：

新建版本：

客戶端升級彈窗：

總結：

做好一個移動端產品，除了需要研發新的功能滿足用戶的需求，還需要關注版本的更新迭代節奏。如何用更好的方式引導用戶升級，以及建立良性的迭代循環和版本兼容管理，都是值得思考的，如果更多的好的想法歡迎一起交流溝通~