為什麼我在 SwiftUI 專案裡自創了一套 MVVMC 架構

Fri, 24 Apr 2026 00:00:00 +0000

在公司與外包共同開發，並在外包離開後接手留下來的 SwiftUI 專案。外包用的是 TCA（The Composable Architecture），target iOS 15+，架構本身有它的邏輯，但接手之後我做了第一個決定，不繼續用 TCA。

接著把 minimum deployment target 直升 iOS 17+。@Observable 可以用了，WithPerceptionTracking 全部可以掃掉，光這件事就讓整個 codebase 清爽不少，bug 也少了不少。

但還有一個問題一直卡著我：導航。

SwiftUI 導航，用過就知道

NavigationStack、NavigationLink、.navigationDestination，光看 API 名稱感覺很整齊，用下去才知道有多零碎。

頁面跳轉的邏輯開始出現在各個 View 裡，A 頁知道 B 頁的存在，B 頁知道 C 頁的存在。專案小的時候還好，Feature 一多，導航邏輯就像藤蔓一樣纏進每個 View，要改一個跳轉邏輯得找半天。

更麻煩的是 state 管理，navigationPath、@State var isPresented、.sheet、.fullScreenCover 各自為政，散落在不同層級的 View 裡，沒有一個統一的地方可以看清楚整個 app 的導航狀態。

然後你就會遇到這種需求：

「使用者在購物車結帳完成後，dismiss 掉結帳流程，然後自動切換到『訂單』Tab，同時把購物車的 Navigation stack 清空。」

UIKit 的做法很直覺：

1
2
3
4


// 清空 stack、切 Tab，三行搞定
navigationController?.popToRootViewController(animated: false)
tabBarController?.selectedIndex = 2
dismiss(animated: true)

SwiftUI 呢？你需要在對的時機、對的層級，同時操控 navigationPath、selectedTab 這些分散在不同 View 的 state，還要確保時序正確，不然畫面會閃、動畫會跳、甚至 state 不同步。更麻煩的是，深層的 View 根本拿不到外層的 selectedTab，除非你用 @Environment 或 @Binding 一層一層往下傳，然後每個中間層都變成了導航邏輯的搬運工。

MVVMC on Joe's Blog

為什麼我在 SwiftUI 專案裡自創了一套 MVVMC 架構

SwiftUI 導航，用過就知道