你在 Windows 或 Linux 上用 VS Code 寫完 Swift，卻卡在模擬器、簽名或 Archive；最快解法是把 VS Code 當作遠端編輯入口，讓 Xcode 27 留在遠端 Mac 負責 Apple 平台工具鏈。

VS Code 不能完整替代 Xcode 27，但可以成為遠端開發的主要操作介面。透過 Remote SSH 開啟遠端 Mac 上的單一工作目錄，再由遠端終端機或 Task 呼叫 xcodebuild；專案設定、模擬器互動、簽名診斷及發布驗收，仍須交給 Xcode 或遠端圖形會話。

這篇適合以下讀者：

  • 以 Windows 或 Linux 為主力電腦，但需要建置及發布 iOS App 的開發者。
  • 偏好 VS Code、希望減少遠端桌面操作時間的 Swift 開發者。
  • 準備把一台常駐遠端 Mac 同時用作開發環境和打包機的小型團隊。

最後更新於 2026 年 8 月 31 日；Xcode 27 狀態、macOS 要求、Remote SSH 主機支援範圍及命令列工具行為，已按 Apple 的 Xcode 系統要求、Microsoft 的 Remote SSH 文件及 Apple 開發者文件核實。

能力邊界

VS Code 的價值在於檔案編輯、終端機、Git 操作及任務整合。它不會把 Windows 或 Linux 變成 macOS，也不會在本機提供 Xcode 的專案管理、Apple 模擬器和簽名環境。

開發環節 VS Code + Remote SSH Xcode 27／遠端圖形會話 判斷
Swift 原始碼編輯 可在遠端 Mac 直接修改 可編輯並提供完整工程脈絡 VS Code 足夠作為主入口
Swift Package 可讀取及編輯套件原始碼 可處理更完整的套件與工程設定 視專案複雜度而定
Xcode project/workspace 可開啟檔案及呼叫命令 管理 Scheme、Target、Build Settings Xcode 仍是設定基準
命令列建置 可執行 xcodebuild 可查看完整建置記錄 兩者可並行
iOS 模擬器 可啟動命令及查看結果 提供圖形互動、除錯及 Preview 圖形工作仍留在 Xcode
程式碼簽名 可檢查建置輸出 管理 Keychain、Archive 和簽名診斷 不應只靠 VS Code
App Store 發布 可觸發自動化流程 完成 Archive、驗證及人工確認 發布前需遠端 Mac 驗收

Apple 的 Xcode 系統要求頁截至上述核實日期列出 Xcode 27 beta 6，並說明相應的 macOS、SDK 及模擬器支援範圍。這代表版本能否使用，首先取決於遠端 Mac 的 macOS 是否達到門檻，不是取決於你本機安裝了哪個 VS Code 版本。

VS Code 能直接開啟並建置 Xcode 專案嗎？
你可以透過 Remote SSH 開啟遠端 Mac 的 .xcodeproj、.xcworkspace 及 Swift 檔案，也能在整合終端機執行建置命令。但「看得到工程檔」不等於「完整管理 Xcode 工程」。Scheme、簽名設定、Build Phase 及某些圖形化配置，仍以 Xcode 的工程模型為準。

遠端工作目錄

遠端開發最常見的故障，不是編譯器本身，而是檔案分散在不同位置。你在本機修改一份程式碼，Remote SSH 開啟另一份，Xcode 又使用第三份建置副本，最後會得到無法重現的結果。

建議將 Git 儲存庫放在遠端 Mac 的單一工作目錄，例如：

/Users/<USERNAME>/Projects/<REPOSITORY>

<USERNAME>、<REPOSITORY>、主機地址、Bundle ID 及 Team ID 都應替換成你自己的值。不要把真實帳號、私密金鑰或發布令牌直接貼到指令及文章範例中。

連線後，按以下順序驗收：

  • 以 Remote SSH 登入遠端 Mac，確認登入帳戶能讀寫工作目錄。
  • 在 VS Code 開啟遠端資料夾，而不是開啟本機同步副本。
  • 執行 git status，確認分支及未提交變更符合預期。
  • 在遠端終端機修改一個檔案，再由 Xcode 查看同一檔案是否立即變更。
  • 確認需要在 Mac 執行的擴充功能安裝於遠端主機，而非只安裝在本機。
  • 關閉並重新連線後，再次確認目前資料夾、Git 狀態及檔案內容沒有漂移。

Microsoft 官方文件確認 Remote SSH 可連線到受支援的 macOS 主機；它解決的是編輯器與主機之間的工作通道，不是把 Xcode 搬到 Windows 或 Linux 執行。

Windows 以 Remote SSH 連線 Mac 後，能否使用 iOS 模擬器？
你可以從遠端終端機或 VS Code Task 呼叫模擬器相關命令，但模擬器的圖形畫面及互動仍在遠端 Mac 的圖形工作階段。若你只保留 SSH，便不能把完整的模擬器視窗當成本機 VS Code 面板使用；需要操作 UI、SwiftUI Preview 或圖形除錯時，仍要連入遠端螢幕環境。

工具鏈一致性

VS Code 的 Swift 語言功能可以改善語法提示、錯誤標記及部分程式碼導覽。Swift 官方的 VS Code Swift 入門文件也將它定位為 Swift 開發的編輯工具，而不是完整取代 Xcode 工程功能的方案。

你需要在遠端 Mac 逐項核對：

  • xcode-select 指向正確的 Xcode 開發者目錄。
  • 使用中的 SDK 與 Xcode 27 工具鏈相符。
  • Scheme、Target 及建置組態在 Xcode 與命令列中指向同一套設定。
  • Swift Package 的依賴解析位置與 Xcode project/workspace 沒有分叉。
  • 遠端 Mac 上的 Xcode 版本與團隊其他建置節點保持一致。

Apple 的 命令列工具設定文件說明如何確認 active developer directory；Xcode 命令列工具參考則列出 xcodebuild 等工具的使用範圍。這些檢查比「VS Code 是否能補全 Swift」更能判斷專案是否具備可發布條件。

VS Code 寫 Swift 時，為什麼無法完整識別 Xcode 工程？
因為語言服務與 Xcode 工程模型不是同一層。Swift Package 的目錄結構通常較容易由編輯器理解；Xcode project/workspace 可能包含多個 Target、Scheme、生成設定、資源組及簽名條件。當補全正常但 xcodebuild 失敗時，不要把問題判定為編輯器故障，先檢查工程設定、SDK 和依賴解析。

建置與測試回饋

VS Code 適合把重複命令收斂成 Task。你可以先以查詢命令確認 Scheme，再執行 Debug 建置，接著執行自動化測試，最後保留可追蹤的日誌及測試結果。

可採用以下操作流程：

  • 在遠端終端機執行 xcodebuild -list -project <PROJECT>.xcodeproj，確認工程及 Scheme 名稱。
  • 使用明確的 -scheme <SCHEME>、-configuration Debug 及目的地參數執行建置。
  • 以 xcodebuild test 執行測試，指定符合工具鏈的模擬器目的地。
  • 將原始輸出導向工作目錄中的建置日誌，避免只依賴終端機捲動內容。
  • 需要機器可讀結果時，保存測試結果包，並在遠端 Mac 上檢查失敗測試及錯誤摘要。
  • 以模擬器命令啟動指定裝置，確認應用程式安裝、啟動及基本互動。
  • 把建置產物、測試結果和提交版本關聯，讓日後能回溯是哪一個提交造成問題。

Apple 的 測試執行與結果解讀文件說明測試結果不只是一行成功或失敗訊息。你需要保留結果包及日誌，才有機會定位測試案例、裝置目的地與建置組態。

驗收層級 VS Code 操作 必須由 Xcode 或圖形會話完成的部分 通過標準
編輯 Remote SSH 修改及提交程式碼 檢查工程是否正確載入 Xcode 看到與遠端目錄相同的變更
建置 Task 呼叫 xcodebuild 查看複雜 Build Phase 及簽名錯誤 產出可追蹤的建置日誌
測試 執行 xcodebuild test 檢查互動式失敗及圖形狀態 測試結果可被重新查看
模擬器 呼叫裝置命令 操作畫面、Preview、除錯 App 可在目標模擬器啟動
發布 觸發 Archive 或自動化流程 確認簽名、驗證及上傳狀態 Archive 可在遠端環境重現

一次命令列測試通過，不代表 SwiftUI Preview、手勢、推播流程或畫面佈局已驗收。這是 VS Code 替代 Xcode 27 時最容易被忽略的邊界。

憑據與發布安全

簽名資料應跟著實際建置主機走。簽名證書、私鑰及 Provisioning Profile 不應因你從 Windows 或 Linux 使用 VS Code，就複製到本機硬碟。原始碼權限、SSH 登入憑據、Mac Keychain 簽名身份及 App Store Connect 上傳權限，也必須分開管理。

遠端開發時，簽名證書應放在本地還是 Mac 上？
若建置與 Archive 在遠端 Mac 執行，簽名證書及私鑰應受控保存在該 Mac 的 Keychain。你的本機只保留必要的 SSH 憑據，不要把私鑰放進 Git、同步資料夾或 VS Code 工作區。

驗收時不要在文章、終端機或截圖中暴露真實憑據。可以檢查簽名身份的脫敏輸出、Provisioning Profile 的有效關聯及 Archive 是否成功產生。Apple 的 Mac 簽名程式碼文件可用來核對簽名流程；若使用 API 金鑰自動上傳，則應按照 App Store Connect API 金鑰文件限制權限及保管私鑰。

恢復能力與方案選擇

遠端環境能否長期使用，不應只看第一次建置是否成功。你還要模擬 SSH 斷線、圖形會話中斷、Mac 重啟、Xcode 工具鏈切換及產物取回。若其中一項沒有明確恢復方式，這台 Mac 只能算臨時測試機，不能直接當作常駐打包機。

可以用以下條件作最後判斷：

  • 只需要改檔及執行簡單命令：選「僅遠端編輯」。
  • 需要反覆建置、測試及偶爾使用模擬器：選「開發雙軌」。
  • 需要固定工具鏈、保留快取、保存簽名狀態及持續產出 Archive：選「常駐打包環境」。
  • 若專案要求實體 iPhone、USB 配件或本機連接的專用硬體，先確認遠端方案能否提供；不能提供時，不要只因 VS Code 方便就改用遠端流程。

你可以先閱讀 MACCOME 的繁體中文遠端 Mac 入口，再按連線方式、租用週期及專案用途比較合適的環境。若你的團隊需要固定保存工作目錄與工具鏈，也可查看 遠端 Mac 方案選擇頁，把一次性測試與持續建置分開評估。

以 Windows/Linux + VS Code 的使用方式來看，本機方案的主要缺點是不能原生執行 Xcode，還要自行處理硬體升級、磁碟空間、版本切換及長時間建置時的電源與連線穩定性。純雲端建置則可能限制互動式模擬器、Keychain 控制和自訂依賴。當你已用同一個儲存庫完成編輯、建置、測試、Archive 及結果取回，租用 MACCOME 的遠端 Mac 通常比另外購買一台只作打包用途的 Mac 更容易按使用頻率調整；偶爾驗證可選短週期，持續開發或自動打包則應選能保留工具鏈與簽名狀態的環境。