2026 年 11 月 2 日，GitHub Actions 的 macOS 14 Runner 已退役，macos-14、macos-14-large 與 macos-14-xlarge 不應再作為工作流程依賴。遷移時先依專案的 macOS、Xcode 與 CPU 架構要求篩選目前受支援的標籤，再以隔離或雙軌工作流程驗證建置、測試及交付；不要直接改成 latest。GitHub 退役公告
仍在工作流程中使用上述標籤的 Apple 平台開發團隊，應先盤點受影響任務並制定遷移方案。
負責簽名、測試與發布的 CI 工程師，應以真實流水線驗證替代 Runner。
需要持續管理 macOS 工具鏈的 DevOps 或研發平台負責人，可用本文建立切換准入與回退條件。
最後更新於 2026 年 11 月 8 日；退役狀態、Runner 文件與映像清單以 GitHub 公告、現行文件及 runner-images 倉庫為核對來源，Xcode 相容性則對照 Apple 發布說明。
標籤狀態與盤點範圍
macos-14 Runner 退役後，第一步不是猜測替代標籤，而是找出工作流程實際使用了哪些 Runner 標籤，以及它們承載哪些建置工作。GitHub 公告確認了退役標籤，但公告中的遷移方向不能取代目前的標籤清單；可用標籤和映像內軟體應以現行 GitHub-hosted runners 文件及Runner 映像倉庫為準。
| 盤點項目 | 要檢查的內容 | 遷移判斷 |
|---|---|---|
| 工作流程標籤 | 搜尋 workflow YAML、複用工作流程及共用 action 中的 runs-on |
列出所有引用舊標籤的工作，不能只改主要建置檔 |
| 歷史執行紀錄 | 檢查曾執行的標籤、Xcode 與 SDK 資訊、失敗訊息 | 找出實際使用的工具鏈與特殊任務 |
| 替代標籤 | 對照 GitHub 當前文件及映像清單 | 只選擇文件列為可用、且符合專案條件的標籤 |
盤點時也要檢查由變數、矩陣或共用 workflow 組成的標籤；若只在程式碼搜尋 macos-14，可能漏掉動態組合的 runs-on。需要多個標籤或工具鏈組合時，可參照 GitHub 的矩陣工作流程文件，把候選環境分開執行，而非在同一輪直接替換所有正式工作。
工具鏈相容條件
Runner 作業系統標籤與 Xcode 工具鏈不是同一件事。標籤更換後，即使工作能啟動，也不代表所需的 Xcode、SDK、建置工具和專案設定都相容；先對照Apple Xcode 26 發布說明及Xcode 系統需求，並把正式版與 Beta 分開記錄。
| 相容性指標 | 應取得的證據 | 未通過時的處理 |
|---|---|---|
| macOS 與 Xcode | 工作執行記錄中的 Runner 標籤、macOS、Xcode 和 SDK 版本 | 暫停切換，先找出版本不符的工具鏈需求 |
| 專案建置設定 | 相同提交在乾淨環境中的建置結果與錯誤紀錄 | 檢查專案部署目標、建置設定與套件相容性 |
| Beta 依賴 | Beta 版 Xcode、SDK 或功能的明確需求 | 建立獨立驗證路徑，不與正式版結果混為一談 |
遷移工作表最好記錄「專案要求」與「新 Runner 實際提供」兩欄，而不只記錄一個 Xcode 版本號。若流水線需指定某個工具鏈，先確認替代映像是否提供它；若工具鏈由工作流程自行安裝，也要測試安裝來源、權限與後續命令是否能在新環境完成。
架構與原生依賴判斷
作業系統版本無法單獨回答 Intel 任務能否遷移。先從建置腳本、套件來源、預編譯二進位檔與測試紀錄找出架構依賴，再確認候選 Runner 的實際架構；GitHub 文件與映像倉庫應作為標籤、映像及軟體清單的核對依據，而不是沿用舊環境的假設。
| 依賴類型 | 驗證方式 | 通過條件 |
|---|---|---|
| 原生套件或二進位檔 | 在候選架構安裝依賴，檢查載入與編譯紀錄 | 依賴能安裝，編譯或載入過程沒有架構衝突 |
| 自訂建置腳本 | 檢查架構判斷、路徑和條件分支 | 不依賴舊 Runner 的固定路徑或未宣告環境變數 |
| 測試與打包工具 | 分開執行測試、歸檔及交付步驟 | 除建置外，必要測試和產物流程也能完成 |
遷移決策條件：
- 若專案要求的 macOS 與 Xcode 均由當前文件列出的候選 Runner 支援，且實際架構符合原生依賴，就選擇該候選標籤進入隔離試跑。
- 若架構尚未查明，或套件包含只有特定架構可用的二進位檔，先維持正式流程不變，補做依賴安裝、編譯與執行驗證。
- 若候選 Runner 缺少必要工具鏈，或測試、簽名及歸檔無法重現，就回退到可控的驗證路徑；不要以「Runner 啟動成功」作為切換依據。
這項判斷也涵蓋 Intel 構建任務。先確認程式碼是否真的依賴 Intel，而非僅因過去工作流程使用某個標籤就推定；若必須保留 Intel 相容性，而目前託管標籤無法滿足要求，應另行評估符合需求的執行環境，並將其維護責任納入方案。
建置與交付驗收
新環境至少要以相同提交驗證建置、測試與發布相關步驟。若只看一次建置通過，可能漏掉 Simulator 目標、私有依賴、簽名憑據或歸檔產物的差異；建議將驗收紀錄與原 Runner 的可比較結果一併保存。
- [ ] 固定同一提交與相同工作流程輸入，記錄新舊 Runner 標籤及映像識別資訊。
- [ ] 在候選環境執行乾淨建置，保留 Xcode、SDK 和關鍵建置命令的記錄。
- [ ] 執行專案實際使用的測試與 Simulator 目標，不以單純編譯結果取代測試結果。
- [ ] 確認私有套件、憑據存取與網路政策符合團隊要求；不要把祕密值寫入可公開檢視的日誌。
- [ ] 驗證簽名、歸檔及交付產物，記錄產物名稱、來源提交與可供追查的工作流程紀錄。
- [ ] 設定准入條件與回退方式，待負責團隊檢視證據後，才擴大到正式工作。
使用快取時，還要分辨「快取命中」和「乾淨環境可重建」是兩種不同證據。遷移初期可在隔離工作流程中比較有無快取的結果，並確認快取鍵不會把舊架構或舊工具鏈的產物帶入新環境；GitHub 對依賴快取的用途與行為有獨立說明。
網路與運維責任
託管 Runner 與自我代管 Runner 的運維邊界不同。若工作需要存取私有依賴或內部服務，先驗證新環境的連線路徑、存取權限與憑據管理；若改採自我代管 Runner，則須將網路和節點維護責任納入驗收。GitHub 自我代管 Runner 文件說明了相關網路及運作要求。
快取、佇列或任務可用性也不應以 macOS 14 時期的經驗推斷新環境表現。遷移紀錄可以保存實際執行時間、等待狀況和錯誤訊息，供團隊觀察自身工作流程；但未有觀測資料前，不應把單次結果當成服務水準或長期效能結論。
遷移常見問題
macOS 14 Runner 退役後應選哪個標籤？
對照 GitHub-hosted runners 現行文件與映像倉庫，依專案需要的 macOS、Xcode 和架構篩選其中列出的標籤。若文件沒有列出必要條件，或映像軟體清單無法滿足工具鏈需求，就先不要切換正式流程；公告的遷移方向不是完整的可用標籤清單。
遷移到 macOS 15 或 macOS 26 前要確認什麼？
先檢查專案部署目標、Xcode 與 SDK 需求、原生依賴和建置腳本，再確認候選 Runner 標籤目前可用。對照 Apple 發布說明及系統需求時，需分清正式版與 Beta；作業系統符合要求，不代表專案依賴的工具鏈也已適配。
Runner 標籤更換後如何驗證 Xcode 與 Simulator？
在隔離工作流程中以同一提交執行乾淨建置、專案測試及所需 Simulator 目標，並記錄 Runner、Xcode 與 SDK 資訊。若流程包含私有依賴、簽名或歸檔，也要分項驗收；只有建置成功時，不應將整條發布流程判定為通過。
Intel 建置任務應怎樣安排？
先查明專案是否包含必須以 Intel 執行的工具、原生依賴或二進位檔，再核對候選環境架構。分別驗證依賴安裝、編譯和測試；若必要依賴在候選架構無法運作，就保留隔離驗證路徑，並評估符合架構需求的執行環境，不要直接把工作轉入正式發布。
切換准入與環境選擇
正式切換前，應由維護團隊確認工具鏈、架構、建置、測試、簽名與網路條件都有可追查的證據。若只需使用 GitHub 提供的執行環境，依其文件和映像清單選擇候選標籤即可；若團隊另有持續使用真實 macOS 環境的需求，則要把節點管理、憑據保護和網路策略一起評估，而不是把環境差異簡化成標籤替換。
相較於可控的 Mac 執行環境，託管 Runner 可能受到映像更新影響、工具鏈選擇受現行標籤限制，也未必符合需要存取內部網路或長時間保留工作狀態的任務；但自我管理 Mac 也有節點維護和安全責任，不適合所有團隊。若需要持續存取真實 Mac 來復跑同一專案的建置與測試，可查看 RUVCLOUD 遠端 Mac 服務資訊及方案價格，再依工具鏈控制、網路需求與維護能力判斷是否適合。