蘋果為什么要全面禁止熱更新

　　6月1日，部分開發者在 iTC 后臺收到了一則通知：蘋果要求當前含有熱更新功能的 App，在6月12日前移除相關代碼，否則這些APPp 可能會下架。那么蘋果為什么要全面禁止熱更新呢？蘋果全面禁止熱更新怎么辦？下面小編就帶大家一起來詳細了解下吧。

　　6月1日，部分開發者在 iTC 后臺收到了一則通知：蘋果要求當前含有熱更新功能的 App，在6月12日前移除相關代碼，否則這些APPp 可能會下架。

　　據相關報道，蘋果在今年 3 月份的時候就曾向所有開發者推送警告郵件，宣布未來將禁用 APP 內部的“動態分發”功能。并要求開發者在自家 APP 中刪除 JSPatch 相關框架，否則 APP 將面臨下架或禁止上架。6月1日，蘋果再次重申：要求當前含有熱更新功能的 APP，在6月12日前移除相關代碼，否則這些APP可能會下架。從 6 月12日開始，iOS 可能會出現一次 APP 下架的小高潮。

　　據悉，蘋果已經向所有開發者發送了警告郵件，宣布未來將禁用APP內部的“動態分發”功能，并要求開發者在自己APP中刪除JSPatch相關框架，否則APP將面臨下架或禁止上架，最終期限是6月12號。目前，國內很多APP都使用了JSPatch，其中就有騰訊的微信和QQ等王牌產品。

　　此次蘋果的態度非常明確，封殺熱更新，全面收回APP更新的審核權限。據了解，“熱更新”是利用軟件內的框架協議，允許軟件從網絡中下載并運行調用可執行代碼，對軟件進行修改。簡單來說，就是IOS系統用戶通過Apple store下載APP后，打開APP時遇到的即時更新。

　　有評論稱由于“熱更新”繞過蘋果漫長的審核，直接通過服務器推送進行版本的迭代，因此被國內眾多APP所采用。在蘋果看來，這樣的做法對用戶的信息安全造成了極大的隱患，容易被黑客利用，因此要求IOS開發者移除相關代碼，并重新提交版本審核。這將使蘋果自身的系統更為封閉，保障IOS的可控性和安全性。

　　而上文提到的蘋果開發者協議 3.3.2 節具體內容如下:

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

　　蘋果警告郵件波及甚廣，在 GitHub 的 JSPatch 和 react-native 項目下非常多的 iOS 開發者在討論這件事，也因為蘋果并沒有具體指明，導致了大家的各種猜測。今天，React-Native 官方已經辟謠，確認不是 React-Native 的問題，而是 JSPatch / Rollout 的問題，而 JSPatch 作者 bang 也發文對此進行了回應，并表示：

　　動態化還是處于灰色地帶，嚴格來說 RN 是不符合規則的，但還是被允許，只要不給蘋果添麻煩，蘋果就不會管，JSPatch 因為前面提到的兩點風險被管了，怎樣做到使用并不給蘋果添麻煩呢?

　　1、減少使用人數，降低影響面;

　　2、禁止 SDK 接入;

　　3、接入保證傳輸安全和只用于修復 bug。

　　第一點警告郵件和代碼檢查使得使用門檻變高了，顯然會減少使用人數。第二點第三點只要有一個平臺來管控，是可以做到的，可能的話希望能跟蘋果審核團隊協商。

　　>>>點擊下一頁了解“蘋果是不是完全禁止了熱更新技術”