去年 9 月，我們推出了 iOS 和 Android 版 Proton Mail 的重大更新。
表面上，新的應用程式提供了現代化的設計、更好的效能和離線功能——但還有很多不僅止於眼見的地方。在幕後，這些應用程式是在新穎的技術堆疊上對 Proton Mail 的完全重寫，這個專案在內部被稱為工程轉型。新穎一詞是刻意使用的，因為——據我們所知——這是所選技術首次在已建立的生產應用程式環境中使用。
本文旨在闡明我們團隊在打造這場革命過程中所經歷的迷人旅程，並回答我們社群在此過程中問過我們的一些問題。首先，背後的理由是改變現狀的需要。
這一切是如何開始的
需要改變的領悟在 2023 年 10 月的一個週五晚上襲來。它以令人驚訝的清晰度具體化，但並非憑空而來：這是數月努力尋找影響我們使用者對 Mail 和行事曆行動產品體驗的看似不相關問題的共同分母的結果。
冒著過於簡化的風險，我們可以將痛點總結為三個領域：
- 品質： 單獨來看，Mail iOS 和 Mail Android 在品質和效能方面未達到預期。
- iOS 和 Android 之間的功能差距： 某些功能僅在一個平台上可用，而不清楚另一個平台何時會趕上。
- 工程速度： 關鍵更新和期待已久的功能沒有在兩個平台上及時交付。
一些問題延伸到了行動裝置之外，回答這些問題需要從技術領域離題到組織擴展的迷人問題空間，特別是快速成長的科技新創公司。但行動生態系統的脆弱性很大程度上植基於技術和架構。
擴展行動工程
擴展行動工程伴隨著一系列獨特的挑戰，這些挑戰與擴展後端和網頁團隊有顯著不同。這些差異源於平台碎片化和行動生態系統的營運現實。行動團隊通常需要支援跨各種作業系統和裝置（手機、平板電腦，有時還有穿戴式裝置）的多個平台。iOS 和 Android 都有自己的程式語言、框架和工具，這導致大量的重複工作：多個團隊、重複的程式碼基底，以及在特定於平台的工作與產品相關工作之間不斷權衡。保持產品供應同步需要大量的協調。
對 Proton 來說，全行業的挑戰尤其嚴峻。像 Mail 和行事曆這樣的功能性應用程式本質上比市面上的大多數行動應用程式更複雜。當您在其之上添加處理端對端加密所需的額外客戶端邏輯層時，您最終會得到特別「厚」的客戶端。當年，Android 團隊忙於重寫 Mail 以達到更好的品質標準——這項投資花費了 18 個月的大部分時間。iOS 也急需重新架構，更不用說行事曆了。重複的成本正在吞噬我們所有的工程資源，很明顯，我們若繼續做同樣的事情是不會成功的。
承認自己陷入困境的最好之處在於，它充當了一個強迫因素，讓您在當前現狀的限制之外思考。如果我們可以重新開始，擺脫導致我們走到這一步的選擇和承諾的負擔，我們會怎麼做？當您更仔細地檢視成功公司在過去十年中如何處理這個問題時，您會意識到他們只遵循了兩種可能的策略之一：
- 他們砸錢解決問題，建立越來越龐大的團隊，因為源源不絕的投資和/或豐厚的回報抵銷了高昂的營運成本。這對 Proton 不依賴創投的商業模式來說並非選項：我們無法與依賴廣告且有投資者支持的競爭對手的支出相抗衡。
- 他們在這個問題上砸錢，建立更大的團隊，因為高昂的營運成本被無底洞的投資和/或豐厚的回報所抵消。這對於 Proton 無創投的商業模式來說不是一個選項：我們無法與基於廣告、有投資者支持的競爭對手的支出競爭。
由於方案 1 不可行，未來的路徑已經確定。
由於選項 1 不可行，前進的路徑已經確定。
達到目的的手段：選擇正確的技術堆疊
下一步是選擇一個實際上能完成工作的技術堆疊。
在過去 15 年中，跨平台行動開發充斥著「一體適用」的解決方案：HTML5、Xamarin、React Native、Flutter、Kotlin Multiplatform 和許多其他解決方案。每一個的到來都帶著相同的承諾——徹底取代原生開發。實際上，大多數要麼徹底失敗，要麼僅在受到嚴格限制的問題空間內成功。沒有通用的抽象可以讓平台差異消失：任何發佈並維護過大型行動應用程式的人都知道這一點。唯一可靠的前進方式是從具體需求向後工作，而不是從工具趨勢向前工作。
- 成本和時間表： 該堆疊必須實質降低在 iOS 和 Android 上發布、維護和演進 Proton Mail 所需的成本和時間。
- 成本和時間表： 該堆疊必須實質性地減少在 iOS 和 Android 上發佈、維護和演進 Proton Mail 所需的成本和時間。
- 使用者體驗： 它必須保留近乎原生的效能和互動品質——任何不足之處都是不可行的。
前兩個限制之間的張力是業界的聖杯：「一種跨平台解決方案，可提供原生應用程式的效能和使用者體驗。」
我們從一開始就懷疑 React Native 或 Flutter（當時兩個主導的跨平台框架）能否達到這個標準。儘管如此，我們還是透過建立 Mail 訊息清單檢視的概念驗證實作來驗證這種懷疑。
React Native 很快就暴露了它的局限性。捲動大型資料集使得其解釋執行模型的成本顯得非常明顯。Flutter 的表現較好，但 UI 在視覺上仍然顯得非原生，尤其是在 iOS 上。更重要的是，Flutter 是由 Google 控制的專有框架，Google 有放棄內部技術的歷史(新視窗)，且最近解雇了大部分 Flutter 團隊成員。對於一個具有長期安全性和可靠性保證的產品來說，這種程度的外部依賴是無法接受的。
Kotlin Multiplatform 是下一個候選者。這是一個引人注目的選項，特別是對於擁有深厚 Android 專業知識的組織而言，但它最終未能滿足我們的使用案例。缺乏共享 UI 層、成熟度問題以及其執行模型引入的額外開銷超過了它的好處。
Kotlin Multiplatform 是下一個候選者。這是一個引人注目的選項——特別是對於擁有深厚 Android 專業知識的組織來說——但它最終未能滿足我們的使用案例。缺乏共享的 UI 層、關於成熟度的問題，以及其執行模型引入的額外開銷，超過了它的好處。
此時，結論很明確，並且與我們最初的直覺一致：唯一能持續接近預期結果的架構是刻意混合的堆疊。每個平台上的原生 UI – Android 上的 Jetpack Compose，iOS 上的 SwiftUI – 由用高效能、低階語言編寫的共享業務邏輯層支援。這種方法有跡可循：Dropbox 曾著名地使用 C++ 在行動平台之間共享業務邏輯，然後在 2019 年因為該語言的營運和認知成本而放棄了它。
到 2023 年底，Rust 已明確成為系統程式語言譜系中的繼任者。
Rust 擁有與 C++ 相同的效能範圍，但沒有其許多的歷史債務。它提供強大的記憶體安全保證而無需垃圾回收，在編譯時強制執行執行緒安全的並發性，並由龐大、高能力的開放原始碼生態系統支援。同樣重要的是，Rust 與原生行動語言——iOS 上的 Swift 和 SwiftUI，Android 上的 Kotlin 和 Jetpack Compose——乾淨地整合，使其成為共享核心邏輯而不損害 UI 層的務實選擇。
這不是一個無風險的決定。當時，幾乎沒有建立在以 Rust 為中心的架構上的大規模、面向消費者的行動應用程式的例子，且團隊內部的 Rust 經驗有限。
但有意義的創新很少發生在低風險領域。真正的挑戰不是 Rust 本身，而是組織慣性——在明確的限制和工程判斷的指導下，從經過驗證、保守的方法轉向刻意的實驗。
新的 Proton Mail：結果和教訓
讓我們快轉到今天，看看這場賭博的結果如何。
架構圖由 Leander Beernaert 提供，2026
- 在發布後的兩個月內，團隊設法維持了跨兩個平台的每週功能更新步調（總共 12 次功能發布）。
- 在發佈後的兩個月內，團隊設法維持了跨兩個平台的功能更新每週節奏（總共 12 次功能發佈）。
- 我們關閉了平台之間的功能差距，將期待已久的功能帶到了 Android，例如延後、行事曆 RSVP 和滑動至下一則訊息。
在這種方法下，支援也能更有效地擴展。識別並解決單一、共享的根本原因，通常比追查散布在兩個獨立程式碼庫中、由稍微不同的邏輯缺陷引起的表面相似問題要快得多。在修復一類影響應用程式離線功能的類別同步問題時，我們發現了先前工作假設的實證確認：一個根本原因，一個解決方案——如上圖所示，由隨 7.6.2 版本發布的 Rebasing 模組所代表。
在這種方法下，支援也更有效地擴展。識別並解決單一、共享的根本原因，通常比追查因分佈在兩個獨立程式碼基底中的稍微不同邏輯缺陷而產生的表面相似問題要快。在修復一類影響支援應用程式離線功能邏輯的類別同步問題時，我們發現了先前工作假設的經驗證實：一個根本原因，一個解決方案——由上圖中隨 7.6.2 版本發佈的 Rebasing 模組表示。
- 錯誤和回歸可能會產生更廣泛的影響，並影響兩個平台上的使用者。你無法真正擁有一切，但絕對可以透過過度重視端對端 (E2E) 測試來降低風險。
- 正如任何沿著水平技術劃分使用者導向解決方案的切分一樣，存在著建立知識孤島和失去對端對端使用者體驗的一些工程關注的風險。你需要意識到這一點並刻意降低風險。其中最有效的措施：
- 錯誤和回歸可能會有更廣泛的影響，並影響兩個平台上的使用者。您真的不能兩全其美——但您絕對可以透過過度索引端對端 (E2E) 測試來減輕風險。
- 培訓行動工程師成為「全端」工程師，即能夠在 Rust 程式碼庫和原生平台之間進行偵錯、支援和工程設計。
工程轉型的下一步
工程轉型的下一步是什麼
從這個專案的一開始就很明確，利害關係遠遠超出了 Proton Mail 本身。成功將此技術堆疊套用於 Proton 的旗艦應用程式，一直旨在作為更長旅程的第一步——這最終將看到這種方法在我們其餘的行動生態系統中推出。
這標記著第二波工程轉型的開始——這是一個演進，透過一個架構框架擴展技術藍圖，旨在使元件重用更容易，不僅跨平台，而且跨產品。雖然這種轉變不會在一夜之間發生，但這對於建立客戶期望 Proton 成為的無縫整合、隱私優先的生態系統至關重要。
(1): Simon Lewis,「多平台應用程式實作策略」, 2023.
