App的開發總會面臨着新功能的迭代和Fix Bug,這個時候的App就須要進行升級而且及時通知用戶更新。對於更新的一些小功能,考慮到用戶所處環境可能不具有更新條件,通常不要求用戶即刻的去升級App,只須要及時通知到用戶就夠了。可是若是這次更新捨棄了大部分舊功能的需求或是Fix重大Bug的狀況下,就須要讓用戶強制進行升級,不然就沒法正常使用app。git
不過如今Apple不容許以彈窗的方式告知用戶更新,在審覈時發現會被據回,Apple更但願看到的是在用戶手機鏈接Wifi的時後臺自動進行升級。可是若是用戶關閉了自動更新,或是一直未鏈接到wifi,此時app修復了嚴重bug須要強制升級的話就行不通了。因此現在須要一些策略來進行App的彈窗控制升級。github
兩種版本控制方式數據庫
實現和注意網絡
獲取appid的方法app
AppStore上的每一個App都惟一對應一個AppID,咱們能夠經過調用下面兩個接口任一個來獲取應用當前的版本信息。
http://itunes.apple.com/cn/lo...
http://itunes.apple.com/looku...(其中的appid要替換成你本身的appid號,如QQ的appid爲444934666)
post
因爲新版本的App在經過審覈以後AppStore上該App的版本信息纔會更新,因此能夠經過利用該時間差來進行版本控制。spa
好比當前AppStore上App版本爲2.0,此時須要進行審覈的新版本爲3.0。由於還沒有經過審覈,因此在審覈人員操做3.0版本的App時,App從iTunes的接口獲取到的版本號信息依舊爲2.0,經過判斷3.0 > 2.0,因此審覈人員在操做3.0版本的App時並不會彈出須要升級的提示。
在App上架後,當用戶在操做App時,App從iTunes的接口獲取到的版本號信息變成了3.0,此時將會通知用戶進行升級。版本控制
不須要本身定義接口,使用方便;code
更新時間的控制比較準確。只要新版本上架,用戶打開app時就能看到更新提示。blog
不能自定義升級類型。由於調用的是itunes的接口,沒法控制接口返回數據,因此不能在「選擇升級」和「強制升級」之間進行自定義控制。
第一種方式不能自定義升級類型,其根本緣由在於沒法自定義接口的返回數據,因此咱們能夠定義接口,在本身服務端後臺維護一份app版本信息,返回數據中咱們能夠返回一個字段專門用來控制是否進行強制升級控制。
自定義程度高,可自定義升級類型、是否顯示彈窗等等。後續還能夠創建一個內部的app版本控制平臺。
須要新增接口;
須要及時的更新版本信息。
經過上述的對比,其實我以爲第二種方案的缺點能夠忽略,通常app都會有本身的服務端,因此在工做量容許的範圍內能夠考慮第二種方案,畢竟須要應對大版本迭代或是發生重大Bug的狀況。其實現在有不少的問題均可以經過熱更新方案及時解決,不過熱更新不是萬能的,強制更新能夠做爲另外一層保障。
對於無服務端或服務端不是由本身搭建的app,或是對bug的容忍度較大的app,能夠考慮第一種方案。
在時間容許的前提下,對於有成熟服務端的app能夠儘可能考慮第二種方案。
1.在app啓動回調中觸發檢查更新方法; 2.調用接口獲取最新的版本信息; 3.判斷須要更新後彈出alert提示。
對於調用itunes接口的方案:
接口返回數據裏的version字段爲版本號,trackViewUrl字段爲下載連接,判斷version須要更新後使用代碼調用safari打開trackViewUrl對應的連接便可。
好比QQ:@"version": @"6.6.9","trackViewUrl": "https://itunes.apple.com/cn/app/qq/id444934666?mt=8&uo=4"
對於自定義更新的方案:
可經過本身定義的接口字段來判斷是否升級、新版本下載連接、升級類型等。
附github地址:https://github.com/MagicianMa...
對於本身服務端維護的接口,app的下載地址或其餘信息能夠經過第一種方案獲取後保存到數據庫,下載地址要在app上架後查看是否有改變並及時更新。
強制升級的實現,可在alert的點擊事件中再彈出alert來實現控制。
若是用戶在app打開時,經過關閉網絡數據來避掉升級提示,須要進行一些控制。好比,能夠在基類控制器viewDidLoad:方法中從新判斷app版本信息,並可將版本信息維護在本地,以防止接口調用次數過多。
1.在itunes中搜索並找到應用後複製連接
2.連接中id後的數字就是appid
3.在postman中能夠看到該app的相關信息