要么改进要么消亡：我想跨平台应用程序快要终结了

作者 Pen Magnet 译者 张健欣

2015年时，我是一名自由职业的原生iOS开发者。我知道Objective C——这是唯一我睡着都能写的语言。Swift还在努力解决ABI兼容性问题，而我还在观望。

当我决定重新进入就业市场时，每个人都想要React Native。

我是这个领域的新手。每个工程博客，主要包括Airbnb，都在鼓吹“一次编写，随处发布”的优势。我的朋友们建议我转向跨平台，或者立即退休。

如果有人给我提供机会，相信我在Windows + iOS领域的工程技能，我可以在工作中学习原生安卓。

但是我犹豫要不要学习RN。Linked In在2013年放弃了其基于HTML5的跨平台app，这在我的脑海中记忆犹新。尽管React Native在执行时是完全原生的，但是它没有像Objective C或Java那样暴露出原生的感觉。

我的犹豫很快得到了验证：

我读到了相关新闻，RN的创造者Facebook——宣布将其iOS主页（新闻流）切换到Kit组件——一个基于Objective C++创建的框架。他们大量借用了React的声明式方案，但是用Objective C++实现了所有东西来利用iOS架构的真正力量——甚至Swift现在还无法提供。

现在大部分经常使用的应用程序依赖C++或它的一些变种（对于安卓是JNI，对于iOS是Objective C++）。

快进到2020年。

Airbnb早在2019年就放弃了继续使用RN。这在工程界引起了足够的轰动，迫使人们重新思考。在2019年的同一年，苹果发布了Swift UI，一个声明式的UI框架，旨在再次吸引新手开发者度过其Swift灾难（尽管现在已经稳定了）。

什么敲响了跨平台的丧钟：

跨平台的应用程序有其固有缺陷。随着市场的不断变化，现在市场已经成熟，它们要么改进要么消亡。

苹果正在整合

在开发者收入方面，苹果已经占据了主导地位

这是公开的秘密，从未变过。尽管安卓的市场份额很大，但在应用程序收入方面，它远远落后于苹果。这不仅仅是因为安卓在世界的低收入地区处于领先地位，还因为安卓的核心业务是授权，而不是硬件制造。

因此，i OS + i Device的更新更符合其高付费用户的需求。

苹果的系统在移动体验方面已经非常成熟

尽管非苹果制造商引领了许多智能手机创新。

由于苹果对操作系统和硬件的控制更严格，苹果在提供卓越 +个性化的体验方面做得更好，而这也是高价值用户在移动设备上的追求。

由于苹果最新致力于成为一个以隐私为中心的软件生态系统，显而易见，苹果将继续在企业移动解决方案领域占据主导地位。

对于开发者来说，苹果和安卓之间的收入分成非常简单：

苹果最近强制应用程序请求用户权限来分享广告数据。这对于那些以广告数据为唯一资产的公司来说是一个直接的打击——特别是Facebook和谷歌。

而Facebook和谷歌碰巧是React Native和Flutter的创造者，这应该不是个巧合。

你很容易看到这对于App开发者来说意味着什么：进一步搞明白你的理想的用户基础。尽早做出选择，并选择你相应的工具集。

例如，如果你不想做广告，你最好先开发苹果应用。经过验证后，再开发安卓应用。这种比较零碎的方案几乎没有动力来进行跨平台开发。只要团队保持不变，通用代码库需求很容易得到满足。

Apple Silicon是苹果在应用经济领域的王牌

除非某家颠覆性的硬件公司从黑暗中走出来。

谷歌是一个规模相当大的挑战者，但并不可怕。它在移动领域的主要目的不是销售软件，而是掌握用户数据。如果不在硬件上取胜，正如它所公开承认的那样，谷歌很难打破这种平衡。安卓的采用直接取决于它许可的硬件制造商。

有了Apple Silicon，苹果就整合了它的开发者社区。它已经向开发者支付了更多。现在有了Apple Silicon，i OS开发者可以轻松迁移到新的苹果Mac上。

这一举措使得开发苹果应用更有利可图，使用它自己的工具：XCode、Playground等等，使用Apple Silicon驱动的Mac电脑，因为它可以完全控制它的硬件。有更明确的动机让所有人都投入到一个平台上，至少在最初是这样，而且没有开发者或创业公司会错过这个优势。

跨平台是一种渐进性改进，而不是创新

这是一种渐进性改进，告诉垄断者：

一次又一次，跨平台工具将自己作为解决每个与平台相关的问题的灵丹妙药。

如果没有底层硬件，它们会成为垄断者的挑战者，因为垄断企业有很高的进入成本壁垒。Mac机器vs windows机器的成本是被引用最多的标准。

它们迅速被采用的另一个原因，不是它们有能力创造更好的体验，而是开发者对专有平台的不满。

它们可以是开源的。快速入门项目、Youtube教程和价值100美元的模板充斥在开发人员的信息流中，但几乎很难找到依据：

跨平台App可以实现的东西用原生并不容易实现！（5行代码vs 3个类！）。不要看原生提供的定制可能性vs 5行代码的底层机制。

它提供了通用业务逻辑的独特优势——这是任何初创公司都无法抗拒的。最后，每个千万美元的初创公司都会雇佣一名移动开发人员来维护一个最终依赖于Git Hub贡献者支持的通用代码库。这些公司没有意识到的是，通用业务逻辑必须通过清晰的文档（嗯？那是什么）和简洁的规范（但我们是敏捷开发！）维护。

幸运的是，如果这些初创公司能够超过一个收入点，如果出现开发人员流失，增长策略就会介入，在app store/play store上排名退步 +投资人的压力会促使创始人重新考虑他们最初追求快速但杂乱的解决方案的决定。这也解释了Linked In、Facebook iOS版、Airbnb以及其它无数应用后期采用原生方案的原因。

然而，初露头角的创业公司数量从未减少，跨平台开发人员的市场也从未枯竭。反抗精神万岁！但现实是这样的：如果你知道C++（或Objective C及其变种）或者Java，你的技能将在几十年后还不落伍。如果你用一个奇特的跨平台开源工具集来修饰你的简历，那就要准备好每3-5年做一次彻底的调整。

跨平台糟糕透了

在跨平台应用中，困惑不断。

如今的跨平台产品能够提供几乎100%的原生代码——这一点毫无疑问。Xamarin、React Native和Flutter——都承诺100%原生执行。

它们不同于以往运行在浏览器上和基于HTML5的PWA应用。

但在设计上，它与每一个代码组织原则都相反。它们由500多个从完全不同的不受监控的源代码（而不是本地库）下载的包组成，模仿了Web开发方法。在移动开发中采用这种方法——其源代码被视为公开的，而不是在由开发人员控制的服务器的边界内，人们可以想象其风险。

跨平台工具很容易被采用，因为它们提供了初学者更容易理解的更高级别的抽象。它们融合了不同底层原生API之间的差异。它们采用了最常用的功能，其余的定制工作留给了开发人员。

设想一个假设的函数F在原生iOS和安卓中有如下实现：

一个典型的跨平台包会提供如下函数：

如果你想要充分利用这两个功能，你必须在原生代码（即Objective C和Java）中找出c、p、q和r的调整。

在我的上一个组织中，由于现有的Flutter通知包的缺点，开发人员必须在以下方面进行开发：

1. Dart

2. iOS插件

3. 安卓插件

因为Flutter开发人员只熟悉XCode或Android Studio，并不精通Objective C或Kotlin API，所以这被认为是一个缺陷。

大部分跨平台爱好者都是大学生，他们在图书馆中创建了他们的第一个软件，不能忘记他们的“初恋”。他们构建跨平台App是用来发布，而不是维护。

但当你被迫下载一个包来实现一个简单的功能，例如设备信息，真正的痛苦就开始了。

平均而言，虽然一个移动应用开发人员开发一个单一代码库只节省了20%时间（而不是50%，因为需求转化 +定制化），包管理占用了维护者70%多的时间。

一个React Native应用程序被一些非常严重的功能+性能相关问题困扰，这些问题会在开发周期的后期被发现。

相比于原生开发者的IPA和APK，一个典型的flutter app的尺寸要大得多。

在我的上一个组织中，我修改了70多个文件，来处理Flutter的Equatable实现的兼容性中断。

这并不痛苦，直到我了解了其背后的原因：早期的哈希算法对于一个对象内属性值的交换产生相同的哈希值！

换句话说，以下对象将在旧的有缺陷的实现中产生相同的哈希值，除非你显式地重写Equatable哈希函数，在1.0之前，这从不是一个强制要求！

想象一下，检查所有500多个包是否存在equality检查漏洞…

我问我的架构师，为什么像我们这样的数据密集型应用程序首先采用了Flutter。

他的回答非常经典：

“管理人员常说：敏捷的目标之一，就是避免无价值的操作，例如文档。通用代码库就是我们的文档和唯一信源。”

跨平台是一种不依赖的依赖关系

这个问题不是跨平台固有的。但这个问题通过开源共享与跨平台紧紧绑定在了一起。

这个问题的存在有两个原因。

首先，Git Hub（和它的竞品）是未评级的，但要对国家法律负责。它可以在任何时候通过合法的改组来摧毁任何东西。

其次，库所有人对于贡献者的工作具有不可思议的权力，无论这个库有多大。

库所有者的暴政已经在区块链领域臭名昭著，创始贡献者在制定链币发行规则方面占据上风。

所有头部公司（包括FAAMG）都已经在利用开源，来使他们的SDK可以被获取+对bug修复开放。公司雇佣开发者来维护社区意识，关注开发者的兴趣，并根据大众需求来发布特性。

如果他们不这么做，他们的核心产品就会受损。

对于跨平台供应商则不是这样。事实上，他们对严重的bugs或关键的增强请求没有任何反映。因此，错误处理Git Hub问题不会对他们造成任何后果。

如果Flutter有严重的bugs，谷歌在已经微不足道的Pixel销量或庞大的搜索流量方面不会有任何减少。

如果React Native缺少一个功能，Facebook的广告收入不会缩减。

但是，如果Android/Kotlin或iOS/Swift有严重的漏洞，谷歌和苹果肯定会遭受损失——谷歌在授权收入方面受损，苹果在i Phone销量方面受损。开发者会削减30%收入。

因此，与那些在午夜发布修补程序的原生平台所有者不同，跨平台开发者对开发人员的请求置若罔闻。

稍好点的回应者会对问题写一个正式的回应，并单方面关闭它们，而不进行后续处理。在没有适当文档的情况下，开发人员的唯一办法就是深入研究包/库代码，修复问题，然后发布他们的应用程序。

有时，他们被库开发者诱导回馈，而这也没有任何激励措施，这一切都是基于开源精神。

对于一个被承诺了高效跨平台实现的开发者来说，这是2个缺点：花在bug上的时间更多 +特性请求是开源的。

但还有更糟糕的。

雪上加霜的是，他们的PR有时候会被库所有者拒绝或忽视，理由是为了保证他们的记录簿干净。

除非高薪的跨平台库所有者平等对待他们的低薪同行创新者，否则情况只会恶化。

随着有经验的开发人员转向更好的平台原生的解决方案，跨平台项目注定会是一个伪装成创新的巨大渐进改动。

结论

在所有的移动开发厂商中，苹果是唯一一家真正的业务线是硬件的公司。随着他们平台的统一，它向开发者发出了一个明确的信息：你对我们的服务业务至关重要，我们关心你们的增长。

现在预测其长期市场主导地位还为时过早。谷歌有足够的财力来为其原生安卓平台提供燃料，使其对开发者更有吸引力。

虽然单靠苹果无法撼动整个跨平台社区，但它肯定能够迫使其竞争对手采用一种更结构化更易于维护且更不易出现故障的移动开发方案。

跨平台开发领域将很快意味着对多种设备的单平台开发，就像.NET早期那样。

创业公司最好不要跨平台。公共代码库的诱惑必须被良好的老文档取代，这样才能在开发人员心中培养真正的通用商业逻辑。

你的客户值得原生平台提供的最佳统一体验。

你的开发者？休息（不是双关语） +尊敬。

作者介绍

Pen Magnet创业作家、程序员、科技职业博主、教育爱好者。