本文為轉載文章
故事背景：
這兩天，不少iOS開發群都炸窩了，原因是部分iOS開發者收到了蘋果的警告郵件：
有開發者質疑可能是項目中使用了JSPatch、weex以及ReactNative等熱更新技術。對於修復bug提交審核的開發者來說，熱更新技術可以幫開
發者避免長時間的審核等待以及多次被拒造成的成本開銷。但也給黑客留了后門，也就違反了蘋果的安全和隱私政策。
不過這次蘋果只是對使用熱更新的應用進行了警告，並沒有開發者反應產品因此問題被下架。
在蘋果開發者論壇上，一位開發人員透露，他們的公司已經接到消息，稱在刪除這些“HotPatch”代碼之前，蘋果將不接受其應用更新。
分析說明：
從目前各方面反饋來看，蘋果此次狠抓的是下發代碼，所以JSPatch就被拉出來吃槍子了，JS等形式代碼將被禁止。
WWDC后App Store Review Guide
Line更新 2.5.2 條這樣描述：
2.5.2 Apps should be self-contained in their bundles, and may not read or
write data outside the designated container area, nor may they download,
install, or execute code, including other iOS, watchOS, macOS, or tvOS apps.
本條規定所有執行代碼都需要包含在App中，不能下載代碼到本地執行，所以OC或者JS形式的代碼明顯違反了這條規定，但蘋果顯然沒有在
過去一年中對這條規定進行貫徹，直到今天才向相關開發者發出了警告。
對游戲本身有何影響?
這個問題其實有目共睹，在禁止熱更新之后
1、游戲無法頻繁更新功能、修復BUG，廠商在更新版本之前，可得長點心吧!
2、游戲更新后用戶需要重新下載完整游戲，帶來了用戶流失和活躍度下降，特別是大包體游戲更為嚴重，用戶要是動不動就下載個1G多的游戲，對游戲體驗的傷害太大。
3、游戲更新后整體需重新經過蘋果再次審查，造成審核周期增加。
是否有規避方法?
根據目前蘋果進行審查的方式主要有兩種：
一種是檢查特定的類名，如JSPatch和Rollout，蘋果會審查APP是否攜帶了這一類的庫。
另一種是掃描特定的API，有規則將會檢查這些 API 的參數是否可能由外部引入。
通過混淆JSPtach(替換JSPtach內部所有類和方法名)，或許是可以繞過審查蒙混過關。雖然蘋果尚未明確懲罰方式，但在繼續
HotPatch和開發者賬號被封之間，還是提高點App穩定和Debug上多下功夫，Weex似乎也還有機會。
蘋果開發者在去年就發現了由於JSPatch所引起的更新漏洞將被黑客利用，從而引起一系列損失，蘋果對AppStore的優化也從未停止，無論開發者對於此次HotPatch的禁令是否存在各種怨言，按照蘋果的以往原則來看：你們盡管罵，最后還不得管我叫爸爸!
開發者說：
舞小月：
蘋果注重的就是流暢性和用戶體驗，混編做的東西肯定沒有native的流暢，這就違背了蘋果本來的意願，被禁也是正常的，而且蘋果自己的蛋糕為何要分給競爭對手？以前沒混編的時候你該怎么做不還是做了，現在沒有，不代表以后沒有，就像之前沒有混編，后來有了混編。新的框架蘋果自然也會去完善，蘋果既然做了這個決定，他肯定會優化自己的東西。
Gilbertat：
蘋果爸爸會不會在自己的生態中搞死js啊
luohui8891：
我們也是昨天收到的，目前沒有什么對策。我們的APP只是用JSPatch做熱修復，並不修改應用的功能行為等（但我覺得Apple並不care這個）。
lsllsllsl：
沒用RN沒用JSPatch，同樣收到警告。
luohui8891：
@tcathy 根據郵件里說是你下次提交前請去掉這樣遠程下載代碼運行的機制。所以應該就是下個版本如果不刪除就reject
Loooren：
早上收到郵件，itunesconnect站內信，電話通知....用到了weex
xiaofuyesnew：
昨天晚上微軟發布了Visual Studio 2017，自帶基於React Native的iOS開發功能。鑒於微軟這兩年來開源的力度，發布這一功能似乎是在搶占開發者的市場，基於vs2017，在非蘋果上開發ios應用更容易了。所以，蘋果在這個節骨眼發出這個警告郵件，就有點威脅現有開發者的意思。暗地里想跟微軟互懟。
對於那些已經在學習RN、weex、JSPatch的同學來說，這是個悲慘的故事
從蘋果的角度看，禁止應用使用熱更新技術更多是為了保護用戶隱私、數據安全以及其全力打造的生態圈。對於用戶來說，出於安全起見，應謹慎授予應用權限；對於開發者來說，為了審核以及長遠的用戶體驗考慮，不要輕易觸碰蘋果拉的那條紅線。
