APP 在發布之后，會根據產品的發展和用戶的需求不斷更新迭代。本文作者就 APP 版本在更新管理中必備的需求設計進行了分析，與你分享，希望對你有幫助。

【資料圖】

一、app 的更新流程

app 都會不斷迭代更新，在應用市場上架的 app，常見的更新， iPhone 是跳轉到 App store 更新完成后打開即完成，Android 通常是檢測到新版本，下載完成，繼續安裝再次啟動即可。

app 更新的流程圖大致如下：

一般 app 更新這個環節是技術主導去完成，產品這邊主要是提更新策略，提供上架審核的資料等。這種也是 app 需要上架的情況。

還有另一種情況，app 不需要在應用市場上架。app 只給部分人員，通常是公司內部少部分人使用，只需把最新的安裝包發給相關人員，完成安裝即可。

本文敘述的內容是 app 更新策略的需求設計，指通過用戶端和服務端聯合實現用戶端多版本檢測更新。

二、名詞概念說明

app 更新策略有兩種，分為強制更新和非強制更新：

強制更新：app 更新到最新版本才可使用，在應用內常見的表現是彈窗提示強制升級才能正常使用，不做升級會直接退出應用。

非強制更新：用戶不更新到最新版本的也能正常使用。

app 更新的提示也分為兩種：提示和不提示，根據提示的頻次分為強提示和弱提示。更新策略 + 更新提示組合就組成了應用常見的 4 種升級方式：強制升級、強提示升級、弱提示升級、不提示升級。

不同升級策略的使用場景：

根據不同的升級場景選擇不同的升級策略，以下為 4 種策略的使用場景和界面示意：

強制升級：一般是 app 出現重大 bug 嚴重影響用戶使用，或者后續更新的功能未能兼容到所有版本，低版本的需要升級到高版本才能正常使用新功能。在啟動 app 時不做升級只能退出應用，如下圖所示：

我們的 app 上新時會往起兼容兩個版本，通過埋點數據也能看到在 app 上了新版本后一周內，蘋果用戶基本都會更到最新，安卓用戶在 40-50% 左右，所以我們的 app 很少強制更新，只會對版本很低的使用這個策略。

強提示升級：強提示升級是在啟動 app 時提示用戶自主去做升級，用戶可選擇升級也可選擇下次再升級，不升級到最新版本不影響 app 的使用。用戶選擇下次再升級后，可根據設置的升級提示頻次提醒用戶，如：啟動 app 提示、一天提示一次、三天提示一次、七天提示一次等等。

強提示升級通常用于指引用戶完成升級后使用某些功能，我們平臺曾跟建行合作過一次營銷活動，在平臺開建行戶后即可獲取一定的獎勵金額，完成這次活動是需要在我們平臺接入開通銀行卡 sdk，接入 sdk 是無法兼容舊版本的，且不更新到最新版本也不影響正常使用我們的 app，但為了達成此次活動目標，制定的策略是用戶在參加活動時會判斷用戶當前的版本號，若不是最新版本會提示用戶更新到最新版才能參與，提示的頻次是：每次都會提示，不升級到最新版不能參與。

弱提示升級：弱提示跟強提示的區別在于提示的頻次，在 app 的內可用彈窗或者是 tooltip 等更弱的提示，若用戶選擇不立即更新，之后就不再提示用戶升級。

不提示升級：不提示升級就是 app 在發布新版后在 app 端不使用彈窗或 tooltip 提示，通常是在 app 端版本更新頁面，通過紅點等方式引導用戶進入目標頁面做版本檢測和更新。

三、管理后臺設計

管理后臺主要是維護 app 更新策略，在梳理清楚 app 端升級場景后可著手于管理后臺的設計，app 端偏向于場景梳理，管理后臺著重于邏輯。在管理后臺的設計上規則還是先正后異，也即先按照正常流程設計，再補充異常流程，最后切換視角檢查。

正常流程：各平臺 app 的升級策略，延展開即為 iOS 或安卓端 app 的那個版本在何時按照何種升級策略進行升級，升級的內容是什么。根據正常流程即可梳理出創建版本升級所需的字段內容，如下圖所示：

異常流程：在需求設計中，異常場景的考慮十分關鍵，在開發和測試環節，技術和測試同學也不會放過任何一個異常的。對于異常流程的思考其實就是對正常流程的找茬，對正向流程的每一個節點加上變量后看出現的情況是否已有相應的解決方案，

例如：app 是根據版本號進行判斷進行更新，當前有 1.0、1.5、2.0、2.5、3.0 個版本，制定的策略是：2.5 版本強更，如此設定后，2.5 以下的版本應為強更，2.5 上的版本可設置強更或非強更，也即是 app 的更新策略應為多條。

異常情況整理如下：

第一種情況：更新版本號為強更時，低于更新版本號的版本也要為強更，高過更新版本號的版本可強更或不強更。

第二種：更新版本號為非強更時，低于更新版本號的版本可以非強更或強更，高于更新版本號也可如此。

第三種：更新版本號為非強更時，若低于更新版本中有過強更的策略，則低于強更的版本應更新到強更版本。

四、總結

app 升級管理很常見且不復雜的需求，在做設計之前也參考了一些別人的設計，但看的一知半解的，把本次的需求設計整理下來一是新寫作方向的嘗試，二是想把需求設計用更簡單的方式表達出來。

本文由 @努力努力再努力的 PM 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議。