事情的主要起因在 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.

這條是在16年WWDC之後更新上去的。這條規則也很容易理解，所有被執行的代碼都應該包含在App裡，不能下載代碼到本地執行。下發的無論是OC還是JS或者其他形式的代碼，都可以被認為違反了這條規則。但是蘋果一直沒有嚴格“執法”，直到今天才開始給大批有類似嫌疑的開發者發了警告郵件，或者紛紛被拒。

當然這沒有什麼可怪的，這種執行力度全靠心情，畢竟爸爸從來不用講道理。不時也會父愛如山。

父愛如山

根據看到的反饋，目前蘋果判斷的依據主要有兩條。

一種是掃描特定的 API ，比如：

dlopen(), dlsym(), respondsToSelector:, performSelector:, 

method_exchangeImplementations()

但是這裡並不是完全禁止使用這些 API ，只是有個規則會檢查這些 API 的參數是不是可能是外部引入的。

比如這麼寫是沒問題的：

if([self.delegate respondsToSelector: @selector(myDelegateMethod)]) {
   [self.delegate performSelector: @selector(myDelegateMethod)];
}

這麼寫就可能被打回：

NSString *remotelyLoadedString = .... (download from your backend)
[self performSelector: NSSelectorFromString(remotelyLoadedString)];

另外會檢查特定的類名，比如大家都知道的JSPatch和Rollout，發現APP裡帶了這樣有潛在威脅的庫就可能打回。但是這個方式似乎通過混淆就能過關。

不懂為什麼提到JSPatch我就想發個表情，印象中過去某個時間段也有被這樣提示被下架，後來又放松了。內心 OS ：“皇上！我是被冤枉的！。”

紫薇，快救我

對未來的判斷

蘋果是百分百不願意代碼繞過審核被下發的。無論是修bug，還是一個小功能，高冷的資本主義企業怎麼能讓你亂蹭，萬一你進去了呢。其實我國國情特殊，真要是什麼違法的東西上了蘋果也遭不住，搞不好App Store都要下線。

道高一尺魔高一丈，程序執行起來總是要有漏洞。沒錯，是可以和官方博弈，但是你想一下下發代碼這件事是不是真的影響到App運行非做不可？如果代價提高呢？比如被發現一次直接封掉你的Apple ID，覺得還是非做不可？

聰明的人已經在如何提APP穩定性的道路上努力了。忘了HotPatch這件事吧。

RN&Weex 還能續一輪命

從各方的反饋來看，蘋果這輪狠抓的是下發代碼，而不是針對用 JS 代碼編寫業務邏輯。如果覺得這個有問題，就會把 JSCore 的一些核心 API 改為私有 API 了。只是在這個風口，基於這個技術的框架剛好很容易就提供了下發代碼執行邏輯的能力，所以被推到燈光下。

我之前有次也問過Weex的負責人，他明確表示 Weex 不是為了解決熱更新的問題存在的。只是恰巧有這個能力。

蘋果在 iOS 7中引入新的 JavaScriptCore 框架，必然是認為在 APP 裡執行 JS 對於整個 iOS 生態是有益的，否則何必多此一舉。所以目前只是要解決掉引入這個框架後帶來的濫用問題。 所以我認為這一輪的整治裡，JS2Native 的框架肯定可以全身而退。

Swift ？

有人說有沒可能是蘋果在為 Swift 下一步很大的棋。為了確認此事某好事網友咨詢了 Swift 之父CL：

爸爸口風很緊表示：

共建和諧社會

來，讓我們一起表態：我志願與美方一道建設和諧的 App Store 生態。