跨平台与原生开发的优劣势

我负责项目的 iOS 部分。为了保证技术栈统一，采用的是与桌面端一致的 Tauri@v2 框架。

最近运营方面又提出了一个新的需求。

涉及业务信息不能多说，但总的来说是一个很偏门的需求。

需要访问受到系统保护的，在官方 API 文档中未找到相关具体说明的资源，来呈现给用户。

官方文档中没有明确说明可以访问这个系统资源，也没有说不可以访问，为我带来了很大的困扰。

根据我查询的资料来说，需要访问的资源是受到系统保护的，是不允许访问的。

但是在我反馈说做不了的时候，运营方面给我看了下竞品，竞品是实现了这个需求功能的。

且根据相关测试，竞品好像是真的访问到了，而不是取巧的似是而非。

这就相当麻烦了，虽然根据查询的资料来说是无法实现这个需求的。

但竞品是实现的，证明在一定程度上是可行的。

关键是确定竞品是如何做到的，竞品是通过 App Store 审核然后上架的正规应用。可以初步的排除一些不合规的技术方案。

我甚至还和运营方面提了说要不把竞品举报了，如果下架整改了就不用搞这个需求了，如果没事再继续。

而剩下的方案，因为官方文档中没有说明，那么就需要我们去手动调试，而去调试则需要原生开发能力。

虽然目前我是在负责 iOS 的 APP 开发，但我实际上并不会 iOS 原生技术。

APP 也只是使用跨平台框架，取巧的通过套壳一个只能访问我们指定网页的浏览器实现的。

因为目前 APP 仅支持 iOS 端，也没有什么过多的功能，就只有一个支付的原生能力，因此我想说迁移成原生代码，就不做跨平台了。

从原来的需要关注 WEB、Rust、iOS 原生，专注于原生就行。

刚好公司后面还有其他 APP 需求，可以做技术储备。

然后就被拒绝了，理由也很充分，整体来说就是成本问题，加之原生能力也可以通过编写插件的形式来使用。

关于编写插件让 APP 获得可以操作原生的能力，看起来是很不错，但那个前提是需要会编写原生代码，了解原生开发。

而目前的问题就恰恰是我们欠缺了原生开发的能力。

特别是涉及到系统底层，权限模型这些内容的需求，仅仅只是会原生也难以胜任。这并非是一蹴而就的，而是需要长期积累的。

虽然现在 AI 已经快速发展，可以很好的帮助我们进行开发工作。但 AI 是通过数据训练出来的，如果 AI 的数据库中有这些信息，那么就很好使。但如果是没有的，那就很难办了。

如果我完成了这个功能，然后写了篇文章，指不定后续的开发者询问 AI 时返回的是我文章内的步骤。

盲目推崇跨平台技术是不可取的。因为跨平台只是一个漂浮在水面之上的小木舟，表面上看，不论是江河湖海，它都可以去往。

但实际上，随便一个风浪就可以掀翻这艘小木舟，小河小湖水浅风平，或许还能勉强胜任，可一旦到了大江大海，水深浪急，这样的小木舟便显得力不从心。

跨平台和原生开发，本质上是侧重点的不同。

跨平台专注于宏大叙事——一套代码兼顾多平台——却往往忽略了底层的真实需求：如何更快，更好的编写功能。

而原生开发，虽然受限于单一平台，无法兼顾多平台，但却能够因地制宜，做出各种其他平台无法做到的功能。

软件开发是不存在银弹的，技术终究是要为业务所服务，而业务也只是为了解决某项问题而诞生的。

橘生淮南则为橘，生于淮北则为枳。当选用一门技术时，应该考虑它是否适用于当前的需求，而不是盲目的求新。

新技术可以有一万个优点，但毁掉项目却只通常只需要一个缺点。