前言

在 Day 1 時曾提到，這次要開發的 App，是讓使用者能直接輸入公路的里程數，並即時在地圖上定位。這次我選擇以 SwiftUI 來開發，除了想藉此機會嘗試這個框架外，更重要的是，我認為作為軟體工程師，理解各種技術的優勢與限制，並根據實際需求做出合適的選擇，是非常重要的能力。

技術本身只是工具，沒有絕對的對錯。關鍵在於能否根據專案目標、團隊狀況與未來維護等因素，做出最適合的技術選型，而不是單純因為新穎或流行。

而在 iOS 的原生開發中，主要有 UIKit 與 SwiftUI 兩個框架。SwiftUI 是蘋果在 WWDC 2019 發布的開發框架。以 2025 年的今天來看，它已不算最新技術，但相對於歷史悠久的 UIKit，仍是一個非常年輕的框架。

以下簡單對兩個框架做基本介紹。

SwiftUI 與 UIKit 簡介與比較

雖然本系列文章的重點並非深入比較這兩個框架，但這裡仍簡要說明其主要差異：

命令式語法 ＆ 宣告式語法

命令式（Imperative）語法強調「如何做」：開發者需要明確描述每一步操作，手動管理 UI 狀態與流程。例如在 UIKit 中，必須指定元件的建立、佈局、狀態變更等細節。

宣告式（Declarative）語法則強調「要什麼」：開發者只需描述最終希望呈現的 UI 狀態，框架會自動處理狀態變化與畫面更新。例如 SwiftUI 中，直接描述畫面結構與資料綁定，讓 UI 隨資料自動更新。

我們用例子來說明可能會更清楚，以在畫面上放置一個按鈕，點擊後會增加數量紀錄的計數器為例，兩個框架的寫法相當不同：

• UIKit

圖 2-1 UIKit 範例

• SwiftUI

圖 2-2 SwiftUI 範例

可以看到程式碼的數量有明顯的差異。開發者只需將 count 變數與畫面元件綁定，當資料變動時，框架就會自動為我們處理 UI 更新。這不僅減少了手動操作 UI 的程式碼，也大幅降低了因狀態管理疏忽而出錯的風險。

除此之外，宣告式語法讓開發者的心力能更專注在「畫面應該長什麼樣子」，而不是「如何一步步把畫面變成想要的樣子」。對於我們的里程定位 App 來說，這代表當使用者輸入不同里程、或地圖狀態改變時，我們不必再手動更新標籤、按鈕或地圖標記的狀態，大幅提升了開發效率與程式碼的可維護性。

社群與資源

SwiftUI 看起來很棒對吧，而且每次修改完程式碼，右方會即時渲染。雖然後來 UIKit 也可以達到類似的效果，但我個人覺得還是 SwiftUI 比較方便。不過，SwiftUI 畢竟還年輕，當遇到較複雜或冷門的需求時，社群的資源與成熟的解決方案，仍不如歷史悠久的 UIKit 來得豐富，這點在查找資料時能明顯感受到差異。

性能與相容性

而 SwiftUI 許多新功能都需要較新版本的 iOS 才能使用。例如 NavigationStack（新版的導航結構）、Charts（繪製圖表）等元件必須 iOS 16 以上才支援。
因此若專案需支援較舊的 iOS 版本，SwiftUI 可能會受限，故需特別注意相容性問題。

選擇 SwiftUI 的理由

綜合以上比較，並考量到本專案的特性，我選擇 SwiftUI 的理由如下：

• 個人希望藉此專案練習 SwiftUI。
• 技術優勢：
  • 宣告式語法。除了開發快速，更重要的是它降低了 UI 狀態管理的複雜度。我們的 App 核心功能是「輸入 -> 定位」，畫面狀態相對單純，宣告式語法能讓我們用最直觀的方式實現資料與地圖畫面的連動。
  • 與地圖元件（如 MapKit）整合簡單，適合本專案需求。
  • 即時預覽(Preview)。即時預覽功能讓我們每次微調輸入框位置、按鈕樣式或資訊面板時，都能立刻看到效果，無需反覆編譯和執行 App。這在調整地圖上的圖標與說明文字時，節省了大量的來回確認時間，開發體驗很不錯。

總結：權衡之下的最佳選擇

總結來說，儘管 UIKit 相當穩定，但對於一個以地圖互動為核心、追求快速開發的個人專案而言，SwiftUI 的宣告式語法與高效率的開發體驗，就這個情境來說會是相當不錯的選擇。

雖然可能會面臨社群資源較少或特定功能需要新版 iOS 支援的挑戰，但這個專案的目標不僅是完成一個實用的工具，也是一個學習、實踐新技術的機會。