一、前言
對於蘋果商店的iOS的應用更新，一直以來都是由開發者提交App應用包給蘋果，蘋果審覈通過後，方可在iTunesConnect進行發佈，這中間往往要經過一到兩週的時間。
對於一些嚴重問題的修復，雖然你可以提交加急審覈，但這也最少需要一到兩天的時間，往往做不到十分的及時。
基於這個痛點，一些提供動態更新來進行緊急問題修復的三方庫或者三方服務也就應運而生了。
二、開源庫還是三方服務，這是個問題
方案對比
如果你想要給自己的App添加動態更新的功能，那並不困難，現在可以實現動態更新的方案有不少，比如以JSPatch、WaxPatch爲代表的一些github開源庫，還有rollout和JSPatch作者官方動態更新服務等一些三方服務，這些基本都能滿足基於嚴重bug fix爲目標的需求。
那麼到底是使用開源庫還是三方服務呢，又該如何選擇呢？不如我們來對比一下這兩種方式的優缺點：
- 開源庫（以JSPatch爲例）
-
工程配置
只需要下載項目源碼或者指定pod依賴，然後添加少量配置代碼即可。
-
更新實現
按照文檔規範編寫JS文件，在適當的時機，通過自己約定的服務端接口下載相應文件，然後使用開源庫API執行JS文件。 -
安全機制
必須自己對JS文件和接口本身做一些校驗工作，較繁瑣。 -
灰度發佈
需要自己設計灰度發佈方案。 -
版本控制策略
需要自己設計版本控制的策略，較繁瑣。 -
功能擴展
你可以在開源項目的基礎上進行封裝和拓展，根據自己App實現定製化需求。（例如統計、版本控制等要求） -
開源庫本身BUG修復
如果開源庫存在一些問題，可以提問題給開源庫作者，等待修復，緊急情況下，也可以直接fork一份代碼，依靠自己及時進行BUG修復，較爲靈活。
- 三方服務（以JSPatch作者官方動態更新服務爲例）
-
工程配置
在官方網站下載SDK加入工程，然後添加少量配置代碼即可。
-
更新實現
按照文檔規範編寫JS文件，在指定的應用管理頁面上傳到對應版本的App即可。 -
安全機制
官方服務會對文件下載和獲取會有接口和文件的校驗，不需要我們關心這部分內容。 -
灰度發佈
官方服務提供灰度發佈和條件發佈。 -
版本控制策略
官方服務有對App版本和Patch版本進行版本控制。 -
功能擴展
不易拓展。 -
SDK的BUG修復
如果官方SDK存在問題，需要聯繫服務提供者，只能等待修復後使用。
結論
如果你想***快速便利***的對自己的App接入動態更新服務，且不用考慮依賴本身存在的問題，那使用***三方服務***是個很不錯的選擇，安全策略、版本控制策略以及灰度發佈等都不需要自己關心。
如果你想隨時掌控依賴對自己App產生的影響，隨時可以***解決依賴對工程造成的影響***，那麼你可以使用***開源庫***，不過這就需要花費較大的時間做一些其它工作。