Xcode 26.6 iOS Simulator 下載失敗：2026 遠端 Mac 修復

Xcode 顯示 SDK，只能證明建置工具鏈看得到某個平台 SDK；它不能證明 iOS Simulator runtime 已安裝，也不能證明 CoreSimulator 可以啟動裝置。Apple 將附加 Simulator 元件的下載與安裝列為獨立流程，可參考Apple 的附加 Xcode 元件文件。

先在遠端 Mac 執行以下檢查。<XCODE_APP>、<DEVICE_NAME> 等值都替換成你的實際路徑與裝置名稱：

xcode-select -p
xcodebuild -version
xcrun simctl list runtimes
xcrun simctl list devices

把結果分成三層：

• 專案能否編譯：用最小專案或現有測試目標執行一次建置。
• runtime 是否存在：看 simctl list runtimes 是否列出可用的 iOS runtime，而不是只看 Xcode 的 SDK 版本。
• 裝置能否啟動：建立或選取裝置後，執行啟動與最小測試。

如果第一層失敗，先處理 Xcode 工具鏈；如果第一層成功、第二層沒有 runtime，優先處理元件下載；如果第二層成功、第三層失敗，才調查 CoreSimulator。這個分流能避免把「缺少 runtime」誤判成程式碼或簽署問題。

Apple 的建置與執行 App 文件可用來核對建置與執行的基本路徑。故障紀錄至少保留 Xcode 版本、活動路徑、runtime build、裝置狀態、錯誤文字與發生時間；不要只截取 Preparing 畫面。

多版本 Xcode 共存時，最容易出現「圖形介面是 Xcode 26.6，終端機卻呼叫另一套 Developer Directory」的錯誤。先比較：

xcode-select -p
xcodebuild -version
xcrun --find simctl

如果圖形介面開啟的應用程式是：

/Applications/<Xcode-26.6>.app

而 xcode-select -p 指向其他 Developer 目錄，命令列檢查結果就不具備參考價值。Apple 的 Xcode 26.6 Release Notes 是核對該版本工具鏈行為的第一手資料。

只有在確認錯位後，才切換選擇：

sudo xcode-select --switch /Applications/<Xcode-26.6>.app
xcode-select -p
xcodebuild -version

不要把全域切換當成共享遠端節點的預設動作。CI 節點可能同時服務不同專案；更穩妥的做法是將工具鏈選擇放進工作流程，或在作業開始時明確設定並在日誌中輸出。切換後首次啟動 Xcode，等待必要元件初始化完成，再重新執行 simctl 檢查。

若你只看到 SDK 而沒有 runtime，這一步不會自動補回缺少的平台元件。它的目標是先確保後續命令沒有對著錯誤的 Xcode 執行。

「卡在 Preparing」不是充分診斷。Apple Developer Forums 上確實可見 Xcode 26.6 使用者回報下載停滯或失敗，但這些內容目前只能作為未獲 Apple 普遍確認的個案線索，不能寫成官方已確認的服務故障。可參考相關論壇討論串，但仍要以你自己的錯誤記錄判斷。

按以下順序收集資料：

1. 在 Xcode 的 Components 或附加元件介面記錄目標平台、狀態文字與完整錯誤。
2. 用命令列取得下載結果，不要只重試圖形介面。
3. 記錄解析到的 Apple 服務網域、DNS 結果、代理設定與防火牆規則。
4. 檢查 hosts 是否覆寫相關網域；不要為了「修復」而加入來路不明的固定 IP。
5. 保存錯誤碼、錯誤網域、發生時間、要求的 runtime build，以及遠端節點所在的網路出口。

下載失敗可能來自本地網路阻斷、代理驗證、DNS 污染、防火牆規則、元件目錄暫時異常，或服務端短暫問題。沒有錯誤域名與時間，後續很難區分這些來源。若只有某一台節點失敗，而同一網路下其他節點可下載，先隔離該節點；若多台節點在同一時間、同一網路出口出現相同錯誤，再比較網路層證據。

命令列下載與匯出流程應以 Apple 的附加 Simulator 元件說明及附加 Xcode 元件文件為準。不要依照論壇留言自行拼接未確認的下載網址，也不要把某次成功的錯誤碼對應，當成所有節點都適用的規則。

當 Xcode 元件頁顯示已完成，但 simctl list runtimes 沒有可用項目，先不要刪除資料。這種狀態至少有三種可能：

• 下載包存在，但匯入尚未完成。
• runtime 已匯入，但目前活動 Xcode 不支援或沒有指向它。
• CoreSimulator 的狀態資料異常，導致清單與實際平台檔案不一致。

你可以比對三份證據：

xcode-select -p
xcrun simctl list runtimes
xcrun simctl list devices

再回到 Xcode 的元件頁確認平台狀態。若清單中有 runtime，建立或啟動一台測試裝置，並執行最小測試；若 runtime 有列出但裝置無法啟動，問題已從「下載」轉為 CoreSimulator 或裝置狀態。

低風險處理順序是：退出 Xcode，確認沒有正在執行的 Simulator 工作，重新啟動 Xcode，再次列出 runtime 與 devices。若節點曾經被強制中斷或磁碟空間不足，先保存日誌與現有測試資產，再檢查檔案系統狀態。

刪除 CoreSimulator 資料、系統資源目錄或全部 Developer 資料只能作為末級動作。這些操作可能移除已建立的裝置、快取、測試狀態與尚未備份的環境資訊。執行前要備份必要資料，記錄目前路徑與版本，並確認你有重建節點或重新匯入 runtime 的入口。若刪除後仍無法建立乾淨基線，繼續清理通常只會讓故障證據消失。

當一台 Mac 可以正常下載，另一台遠端 Mac 受網路限制，優先採用官方匯出與匯入，而不是直接複製 CoreSimulator 目錄。Apple 已提供透過 xcodebuild 下載、匯出與匯入 Simulator runtime 的支援路徑；實際參數與目前可下載平台，應以寫作當日的官方文件為準。

概念流程如下：

xcodebuild -downloadPlatform iOS
xcodebuild -exportPlatform iOS -exportPath <EXPORT_DIR>
xcodebuild -importPlatform <RUNTIME_PACKAGE>

上述命令中的 <EXPORT_DIR> 與 <RUNTIME_PACKAGE> 只是佔位符。請先用本機安裝的 xcodebuild -help 核對參數，因為 Xcode 版本、平台名稱與匯出格式可能變動。不要把整個流程包裝成與所有更新版本相容的固定腳本。

落地時按這個順序做：

1. 在可下載的 Mac 上確認活動 Xcode 與目標遠端 Mac 的版本相容。
2. 只下載需要的平台，不要把整個 Xcode 或不相關元件搬到節點。
3. 以官方匯出流程產生平台元件包，保存來源、檔案大小、雜湊值與產生時間。
4. 將匯出包透過受控通道傳送到遠端 Mac，確認傳輸沒有截斷或被代理改寫。
5. 在目標節點匯入，保存完整終端機輸出與錯誤日誌。
6. 重新執行 simctl list runtimes、建立裝置、啟動裝置，再跑最小測試與真實專案測試。

這個流程特別適合批量準備遠端 Mac。你可以把平台包、Xcode 路徑、匯入日誌與驗收結果放進節點交付紀錄，日後遇到相同下載錯誤時，能快速判斷是下載鏈路問題還是節點狀態問題。

修復不是看到 runtime 出現在清單裡就算完成。對需要持續執行 CI 測試的遠端 Mac，至少要完成以下勾選項：

• [ ] xcode-select -p 指向預期的 Xcode。
• [ ] xcodebuild -version 與圖形介面開啟的版本一致。
• [ ] simctl list runtimes 列出目標 iOS runtime。
• [ ] 可以建立或選取測試裝置。
• [ ] 測試裝置可以啟動。
• [ ] 最小專案可以建置並在 Simulator 執行測試。
• [ ] 真實專案的測試目標可以完成一次。
• [ ] SSH 斷線後，背景工作沒有因互動式終端機消失。
• [ ] Mac 重新啟動後，Xcode 與 Simulator 仍能重新啟動。
• [ ] 恢復後的日誌、runtime 識別資料與匯入記錄已保存。

如果只有下載失敗，但官方匯出包能成功匯入，節點可以保留，並將匯入流程納入部署腳本。如果 runtime 在清單中反覆消失、重啟後又失效，或真實專案始終無法通過，應先隔離節點，再以乾淨節點重建。若你已經多次重裝 Xcode、清空資料，卻無法說明每次操作造成的變化，繼續修復的證據價值很低。

你也可以先閱讀遠端 Mac 的方案與使用入口，把「重新修復現有節點」與「在乾淨節點重新驗證」分成兩條路徑。若需要比較週期性使用成本，再查看遠端 Mac 價格方案，不要把一次性救援成本與長期重負載成本混為一談。

如果你目前的 Mac 已被多次重裝或清理，無法建立可信基線，較務實的做法是在一台乾淨的遠端 Mac 上重新驗證下載、匯入、Simulator 啟動與真實專案測試，再決定是否重建原節點。自行維護的 Windows 或 Linux 主機無法直接取代 macOS 專屬的 Xcode 與 Simulator 工具鏈；虛擬化方案還可能增加圖形加速、權限與 runtime 相容性變數。對短期排障、版本驗證或需要持續在線的 CI 測試，租用 CALMVPS 的真實 Mac 通常比繼續修理一台狀態不明的節點更容易建立可追溯基線；但若你需要長期固定負載、實體 USB 裝置或完全自行掌控硬體，購買並維護本地 Mac 仍可能更合適。

在CALMVPS 的遠端 Mac 方案頁面選擇前，先把本文的驗收項目納入你的交付要求：活動 Xcode、runtime 清單、Simulator 啟動、真實專案測試，以及重新啟動後的復測結果都要能留下紀錄。這樣你租到的是可驗證的開發節點，而不只是能連線的 macOS 螢幕。