2026 GitHub Actions iOS CI 用哪種 Mac？託管 Runner 還是雲端 Mac

CI 工作流程常在等待 Runner，或每次建置都要重新整理環境。
最快解法：低頻建置、想少維護，先評估 GitHub 託管 macOS Runner；需要自訂環境、控制執行節點或固定工作負載時，再試跑雲端 Mac。別只比較單次建置時間，也要記錄排隊、執行、維護與清理成本。

這篇適合你，如果：
個人開發者偶爾建置 iOS 專案，不想長期照顧 CI 用的 Mac。
小型團隊需要替多個儲存庫選擇共用執行環境。
技術負責人正在評估託管 Runner 與自管理節點的責任界線。

先確認哪些工作真的需要 macOS

做 iOS 自動建置，不代表每個工作流程工作都要放在 Mac 上。若工作需要 Xcode 編譯、簽署或執行依賴 Apple 開發工具的步驟，就要安排符合要求的 macOS 環境；格式檢查、部分通用測試或文件工作，則可分開評估其他執行環境。Xcode 與 macOS 的相容條件會隨版本而異，選擇前應對照 Apple 的 Xcode 系統需求表，不要只看專案目前能否在某台機器上成功開啟。

先把工作拆成需要 Xcode 的建置工作與不依賴 Xcode 的前置工作，再決定 Runner 的範圍。這可以避免為了少數 Mac 專屬步驟，讓整條流程都承擔 macOS 環境的管理成本。

託管與自管理的差異，不只是「誰提供 Mac」：

• 環境維護：託管 Runner 由 GitHub 提供執行環境；自管理節點則由你負責 Xcode、系統工具、相依套件與環境更新。想固定工具版本，兩邊都要明確設定並驗證，不能把「使用同一台」當成可重現的保證。
• 快取與依賴：依賴快取可減少重複下載，但快取鍵若沒包含足以識別環境與依賴的資訊，可能還原到不合用的內容。GitHub 的快取文件說明 key 與 restore-keys 等設定；先把它們納入流程，而不是先假設換成自管理 Mac 就會更快。
• 佇列與並行：Workflow 的 concurrency.group 可把工作歸入同一組；GitHub 文件說明同一組最多保留一個執行中與一個等待中的工作，新工作可能取代等待中的工作。這是排程控制，不等於增加執行容量。實際規則請參考工作流程並行設定文件。
• 權限與清理：固定節點可能保留先前工作的檔案、快取或登入狀態。這些殘留會造成環境漂移，也會讓密鑰與程式碼暴露在更長的生命週期內；改用自管理 Runner 前，先明確安排工作後清理與存取範圍。

用同一份工作流程檢查環境是否可重現

不要先把整個團隊的 CI 搬家。挑一個有代表性的 iOS 儲存庫，將工作流程所需的 Xcode 版本、相依套件、建置命令、測試與簽署條件寫清楚，再分別交給託管 Runner 與候選雲端 Mac 執行。

在 GitHub Actions 工作流程中，runs-on 用來指定執行環境；自管理 Runner 可用標籤協助工作流程選擇符合條件的節點。GitHub 的標籤說明提到，可將標籤套用至自管理 Runner，並在工作流程中用來選擇 Runner。標籤要反映實際能力，例如作業系統或工具環境；如果多個節點使用含糊或重複標籤，工作可能落到不符合預期的機器。

為了讓兩邊的測試有比較價值，固定輸入與工作內容，不要只比較某次執行的總時間。將建置、測試、簽署和快取各自留下可判讀的工作紀錄；若一邊失敗，先確認是程式碼、相依套件、憑證，還是 Runner 環境差異。

提醒：公開儲存庫的外部貢獻者 PR，不能視作可信任工作。GitHub 明確提醒，自管理 Runner 有安全風險；若節點可存取機密或內部資源，先確認 PR 觸發條件與權限隔離，再開放工作執行。自管理 Runner 的安全建議與安全使用指南都應納入審查。

依照試跑里程碑記錄排隊、執行與維護

把候選環境放進同一個小規模試跑，按以下里程碑收集資料。這些紀錄能幫你分清楚問題來自等待執行節點，還是建置本身。

里程碑一：建立現況基準。 從現有 Actions 工作流程記錄每次工作的排隊時間、執行時間、成功或失敗結果，以及失敗原因。將排隊時間與實際建置時間分開；否則即使工作花很久，也無法判斷是否真的是 Runner 不足。

里程碑二：固定工作流程輸入。 記下 Xcode 與 macOS 條件、依賴鎖定方式、快取設定、測試範圍，以及簽署是否為該次試跑所需。工作流程的快取可依 key 與 restore-keys 設定還原條件，細節見GitHub 依賴快取文件。同一份設定用於兩種環境，才不會把流程差異誤認為硬體差異。

里程碑三：檢查排程設定。 若佇列主要來自同一組工作被 concurrency 限制，先檢視工作流程的並行需求與取消規則；如果等待主要發生在 Runner 尚未接手工作，才進一步評估可用節點。自管理 Runner 標籤可用於選擇執行環境，但標籤只負責匹配條件，不會自行解決節點容量或維護問題。

里程碑四：比對運行與漂移。 在候選雲端 Mac 重跑相同建置與測試，記錄等待、實際執行、快取命中、失敗、重新建置，以及人工介入情況。遇到結果不一致，檢查工具版本、環境變數、檔案殘留和憑證處理，並確認節點是否依預期清理。

里程碑五：核對權限與營運責任。 盤點哪些儲存庫能使用節點、哪些工作可讀取密鑰，以及節點更新與故障後由誰處理。GitHub Runner 組可用於管理哪些儲存庫能存取特定 Runner；在設定前應檢視Runner 組的存取控制說明。不要讓「標籤符合」被誤當成「權限已隔離」。

里程碑六：決定遷移範圍。 試跑後，把排隊改善、建置結果、環境重現性、人工維護與清理責任放在一起判讀，再選擇保留原狀、分儲存庫並行，或擴大自管理範圍。若改善只出現在個別工作，就只調整相關工作，不必把所有 CI 一次搬遷。

比較 Mac CI 執行環境時，最值得記錄的是：工作進入佇列與開始執行的時間點、每個工作實際執行時間、成功率與失敗類型、快取與依賴狀態、人工維護工時、清理結果，以及權限設定是否符合預期。這些資料比單看某一次建置的總耗時更能說明問題，也能避免把推測當成擴容需求。

用條件分支決定採用託管 Runner 還是雲端 Mac

以下條件可先縮小範圍，再以試跑結果確認；它們不是固定構建量門檻。

• 若建置不頻繁、希望少維護，而且現有排隊沒有證據顯示持續阻塞，先選 GitHub 託管 macOS Runner；不要為尚未驗證的並行需求預先管理節點。
• 若工作需要固定安裝的工具、可控的執行節點或持續執行的工作負載，比較雲端 Mac，並把系統更新、Runner 升級、權限隔離與清理責任一起計入。
• 若瓶頸主要是工作流程的併發限制，而非缺少 Runner，先調整工作流程與並行設定，再看排隊紀錄；增加 Mac 不會自動移除流程限制。
• 若公開 PR 必須觸及內部資源或機密，先停下遷移計畫，重新設計權限與隔離邊界；不要只靠 Runner 標籤保護敏感工作。
• 若不同儲存庫的需求差異明顯，保留託管 Runner 與自管理環境並行，讓每個儲存庫依實際需求選擇，而不是強行統一。

GitHub Actions iOS CI 的 Mac 選型，最後要回到你的工作負載與維護責任。若現行託管方案已能穩定完成建置，改用自管理環境仍會帶來節點更新、存取控管、清理與故障處理等工作；若你確實需要保留自訂環境或控制執行節點，長期依賴臨時人工準備又難以穩定重現，也不是理想的 CI 做法。依試跑結果確認需要後，再檢視 Kvmkit 的 Mac 租用選項，核對當期方案資訊是否符合你的節點管理需求；若只想了解服務範圍，可先查看 Kvmkit 服務頁面。