Apple Developer Program 目前包含每月 25 個 Xcode Cloud 計算小時；因此，低頻建置、依賴簡單，而且主要使用 Apple 原生發布流程的獨立開發者，先選 Xcode Cloud 通常較合理。相反地，如果你需要長期在線的 Mac、自訂工具鏈、持久快取，或要讓 fastlane 持續執行後台任務，iOS 打包伺服器會更合適。負載忽高忽低時，日常驗證放在 Xcode Cloud，發布與特殊任務交給獨立 Mac，通常更容易控制風險。(Apple 官方 Xcode Cloud 方案說明)
本週先不要急著比較套餐名稱或單次建置價格。你應該先匯出最近一段時間的建置紀錄，整理觸發頻率、平均任務時間、失敗重跑、平行測試，以及是否有非建置的常駐工作。這組資料，才是比較 Xcode Cloud vs iOS 打包伺服器時真正可用的共同基準。
這篇適合三類讀者：
- 每月建置次數有限，希望快速啟用 Apple 原生 CI/CD 的個人開發者。
- 使用 fastlane、私有依賴或自訂腳本，需要完整 macOS 控制權的開發者。
- 正在比較雲端計算時數與長期 Mac 環境成本的小型 App 團隊。
SECTION 01 先用時間線整理你的建置負載
把工作拆成一條完整時間線，比只看「一次打包要多少錢」更準確：
- 程式碼提交或 Pull Request 觸發建置。
- 依賴下載、腳本安裝與環境準備。
- 編譯、測試、封存及產生
.ipa。 - 簽署並上傳至 TestFlight 或 App Store Connect。
- 失敗後重跑、人工排錯，以及後續通知或交付任務。
Xcode Cloud 的計算小時，是執行雲端任務所消耗的時間。Apple 官方例子指出，5 個各執行 12 分鐘的測試等於 1 個計算小時；測試也可以與分析、封存及建置等工作平行執行。這代表你不能只用「一次編譯花幾分鐘」估算用量，平行測試和失敗重跑也必須納入。(Apple 官方 Xcode Cloud 入門文件)
另外，要先區分兩種環境：
- 臨時建置環境：任務開始時建立，適合標準化 CI 工作；完成後不應假設現場仍然保留。
- 長期在線 Mac 主機：你可以透過 SSH、VNC 或網頁控制台登入，保留專案快取、工具設定與後台流程。
兩者都能完成 iOS 建置，但維護模型完全不同。前者把主機管理交給平台，後者則把環境控制權交還給你。
SECTION 02 成本要看失敗重跑與空閒時間，不只看單次建置
Xcode Cloud 採用計算資源使用邏輯。Apple Developer Program 包含 25 小時／月，另有 100、250、1,000 和 10,000 小時／月的訂閱級距；Apple 公開價格分別為 49.99、99.99、399.99 和 3,999.99 美元／月，未使用的小時不會累積至下一個月。這些是 Xcode Cloud 的官方方案，不應拿來推算 VPSNIX 的租用價格。(Apple 官方計算資源方案)
比較時，建議把成本拆成以下項目：
- 實際編譯與測試時間。
- 依賴下載及每次重新建立環境的時間。
- 失敗後的重跑次數。
- 平行測試造成的額外用量。
- 長期 Mac 的租用週期與閒置時間。
- 你自己處理工具更新、憑證、磁碟空間和故障排查的時間。
可以用三種情境作初步判斷：
| 建置情境 | Xcode Cloud 的傾向 | iOS 打包伺服器的傾向 | 較合理的選擇 |
|---|---|---|---|
| 低頻建置、依賴單純、以 TestFlight 為主 | 啟用快、主機維護少 | 可能出現較多閒置時間 | Xcode Cloud |
| 穩定高頻建置、需要固定工具與快取 | 計算時數及重建環境需持續監控 | 可保留環境並集中處理任務 | iOS 打包伺服器 |
| 發布週期波動大，偶爾有特殊工作 | 高峰期可能快速消耗額度 | 長期租用可能浪費 | 雙軌方案 |
不要自行設定一個「每月超過多少次就一定要換方案」的盈虧分界點。不同專案的測試數量、依賴下載、快取命中率和失敗原因差異很大，應以你自己的連續建置紀錄計算。
如果你希望先了解 VPSNIX 的租用週期與方案，可查看繁體中文方案頁；但真正比較前，仍應把租用週期換算成你的實際建置與維護成本，而不是直接拿月費和計算小時做表面對照。
SECTION 03 依賴與環境控制權，會決定專案能否重現
Xcode Cloud 並不是沒有自訂能力。Apple 官方文件說明，你可以在專案的 ci_scripts 目錄放置 ci_post_clone.sh、ci_pre_xcodebuild.sh 和 ci_post_xcodebuild.sh，用來安裝工具、準備依賴或處理建置後產物；臨時環境也提供 Homebrew，以便安裝部分第三方工具。(Apple 自訂建置腳本文件)
但這種自由度仍然有邊界：
- 臨時環境不應被視為你可以永久修改的主機。
- 私有 Swift Package、Git submodule 或其他私有依賴，需要先完成來源存取授權。
- Swift Package Manager 應提交
Package.resolved，不要依賴每次建置時的自動解析。 - CocoaPods 可以透過鎖定檔和腳本處理；Carthage 則通常需要額外安裝工具。
- Apple 文件明確指出，自訂腳本不能透過
sudo取得管理員權限。(Apple 依賴管理文件)
這裡是兩種方案的關鍵差異：Xcode Cloud 適合「環境可以由 Git 儲存庫和腳本重建」的專案；iOS 打包伺服器則適合「環境本身就是資產」的專案，例如固定版本的 Homebrew 工具、私有二進位依賴、長時間存在的快取，或需要持續運作的自訂服務。
因此，若你的 fastlane 流程每次都能從乾淨環境安裝完成，放在 Xcode Cloud 沒有問題；若流程依賴某些只在特定 Mac 環境中穩定運作的工具，完整主機會更容易維護。
SECTION 04 簽署流程應先決定，再選建置節點
iOS CI/CD 最容易出問題的部分，通常不是編譯，而是憑證、Provisioning Profile、Bundle ID 和上傳權限之間的配合。
Apple 原生工作流適合希望少寫腳本的團隊。Xcode Cloud 可以在 Xcode 或 App Store Connect 中建立工作流，並執行建置、測試及交付任務；Apple 也提供 App Store Connect API，讓你讀取工作流、建置、產物和測試結果，並啟動新的建置。(Apple 工作流與建置 API 文件)
若你使用 fastlane，則可把簽署與發布拆成明確步驟：
- 先建立 App Store Connect API Key，保存 Key ID、Issuer ID 和
.p8私密金鑰。 - 使用
app_store_connect_api_key載入 API 權杖。 - 以
match同步憑證和 Provisioning Profile。 - 以
gym建置並簽署 App。 - 以
pilot或deliver上傳至 TestFlight 或 App Store Connect。
fastlane 官方文件指出，API Key 通常比 Apple ID 登入更適合 CI，因為不需要 2FA，並使用正式的 App Store Connect API。match 則可把簽署憑證和設定檔集中管理；在 CI 環境中，官方建議使用 readonly 模式，避免建置節點意外建立或撤銷簽署資產。(fastlane API Key 與 match 官方文件)
你應該避免以下做法：
- 把
.p8、.p12或密碼直接提交到 Git 儲存庫。 - 在建置輸出中印出 API Key、Token 或 match 密碼。
- 讓多個 App 共用沒有清楚權限範圍的金鑰。
- 把「能夠成功上傳」誤認為「簽署資產已經可長期維護」。
Apple 的環境變數文件也說明，秘密變數可以在建置日誌中遮罩；因此，API Key 和憑證密碼應放在 CI 的秘密變數中，而不是寫進 Fastfile。(Apple 環境變數參考)
SECTION 05 用恢復能力評估穩定性，而不是看一次成功
一次建置成功，只能證明當下的提交和環境可以工作，不能代表方案適合長期運作。你應該在連續紀錄中觀察四個指標：
- 失敗後能否取得足夠完整的建置日誌。
- 相同提交能否重現相同錯誤。
- 依賴和快取是否每次都需要重新建立。
- 遇到憑證、網路或服務中斷時，是否需要人工登入處理。
Xcode Cloud 的優勢是不用自己維護主機，並可在 App Store Connect 查看工作流、建置、產物、問題與測試結果；限制則是建置環境屬於臨時環境，不能把現場狀態當成永久資產。
獨立 Mac 環境的優勢相反：你可以直接登入、檢查檔案、查看快取、執行診斷命令，也能讓背景服務持續運作；代價是你要自行處理 macOS 更新、Xcode 版本、磁碟容量、登入權限、SSH 金鑰和故障復原。
SECTION 06 第一步：用代表性工作流做一輪驗收
在長期遷移前，先選一條最能代表日常工作的流程，例如「Pull Request 測試」或「Release 建置並上傳 TestFlight」，然後按下面清單執行：
- [ ] 記錄一次完整流程從觸發到產物交付的時間。
- [ ] 分開記錄依賴下載、編譯、測試、封存與上傳階段。
- [ ] 讓同一個提交在相同條件下重跑，確認錯誤是否可重現。
- [ ] 刻意測試一次私有依賴或自訂腳本失敗，檢查日誌是否足夠排錯。
- [ ] 確認 API Key、憑證密碼和其他秘密沒有出現在日誌或提交紀錄。
- [ ] 記錄失敗後需要多少人工介入，以及是否必須登入主機。
- [ ] 連續觀察一段時間後，再把實際紀錄代入月度成本。
如果驗收結果顯示所有環境都能由儲存庫和腳本重建，Xcode Cloud 的低維護特性會更有價值；如果你需要登入主機才能恢復工作，或必須保留快取與背景任務，iOS 打包伺服器的控制權就不只是方便，而是流程的一部分。
你也可以先閱讀沒有 Mac 開發 iOS 的方案選擇與遠端 Mac 使用及驗收資訊，再決定是否需要把完整 macOS 節點納入 CI/CD 架構。
SECTION 07 最後的選擇條件：單軌、獨立 Mac，還是雙軌？
你可以用以下條件收束判斷：
- 若每月建置量不高、專案依賴簡單，而且主要使用 Apple 原生工作流，選 Xcode Cloud。
- 若需要 root 權限、自訂 Homebrew 工具、私有依賴、持久快取或常駐 fastlane 任務，選 iOS 打包伺服器。
- 若日常驗證量大但發布任務集中，採用雙軌：Xcode Cloud 負責 Pull Request 和一般測試，獨立 Mac 負責 Release、特殊腳本與長時間任務。
- 若你目前沒有連續建置紀錄，先不要長期遷移；先跑一輪代表性工作流，再根據實際失敗重跑和維護時間決定。
常見方案的隱性代價
Xcode Cloud 的問題通常不是「不能建置」，而是臨時環境、依賴授權和額外腳本會增加重建要求；iOS 打包伺服器的問題則是你需要自行處理更新、磁碟、權限和主機故障。前者可能讓特殊流程需要更多適配，後者則可能在低頻使用時產生閒置成本。
所以，如果你現在使用的方案是純雲端計算，卻經常遇到計算時數不足、依賴每次重裝、失敗後難以保留現場；或者你已經自建 Mac，但長期被主機維護、硬體採購和閒置時間拖住，那麼租用 VPSNIX 的遠端 Mac 會是較容易控制的中間方案。你可以先按週或按月建立一個可登入、可保留環境的打包節點，完成實際驗收後，再決定是否擴大使用，而不是先按硬體型號做長期承諾。