IOS

Build 突然壞了，但沒有人改過 CI 設定 iOS 的 Jenkins pipeline 突然開始失敗。上一版（058）還好好的，下一版（059）就掛了。再跑一次（060），還是掛。 第一時間檢查 git diff —— 兩版之間只有 Dart 程式碼改動，沒有任何人碰過 Fastfile、Jenkinsfile、或 CI 相關設定。程式碼改動是 Flutter 層的 bug fix，跟 iOS build 流程完全無關。 這是最令人困惑的情境：什麼都沒改，但 CI 壞了。 先看一下各版的 build 結果： Tag Build 結果 耗時 prod-0.1.04+2026000058 #1 SUCCESS 9.5 分鐘 prod-0.1.04+2026000059 #1 FAILURE 2.3 分鐘 prod-0.1.04+2026000060 #1 FAILURE 2.3 分鐘 059 和 060 都只跑了 2 分多鐘就掛了 —— 連 Flutter build 都沒跑到，在 Fastlane 的前期設定階段就失敗了。 先理解 Fastlane 的 Keychain 機制 在深入除錯之前，先理解 iOS code signing 在 CI 環境的運作方式。 ...

廠商一句話，整個回調機制要重寫 我們的健康管理 App 整合了一台第三方氣酮檢測裝置。綁定流程很單純：使用者從我們的 App 跳到廠商的 App 完成綁定，綁定完成後跳回來，顯示成功或失敗。 原本的回調方式是 URL Scheme： myapp://device-bindback?status=success iOS 上一直運作正常，直到廠商的 Android App 更新後回報：他們不支援 URL Scheme 回調，要求改用 Universal Link。 這不是改一行 URL 的事。Universal Link 牽涉到網域驗證、靜態檔案部署、平台設定、安全機制，幾乎是把整個回調架構重新設計。 在深入之前，先釐清幾個關鍵術語： 術語 說明 URL Scheme 自訂的 URL 前綴（如 myapp://），讓其他 App 可以透過這個 URL 開啟你的 App。缺點是任何 App 都可以註冊相同的 scheme，沒有驗證機制。 Universal Link（iOS） Apple 的機制，把 HTTPS URL 和特定 App 綁定。系統透過 AASA 檔案驗證網域和 App 的關聯，確保只有合法的 App 能攔截該 URL。 App Links（Android） Google 對應 Universal Link 的機制，透過 assetlinks.json 驗證網域和 App 的關聯，原理相同。 AASA Apple App Site Association，放在 https://你的網域/.well-known/apple-app-site-association 的 JSON 檔案，告訴 iOS「哪些路徑要交給哪個 App 開啟」。 assetlinks.json Android 版的 AASA，放在 https://你的網域/.well-known/assetlinks.json，功能相同。 Provisioning Profile Apple 的簽名設定檔，記錄 App 被允許使用哪些功能（如 Push Notifications、Associated Domains）。新增功能時必須重新產生。 Deep Link 泛指所有能從外部開啟 App 並導到特定頁面的連結，URL Scheme 和 Universal Link 都是 Deep Link 的實作方式。 SHA-256 指紋 App 簽名憑證的雜湊值（32 組 hex，如 AA:BB:CC:...），用來唯一識別一個 App 的簽名身份。assetlinks.json 靠它比對「宣稱的 App」和「裝置上的 App」是否同一個。 Upload Key 開發者本地 keystore 的私鑰，用來簽名上傳到 Play Console 的 AAB/APK。本地開發、CI、模擬器都用這把。 App Signing Key Google Play 持有的私鑰，用來對上架版 App 做最終簽名。使用者從 Play Store 安裝的 App 是這把 key 簽的，指紋跟 upload key 不同。 改動前後的流程差異，用一張圖看最清楚： ...

問題現象：Xcode 正常，冷啟動閃退 最近在開發 Flutter iOS App 時遇到一個詭異的問題：透過 Xcode 按下 Run 按鈕啟動 App 完全正常，但當我停止 Debugger、從多工畫面滑掉 App、再從主畫面點擊圖示重新開啟時，App 只顯示 Launch Screen 就立刻閃退。 這個問題讓我走了不少彎路，最後發現答案簡單得令人意外。 誤導方向：UIScene 與 Plugin 註冊 由於 Xcode 26 開始顯示 UIScene lifecycle will soon be required 警告，我最初懷疑是 UIScene 遷移不完整導致的問題。接著又懷疑是 Plugin 註冊的 race condition，甚至在 GeneratedPluginRegistrant.m 中加入大量 debug log 來追蹤每個 Plugin 的註冊狀態。 嘗試過的「修復」包括： 完整實作 SceneDelegate 與 FlutterSceneDelegate 在 Flutter Engine 初始化前加入 0.5 秒延遲 逐一排除可能有問題的 Plugin 這些方向全部是錯的。 找到根本原因：iOS Console Log 關鍵轉折點是查看 iOS 的 Console log。使用 Xcode 的 Devices and Simulators > Open Console 或 macOS 的 Console.app 連接 iPhone，重現冷啟動閃退後，看到了這段關鍵訊息： ...

前言：當 Build Failed 成為日常 在過去的 19 個小時裡，我經歷了 15 次 build failed，產生了 15 個 fix commits。如果你覺得這很誇張，讓我告訴你更誇張的：最後一個 bug 是 git describe 在多個 tag 指向同一 commit 時會隨機返回其中一個。 是的，隨機。在 CI/CD Pipeline 裡。 這篇文章完整記錄這場除錯馬拉松，從最初的 Fastlane 版本問題，到 Discord 通知功能的實作與修復，再到 Ruby 相容性地獄，最後揭開 git 鮮為人知的行為。泡杯咖啡，這會是一段旅程。 第一章：Fastlane 與 Bundler 的糾葛 問題 1：Fastlane 版本不一致 Commit: fix(jenkins): use bundle exec for fastlane to ensure version consistency Jenkins 機器上有全域安裝的 Fastlane，但版本與 Gemfile.lock 指定的不同。這導致某些 action 行為不一致。 // Before: 使用全域 fastlane sh 'fastlane ios build' // After: 透過 Bundler 執行，確保版本一致 sh 'bundle exec fastlane ios build' 學習：在 CI 環境中，永遠使用 bundle exec 執行 Ruby 工具，確保版本與 lockfile 一致。 ...

引言：為什麼需要 Redux？ 在 iOS 開發中，隨著應用規模擴大，狀態管理逐漸成為最具挑戰性的課題。當多個 View 需要共享狀態、狀態變化難以追蹤時，應用很容易陷入混亂。 Redux 作為一種可預測的狀態容器，最早在 JavaScript 生態系中流行，如今也廣泛應用於 Swift/iOS 專案。本文將深入介紹 Redux 架構的核心觀念，包含： Reducer（減少器）：狀態更新的核心邏輯 Store（儲存區）：應用的單一狀態來源 Action（動作）：描述「發生什麼事」的指令 Middleware（中介層）：處理非同步與副作用 Redux 核心架構概覽 架構組成 架構特性： ✅ 單向資料流：資料流向可預測 ✅ 單一狀態來源：整個應用只有一個 State 樹 ✅ 狀態不可變：不直接修改 State，而是創建新 State ✅ 可測試性高：Reducer 是純函數，易於測試 核心概念 1：State（狀態） State 是什麼？ State 是整個應用的單一資料來源（Single Source of Truth）。它通常是一個 struct，描述當前應用的完整狀態。 實作範例 // AppState.swift struct AppState { // 購物車 var cartItems: [CartItem] = [] var totalAmount: Decimal = 0.0 // 用戶資訊 var userProfile: UserProfile? var isLoggedIn: Bool = false // UI 狀態 var isLoading: Bool = false var errorMessage: String? // 套餐選擇 var packages: [Package] = [] var selectedPackageId: String? } // 購物車商品 struct CartItem: Identifiable { let id: String let name: String let price: Decimal var quantity: Int } // 用戶資料 struct UserProfile { let id: String let name: String let email: String } // 套餐 struct Package: Identifiable { let id: String let name: String let items: [PackageItem] } struct PackageItem: Identifiable { let id: String let name: String var quantity: Int } 設計原則： ...

問題背景 最近在開發過程中遇到一個詭異的問題：呼叫某個 API 後，某個常數 name 的值居然是 nil，但從 raw data 看起來明明有值。 症狀檢查清單： ✅ Console 印出 raw data 看起來正常 ✅ jsonDecode 解碼成功 ✅ Enum 對應的 JSON key (_Name_Ch) 完全相同 ✅ 瀏覽器中直接訪問 API，name 確實有值 ❌ Swift 中取得的 name 卻是 nil 經過反覆檢查，終於發現問題根源：不可見的 BOM (Byte-Order Mark) 字元。 什麼是 BOM？ BOM (Byte-Order Mark)，中文稱為位元組順序記號，是一個不可見的 Unicode 字元，用於標示文字檔的編碼位元組順序。 常見的 BOM 字元： UTF-8 BOM: 0xEF 0xBB 0xBF (Unicode: U+FEFF) UTF-16 BE BOM: 0xFE 0xFF UTF-16 LE BOM: 0xFF 0xFE 問題診斷 根據問題分析，name 為 nil 的原因是： ...

在iOS app中，記憶體管理是基於引用計數模型運作。當創建一個物件的時候，記憶體會在Heap(堆)上分配，並將其引用計數設置為1。隨著其他物件對此物件建立強引用(strong reference)，其引用計數會增加1。 iOS : 記憶體管理 在iOS app中，記憶體管理是基於引用計數模型運作。當創建一個物件的時候，記憶體會在Heap(堆)上分配，並將其引用計數設置為1。隨著其他物件對此物件建立強引用(strong reference)，其引用計數會增加1。 相反的，如果擁有物件的持有者放棄了強引用，引用計數將會減少1。一旦引用計數變為0，該物件的記憶體就會被自動釋放。 當啟用了ARC(Automatic Reference Counting)自動引用計數功能的編譯器編寫程式碼時，編譯器會分析你創建的引用，並自動插入對底層記憶體管理機制的調用，我們無須手動設置引用計數。 隨著自動引用計數(ARC)的引入，我們只需要在引用物件時指定所有權的類型： 強引用(strong reference)：確保被引用的物件只要引用仍然有效，就會一直保留在記憶體中。例如，我們宣告一個控制器屬性 strong var myView: UIView，表示控制器強引用 myView 物件，直到控制器釋放之前，myView 都會存在記憶體中。 弱引用 (weak reference)：對被引用的物件的生存期沒有影響。例如，我們宣告一個閉包中的局部變數 weak var capturedView: UIView，表示閉包弱引用 capturedView 物件，即使 capturedView 被釋放，閉包中的 capturedView 也會變成 nil 而不會崩潰。 非擁有引用 (unowned reference)：與弱引用類似，對被引用的物件的生存期沒有影響，但與弱引用的不同之處是，非擁有引用 預期總是擁有 「非 nil 的值」，**ARC 不會自動將其設置為 ****nil**。例如，我們宣告一個子視圖中的屬性 unowned var parentViewController: UIViewController，表示子視圖非擁有引用父控制器，而父控制器通常擁有比子視圖更長的生存期，因此子視圖可以安全地訪問父控制器。 需要注意的是： 當被引用的物件被釋放時，弱引用會被設定為 nil，而非擁有引用則會變成一個懸浮指標 (dangling pointer)。向懸浮指標發送訊息會導致程式崩潰。 使用非擁有引用時，要確保另一個物件擁有相同的或更長的生存期，避免懸浮指標問題。 簡單來說，在以下情況下使用不同的引用類型： strong: 當你想要確保物件一直存在，直到不再需要它為止； weak: 會在被引用的物件被釋放時自動設為 nil，因此它們可以用來避免循環引用。例如，在代理關係中，委托者通常會使用弱引用來引用代理，這樣當委托者被釋放時，代理也不會被保留。； unowned: 不會在被引用的物件被釋放時自動設為 nil，因此它們只能用於指向那些生命週期一定會比引用它的物件長的物件。例如，子視圖可以使用非擁有引用來引用父視圖，因為父視圖通常會比子視圖存在得更久。 assign: 當你只需要一個指向簡單數據的指標，不需要跟踪它的生命周期。 使用 weak 和 assign 引用可以避免循環引用，即兩個物件互相引用導致彼此都無法被釋放的情況。 ...

它們在使用和用途上有很大的區別。讓我們來解釋這兩者之間的差異： iOS中的associated type和associated value是不同的概念 它們在使用和用途上有很大的區別。讓我們來解釋這兩者之間的差異： 是的，iOS中的associated type和associated value是不同的概念，它們在使用和用途上有很大的區別。讓我們來解釋這兩者之間的差異： Associated Type（關聯類型）： Associated type是Swift中協議（protocols）的一個特性。 關聯類型允許在定義協議時指定一個或多個類型，但不需要提供具體的實現。 具體遵循（conforming）該協議的類別或結構體需要提供關聯類型的具體實現。 關聯類型使協議更具通用性，因為它可以適應不同的類型。 protocol OrderQueue { associatedtype Order // 定義一個關聯類型 mutating func enqueue(_ order: Order) mutating func dequeue() -> Order? } struct OrderQueueImplementation: OrderQueue { // 實現OrderQueue協議，指定關聯類型為OrderStatus typealias Order = OrderStatus private var orders: [OrderStatus] = [] mutating func enqueue(_ order: OrderStatus) { orders.append(order) } mutating func dequeue() -> OrderStatus? { return orders.isEmpty ? nil : orders.removeFirst() } } ...

工作需要把整個app包成一個SDK讓另一個app引用，所以要把原本專案的套件也包進去，不然在打包framework的時候，import套件那一行會報錯. iOS如何把專案打包framwork後也讓原本的pod/套件包入framework ? 工作需要把整個app包成一個SDK讓另一個app引用，所以要把原本專案的套件也包進去，不然在打包framework的時候，import套件那一行會報錯. 假設你的專案叫”B”，打包的framework取名為BPack，那麽在Podfile的部分要加入framework自己的套件引用，原本的專案裝什麼pod，framework如果有用到該套件也要跟著裝，以SnapKit為例，作法如下： target ‘B’ do Comment the next line if you don’t want to use dynamic frameworks use_frameworks! pod ‘SnapKit’, ‘~> 5.6.0’ Pods for B end target ‘BPack’ do Comment the next line if you don’t want to use dynamic frameworks use_frameworks! pod ‘SnapKit’, ‘~> 5.6.0’ Pods for B Pods for BPack end另外，在Build Setting的部分好像也要做一下設定： 如果你包的是動態庫，那麽在framework target的Build Settings: Linking -> Mach-O Type應該要選擇：Dynamic Libray Mach-O這部分不太確定有沒有影響，不過我這樣選是可以Run App Successful. 有錯麻煩請指正，感謝！ ...