2015 年時，我是一名自由職業的原生 iOS 開發者。我知道 Objective C——這是唯一我睡著都能寫的語言。Swift 還在努力解決 ABI 相容性問題，而我還在觀望。

當我決定重新進入就業市場時，每個人都想要 React Native。

我是這個領域的新手。每個工程部落格，主要 包括 Airbnb，都在鼓吹“一次編寫，隨處釋出”的優勢。我的朋友們建議我轉向跨平臺，或者立即退休。

如果有人給我提供機會，相信我在 Windows + iOS 領域的工程技能，我可以在工作中學習原生安卓。

但是我猶豫要不要學習 RN。LinkedIn 在 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 年的同一年，蘋果釋出了 SwiftUI，一個宣告式的 UI 框架，旨在再次吸引新手開發者度過其 Swift 災難（儘管現在已經穩定了）。

什麼敲響了跨平臺的喪鐘：跨平臺的應用程式有其固有缺陷。隨著市場的不斷變化，現在市場已經成熟，它們要麼改進要麼消亡。

蘋果正在整合

在開發者收入方面，蘋果已經佔據了主導地位

這是 公開的秘密，從未變過。儘管安卓的市場份額很大，但在應用程式收入方面，它遠遠落後於蘋果。這不僅僅是因為安卓在世界的低收入地區處於領先地位，還因為安卓的核心業務是授權，而不是硬體製造。

因此，iOS + iDevice 的更新更符合其高付費使用者的需求。

蘋果的系統在移動體驗方面已經非常成熟

儘管非蘋果製造商引領了許多智慧手機創新。

由於蘋果對作業系統和硬體的控制更嚴格，蘋果在提供卓越 + 個性化的體驗方面做得更好，而這也是高價值使用者在移動裝置上的追求。

由於蘋果最新致力於成為一個以隱私為中心的軟體生態系統，顯而易見，蘋果將繼續在企業移動解決方案領域佔據主導地位。

對於開發者來說，蘋果和安卓之間的收入分成非常簡單：

蘋果開發 =>高價值付費使用者 =>應用程式銷售收入安卓開發 =>低價值使用者 =>廣告收入

蘋果最近強制應用程式請求使用者許可權來分享廣告資料。這對於那些以廣告資料為唯一資產的公司來說是一個直接的打擊——特別是 Facebook 和谷歌。

而 Facebook 和谷歌碰巧是 React Native 和 Flutter 的創造者，這應該不是個巧合。

你很容易看到這對於 App 開發者來說意味著什麼：進一步搞明白你的理想的使用者基礎。儘早做出選擇，並選擇你相應的工具集。

例如，如果你不想做廣告，你最好先開發蘋果應用。經過驗證後，再開發安卓應用。這種比較零碎的方案几乎沒有動力來進行跨平臺開發。只要團隊保持不變，通用程式碼庫需求很容易得到滿足。

Apple Silicon 是蘋果在應用經濟領域的王牌

除非某家顛覆性的硬體公司從黑暗中走出來。

谷歌是一個規模相當大的挑戰者，但並不可怕。它在移動領域的主要目的不是銷售軟體，而是掌握使用者資料。如果不在硬體上取勝，正如 它所公開承認的那樣，谷歌很難打破這種平衡。安卓的採用直接取決於它許可的硬體製造商。

有了 Apple Silicon，蘋果就整合了它的開發者社群。它已經向開發者支付了更多。現在有了 Apple Silicon，iOS 開發者可以輕鬆遷移到新的蘋果 Mac 上。

這一舉措使得 開發蘋果應用更有利可圖，使用它自己的工具：XCode、Playground 等等，使用 Apple Silicon 驅動的 Mac 電腦，因為它可以完全控制它的硬體。有更明確的動機讓所有人都投入到一個平臺上，至少在最初是這樣，而且沒有開發者或創業公司會錯過這個優勢。

跨平臺是一種漸進性改進，而不是創新

這是一種漸進性改進，告訴壟斷者：

現在，我挑戰你進行創新。我不能做一個更好的 IDE 或硬體，但是我可以剝奪你從中獲取的一些收益或開發者。

一次又一次，跨平臺工具將自己作為解決每個與平臺相關的問題的靈丹妙藥。

如果沒有底層硬體，它們會成為壟斷者的挑戰者，因為壟斷企業有很高的進入成本壁壘。Mac 機器 vs windows 機器的成本是被引用最多的標準。

它們迅速被採用的另一個原因，不是它們有能力創造更好的體驗，而是開發者對專有平臺的不滿。

每個超過千萬美元的初創公司都會僱傭一名移動開發人員來維護一個最終依賴於遠端 GitHub 貢獻者支援的程式碼庫

它們可以是開源的。快速入門專案、Youtube 教程和價值 100 美元的模板充斥在開發人員的資訊流中，但幾乎很難找到依據：

跨平臺 App 可以實現的東西用原生並不容易實現！（5 行程式碼 vs 3 個類！）。不要看原生提供的定製可能性 vs 5 行程式碼的底層機制。

它提供了 通用業務邏輯 的獨特優勢——這是任何初創公司都無法抗拒的。最後，每個 千萬美元 的初創公司都會僱傭一名移動開發人員來維護一個最終依賴於 GitHub 貢獻者支援的通用程式碼庫。這些公司沒有意識到的是，通用業務邏輯必須透過清晰的文件（嗯？那是什麼）和簡潔的規範（但我們是敏捷開發！）維護。

幸運的是，如果這些初創公司能夠超過一個收入點，如果出現開發人員流失，增長策略就會介入，在 app store/play store 上排名退步 + 投資人的壓力會促使創始人重新考慮他們最初追求快速但雜亂的解決方案的決定。這也解釋了 LinkedIn、Facebook iOS 版、Airbnb 以及其它無數應用後期採用原生方案的原因。

然而，初露頭角的創業公司數量從未減少，跨平臺開發人員的市場也從未枯竭。反抗精神萬歲！但現實是這樣的：如果你知道 C++（或 Objective C 及其變種）或者 Java，你的技能將在幾十年後還不落伍。如果你用一個奇特的跨平臺開源工具集來修飾你的簡歷，那就要準備好每 3-5 年做一次徹底的調整。

跨平臺糟糕透了

它們被開發是為了釋出，而不是維護。

在跨平臺應用中，困惑不斷。

如今的跨平臺產品能夠提供幾乎 100% 的原生程式碼——這一點毫無疑問。Xamarin、React Native 和 Flutter——都承諾 100% 原生執行。

它們不同於以往執行在瀏覽器上和基於 HTML5 的 PWA 應用。

但在設計上，它與每一個程式碼組織原則都相反。它們由 500 多個從完全不同的不受監控的原始碼（而不是本地庫）下載的包組成，模仿了 Web 開發方法。在移動開發中採用這種方法——其原始碼被視為公開的，而不是在由開發人員控制的伺服器的邊界內，人們可以想象其風險。

跨平臺工具很容易被採用，因為它們提供了初學者更容易理解的更高級別的抽象。它們融合了不同底層原生 API 之間的差異。它們採用了最常用的功能，其餘的定製工作留給了開發人員。

設想一個假設的 函式 F 在原生 iOS 和安卓中有如下實現：

iOS: function f (int a, int b, int c)

Android: function f (int a, int b, int p, int q, int r)

一個典型的跨平臺包會提供如下函式：

function f (int a, int b)

如果你想要充分利用這兩個功能，你必須在原生程式碼（即 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 之前，這從不是一個強制要求！

物件 A:

x = 3, y = 4

物件 B:

x = 4, y = 3

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

我問我的架構師，為什麼像我們這樣的資料密集型應用程式首先採用了 Flutter。

他的回答非常經典：

“管理人員常說：敏捷的目標之一，就是避免無價值的操作，例如文件。通用程式碼庫就是我們的文件和唯一信源。”

跨平臺是一種不依賴的依賴關係

這個問題不是跨平臺固有的。但這個問題透過開源共享與跨平臺緊緊繫結在了一起。

庫所有人具有不可思議的權力

這個問題的存在有兩個原因。

首先，GitHub（和它的競品）是未評級的，但要對國家法律負責。它可以在任何時候透過合法的改組來 摧毀任何東西。

其次，庫所有人對於貢獻者的工作具有不可思議的權力，無論這個庫有多大。

庫所有者的暴政 已經在區塊鏈領域臭名昭著，創始貢獻者在制定鏈幣發行規則方面佔據上風。

所有頭部公司（包括 FAAMG）都已經在利用開源，來使他們的 SDK 可以被獲取 + 對 bug 修復開放。公司僱傭開發者來維護社群意識，關注開發者的興趣，並根據大眾需求來發布特性。

如果他們不這麼做，他們的核心產品就會受損。

對於跨平臺供應商則不是這樣。事實上，他們對嚴重的 bugs 或關鍵的增強請求沒有任何反映。因此，錯誤處理 GitHub 問題不會對他們造成任何後果。

如果 Flutter 有嚴重的 bugs，谷歌在已經微不足道的 Pixel 銷量或龐大的搜尋流量方面不會有任何減少。

如果 React Native 缺少一個功能，Facebook 的廣告收入不會縮減。

但是，如果 Android/Kotlin 或 iOS/Swift 有嚴重的漏洞，谷歌和蘋果肯定會遭受損失——谷歌在授權收入方面受損，蘋果在 iPhone 銷量方面受損。開發者會削減 30% 收入。

因此，與那些在午夜釋出修補程式的原生平臺所有者不同，跨平臺開發者對開發人員的請求置若罔聞。

稍好點的迴應者會對問題寫一個正式的迴應，並單方面關閉它們，而不進行後續處理。在沒有適當文件的情況下，開發人員的唯一辦法就是深入研究包 / 庫程式碼，修復問題，然後釋出他們的應用程式。

有時，他們被庫開發者誘導回饋，而這也沒有任何激勵措施，這一切都是基於開源精神。

對於一個被承諾了高效跨平臺實現的開發者來說，這是 2 個缺點：花在 bug 上的時間更多 + 特性請求是開源的。

但還有更糟糕的。

雪上加霜的是，他們的 PR 有時候會被庫所有者拒絕或忽視，理由是為了保證他們的記錄簿乾淨。

除非高薪的跨平臺庫所有者平等對待他們的低薪同行創新者，否則情況只會惡化。

隨著有經驗的開發人員轉向更好的平臺原生的解決方案，跨平臺專案註定會是一個偽裝成創新的巨大漸進改動。

結論

跨平臺開發將很快意味著對於多種裝置的單平臺開發

在所有的移動開發廠商中，蘋果是唯一一家真正的業務線是硬體的公司。隨著他們平臺的統一，它向開發者發出了一個明確的資訊：你對我們的服務業務至關重要，我們關心你們的增長。

現在預測其長期市場主導地位還為時過早。谷歌有足夠的財力來為其原生安卓平臺提供燃料，使其對開發者更有吸引力。

雖然單靠蘋果無法撼動整個跨平臺社群，但它肯定能夠迫使其競爭對手採用一種更結構化更易於維護且更不易出現故障的移動開發方案。

跨平臺開發領域將很快意味著對多種裝置的單平臺開發，就像.NET 早期那樣。

創業公司最好不要跨平臺。公共程式碼庫的誘惑必須被良好的老文件取代，這樣才能在開發人員心中培養真正的通用商業邏輯。

你的客戶值得原生平臺提供的最佳統一體驗。

你的開發者？休息（不是雙關語） + 尊敬。

作者 | Pen Magnet 來自 前端之顛 譯者 | 張健欣