跨平台流動應用已不再是遙不可及的目標。銀行、保險公司及類似產品機構現已將多平台應用視為標準要求，而非實驗室試驗。最昂貴的錯誤是選擇適合會議演講的技術堆疊，而不是適合你的客戶組合、國家足跡及現有工程重心的方案。Flutter 與 Kotlin Multiplatform 均已在 2026 年推出真實產品。它們回答不同的問題。只有在你明確指出 Android、iOS 與網頁是否為同等地位，或 Android 是否為中心而 iOS 只是有意義但規模較小的群體後，才應將它們視為替代方案。
這個決定首先是組織層面的，其次才是技術層面的。一個必須在手機與瀏覽器上看起來完全一致的綠地消費者錢包，與一個已在 Android 上運行 Kotlin 且需將邏輯擴展至 iOS 而無需建立 Dart 產業的大型零售業務，是完全不同的問題。地理因素也很重要。亞洲大部分地區及許多大型零售銀行基地均以 Android 為主。香港、新加坡、英國及美國的部分地區則傾向更均衡的 iOS 與 Android 組合，而網頁往往是重要的獲客及服務渠道。請使用你自己的業務數據，而非全球平均值。
2026 年各方案的實際情況
Flutter 是一個單一 UI 跨平台工具包。你使用 Dart 撰寫，交付單一互動模型，並讓 Flutter 的引擎繪製像素。Impeller 是 iOS 及 Android API 29 以上的預設渲染引擎，並預先編譯著色器以消除舊有的著色器卡頓路徑。同一個產品介面可從單一程式碼庫同時支援 Android、iOS、網頁及桌面。這是誠實的賣點：一個團隊、一個設計系統、多個目標。
Kotlin Multiplatform（KMP）並非「Flutter 但用 Kotlin」。JetBrains 在 2023 年 11 月的 Kotlin 1.9.20 中宣布 KMP 核心穩定且可投入生產。Google 將 KMP 文件化為支援在 Android 與 iOS 之間共享業務邏輯的方案。你可共享領域模型、網絡、政策及持久化；UI 可維持原生（Android 使用 Jetpack Compose，iOS 使用 SwiftUI），或轉向 Compose Multiplatform（CMP）。CMP 是建構在 KMP 之上的可選 UI 共享層，並非 KMP 的同義詞。2025 年 5 月的 Compose Multiplatform 1.8.0 標誌著 Compose for iOS 穩定且可投入生產。這改變了如果你選擇共享 UI 時可共享的程度，但並不強迫你共享 UI。它也不會讓 KMP/CMP 的網頁體驗預設成為 Flutter 網頁故事的同級對手。
請盡早在任何指導委員會中澄清混淆。沒有 CMP 的 KMP 是共享邏輯加上平台擁有的 UI。帶有 CMP 的 KMP 是共享邏輯加上你在選擇使用時的共享 Compose UI。Flutter 則是在單一 Dart 堆疊下的共享 UI 與共享邏輯。這是三種姿態，而非兩個標誌。
Flutter 的優點
Flutter 的優勢在於跨目標的單一 UI 及互動模型。品牌旅程、註冊漏斗及設計系統元件可一同運作。熱重載、成熟的工具及龐大的綠地產品團隊招聘池，使其在無法同時組建平行原生 UI 團隊時極具吸引力。對於需要 Android、iOS 及類應用程式網頁介面感覺像同一個產品的機構，Flutter 仍是實現一致品牌體驗的最短途徑。
這種一致性在設計系統為自訂而非「像素完美作業系統原生」時最為重要。錢包、注重行銷的獲客流程及具視覺特色的消費者產品，通常希望各地像素完全相同。Flutter 正是為此理念而建。桌面目標在需要時存在；對銀行及保險公司而言，實際好處通常是來自單一團隊的流動應用加網頁一致性。
Flutter 的缺點或成本
Flutter 並非真正的原生 UI。無障礙、排版及平台慣例需要刻意投入工作。螢幕閱讀器及作業系統慣例逐年改善，但它們仍是一項工程計劃，而非 Dart 元件隨附的免費特性。深入的平台 SDK 工作（OEM 銀行 SDK、專有加密模組、利基支付或認證函式庫）需透過平台通道或 FFI 進行。這種摩擦在具有大量裝置及供應商整合的企業產業中會顯現出來。
如果機構已是 Kotlin 及 Java 商店，Dart 便會成為技能孤島。應用程式大小及通道複雜度會隨著每一個尷尬的原生橋接而增加。這些都不是致命問題，但它們都是真實的成本中心，而會議演示往往省略。如果你的合規故事取決於對生物識別、金鑰庫及作業系統安全介面的直接原生控制，請在慶祝共享元件樹之前先計算橋接稅。
KMP 及 Compose Multiplatform 的優點
KMP 可重用 Kotlin 領域、網絡及政策邏輯，而無需強迫你在重要之處放棄原生 UI。這對 Android 為重的團隊及現有 Kotlin 程式碼庫來說是自然選擇。Netflix 曾描述透過 KMP 為其 Android 及 iOS 工作室應用共享平台無關的業務邏輯，同時保留對 Jetpack Compose 及 SwiftUI 的偏好。Cash App 已多年在生產環境中使用 KMP，成為 JetBrains 材料中長期金融應用案例研究。請將供應商案例研究視為存在證明，而非保證你的產業能共享相同比例的程式碼。
當 UI 維持平台擁有時，原生 iOS 及 Android 感覺仍可保留。CMP 自 2025 年中起穩定的 iOS 路徑，讓團隊可在選擇時共享更多 UI，包括逐步按畫面採用，而無需全有或全無的重寫。希望對生物識別、金鑰庫及作業系統安全 API 維持原生控制的受監管機構，通常發現 KMP 加原生 UI 的姿態比全自訂渲染堆疊更容易向安全審查者解釋。Google 對 DataStore、Room 及 ViewModel 等函式庫的 Jetpack 多平台支援，進一步減少了 Android 端「共享模組感覺次等」的反對意見。
KMP 及 CMP 的缺點或成本
沒有 CMP 的情況下，你仍需為兩個 UI 團隊或兩個 UI 程式碼庫付費。共享邏輯可減少領域層的重複，但不會刪除 SwiftUI 及 Compose 的人力配置。使用 CMP 時，iOS 及特別是網頁的成熟度，加上招聘 Android 以外的 Compose 人才，對某些團隊而言仍落後於 Flutter 的單一堆疊開發者體驗。JetBrains 自己的 CMP 1.8 說明將網頁描述為正在演進而非完成：導航及潤飾已改善，但 Compose Multiplatform for the web 並非 Flutter 作為首要產品渠道的同級對手。
許多銀行無論如何仍將網頁維持為獨立的 React 或 Angular 產業。這往往是正確的決定。不要假設 KMP 預設可取代網頁產品策略。協調開銷依然存在：共享模組、API 合約及跨平台專家的發布列車。KMP 獎勵已有 Android 及 iOS 專家且能就合約達成共識的機構。它會懲罰那些希望單一初級團隊就能抹除平台差異的機構。
Flutter 的良好使用案例
適合綠地消費者應用的精簡 Flutter，此類應用中品牌 UI 必須在 Android、iOS 及網頁上保持一致。無法組建平行原生 UI 團隊的小型或中型產品團隊，可從單一互動模型中獲得不成比例的價值。兩個流動作業系統及經常使用的流動網頁均為首要獲客渠道的市場，適合單一介面的押注。以設計為主導的產品（錢包、註冊、注重行銷的旅程）勝過深度 OEM 整合的情況是最甜蜜點。
如果你無論如何都要捨棄舊 Android 應用，且網頁一致性是未來十二個月的關鍵路徑，即使在原本以 Kotlin 為重的公司中，Flutter 仍是連貫的選擇。成本是開始一個 Dart 產業。好處則是不再假裝三個渠道為一，卻以三個渠道的方式配置人力。
KMP 及 CMP 的良好使用案例
適合 Android 優先機構的精簡 KMP，這些機構正擴展至 iOS 而無需進行 Dart 重寫。核心銀行及高保證流動應用中，原生 UI 及平台安全 API 不可妥協的情況，適合共享邏輯模型。已在生產環境中的大型 Kotlin 後端及 Android 應用，可逐步共享領域層。主要為 Android 且有意義但規模較小的 iOS 群體的足跡，符合經濟效益：保護 Android 速度、擴展邏輯、保持 iOS UI 原生或選擇性使用 CMP。
逐步採用是一項特性，而非對沖。先共享網絡及政策。若設計系統及團隊技能合理，之後再為選定畫面加入 CMP。這種排序一旦你已為整個介面投入 Dart，便較難以 Flutter 方式偽裝。
策略分岔 A：Android、iOS 及網頁均為首要
當客戶群同時涵蓋兩個流動作業系統，並將流動或桌面網頁視為真實渠道時，分岔非常明確。iOS 與 Android 組合均衡的國家及客群（香港、新加坡、英國及美國的部分地區常見），加上注重網頁的註冊流程，會傾向單一產品介面。當一個設計系統必須部署到各處，且你不會為相同旅程資助獨立的網頁產品堆疊時，選擇精簡 Flutter。
只有在網頁維持為獨立堆疊，且你接受流動端僅使用原生或 CMP UI 時，才選擇精簡 KMP。這仍可能是正確做法：許多機構會為公開網頁保留 React 或 Angular，並使用 KMP 處理已驗證的流動應用。不要將這種姿態推銷為「單一跨平台策略」。應將其推銷為流動邏輯共享，並旁邊有一個誠實的網頁產業。失敗模式是因為投影片寫著 multiplatform，就承諾 KMP/CMP 可提供類似 Flutter 的網頁一致性。
策略分岔 B：主要 Android，部分 iOS
當客戶群及國家以 Android 為主（亞洲大部分地區、許多大型零售銀行基地），而 iOS 群體規模較小但重要時，機構內現有的 Android 及 Kotlin 重心通常會勝出。選擇精簡 KMP：保護 Android 速度、將邏輯共享至 iOS、保持 iOS UI 原生或選擇性使用 CMP。安全及平台團隊可繼續使用熟悉的 API。招聘則維持在你已支付的 Kotlin 人才市場內。
Flutter 在此情況下若網頁一致性比 Android 傳承更重要，或如果你正替換而非擴展舊 Android 應用，仍然可行。關鍵在於下一個主要版本是「擴展我們已有的」還是「具瀏覽器一致性的新消費者介面」。沒有網頁壓力的傳承指向 KMP。具網頁同級地位的綠地品牌介面則指向 Flutter。
CTO 的決策要點
按產品而非口號為組合評分。先從客戶及國家開始：你真實業務中的作業系統份額，而非供應商全球圖表。詢問網頁是同級應用還是手冊加回應式網站。明確產業情況：綠地還是你打算保留的大型 Kotlin 或 Android 程式碼庫。明確團隊形態：單一跨平台團隊，還是 Android 及 iOS 專家，他們不會在一夜之間成為 Dart 工程師。
接下來是合規及裝置安全深度。如果平台通道相對於原生 API 將主導每個發布列車，請誠實計算該摩擦。陳述你的 UI 原則：各地像素完全相同，還是原生平台慣例。設定時間範圍：十二個月內推出有利於你團隊現在能配置的堆疊；五年平台則有利於你能維持的語言及招聘市場。寫下明確的非目標：你不會共享什麼（網頁、桌面、OEM SDK、無障礙關鍵畫面）。模糊的非目標正是 Flutter 計劃悄悄放棄網頁，以及 KMP 計劃悄悄發明第三個 UI 框架的原因。
立即下一步
在單一工作會議中與產品、流動及安全負責人共同為每個產品按該清單評分。只有在決定 genuinely 接近時才雙向試行單一旅程；否則就選擇並配置人力。沒有人打算終止的雙重試行是路線圖停滯的原因。將「我們之後可能加入網頁」凍結為架構決策記錄中的明確假設。這單一句子往往比任何功能矩陣更能乾淨地決定 Flutter 還是 KMP。
當你的客戶組合、國家足跡及 Kotlin 或 Dart 重心仍未在白板上使用時，卻緊抱框架潮流，正是機構買錯五年方案的原因。當單一 UI 必須橫跨 Android、iOS 及網頁時，Flutter 仍然勝出。當 Android 為中心、原生控制重要且網頁維持次要或獨立時，KMP（搭配可選 Compose Multiplatform）勝出。根據你現有的產業選擇。