苹果怒对微信 JSPatch躺枪

苹果拒绝引用JSPatch框架的应用上架，导致中国区iOS开发界一片动荡。

而最近身边很多的开发者朋友都收到了苹果这样的警告邮件：

大概的说就是，你的 APP 存在审核之后还能更改应用功能或者行为的能力，现在的这种能力App Store 不允许了， 需要开发者去掉相应的功能，而首先躺枪的就是JSPatch这个第三方框架。

毫不意外的，凡事引用了这个JSPatch的应用首当其冲，立刻引起了开发者社区的激烈讨论。有的紧张，有的恐慌，也有的淡定， 更有甚者说公司的某某部门因为这个消息都被裁掉等。

这件事情的起因还是要从 iOS系统的运行原理说起。 最初苹果公司开放的开发语言是Objective-C，甚至于现在的swift，它们都属于动态的运行时语言，简称Runtime。这就意味着开发者可以动态的改变应用程序的功能界面和业务逻辑。当然刚开始之初，大家都是懵懵懂懂的小学弟，老老实实的做开发，虽然知道有这个东西但也止步于了解而已，不过几年过去了，终于有人利用这个机制作出了类似于JSPatch的第三方框架，很多app包括qq，微信等大型的应用都先后引用了这种框架来绕过苹果繁杂的审核的过程。

说道苹果的审核，那真是一把辛酸泪，如果 APP 上线后闪退或者卡死了，几乎很难立即修复。 只能尽快的在本地把问题修复，重新打包上传，然后给苹果审核的团队大佬们发一封加快审核的申请，而且要把情况写的很严重，才有可能得到一个 1 天左右的快速审核，一般来说审核都是需要2-5天的样子，看起来没几天，可以对于用户体验来说却是非常大的冲击，而且在这个新的应用潮涌的时代，可能就是因为一点小小的bug导致你的app很快消失在大众的眼里，转而使用别人的app。

随着技术社区的充分交流，我们开发 APP 的成本越来越小，也越来越灵活。 慢慢开始有了云端开关的概念。 服务端配置好一些参数， 客户端预先把对每个参数的处理方法都写好。 然后在线上只要修改参数就可以在 APP 已经发布后还能对它有一定的控制力。

再后来技术社区就更先进了，比如 Apache 的 Cordova 这样号称使用类似 JS 的中间语言就可以一次开发，同时发布到 iOS 和 Android 多个平台的相关解决方案。

到现在 Facebook 的 React Native，以及 JSPatch 等技术的出现。 让 iOS 的开发变得越来越灵活。 比如 JSPatch 的初衷是让开发者不必重新发版，线上即可修复 bug。

对于做技术的朋友而言，应该会比较喜欢这些新技术的出现。 毕竟过去 iOS 平台给技术人的感觉是苹果控制的太多，技术上可做的很少。 这些新技术方案的出现，会让大家在开发 iOS 的时候也会有更多的成就感。

但它们却越来越背离苹果对 iOS 生态的价值观。 iOS 生态相比 Android 来说基本上算是两种哲学的现实体现。 Android 整体给大家的感觉就是更加开放，开源的精神。 从某种意义上我们可能还会赞赏 Android 的这种哲学。 但任何事情都有利有弊， Android 虽然开放，但必然会有开放所带来的弊端，比如各种厂商 OS 的体验不统一，过度定制化会造成不必要的复杂性，以及 APP 设备兼容性等等问题。 虽然 iOS 看起来 “封闭”， 但这样的 “封闭” 却带来的更好的用户体验。 比如同样一款游戏，在机器性能差不多的情况下，基本上是 iOS 的体验会更好。 我个人同时用过 iOS 和 Android 设备， 我只有在 iOS 上才会更放心的登录涉及银行账户等安全性非常重要的产品。这两种哲学，我个人的感觉，没有哪个比哪个好，只是两种价值观，并且目前这两个平台都活的很好。

再说回咱们这次的话题，此次苹果禁止动态下发代码，就免不了引起大家对它 “封闭” 的质疑。 但在我看来，这只是苹果对它自己价值观的一次实践。为什么要禁止动态下发，苹果在邮件中也说的很清楚了。 更多的是出于用户安全的角度考虑。 防止这些动态下发代码的机制会被中间人劫持，造成 APP 的安全隐患。 还是回到苹果的价值观上， 这只是它对自己价值观的一个实践，谈不上对错。 苹果优先保证每一个 iOS 用户的安全和体验。保证每个用户最好的体验，实际上是对 App Store 整个平台品牌的最好的支撑。 同样的 App Store 好了， 最终获益的是整个生态的参与者，其中也包括我们这些开发者。

苹果的目的是让整个 iOS 生态变得更好。 作为 iOS 技术人，确实不必有任何恐慌。 就像前些年中间语言可以多平台发布，就有人说原生开发者面临威胁一样。 技术平台没有那么容易被谁取代。就像今天移动端几乎完全普及了，但传统 Web 技术依然有用武之地一样。

部分引用：http://www.tuicool.com/articles/ZB3Ezej