JSPatch 作者 bang：關于蘋果警告

感謝作者 bang 的授權釋出，版權歸原作者所有，未經允許，請勿轉載。

原文位址：http://blog.cnbang.net/internet/3374/

作者：陳振焯，網名 bang，iOS 開發者，推特中文圈 / JSPatch 作者。

【CSDN 有獎征稿啦】技術之路，共同進步，有優質移動開發、VR/AR/MR、物聯網原創技術文章歡迎發送郵件至 [email protected]。

昨天早上 iOS 開發者們陸續收到蘋果郵件，警告去掉動态下發功能，覆寫面很廣，内容沒有明确訓示是什麼庫，導緻大家各種猜測。

其實上周已經有少量使用者收到蘋果這份警告郵件，當時還以為是特例，現在看來是在灰階測試掃描代碼，可見這事蘋果應該讨論已久，并專門排期開發測試了掃描程式，直到昨天才正式上線。

從各方資訊看起來，很不幸主要禁的還是 JSPatch / wax / rollout 這樣的熱修複架構，特點是可以通過 JS 腳本調用和替換任意 OC 方法，而像 React Native/ 小程式這樣用 JS 做功能的暫時不受影響，Weex 不确定，至于其他庫像 AFNetworking / SDWebimage 用到那幾個接口的，應該隻是誤傷。

根據蘋果要求，收到警告的同學隻需要在下次送出版本時去掉相關架構就可以，沒有時間期限，目前也不會強制下架。

為什麼

蘋果為什麼這麼做呢？蘋果對熱修複一直以來的态度都是不贊同也不拒絕，JSPatch 本身也并沒有違反開發者條例，而且 JSPatch 大多數都用于修複 bug，提升 iOS 平台 App 的品質，對蘋果也是件好事，為什麼要禁？猜測原因有兩點：可控和安全。

可控

蘋果一貫作風是讓所有事情可控，開發者能用什麼不能用什麼都盡量在自己的控制範圍内。大多數人使用 JSPatch 修複 bug，或者弄一些臨時營運的小功能配置，這些沒有問題，但總會有少數使用者使用 JSPatch 去調用私有API做些事，這是蘋果不可控的，也無法知道有多少人這樣做了。

不過其實在代碼這塊蘋果其實一直可控程度有限，他會在送出時掃描你有沒有用某些私有方法，但隻要你對這些私有方法調用做一些變化，加解密字元串拼接什麼的，就能繞過掃描，再通過背景配置調用，是一樣的。JSPatch 隻是讓調用私有 API 變得成本更低更友善點而已，可控這裡隻是個小理由。

安全

去年 FireEye 分析了使用 JSPatch 的安全問題，當時我也寫文章回應了，再複述一下，主要安全風險有三點：

1. 開發者自己本身對 App 下發惡意代碼。
2. 開發者沒有做好加密傳輸和校驗。
3. 開發者接入的 SDK 裡接入了 JSPatch，SDK 作者可以對這些 App 下發惡意腳本。

第一點其實不算安全風險，因為開發者自己有惡意的話完全不需要借助 JSPatch。

第二點大多數使用者使用 JSPatch 時都做好了非對稱加密，保證不會在傳輸過程被第三方篡改。但這裡技術上沒法保證使用者一定使用正确的加密方式，蘋果無法知道有多少接入 JSPatch 的使用者沒有正确加密和校驗，這是未知的安全隐患。

第三點在當時并沒有什麼第三方 SDK 接入 JSPatch，但現在像高德地圖/個推等都接入了，如果他們要作惡，或者他們本身服務端被入侵，确實是個安全隐患。

iOS 平台是最安全的，也是最注重安全的，即使熱修複帶來了 App 品質更高的好處，也無法無視這裡的安全隐患，現在 JSPatch 國内覆寫面很大，若出一個安全問題，會影響 iPhone 的聲譽，因為這個風險，是以考慮禁掉。

反應

這個警告出來後，國内開發者有各種反應，各種表情貼圖還挺搞笑的，不過大家放心，JS 沒事，iOS 開發該失業的還是失業:)

看到有一些人拍手稱贊，贊的理由不是說蘋果維護了平台安全，而是：1.國内開發方式low，2.産品經理濫用。這裡我有一些想法說一下。

開發方式

他們說國外開發不了解國内為什麼要用熱修複，國外很少使用，國外開發流程很好很規範，會做好充分的 codereview 和測試，上線後沒什麼 bug，不需要熱修複，也不會有産品經理亂提需求，疊代沒像國内這麼快，使用熱修複是本末倒置，不去考慮提高 APP 品質，國内開發方式太 low，國外的才是正道。

這裡有個問題，就是什麼是好的開發方式？以什麼标準界定？上面的說法可以看出他們是把工程的嚴謹性，流程的規範性作為好壞的依據。雖然我是個程式員，覺得工程嚴謹和流程規範确實是好東西，但我比較實用主義，更傾向于以結果作為标準，也就是能不能更低成本更高效地開發出品質更好的産品作為标準。

如果我使用熱修複能以更低的人力成本（工程師能力和薪水不如國外，人數少），更高效（測試時間縮短，不需要覆寫到0.01%幾率出現的 bug / crash ），做出品質更高的産品（ bug / 特殊情況和需求反應速度快），為什麼不是一個更好的開發方式呢？

另外用戶端的開發方式本身就是落後的，不利于快速疊代，無法對線上産品有控制權，參考另一篇文章。這也就是為什麼 Facebook 一開始要用 Web Hybird 的方式開發，現在又要做 React Native。熱修複是這種落後開發方式的彌補。另外我沒在國外公司工作過，但感覺他們對bug的容忍程度還是比國内高的，對比一下 IAP 和微信支付的失敗率，做過的人都知道。

還有一個聲音說國内的人喜歡違反規則，鑽空子太不老實。首先前面也說了熱修複的方式并沒有違反規則，完全符合開發者條例，其次國外也有熱修複 rollout，最後如果從開發者條例來說，React Native 反而是違反規則的，因為主要用途動态添加和修改 App 的功能。

濫用

另一個說法是上了熱修複後産品經理來勁了，産品時不時想到一個功能配置說上就上，開發者弱勢隻能跟着上。

這種情況在我這邊團隊還沒遇到過，我的想法是：如果要上的功能配置對産品是有好處有必要的，開發維護成本又低，為什麼不上？如果要上的功能配置是無關緊要的，或者開發維護成本太高，為什麼不能講理拒絕？

開發者把原因定位為自己“弱勢”，就把自己從團隊剝離開了，變成對人不對事，這種團隊氛圍是挺糟糕的，而這個鍋也不是産品經理的。大家做的事都是為了産品更好，應該不會有那麼多故意刁難不講理的産品經理和老闆。至于怎樣界定對産品有沒有好處和有沒有必要，以及開發成本高低，這得自己協商了，以我們團隊的做法是以做這個事的成本效益計算。

怎麼辦

接下來如果還想用 JSPatch 怎麼辦？我沒有跟蘋果稽核團隊交流過，不知道他們的想法，短時間内是先不要用，後續再看情況。

熱修複的需求很大，很希望蘋果可以推出自己的方案，由系統做這個事是可以保證安全的，但現在看起來可能性較低，國外需求量不大，蘋果也就不會重視這個需求，何況目前在大力推 Swift。

對于 JSPatch，蘋果應該是掃描可執行檔案裡的關鍵字，從技術上說是很難禁掉的，可以做各種混淆去繞過檢查，但若下發時被查到，會有政策風險，政策有待觀察。

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

1. 減少使用人數，降低影響面。
2. 禁止 SDK 接入。
3. 接入保證傳輸安全和隻用于修複 bug。

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