苹果为什么要拒绝 JSPatch 这些热更新机制

苹果为什么要拒绝 JSPatch 这些热更新机制

苹果为什么要拒绝 JSPatch 这些热更新机制

swift 发布于 2020年12月21日

最近几天，身边的很多开发者朋友都收到了这样一封警告邮件：

邮件的大致意思是说，你的 APP 包含了可以在审核之后还能更改应用功能或者行为的能力。 现在 App Store 不允许应用再有这样的能力了。 需要开发者去掉相应的功能。

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

这件事情的起因还是要从 APP 动态化说起。 我从 iPhone 4 时代开始进入 APP 开发者的行列。 记得最早的 iOS APP 开发并没有如今这么多强大的第三方库。 当时大家都只能规规矩矩的写着需要进行手动内存管理 Objective-C 代码，等待着至少要一周以上的 APP 审核。

那时候，如果 APP 出现了线上 Crash，你几乎很难立即修复。 你只能尽快把问题修复，重新打包上传，然后给苹果大大们发一封加快审核的申请，要把情况写的很严重，才有可能得到一个 1 天左右的快速审核。

即使是这样，从修复问题到最终反映到用户身上，至少需要 1-2 天的时间。 所以当时大家发布 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 技术依然有用武之地一样。

关注微信公众号
发现更多精彩
swift-cafe