[Day 2] SwiftUI 與 UiKit 之比較與選擇
前言 在 Day 1 時曾提到，這次要開發的 App，是讓使用者能直接輸入公路的里程數，並即時在地圖上定位。這次我選擇以 SwiftUI 來開發，除了想藉此機會嘗試這個框架外，更重要的是，我認為作為軟體工程師，理解各種技術的優勢與限制，並根據實際需求做出合適的選擇，是非常重要的能力。 技術本身只是工具，沒有絕對的對錯。關鍵在於能否根據專案目標、團隊狀況與未來維護等因素，做出最適合的技術選型，而不是單純因為新穎或流行。 而在 iOS 的原生開發中，主要有 UIKit 與 SwiftUI 兩個框架。SwiftUI 是蘋果在 WWDC 2019 發布的開發框架。以 2025 年的今天來看，它已不算最新技術，但相對於歷史悠久的 UIKit，仍是一個非常年輕的框架。 以下簡單對兩個框架做基本介紹。 SwiftUI 與 UIKit 簡介與比較 雖然本系列文章的重點並非深入比較這兩個框架，但這裡仍簡要說明其主要差異： 命令式語法 ＆ 宣告式語法 命令式（Imperative）語法強調「如何做」：開發者需要明確描述每一步操作，手動管理 UI 狀態與流程。例如在 UIKit 中，必須指定元件的建立、佈局、狀態變更等細節。 宣告式（Declarative）語法則強調「要什麼」：開發者只需描述最終希望呈現的 UI 狀態，框架會自動處理狀態變化與畫面更新。例如 SwiftUI 中，直接描述畫面結構與資料綁定，讓 UI 隨資料自動更新。 我們用例子來說明可能會更清楚，以在畫面上放置一個按鈕，點擊後會增加數量紀錄的計數器為例，兩個框架的寫法相當不同： UIKit SwiftUI 可以看到程式碼的數量有明顯的差異。開發者只需將 count 變數與畫面元件綁定，當資料變動時，框架就會自動為我們處理 UI 更新。這不僅減少了手動操作 UI 的程式碼，也大幅降低了因狀態管理疏忽而出錯的風險。 除此之外，宣告式語法讓開發者的心力能更專注在「畫面應該長什麼樣子」，而不是「如何一步步把畫面變成想要的樣子」。對於我們的里程定位 App 來說，這代表當使用者輸入不同里程、或地圖狀態改變時，我們不必再手動更新標籤、按鈕或地圖標記的狀態，大幅提升了開發效率與程式碼的可維護性。 社群與資源 SwiftUI 看起來很棒對吧，而且每次修改完程式碼，右方會即時渲染。雖然後來 UIKit 也可以達到類似的效果，但我個人覺得還是 SwiftUI 比較方便。不過，SwiftUI 畢竟還年輕，當遇到較複雜或冷門的需求時，社群的資源與成熟的解決方案，仍不如歷史悠久的 UIKit 來得豐富，這點在查找資料時能明顯感受到差異。 性能與相容性 而 SwiftUI 許多新功能都需要較新版本的 iOS 才能使用。例如 NavigationStack（新版的導航結構）、Charts（繪製圖表）等元件必須 iOS 16 以上才支援。 因此若專案需支援較舊的 iOS 版本，SwiftUI 可能會受限，故需特別注意相容性問題。 ...