前言
最近不少 iOS 開發者都收到了蘋果的警告郵件，在郵件中，蘋果稱開發者使用了動態代碼更新技術，要求開發者刪除相關代碼，并重新提交一個新的 App 版本以供審核。
郵件原文翻譯如下：
尊敬的開發者，
您的應用，擴展程序和/或鏈接框架似乎包含明確設計的代碼，能夠在應用審核批準后更改應用的行為或功能，這不符合 Apple 開發人員計劃許可協議和應用的第 3.3.2 節商店審查指南 2.5.2。此代碼與遠程資源相結合，可以幫助對應用程序的行為進行重大更改，與最初對 App Store 進行審核相比。雖然當前可能不使用此功能，但它可能會加載私有框架，私有方法，并支持未來的功能更改。
這包括將任意參數傳遞給動態方法（如
dlopen()、dlsym()、respondingToSelector:、performSelector:、method_exchangeImplementations()）和運行遠程腳本以便更改應用程序行為或調用 API 的任何代碼，下載的腳本。即使遠程資源不是故意惡意的，它也可能很容易被劫持通過中間人（MiTM）攻擊，這可能對您的應用程序的用戶造成嚴重的安全漏洞。請對您的應用執行深入審核，并刪除符合上述功能的任何代碼、框架或 SDK，然后再提交下一個更新以供審核。
而上文提到的蘋果開發者協議 3.3.2 節具體內容如下:
一個應用程序不應該下載或安裝任何可執行代碼。解釋執行的代碼可以在應用內使用，如果所有的腳本、代碼，和解釋器都被打包在應用內而沒有被下載。前述內容的唯一的例外在于下載的腳本和代碼使用了 Apple 內置的 WebKit 框架或 JavaScriptCore，并且對應的腳本或代碼并沒有改變這個應用提供功能和特性的主要目的，與提交到 App Store 的版本以及相應的宣傳描述相符。
蘋果警告郵件波及甚廣，在 GitHub 的?JSPatch?和?react-native?項目下非常多的 iOS 開發者在討論這件事，也因為蘋果并沒有具體指明，導致了大家的各種猜測。今天，React-Native 官方已經辟謠，確認不是 React-Native 的問題，而是 JSPatch / Rollout 的問題，而?JSPatch 作者 bang 也發文對此進行了回應，并表示：
動態化還是處于灰色地帶，嚴格來說 RN 是不符合規則的，但還是被允許，只要不給蘋果添麻煩，蘋果就不會管，JSPatch 因為前面提到的兩點風險被管了，怎樣做到使用并不給蘋果添麻煩呢？
減少使用人數，降低影響面；
禁止 SDK 接入；
接入保證傳輸安全和只用于修復 bug。
第一點警告郵件和代碼檢查使得使用門檻變高了，顯然會減少使用人數。第二點第三點只要有一個平臺來管控，是可以做到的，可能的話希望能跟蘋果審核團隊協商。
至此，我們不禁要思考，蘋果是不是完全禁止熱更新技術了？為什么要這么做？對于這幾個問題，白鷺引擎架構師王澤撰文分享了他的觀點，并闡述了此事件是否會對手游開發產生影響，具體如下：
蘋果是不是完全禁止了熱更新技術？
并不是，目前為止收到警告郵件的開發者絕大部分使用了 JS-Patch 或 Rollout 類庫，剩下未直接使用這些類庫的開發者，目前初步估計很可能是在集成的第三方 SDK 中使用了上述框架。而未采用上述框架的熱更新技術，目前為止并未收到影響。而絕大部分游戲引擎由于并沒有調用這些類庫，也自然沒有受到影響。
當然，后續事態會不會進一步擴大，還需要看蘋果接下來的策略。但是筆者認為，游戲中的熱更新技術并不會受到蘋果的禁止，作為一名技術人員，我們不討論產品、商業等問題，只從技術角度來看，為什么 JSPatch 蘋果認為是不允許的，而游戲引擎的熱更新技術，蘋果目前認為是可以的。
蘋果為什么要禁止 JSPatch 等熱更新技術？
JSPatch 的原理是，開發者編寫 JavaScript 代碼，利用蘋果內置的?JavaScriptCore.Framework?執行，以實現熱更新功能。這一點看似也符合標準，但是在技術上，存在著重大安全隱患，參考 JSPatch 的業務邏輯：
require('UIView')var view = UIView.alloc().init()view.setBackgroundColor(require('UIColor').grayColor())view.setAlpha(0.5)簡單理解，JSPatch 可以理解為所有的 Objective-C 的 API 進行了映射，允許開發者在 JS 端調用任意原生代碼，這顯然是極其危險的。假設這段代碼是通過熱更新技術下載執行的，如果在中間存在黑客，把這段代碼動態替換掉，比如修改為獲取用戶通訊錄并上傳到黑客的服務器，就會造成重大的安全問題。
為什么游戲熱更新技術可以被理解為是安全的？
與 JSPatch 不同的是，游戲熱更新技術主要的實現方式是把動態腳本下載之后，讓動態腳本調用游戲引擎提供的接口實現缺陷修復。與 JSPatch 不同的是，動態腳本并不能任意調用全部原生代碼，而是只能根據游戲引擎提供的接口調用相關功能。在這個過程中，游戲引擎的原生端作為一個安全沙箱，提供了一個安全的保護層，只要游戲引擎不要對外提供獲取通訊錄的接口，黑客就無法通過替換動態腳本的方式獲取用戶的隱私資料。進而可以被認為是安全的，自然不在蘋果的禁止范圍內。
小結
蘋果認為熱更新技術容易被黑客利用，造成重大安全問題。在官方警告郵件中，也是在進行如此描述。
JSPatch 這種基于反射，允許獲取全部系統接口的方式，確實存在著一定的安全風險。雖然可以通過安全策略去防范，但是蘋果決定一刀切，嚴格禁止。
游戲引擎由于不是利用反射機制實現的熱更新，不能獲取全部系統接口，所以目前蘋果認為是安全的，無需警告。
最后，筆者作為一名技術人員，以上所有內容，都是基于客觀的技術層面進行討論，請勿上升到“商業模式”、“生態閉環”等層面的“高度”，歡迎技術層面的交流討論。
