SwiftUI

前言 三十天的鐵人賽，像一場技術馬拉松，終於來到了終點線前。最初的目標很明確：結合我對 iOS 開發的熱情與工作上學習到的 DevOps 實踐，從零到一打造一款名為「台灣公路 K 點通」的 SwiftUI App，並為它建立一套完整的自動化開發流程。 每天產出一篇文章是個挑戰，也是將腦中零散知識點串連成完整實踐地圖的過程。從動機、UI/UX 的草圖規劃，到 Swift 語法的基礎、SwiftUI 的畫面雕刻，再整合 Core Location 與 MapKit, Google map 的地圖服務，期間並導入 Azure Boards 進行專案管理，最後用 Azure Pipelines 實現 CI/CD。 旅程回顧：從痛點到 App Store 的完整路徑 這三十天的內容，可以劃分為四個階段，描繪了一個 iOS App 從概念誕生到最終上架的完整生命週期。 第一階段：從痛點到藍圖 萬事起頭難，在一開始專注於「想清楚要做什麼」與如何做。 我們從一個生活中的真實痛點出發：在公路上難以快速找到特定里程的確切位置，這個具體的目標，成為了整個專案的起點。在技術選型上，我們比較了 UIKit 與 SwiftUI，並基於開發效率、宣告式語法的優勢，以及想要嘗試新技術的心情，最終選擇了 SwiftUI 作為主力框架。 接著，我們在 Azure DevOps 上初始化了專案，設定了 Git Repo，並選擇了適合個人專案的 Basic 流程，為後續的專案管理與 CI/CD 建立基礎架構。 在開始動手寫 App 前，我們先透過使用者流程圖釐清了 App 的操作路徑，再用手繪 Wireframe 與 AI 工具輔助，描繪出 App 的畫面草圖，確保了後續開發的方向明確。 第二階段：掌握 SwiftUI 在這個階段建立 Swift 的語言基礎，快速複習了變數、常數、Optional 型別與流程控制等核心語法，並釐清了 Class 與 Struct 的關鍵差異。接著，我們深入 SwiftUI 的核心，從 Text、Image 與 Button 等基本元件著手，並學習運用 VStack、HStack 與 ZStack 這些佈局容器將畫面元素組合起來。在此過程中，我們掌握了 @State 與 @Binding 如何驅動畫面即時更新，理解了 SwiftUI 的宣告式思想。 ...

前言 經過了前面 28 天的努力，我們的 App 終於來到提交審查的這一步。Apple 的 App Store 審查機制其實算是蠻嚴格的，確保每一款上架的 App 都經過確實審核，所以有不少人會卡在上架的門檻前。 蘋果 App Store 上架審查機制 權限存取 (Access) vs. 資料收集 (Collect)。 資料收集 (Collect) 蘋果的審查規則其實大致上繞不開幾個重點，比方說禁止任何形式的歧視、誹謗、暴力描述，以及色情或鼓勵非法行為的內容。 另一個重點是「隱私權」。Apple 是著名地十分注重隱私，並將這一理念貫徹到 App Store 的每一個角落。其核心要求是：透明與掌控。開發者必須清楚告知用戶他們收集了什麼資料、為何收集，並給予用戶控制其個人資料的權利。 開發者在 App Store Connect 提交 App 時，必須誠實地自我報告 App 會收集的各種資料。這些資訊會直接顯示在 App Store 的產品頁面上，供使用者下載前參考。 舉例來說，假設你的 App 是一款健身應用，會記錄用戶的身高、體重等健康資訊，並使用電子郵件註冊。在隱私權標籤中，你就必須勾選「健康與健身」和「聯絡資訊」這兩項，並說明這些資料會「與您連結」，因為它們與用戶的個人帳號綁定。如果你的 App 只是個單機遊戲，完全不收集任何資訊，你也需要在標籤中明確標示「未收集資料」。 回到我們的 App，有取得使用者位置，這樣算不算「收集」資料？我們來看蘋果官方在 Data collection 這一節當中的這段說明： “Collect” refers to transmitting data off the device in a way that allows you and/or your third-party partners to access it for a period longer than what is necessary to service the transmitted request in real time. “Third-party partners” refers to analytics tools, advertising networks, third-party SDKs, or other external vendors whose code you’ve added to your app. ...

為我們的 App 加上 logo 在我們開始寫我們的 pipeline 之前，我突然想到有一件很重要的事情，那就是為我們的 App 加上一個看起來很讚的 icon。App icon 是使用者在 App Store 的第一個接觸點，某種程度上算是決定使用者有沒有興趣的關鍵。 蘋果對 icon 的格式有明確的要求，必須是一個 1024x1024 像素、方形、無圓角、無透明度的 PNG 檔案。當你圖片檔拖入 Xcode 的 Assets.xcassets 中對應的 AppIcon 位置時，Xcode 會自動根據這個圖檔，生成所有需要的尺寸，以適應 iPhone、iPad、通知、Spotlight 搜尋、設定頁面等各種顯示情境。 你也可以按照亮色或暗色主題提供不同的 icon 樣式。 接著我們要進入一個十分重要的部分。 蘋果的 Code sign 機制 為什麼要有這個機制？ 蘋果希望確保用戶從 App Store 下載或安裝的每一個 App，都來自於「已知的開發者」，且「未被竄改」。為了實現這個目標，蘋果建立了一套基於數位簽章的信任鏈。 為了達到這個目的，有以下幾個核心概念： 開發者憑證 (Certificate) 可以把它憑證想像為蘋果官方頒發給開發者的身份證，用來證明「該開發者為該開發者本身」。它保證了 App 是由一個已知的、經過蘋果驗證的開發者所建立的。 而憑證又可區分為開發憑證與分發憑證： 開發憑證 (Development Certificate): 此張憑證讓開發者可以在自己的測試裝置上安裝和測試 App。 分發憑證 (Distribution Certificate): 只有用此憑證簽署的 App，才能上傳到 App Store。 App ID 每個 App 具有獨一無二的的全球唯一識別碼，用來特定 App。 ...

前言 在上一篇文章中，我們完成了 iOS 專案的本地端準備工作。現在，我們將實際設定 Azure Pipelines，目標是讓專案能夠自動化建置並部署到 App Store Connect。 步驟一：Apple Connect 新增 API 金鑰 為了讓 Azure Pipelines 這類 CI/CD 工具能以自動化的方式將 App 上傳至 App Store Connect，我們必須先產生一組專用的 API 金鑰。這組金鑰將授權 Azure Pipelines 執行上傳等操作。 首先登入 App Store Connect 帳號。 登入後，點擊進入「使用者與存取權限」區塊。 選取「使用者與存取權限」，並要求存取權限。 接著，切換到「整合」頁籤，點擊「產生 API 金鑰」。 為這組金鑰設定一個好辨識的名稱，並在「存取權限」欄位選擇「App 管理」。這個權限足以讓 Pipeline 執行建置、上傳與發布等任務。 金鑰產生後，請下載 .p8 檔案並妥善保存，因為它只能下載一次。同時，將頁面上的 Key ID 和 Issuer ID 記錄下來，這些資訊在後續設定中都會用到。 步驟二：Azure Pipelines Connection 設定 有了 Apple 提供的憑證後，接下來我們回到 Azure DevOps，設定 Pipeline 與 App Store Connect 之間的橋樑。 ...

前言 時間來到了第 26 天，App「台灣公路 K 點通」(對，取名了XD) 核心功能已大致完成，是時候著手建立一套自動化的 CI/CD (持續整合/持續部署) 流程了。預想目標是，當推送一個新的 Git Tag 時，Azure DevOps 能自動幫我完成測試、建置、簽署，並將 App 上傳到 App Store Connect，以供後續提交審查。 但在開始處理 CI/CD 之前，有個前置作業必須先完成，那就是我們必須先在 Apple 的後台註冊我們的 App。 CI/CD 無法無中生有 在我們的情境當中，CI/CD 工具的角色是更新部署一個已經存在的 App 紀錄。它們無法替我們決定 App 的名稱、定價、隱私權政策等需要人工決策的資訊。因此，我們必須先手動完成 App 的註冊與設定，CI/CD 的自動化流程才能接著運作。 整個前置作業分為兩步驟： 在 Apple Developer 網站註冊 App ID 在 App Store Connect 新增 App 步驟一：在 Apple Developer 網站註冊 App ID App ID 是你的 App 在 Apple 生態系中獨一無二的識別碼，也稱之為Bundle Identifier。CI/CD 工具和 Xcode 都會用這個 ID 來識別你的專案。 登入 Apple Developer 網站 前往 developer.apple.com，使用你的開發者帳號登入。 ...