多數 iOS CI 工作不會因 GitHub Actions arm64 Runner 沒有固定 UDID 就中斷；先確認工作流程需要的是 Mac 主機識別碼，還是已註冊的 iPhone 測試設備。只有確實依賴固定 Mac UDID 的簽名或主機端驗證工作，才需要按官方支援情況更換節點；真機測試則要登記實際測試設備，並準備能連接該設備的環境。
本文適合負責 GitHub Actions、企業 iOS CI 與 macOS Runner 選型的 IT 及平台工程負責人。
若你正因簽名失敗、設備安裝或 Runner 標籤而考慮搬遷，先按任務拆解，不要只看到「沒有固定 UDID」就重做整條流水線。
最後更新於 2026 年 10 月 4 日；核對 GitHub 較大 Runner 說明，以及 Apple Developer 的設備登記、配置檔與 App 上傳文件。
01 GitHub Actions arm64 Runner 固定 UDID：先定位受阻任務
GitHub 的較大 Runner 文件指出，arm64 macOS Runner 沒有靜態 UUID；文件亦列出 Intel macOS Runner 的固定 UDID 選項。這項差異描述的是 Runner 主機識別碼，不等於所有 iOS 建置、測試或上架工作都需要它。GitHub Runner 文件中的架構與 UDID 說明
先將失敗工作分類：
- 編譯：產生 App 或框架，不代表已安裝到 iPhone。
- 模擬器測試：驗證模擬器中的執行結果，不等於實體設備驗收。
- 開發簽名：檢查簽名類型、配置檔及目標設備是否相符。
- 真機測試：需要實際測試設備、設備登記和可用的連線路徑。
- 商店發布：核對簽名與上傳流程，不能把開發測試的設備限制直接套用到商店發布。
先從失敗日誌找出是哪個步驟拒絕執行，再看該步驟要求什麼識別碼。若錯誤發生在設備安裝或開發配置檔，不要先假設是 Runner 主機 UDID；若工作明確要求固定的 Mac 主機識別碼，才進一步比對 Runner 類型。
02 Mac 主機與 iPhone 設備 UDID 必須分開
Runner 的 UDID 指向執行工作流程的 Mac 主機；iPhone 的 UDID 指向實際測試或安裝 App 的設備。兩者不是可互換的值，也不應共用同一欄位或驗收證據。
Apple Developer 的設備登記文件說明如何登記單一設備；開發配置檔與 Ad Hoc 配置檔則分別有其建立流程與設備選擇條件。Apple Developer 設備登記說明 開發配置檔建立條件 Ad Hoc 配置檔的設備選擇方式
因此，看到簽名失敗時，先確認簽名目標是 iOS App、Mac App，還是特定設備上的測試工作。若是 iPhone 開發或 Ad Hoc 安裝，應核對實際 iPhone 是否列入相應設備清單，以及配置檔是否涵蓋該設備；不能把 arm64 Runner 的 UDID 填進 iPhone 設備清單，當作替代方案。
注意：節點可以登入，並不代表簽名憑證、Keychain、工作區或拉取請求都已達到生產安全要求。自託管 Runner 尤其需要檢查不可信工作流程帶來的風險；GitHub 對
pull_request_target的安全說明列有相關注意事項。GitHub 關於安全使用pull_request_target的文件
03 簽名與商店發布取決於交付路徑
開發簽名和 Ad Hoc 分發會牽涉已登記設備；商店發布則應按商店分發流程驗證。Apple 的建置上傳文件描述 App Store Connect 的上傳步驟，不能把「設備是否列入開發配置檔」當成所有商店發布工作都必須通過的條件。Apple App Store Connect 建置上傳流程
這裡的判斷重點是區分「能完成建置」、「簽名有效」與「可在指定設備安裝」：
- 成功編譯只能證明該次建置完成，不能證明真機安裝有效。
- 模擬器測試通過，不能替代實體 iPhone 上的啟動與功能驗收。
- 簽名驗證通過，也不代表目標設備已登記或配置檔涵蓋該設備。
- 上傳流程完成，應另外確認 App Store Connect 中的建置狀態與交付制品。
需要調整配置檔時，應留下使用中的配置檔、涵蓋設備及簽名結果，避免只憑 Runner 工作成功就推定發布條件已滿足。Apple 配置檔管理說明
04 常見問題 FAQ
arm64 Runner 沒有固定 UDID，iOS 簽名一定會失敗嗎？
不會自動失敗。先判斷簽名工作是否真的依賴固定的 Mac 主機識別碼，再檢查 iOS 開發或 Ad Hoc 配置檔是否包含實際測試設備。一般建置、模擬器測試和商店發布不能只因 Runner 沒有靜態 UDID，就一律判定不可執行。
Mac Runner 的 UDID 和 iPhone 測試設備 UDID 有何不同？
Mac Runner UDID 辨識執行工作流程的主機，iPhone UDID 辨識安裝或測試 App 的設備。Apple Developer 的設備登記及相關配置檔應按實際測試設備處理。請分開記錄兩種識別碼，並在錯誤日誌與簽名設定中確認欄位用途。
GitHub-hosted macOS Runner 能直接連接實體 iPhone 嗎？
不要把 GitHub-hosted macOS Runner 視為已連接你手上設備的環境。真機測試要有可用的設備連線方式、已登記的測試設備、正確配置檔，以及安裝和執行結果。若工作流程沒有這些證據，模擬器通過不能代替真機測試通過。
哪些工作流程需要固定的 Mac UDID？
只有工作流程確實依賴固定 Mac 主機識別碼時，才需要處理此限制。先查明失敗步驟、簽名目標和平台要求，再對照 GitHub 當前列出的 Runner 選項。iOS 設備登記針對實際測試設備，不應把 Mac Runner UDID 當成 iPhone UDID 使用。
05 以驗收證據決定 Runner 分工
把每個工作流程的目標寫清楚，再選節點。若只編譯或執行模擬器測試，先評估現有 GitHub-hosted macOS Runner；若要求固定 Mac 識別碼、連接實體設備，或需要受控簽名環境，先以隔離的專用節點試跑。GitHub 亦提供自託管 Runner 的設定與使用說明；自託管可增加環境控制，但安全隔離與維護責任也由你承擔。GitHub 自託管 Runner 文件
| 工作目標 | 優先驗證方式 | 不可省略的通過證據 |
|---|---|---|
| 一般 iOS 編譯 | 先保留托管 Runner | 建置結果、簽名步驟與產物檢查 |
| 模擬器驗證 | 先確認 Runner 支援所需測試環境 | 測試結果與失敗診斷 |
| 開發或 Ad Hoc 安裝 | 核對簽名配置檔及設備登記 | 目標設備識別碼、安裝結果與啟動紀錄 |
| 需要固定 Mac UDID | 核對 GitHub 當前 Runner 文件，再安排節點試點 | 主機識別碼、簽名或主機端驗證結果 |
| 商店發布 | 按商店交付流程獨立驗收 | 簽名狀態、上傳結果及建置制品 |
開始試點前，逐項勾選以下驗收項目：
- [ ] 從失敗日誌確認受阻步驟，不以「UDID 錯誤」作為未核實的根因。
- [ ] 記錄流水線需要的是 Mac 主機 UDID、iPhone UDID，還是完全不需要設備識別碼。
- [ ] 對照簽名類型，確認開發或 Ad Hoc 配置檔涵蓋目標測試設備。
- [ ] 用實際 iPhone 完成安裝與啟動驗證；沒有實體設備時，將該項標示為未驗收。
- [ ] 獨立檢查憑證、Keychain、配置檔與工作區的存取責任。
- [ ] 保存建置、簽名、設備安裝和上傳紀錄，再依失敗原因決定是否增加專用 Mac。
| 節點選擇 | 適用條件 | 主要代價與風險 |
|---|---|---|
| 保留 GitHub-hosted Runner | 工作不依賴固定 Mac UDID，且建置或模擬器驗收已足夠 | 不應假設能直接連接實體 iPhone；要先驗證 Runner 的識別碼條件 |
| 自託管節點 | 需要自行管理執行環境或連線路徑 | 你需承擔節點安全、環境維護與工作流程隔離 |
| 專用遠端 Mac | 工作需要固定主機條件、實體設備連線或受控簽名環境 | 增加節點管理與簽名憑證保護責任；應先以真實任務驗證需求 |
06 擴充 Mac 容量前先完成小範圍試點
試點時，把失敗原因、所需設備、簽名路徑和節點交接證據放在同一份紀錄。若只在少數工作流程遇到固定主機條件，不必因此搬走所有建置任務；可以讓一般建置留在托管 Runner，把需要固定主機或實體設備的工作分流至專用節點。
如果你要評估遠端 Mac 作為專用驗證環境，可以先查看 CALMVPS 的服務入口，再按實際工作負載核對可用方案。不要在未驗證設備連線、簽名與權限前，就把任何遠端節點視為已符合生產需求。
若現有方案因 arm64 主機沒有固定 UDID、無法安排實體設備連線，或簽名憑證難以在共享工作流程中妥善隔離而受限，專用遠端 Mac 值得納入試點；它能提供一台真實 Mac 主機，按週、月或季評估租用，不必先為每位開發者購買 Mac。反過來說，若你只需一般編譯或模擬器測試，先保留現有 Runner，不要只因 UDID 一項就遷移。需要測試臨時算力與專用環境時，可再核對 CALMVPS 方案資訊，並以你的真實簽名與設備驗收結果決定是否擴充。