AI 時代 iOS/Android 跨平台框架的尷尬未來

跨平台幻象：工程、官僚主義與 AI 時代

我曾在中國大陸幾家最大的網際網路公司工作了十多年。後來，我移居海外，加入了一家業務遍及全球、但不在中國大陸營運的全球性科技公司。再後來，我在海外創辦了自己的公司。

這些經歷讓我得以從不同的視角，重新審視自己在中國見到的工程文化和技術決策。

我對跨平台框架的懷疑始於 2024 年。

當時，我在業餘時間開發一款 ASR/TTS 行動應用程式。我不想依賴雲端運算，而是希望利用裝置本身的運算能力，因為 iOS 和 Android 都已開始支援能力日益增強的機器學習 API。

我也已經開始使用 Cursor 進行 AI 輔助開發。

在為自己的應用程式研究跨平台方案時，我得出了一個結論：在 AI 時代，iOS/Android 跨平台框架會變得越來越無足輕重。

而且，或許早在 AI 出現之前，它們的價值就被高估了。

最近，我讀到了 Shopify 的工程文章：原生開發如今是 Shopify 行動端的未來。文章講述了他們從 React Native 回歸原生開發的決定。

它讓我想起了自己在 2024 年對跨平台框架的那些疑問，也促使我終於把自己的想法寫下來。

Shopify 聲稱，React Native 在 2020 年是正確的選擇。我並不那麼確信。

Shopify 自己也承認，在效能最佳化、框架改進和相依套件維護上投入了大量時間與資源。但這些只是跨平台開發成本的一部分。那麼，維護開發者生態系統的隱性成本、組織開銷，以及錯失的商業機會呢？

Shopify 是否曾完整核算過這項決策真正的經濟成本？我對此深表懷疑。

我的結論主要基於以下幾點：

• AI 程式設計代理正在大幅降低原生應用程式的開發和維護成本。
• 裝置端 AI讓原生開發更具吸引力，而跨平台框架往往落後於平台的新能力。
• **隱性成本，**包括框架維護、內部開發者生態、跨團隊協調和組織政治，經常被低估。
• **新冷戰與 AI 軍備競賽：**我們如今正處於一場新冷戰之中，AI 已成為其中最重要的戰略戰場之一，就像上一次冷戰中的戰略防禦倡議（星際大戰計畫）一樣。隨著競爭加劇，相比開發成本，產品上市速度和使用者體驗變得越來越重要。

不過，在討論 AI 之前，我想先分享一些自己在中國網際網路產業觀察到的事情。

一次編寫，到處執行？

在我工作過的幾家中國大型網際網路公司裡，跨平台框架常常被宣傳為降低開發成本的手段。

但它們的野心遠不止於在 iOS 和 Android 之間共用程式碼。

公司希望程式碼只寫一次，就能在所有地方執行：iOS、Android、H5、微信小程式、支付寶小程式，有時甚至包括更多平台。

這個說法聽起來很簡單：一次編寫，到處執行。

但現實要複雜得多。

• **只寫一次？未必。**有時開發者最終需要寫三遍程式碼：iOS 一遍，Android 一遍，跨平台框架再一遍。支援 Web 或小程式平台還可能帶來更多工作。
• **效能與使用者體驗。**要接近原生效能，往往需要投入大量工程工作，而且某些限制無法徹底消除。
• **平台 API 的落後。**iOS 和 Android 的新能力，並不總能立即透過跨平台框架使用。
• **協調開銷。**跨平台開發在業務團隊、框架團隊和原生平台團隊之間引入了額外的相依關係。
• **組織政治。**有些工程專案似乎更關注技術成就、團隊擴張和升遷，而不是實際業務價值。
• **不必要的迭代。**業務真的需要如此頻繁地修改應用程式嗎？還是說，有些專案僅僅是為了工作而製造出來的工作？

而每增加一層複雜性，都要付出代價。

即使一個框架縮短了開發時間，我們又該如何衡量在這個過程中犧牲的效能、使用者體驗和商業機會？

隱性成本：內部開發者生態

建構跨平台框架時，最容易被低估的成本之一，就是維護它的開發者生態。

Apple 和 Google 在開發者生態上投入巨大，因為這些生態直接強化了它們的平台和業務。

但當一家網際網路公司建構自己的跨平台框架時，實際上是在公司內部建立了另一個開發者平台。

它必須維護原生 API 橋接、UI 元件、建置工具、除錯工具、測試基礎設施、文件、SDK 整合，以及向後相容性。

而這個內部生態必須持續跟進 iOS、Android 的演進，有時還包括 Web、小程式和 HarmonyOS。

這家公司不再只是在開發一個應用程式，而是在維護一個平台之內的平台。

使用 React Native 這樣的成熟框架可以減輕這種負擔，因為 Meta 和開源社群維護了它的大部分生態。但大型公司最終往往還是會圍繞它建構大量內部基礎設施。

那麼，把這個生態自身的開發和維護成本算進去之後，它究竟節省了多少錢？

建構它，到底是因為業務需要，還是因為一個工程組織需要找些東西來做？

熱更新與被製造的需求

跨平台和動態化框架在中國網際網路產業如此流行，還有另一個原因：熱更新。

許多公司希望更新應用程式時，不必每次都走傳統的應用程式商店審核和發布流程。

對於那些不斷開展行銷活動、促銷活動和頻繁產品實驗的公司來說，這尤其有吸引力。

但回頭看，我有一個疑問。

使用者真的需要這麼多變化嗎？

那些活動和持續迭代，真的創造了足以覆蓋其成本的業務價值嗎？

還是說，其中一些僅僅是被需要更多專案、更多活動和更多業績的大型組織製造出來的？

一個能讓不必要的開發變得更快的框架，並不一定能讓公司更有效率。

它可能只是讓公司更擅長製造不必要的工作。

而且，無論工程基礎設施變得多麼精密，公司都無法靠推出更多功能來解決根本性的業務問題。

工程效率並不必然轉化為業務效率。

應試型工程與被製造的複雜性

我在中國網際網路產業還觀察到另一個問題：一種應試型的工程文化。

中國的應試教育體系訓練人們解決難題，卻很少鼓勵他們追問：這些問題是否本來就不該存在？

這種思維方式可能延續到工程組織之中。

有些工程師非常擅長解決複雜的技術問題，卻很少質疑這些問題是否有必要解決。

有時，他們甚至會在沒有問題的地方製造問題。

軟體工程沒有完美的架構，沒有完美的框架，也沒有普遍正確的解決方案。只要拿出足夠多的論據、效能評測和精心挑選的取捨，幾乎任何技術決策都能被合理化。

這給組織政治留下了充足的空間。

只要一個提案聽起來在技術上合理，並讓關鍵的人滿意，工程團隊就幾乎可以為任何事情找到理由。

造一個新框架。重寫一個現有系統。再引入一層抽象。建立一個新的技術標準。

然後，利用專案的複雜程度、參與工程師的人數，以及所謂的技術成就，來獲得升遷。

目標不再是解決問題，而是製造值得拿來升遷的問題。

而且，因為不存在完美的架構，總會有另一個問題可以解決，另一個框架可以建構，以及另一個讓組織繼續忙碌的理由。

真正的問題——這一切是否創造了足以覆蓋成本的價值——卻往往被順手忽略。

當工程複雜性成為升遷的通道，簡單就成了威脅。

當抽象製造更多抽象

這裡有一件近乎荒誕的事。

在某家中國網際網路公司裡，曾經同時存在多個跨平台框架。

最終，又有人開發了另一個框架，用來讓這些已有框架彼此相容。

想想這件事。

我們為了降低複雜性而建構抽象，然後又建構另一層抽象，來管理那些抽象製造出來的複雜性。

荒謬。

而這發生在 AI 程式設計代理開始改變軟體開發經濟規律之前。

跨平台開發的經濟帳

這一切都可以用一個簡單的公式來審視。

先定義變數：

• $V_{cross}$

  — 採用跨平台框架所帶來的淨經濟價值。

• $C_{saved}$

  — 透過跨平台程式碼重用實際節省的開發與維護成本。

• $C_{complexity}$

  — 抽象、相容性問題、除錯和效能最佳化帶來的額外成本。

• $C_{ecosystem}$

  — 維護開發工具、SDK、測試基礎設施和平台 API 相容性的成本。

• $C_{organization}$

  — 協調、官僚主義、組織政治和升遷驅動型專案帶來的額外成本。

• $C_{opportunity}$

  — 上市延遲、平台 API 落後、較差的使用者體驗，以及喪失平台差異化所帶來的機會成本。

公式如下：

只有當跨平台框架實際節省的成本超過它引入的額外成本時，它才創造了正的經濟價值。

而這在 AI 出現之前，就已經是一個值得追問的問題。

AI 時代跨平台開發的經濟帳

現在，來看看 AI 如何改變這個等式。

第一，AI 程式設計代理正在大幅降低原生開發的成本。

因此，跨平台框架最初試圖節省的開發成本正在縮小。

第二，新冷戰和 AI 軍備競賽正在讓原生平台能力變得越來越有價值。

裝置端 AI，或者說邊緣 AI，將不可避免地成為 iOS、Android 及其他運算平台的重要組成部分。

原生開發能更快地使用新 API，提供更好的效能、更容易的整合，以及對平台專屬軟硬體更直接的存取。

但還有另一個值得問的問題。

為什麼 iOS 和 Android 應用程式一開始就應該一模一樣？

Windows 和 Linux 應用程式不一定外觀相同、行為一致。為什麼行動應用程式就應該如此？

不同平台擁有不同的硬體、作業系統、AI 能力和使用者預期。

未來幾年，Apple 和 Google 將繼續發展各自的裝置端 AI 能力、模型、硬體加速、隱私機制和系統層級整合。

為什麼一個產品要把自己限制在這些能力的共同子集之中？

在技術競爭激烈的時代，平台特有的差異可以成為競爭優勢，而不是有待消除的問題。

而當公司在效能、使用者體驗和創新速度上競爭時，開發成本的相對權重就會下降。

這提高了依賴跨平台框架的機會成本。

第三，AI 並不會消除跨平台框架引入的複雜性。

AI 程式設計代理可以幫助開發者更快地建構原生模組、調整以支援新 API，以及維護跨平台框架。

但寫程式碼只是問題的一部分。

跨平台框架仍然會引入額外的執行環境層、整合邊界、相容性要求和除錯複雜性。

出問題時，開發者可能需要判斷：問題來自作業系統、原生實作、框架，還是它們之間的整合？

AI 可以降低處理這些問題的成本，卻無法讓架構複雜性消失。

與此同時，AI 正在讓原生開發變得更便宜，而且不需要那些額外的抽象層。

AI 降低了實作抽象的成本，卻沒有消除這些抽象引入的複雜性。

因此：

跨平台框架的經濟價值正在受到兩頭擠壓。

原生實作正在變得更便宜，而平台特有的能力正在變得更有價值。

重用核心，不一定重用整個應用程式

2024 年開發那款 ASR/TTS 應用程式時，我最終選擇不使用跨平台應用程式框架。

我希望直接使用原生能力，包括 Core ML，以及圍繞 Whisper 的 C/C++ 推論生態。

有意思的是，whisper.cpp 本身就是一個跨平台專案。

但這是一種本質上不同的程式碼重用。

在不同作業系統之間共用一個 C/C++ 推論引擎，與強行讓整個應用程式經過同一套 UI 框架、執行環境和開發者生態，並不是一回事。

原生 iOS 應用程式可以使用 SwiftUI 和 Core ML。原生 Android 應用程式可以使用 Kotlin 和 Android 特有的加速能力。兩者仍然可以重用同一個推論核心中適合共用的部分。

跨平台程式碼重用，不等於跨平台應用程式框架。

我反對的不是共用程式碼，而是「共用整個應用程式的實作總能帶來經濟收益」這個假設。

而 AI 讓這種區分變得越來越重要。

尷尬的中間地帶

對於簡單應用程式、內容驅動型產品和頻繁更新的頁面，為什麼不直接使用 Web 技術？

Web 已經提供了一個成熟、受到廣泛支援、擁有龐大開發者生態的平台。

對於功能豐富的應用程式，尤其是那些深度整合裝置端 AI、硬體加速和作業系統能力的應用程式，為什麼不使用原生開發？

跨平台應用程式框架正越來越尷尬地夾在中間。

當然，它們在某些情境下仍然有價值。一個小團隊，如果在開發複雜度適中、對平台特有能力需求有限的應用程式，可能會從 React Native 或 Flutter 中獲得很大收益。

但這種價值應當被證明，而不是被假定。

我們也應該停止把程式碼重用視為不容質疑的工程美德。

幾十年前，Java 普及了「一次編寫，到處執行」的理念。現代軟體工程的很大一部分沿著同一個方向前進：引入抽象，降低支援不同平台的成本。

AI 正在改變這一決策背後的經濟邏輯。

我們可能會再次為不同平台建構獨立實作，不是因為忘記了過去的經驗，而是因為實作本身的成本已經改變。

未來或許不是消除平台差異。

而是擁抱這些差異，同時讓實作它們的成本大幅下降。

重用核心。自動化實作。保留平台特性。