Apple 的官方資料確認，Xcode Cloud 使用臨時建置環境；這代表每次建置都不能假設上一輪留下的工具、檔案或背景服務仍在。Xcode Cloud 建置太慢時，不要因一次失速就遷移：本週先用建置報告拆出依賴準備、編譯、測試與歸檔時間，再調整快取、觸發條件和測試範圍。只有當慢點持續來自環境初始化、常駐服務或主機控制權不足，才把相關任務移到遠端 Mac，並保留 Xcode Cloud 做標準建置或發佈驗證。
這篇適合三類人：第一是建置時間不斷增加、但還不知道瓶頸在哪裡的 Apple 平台開發者。第二是需要複雜依賴、快取或常駐服務的 CI 工程師。第三是正在比較計算用量、遠端 Mac 或雙軌 CI 的研發負責人。
01先建立同一提交的耗時基準
總耗時相近的兩次建置，可能分別慢在依賴下載與測試矩陣。只看流水線完成時間，會把不同問題誤判成同一個問題。
先選一個可重現的提交，固定帳戶、Repository、Scheme、建置設定與測試範圍。記錄一筆正常樣本，再記錄一筆異常樣本。資料來源應包括 Xcode 或 App Store Connect 的建置報告、動作日誌，以及 Apple 提供的 Xcode Cloud 使用資料說明。
| 建置階段 | 應查看的證據 | 可採取的動作 | 何時停止原地優化 |
|---|---|---|---|
| 排隊等待 | 工作流程開始前的等待紀錄 | 檢查觸發條件與同時啟動的工作流程 | 等待長期由共享資源或併發需求主導 |
| 環境準備 | post-clone、依賴安裝與授權日誌 | 移除重複安裝，固定鎖定檔與認證流程 | 每次都必須完整初始化且無法壓縮 |
| 編譯與歸檔 | Xcode 動作日誌、Scheme 與 Archive 步驟 | 確認是否誤啟用 Clean Build，分離不必要動作 | 需要完整主機控制或固定本機工具鏈 |
| 測試 | 測試套件、裝置組合與 UI 測試日誌 | 拆分快速驗證、主分支回歸和定時測試 | 必須保留特定模擬器狀態或測試資產 |
不要自行設定「超過幾分鐘就算太慢」的門檻。Apple 官方並沒有針對所有專案提供統一的過慢或遷移標準。判斷依據應是同一專案的階段資料、成功率、人工維護成本和回饋需求。
02依賴與臨時環境的重複成本
Xcode Cloud 每次使用臨時環境，因此本機曾經安裝的 CocoaPods、Carthage、Swift Package 或自訂工具，不應被視為下一次建置的既有狀態。請先核對鎖定檔、私有 Repository 權限和自訂腳本，Apple 的依賴可用性文件可作為檢查入口。
常見問題有三種：
- post-clone 腳本每次都安裝其實不需要的工具。
- 私有依賴授權失敗後反覆重試，日誌只留下長時間等待。
- 腳本需要本機服務、固定路徑或上一輪生成的檔案。
先把安裝步驟拆成「必要工具」、「專案依賴」和「測試資產」。每一項都記錄下載來源、認證方式、生成位置和失敗時的退出碼。自訂腳本的寫法可對照 Apple 的自訂建置腳本文件。
如果某個步驟必須接觸內網、啟動長期背景服務，或依賴跨建置保留的檔案，這不是單純的下載速度問題。此時應將該任務列為遠端 Mac 候選，而不是繼續增加重試次數。
03Clean Build、快取與測試矩陣
快取不是越多越好。Derived Data、依賴快取和腳本生成檔案屬於不同狀態，不能籠統寫成「快取沒有生效」。請分別觀察全新建置、快取可用的建置，以及只修改少量程式碼後的增量建置。
| 檢查項目 | 你要確認的內容 | 風險 |
|---|---|---|
| Clean Build | 工作流程是否每次都清除可重用狀態 | 可能令每輪編譯都重新開始 |
| 依賴快取 | 鎖定檔變更時是否正確失效 | 快取殘留可能掩蓋依賴問題 |
| Derived Data | 產物是否只供當前建置使用 | 不應把它當成完整主機狀態 |
| 腳本生成檔 | 檔案是否可重建、是否被錯誤重用 | 為求速度保留不可驗證殘留 |
接著檢查測試矩陣。每次提交若同時執行多組裝置、UI 測試、Archive 和重複工作流程，計算用量與回饋時間都會被放大。較穩妥的分層方式是：
- 合併請求：保留必要的快速編譯與核心測試。
- 主分支：加入較完整的回歸測試。
- 定時任務：執行完整裝置組合、UI 測試與發佈前驗證。
若舊提交在新提交已產生後仍繼續執行，應檢查自動取消建置和開始條件。Xcode Cloud 工作流程的觸發、快取與取消選項，可參考官方工作流程參考。
| 測試安排 | 適合目的 | 不適合的做法 |
|---|---|---|
| 單一快速流程 | 早期回饋與基本編譯驗證 | 把完整回歸全部塞入 |
| 分拆測試流程 | 讓不同套件獨立失敗、易於定位 | 讓所有流程重複安裝相同依賴 |
| 定時完整流程 | 覆蓋較大的測試矩陣 | 每次提交都無條件觸發 |
04提醒： 減少裝置組合不一定比拆分工作流程更好。若測試共享狀態或需要不同初始化條件，拆分能提高可診斷性；若只是合併請求不需要完整回歸，先縮小範圍通常更直接。
腳本、網路與權限邊界
下載、上傳和外部 API 呼叫很容易形成長尾等待。請為自訂腳本補上清楚的超時處理、有限重試、階段性日誌和正確退出碼。不要把存取令牌、私密金鑰或完整環境變數直接印入日誌。
Xcode Cloud 的腳本可能需要識別平台提供的環境變數。使用前應核對官方環境變數參考，並以占位符測試帳戶、Repository、Scheme、金鑰名稱和腳本路徑。不要把真實憑證寫入文章、腳本範例或建置輸出。
| 條件 | Xcode Cloud 的處理方向 | 遠端 Mac 的評估理由 |
|---|---|---|
| 依賴可鎖定、腳本可重建 | 繼續優化 | 不需要為可重建問題增加主機維護 |
| 需要內網或常駐服務 | 另建獨立工作流程 | 可保留網路與服務狀態 |
| 需要跨建置資產 | 先確認是否能安全快取 | 可控制檔案保存與清理策略 |
| 需要主機級權限 | 評估局部遷移 | 真實主機更適合自訂工具鏈 |
這也是你應區分「遠端 Mac」和一般雲端 Linux 主機的地方。Xcode、簽名、模擬器和 macOS 專屬工具鏈要求真實 macOS 環境時，主機權限與狀態保存會直接影響維護方式。若你正在規劃遠端 Mac 租用開發環境，應先以一項最慢、最難重建的任務做驗證，而不是一次搬完整條流水線。
05FAQ：從排障走到遷移決策
Xcode Cloud 為什麼每次都要重新安裝依賴？
因為 Xcode Cloud 使用臨時建置環境，建置之間不應假設本機工具、Derived Data 或背景服務仍然存在。你應檢查鎖定檔、依賴可用性、post-clone 腳本與私有倉庫授權；若每次初始化都不可避免，才把這類任務列入遠端 Mac 評估。
Xcode Cloud 的建置時間要從哪裡查看？
不要只看工作流程總耗時。請在 Xcode 與 App Store Connect 的建置報告、動作日誌及使用資料中，分別記錄排隊、環境準備、編譯、測試和歸檔所占時間，再以同一提交的正常樣本與異常樣本互相比較。
Xcode Cloud 測試太慢，應該減少裝置還是拆分工作流程？
先看測試矩陣是否把快速驗證與完整回歸混在同一流程。若只是合併請求需要快速回饋，可縮小測試範圍；若不同測試套件依賴不同環境或資產，拆分工作流程通常更容易定位耗時，也方便設定取消舊建置。
什麼情況適合把 Xcode Cloud 遷移到遠端 Mac？
當瓶頸持續來自臨時環境初始化、必須保留跨建置檔案、需要常駐服務、內網連線或完整主機權限時，遠端 Mac 才有明確價值。先用同一提交、Scheme 與測試範圍做對照，確認重啟後仍能復現，再決定局部遷移或雙軌運作。
06遠端 Mac 的任務級遷移方法
不要把「遷移 CI」當成單一大工程。先選一個符合以下條件的任務：耗時來源已被日誌確認、在 Xcode Cloud 上反覆出現、又需要臨時環境難以提供的狀態。
建議依以下步驟執行：
- 固定輸入：鎖定提交、Scheme、Xcode 設定、測試範圍和簽名資料。
- 建立遠端節點：使用專用帳戶，限制 SSH 金鑰權限，避免把個人工作階段當成 CI 環境。
- 重建工具鏈：安裝 Xcode、必要命令列工具、依賴管理工具和腳本；所有版本都寫入可審核的設定。
- 重播同一任務：先執行依賴安裝、編譯、測試和 Archive，再比對輸出，不要一開始就加入更多測試。
- 驗證重啟恢復：重新啟動主機後，確認工作流程能重新登入、取得依賴、執行 Xcode 和產出日誌。
- 檢查失敗處理：模擬網路中斷、簽名失效和腳本非零退出，確認錯誤能被 CI 看見。
- 決定範圍：只把需要持久狀態或主機控制的工作移走，其餘標準建置仍留在 Xcode Cloud。
你可以先查看遠端 Mac 方案與租用價格，但不要只用月費作決定。真正要比較的是初始化維護、失敗後恢復、日誌完整度、節點閒置成本，以及是否仍需保留 Xcode Cloud 的標準驗證流程。
07三種可執行的結論
| 決策 | 適用條件 | 落地方式 |
|---|---|---|
| 繼續使用 Xcode Cloud | 慢點可定位，依賴可重建，測試可分層 | 優化觸發、快取、腳本與測試範圍 |
| 局部遷移遠端 Mac | 只有少數任務需要常駐服務或完整權限 | 將最慢、最難重建的工作獨立搬移 |
| 雙軌 CI | 標準建置順暢，但複雜測試需要自管環境 | Xcode Cloud 做標準與發佈驗證，遠端 Mac 做專用任務 |
若你目前的 Xcode Cloud 只是在一次提交中偶發變慢，先不要改平台。若連續樣本都顯示時間消耗在重複初始化、持久服務或主機級限制，繼續購買更多用量未必能解決根因。
Xcode Cloud 的優點是標準化、觸發方便，缺點是臨時環境可能令依賴初始化重複發生，且你無法完全控制主機狀態。相對地，遠端 Mac 需要你維護工具鏈、帳戶、金鑰和節點恢復，但能提供真實 macOS 主機、持久檔案與更完整的服務控制。若你只需要短期驗證，可先用特定地區的遠端 Mac 節點跑最慢的任務；若已證明雙軌更容易維持，再擴大範圍。
本週建議動作
今天先匯出同一提交的正常與異常建置報告，標記排隊、準備、編譯、測試和歸檔階段。接著移除不必要的 Clean Build，檢查依賴腳本和自動取消條件。若證據仍指向臨時環境限制，再把單一工作流程移到遠端 Mac 做對照；不要在沒有階段資料的情況下整批遷移。
如果你的報告已經證明主要時間花在重複初始化或需要保留主機狀態，VpsMesh 的遠端 Mac 可先作為短週期測試節點。確認建置可重現、重啟可恢復、維護工作量可接受後，再決定局部遷移或長期雙軌，而不是用一次慢建置替整個平台下結論。