前言

3月8號，很多iOS群炸鍋了，原因是不少iOS收到了蘋果的警告郵件，在郵件中，蘋果稱開發者使用了動態代碼更新技術，要求開發者刪除相關代碼，并重新提交一個新的 App 版本以供審核。

郵件中明確指出，違反了蘋果開發者協議 3.3.2 節：

一個應用程序不應該下載或安裝任何可執行代碼。解釋執行的代碼可以在應用內使用，如果所有的腳本、代碼，和解釋器都被打包在應用內而沒有被下載。前述內容的唯一的例外在于下載的腳本和代碼使用了 Apple 內置的 WebKit 框架或 JavaScriptCore，并且對應的腳本或代碼并沒有改變這個應用提供功能和特性的主要目的，與提交到 App Store 的版本以及相應的宣傳描述相符。

作為一個iOS開發者，又剛好手上有個KPI任務和熱更新相關，所以特別關注這塊。借鑒國內外大神們的分析和個人見解，寫一些我認可的想法和對以后熱更新的安全策略。

一些問題

1、蘋果是不是完全禁止熱更新技術？

事情已經過去了幾天，可以看到蘋果爸爸并沒有進一步擴大“戰果",受災的開發者集中在使用JS-Patch或者Rollout類庫，可以明確的看出蘋果不會完全禁止熱更新，當然蘋果爸爸是不會公開說明這些的。

從事件的起因上，主要是由于國外大量APP使用Rollout.io熱更新引發的安全性問題。國外具備更成熟的開發測試環境，另外蘋果本身對APP審核速度的加快，熱更新技術并不像國內這么"猖獗"，也沒有國內這么"熱衷"，所以相較于國內，國外熱更新用的其實并不多，但可能外國民眾自我隱私和保護、安全意識的高覺，蘋果迫于壓力不得不將Rollout.io砍掉，至于JS-Patch更覺得是被順便砍了一刀。

2、為什么游戲熱更新技術被理解為安全的，而JSPatch等熱更新理解為不安全的？

從事過游戲開發的開發者，肯定接觸過熱更新，至少90%的游戲都支持熱更新，像現在APP端熱更新實現原理都來源于游戲熱更新，但這次卻沒有一個游戲因為熱更新被警告，所以從這可以看出，游戲熱更新技術是被理解為安全的；反過來說，JSPatch等熱更新理解為不安全的。

但，游戲熱更新真的安全嗎？真的和JSPatch這些熱更新有本質的區別嗎？

可以很明確的說，游戲的熱更新和JSPatch這些熱更新并沒有本質上的區別，cocos2d-js，unity3D-js 等js熱更新中就使用JavaScriptCore.Framework實現;而至其他像lua熱更新也是類似基本上都是源于runtime，改寫原有方法。。所以本質上他們并沒有區別。所以，我更傾向于像Rollout.io CEO說的那樣，這次僅僅是蘋果對3.3.2協議的一次狹隘的偏見，熱更新技術本身，蘋果是不禁止的。

3、RN是否會受到影響，是否被蘋果禁止？

RN近一年來備受關注，行業內大受好評，甚至像BAT等一些大公司都會有直接招RN的職位。RN的優點在于跨平臺，仿原生，還有一點是熱更新。RN用的語言是js，同時又能熱更新，鑒于jsPatch被警告，很多開發者猜測，以后RN開發的APP是否被蘋果拒之門外，然而事實證明，在github,RN社區里面，可以看到RN其實并沒有受到影響，從這也可以看到蘋果對熱更新技術其實并不是禁止的。

從個人角度來說，RN的優勢是非常明顯的，相較于之前的跨平臺框，html5等，RN不僅僅實現的跨平臺技術，仿原生技術，另外還有重要的一點是性能上，對于大多數APP來說，比原生差不了多少。而3.8號微軟新出的20周年visula studio2017版，對RN的支持，也可以看出微軟對RN的認同，至于RN最后能不能大一統，我想還是有可能的。由于硬件不再是瓶頸，低一點效率的語言對最終用戶來說感覺并不明顯，但采用RN可以省去大量開發、維護、學習成本，大一統應該也是大勢所趨吧。

一些猜想

1、蘋果本身并不想砍掉熱更新

熱更新的優點，不僅僅實現了在線的bug fix，功能模塊增加，同時在這個背后節省了大量測試人員成本和測試時間成本（因為即使線上APP出問題了，也可以通過熱更新修復，測試必然就沒那么謹慎），也減輕了蘋果公司本身對APP審核成本（如果沒有熱更新，開發者就會提交新的APP），同時由于及時的熱更新也為蘋果創造了更多的利益（APP出問題了，等審核修復，中間的幾天用戶就不能為蘋果創造利益了）。所以熱更新對于開發者、蘋果本身、用戶都有很好的作用，可以大膽猜想，這次蘋果只是迫于壓力，或者只是看Rollout不順眼，做了一次警告，當然里面肯定也有蘋果對熱更新的”猖獗“打擊。

2、蘋果自己不會做熱更新

假如蘋果自己開發一個工具，支持熱更新，蘋果還是得審核patch（不可能不審核）,這和開發者重新提交APP審核對于蘋果來說是一樣的，這樣APP還是不能及時更新，唯一的好處可能是不用重新到APPStore重新下載，如果這樣子，不管是對開發者來說并沒有達到熱更新的效果，同時對于蘋果來說，還加重了審核成本，然而并沒產生任何效益。所以，可以猜測蘋果自己不會做熱更新。

3、如何做一個符合蘋果要求的熱更新

從上文的論述中，雖然蘋果不會明確公開說明--你們可以大膽的熱更新，可以看到蘋果本身對熱更新并不排斥，甚至有那么點支持。其核心問題其實就是，如果出了問題誰背鍋。如果開發者可以保證下載的patch一定是開發者自己本身創造的，出了問題開發者自己背鍋，我想蘋果審核者肯定會閉一只眼的。

像github社區中，對如何避免APP熱更新被下架，有說針對dlopen()、dlsym()、respondingToSelector:、performSelector:、method_exchangeImplementations()幾個方法的代碼混淆，這實現上并不難，但誰也不能保證這是不是所有檢測的方法，難道一次次提交APP測試 O(∩_∩)O？

我的個人猜想是可以采用類似android加固的方式，下載的patch增加一個殼，下載app后，去掉殼，保證patch的安全性；至于如何加殼，我想如果可以把開發者證書的信息包含進去，應該會更安穩點。

最后

天下熙熙，皆為利往。說到底，最終都是為了利益，至于是不是和我猜想的一樣，也不能完全保證，對于大蘋果的生態圈來說，也許并不像我所看到的那樣。但從蘋果對RN、游戲的熱更新的模棱倆可，可見，只要對蘋果有利，又不給蘋果帶來麻煩，不管你上層用什么語言開發，只要底層還是OC,最后還是通過APPStore，給大蘋果創造利益，它也不會找你麻煩。

參考資料：

http://geek.csdn.net/news/detail/185602

https://baijiahao.baidu.com/po/feed/share?wfr=spider&for=pc&context=%7B%22sourceFrom%22%3A%22bjh%22%2C%22nid%22%3A%22news_3347847651371257825%22%7D

https://github.com/bang590/JSPatch/issues/746