什麼是 JWT Token？ JTW 為 Json Web Token 的簡稱，是 RFC 7519 規範的一種資料交換格式。 JWT Token 的基本組成 JWT 字串分成三個部分，將三份資料以小數點的方式組合起來。 這三個部份分別為： Header: 描述加密的演算法及 Token 類型(JSON 格式) Payload: 實際上要傳遞的聲明資訊(JSON 格式) Signature: 將 Header 與 Payload 經過 Base 64 encode 後加上雜湊演算法產生的簽章，用來驗證 JWT 是否經過篡改。 將圖 1 拿去 JWT.io 解碼，結果分別會是： // Header { "alg": "HS256", "typ": "JWT" } // Payload { "sub": "1234567890", "name": "John Doe", "admin": true, "iat": 1516239022 } // Signature a-string-secret-at-least-256-bits-long RFC 7519 定義了 Payload 中的一些公認欄位： ...

Azure DevOps 設定 什麼是 Azure DevOps？ Azure DevOps 是微軟提供的開發工具服務平台，整合了版本控制、工作項目追蹤、自動化建置等功能。對於 iOS 開發者來說，它提供了： Azure Repos：Git 版本控制系統 Azure Pipelines：自動化建置和部署工具 Azure Boards：專案管理和工作追蹤 Azure Test Plans：測試管理工具 Azure Artifacts：套件管理系統 Azure DevOps 免費方案 依據官方說明，個人開發者可以享有以下免費額度： 無限量的私人 Git 儲存庫 最多 5 位 Azure DevOps 使用者 每月 1,800 分鐘的 Pipeline 執行時間 2GB 的 Azure Artifacts 儲存空間 這些免費額度對於個人專案來說已經相當充足。 建立 Azure DevOps 帳號 前往 Azure DevOps 官網 點擊「開始使用 Azure」按鈕 使用 Microsoft 帳號登入（如果沒有就註冊）。首次啟用 Azure 帳號時，系統會要求您填寫基本資料，依照畫面指示完成即可。 最後系統會要求綁定信用卡，這主要是為了驗證身分，在免費額度內並不會產生費用。如後續說明，Azure DevOps 的免費額度對個人專案來說綽綽有餘。 建立組織（Organization 登入後，第一步是建立一個組織。 ...

前言 在 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 可能會受限，故需特別注意相容性問題。 ...

與 iOS 開發的相遇 大家好，我是個從律師轉職的軟體工程師，踏入這個領域不知不覺也快兩年了。回想當初轉換跑道，一切從自學 Python 開始，接著摸索資料庫、API 等後端技術。後來有幸進入 AppWorks School (現已更名為 AiWorks) 接受 iOS App 開發訓練，最終進入金融業的 IT 部門。 進入公司後，我的工作日常相當「精彩」，除了本行的 iOS 專案開發與維護，還得兼顧後端維運、和 SQL 打交道，甚至管理 Splunk、Kong APIM 這些系統。雖然實際能投入在 iOS 開發的時間不如預期，但我對這塊領域的熱情從未減少。親手打造出一個能看、能用、能互動的應用程式，那種從無到有的創造感與成就感，是其他工作難以比擬的。也因此，剛進公司時，對於無法專注在 iOS 開發上，心裡難免有些失落。但現在回頭看，我相信廣泛接觸不同技術對一個軟體開發者來說絕對是不虧的事情。然而，心中那份對 iOS、特別是 SwiftUI 的渴望，依然強烈。 目前公司的專案仍以 Objective-C 與 UIKit 為主，雖然我曾用 SwiftUI 開發並上架過個人 App，但總覺得學得不夠扎實。這次鐵人賽，對我來說正是一個完美的機會，能強迫自己更多了解 SwiftUI 的世界，將那些零散的知識串連起來。 初入 DevOps 世界 在公司任職期間，我有幸參與了 Azure DevOps 的導入過程。坦白說，起初它對我而言，就只是個「新來的工具」：用 Wiki 寫文件、開 Work Items 追蹤任務、等 Pipeline 編譯出 .ipa 檔，然後透過 Pull Request (PR) 進行程式碼審查。每個環節都得遵循特定流程，像是 Pipeline 還需要主管審核才能部署，有時覺得有些繁瑣。 但隨著時間推移，這些經驗讓我逐漸體會到，DevOps 不僅僅是工具的堆砌，它更是一種文化，一種讓開發、測試與部署流程更順暢、更可靠的思維模式。當我看到一個小小的修改，能自動觸發測試、打包、甚至部署到測試環境，我才真正理解自動化所帶來的安心感。 即使現在是一人開發的個人專案，我也相信導入良好的 DevOps 實踐也是一個不錯的嘗試： 版本控制： 使用 Azure Repos 搭配 Git-flow 策略，讓每一次的程式碼異動都有所依循。 自動化測試： 設定 Pipeline 自動執行單元測試，確保程式碼品質。 持續整合： 每次提交程式碼後自動編譯並檢查。 持續部署： 自動將測試通過的版本部署到 App Store Connect。 這次的系列文章，我將結合 SwiftUI 開發與 DevOps 實踐，從建立基礎專案開始，一步步實現自動化的開發流程。 ...

之前因為一直沒有機會去處理到不同 App 之間跳轉的問題，對這塊的東西一直不太熟悉。最近因為遇到 App 不能成功開啟其他 App 的問題，才有機會了解一下。 不能開啟的原因是 App 使用很久以前的 API: 可以看到在 iOS 10 以後就被蘋果棄用了，然而蘋果棄用通常並不表示馬上不能用，所以這支 API 還活了很久一段時間，直到 iOS 18 蘋果才真正不給用。這支 API 已經被 open(_:options:completionHandler:) 取代（Objective-C 為 openURL:options:completionHandler:）: 雖然這個問題解決了，但我想藉此機會多了解一下跳轉這個機制。 要實現 App 能夠跳轉，例如 20250829_B 這個 App 要能夠讓被其他 App 開啟，就必須要去 target 設定裡的 Info 分頁，在 URL Type 裡面替自己定義 URL Schemes，這裡我們定義為 AppB。 接著，我們在另一個 App A 裡建立一個點擊會實現跳轉 AppB 的按鈕 程式碼如下： @IBAction func jumpToB(_ sender: Any) { let scheme = "AppB://" guard let url = URL(string: scheme) else { return } UIApplication.shared.open(url, options: [:]) { success in } } 我們僅實作 open(_:options:completionHandler:)，而不實作 canOpenURL(_:) 這支很常被使用的 API。 ...