第一次用雲 Mac 跑通 iOS 構建，我做出了真正能運行的 App

我日常主力是一台 Windows 筆電，後端和腳本跑在 Linux VPS 上——唯獨 iOS 這條路，繞不開 Xcode 和 Apple 硬體。買 Mac mini 當然可行，但在「還不確定 App 能不能做完」的階段，我更想先用最小成本驗證整條鏈路：連線、編譯、模擬器、簽章、Archive。於是我租了一台雲 Mac，用了一個週末，從零做出能在 iPhone 模擬器裡點開的 SwiftUI App，並在週日晚上完成第一次 Release Archive。這不是教學式的「Hello World 三行程式」，而是一次真實的遠端 Xcode 開發紀錄——包含我踩過的坑，以及哪些步驟其實比想像中更快。

1 台

雲 Mac mini 跑完全鏈路

~6h

從連線到 Simulator 跑通

1 次

首次 Archive 成功

為什麼沒有 Mac，卻先租了雲 Mac

很多人第一次做 iOS 的第一反應是搜「xcode windows」——我也一樣。結論很快明確：面向 App Store 的建置不可能在 Windows 上原生完成，模擬器、codesign、Archive、上傳 TestFlight，每一步都綁在 macOS 上。黑蘋果和違規虛擬機我不考慮：個人玩玩也許可以，但要正經簽章、要以後能稽核，必須落在合規的 Apple 硬體上。

買 Mac 的門檻不只是錢，還有「值不值得現在就買」：如果兩週後發現自己並不需要持續發 iOS 版，一台閒置的 Mac mini 比月租雲節點更浪費。反過來，按週或按月租一台專屬雲 Mac，等於用一次完整實踐來回答三個問題：我能不能適應遠端 Xcode？編譯速度夠不夠？簽章和 Archive 會不會在某個環節卡死？若答案都是肯定的，再決定買本機或上 CI 都不遲。更系統的 Windows 團隊選型，可參考 xcode windows 與 virtual mac online 指南。

Day 0：連線、桌面與第一個「這真的是 Mac」的瞬間

拿到雲 Mac 帳號後，我做了兩件事：SSH 用於命令列和 VS Code Remote，Microsoft Remote Desktop 用於需要點模擬器和 Xcode GUI 的時候。亞太區域選近一點的節點很重要——我第一次誤連了歐洲機，git clone 和 RDP 畫面延遲都明顯偏高，換區之後互動才接近「本機開發可接受」的水準。

系統預裝 macOS，但 Xcode 通常要自己裝。我直接從 Mac App Store 登入個人 Apple ID 下載最新穩定版，裝完跑 xcodebuild -version 和 xcode-select -p 確認 CLI 可用。接著執行 sudo xcodebuild -license accept 和首次啟動 Xcode 安裝額外元件——這一步在遠端桌面裡等進度條，比 SSH 裡盲跑安心。雲 Mac 的好處是：不用自己折騰 Hackintosh，開機就是正經 Apple Silicon，Homebrew、Git、SSH 金鑰可以照你 Linux 伺服器的習慣設定，學習曲線比想像中平。

Day 0 檢查清單

SSH 與 RDP 都能穩定連上；Xcode 與 Command Line Tools 版本一致；git clone 你的 repo 無報錯；在鑰匙圈裡能建立並解鎖 login keychain。任一項不過，先別急著新建工程——後面簽章會全部返工。

從新建工程到「模擬器裡真的能點」

我在 Xcode 裡選了 App 範本，SwiftUI + Swift，Bundle ID 先在開發者帳號裡註冊好。第一遍 Cmd+R 跑模擬器時，雲 Mac 的 Apple Silicon 優勢很明顯：冷編譯大約三四分鐘，之後增量建置常在十幾秒內——比我之前在雲主機上跑 Linux 容器裡假想的「跨平台建置」直觀得多。

真正讓我興奮的不是編譯成功 log，而是模擬器視窗裡出現圖示，點進去 UI 能互動——那一刻才覺得「這是一個 App」，而不只是 repo 裡的幾份 Swift 檔。遠端開發的小技巧：RDP 視窗盡量全螢幕，Simulator 解析度設成與目標機型一致；純 SSH 適合改程式和跑 xcodebuild test，但第一次調 UI 還是桌面靠譜。我在 Windows 上用 VS Code Remote SSH 改邏輯，需要看版面時切 RDP，兩套入口並行，比單押一種方式順手。

命令列同樣能驗證「能跑」

GUI 跑通後，我刻意用 CLI 再跑一遍，為後面的 Archive 鋪路：

Shell · 模擬器 Debug 建置

cd ~/Projects/MyFirstApp
                xcodebuild build \
                  -scheme MyFirstApp \
                  -destination 'platform=iOS Simulator,name=iPhone 16' \
                  -configuration Debug

當這條指令在 SSH 裡也能 green，代表工程設定沒有綁死在 Xcode GUI 的隱式狀態上——以後上 CI 或夜間建置，不會從零重來。

簽章這堵牆：個人開發者也會卡一次

模擬器 Debug 不需要 Distribution 憑證，但Archive 一定會碰到簽章。我卡在兩個地方：一是 Apple Developer 後台的 App ID 與 Bundle ID 不一致；二是遠端 Mac 鑰匙圈第一次彈窗時 RDP 斷線，沒人點「始終允許」，導致背景 xcodebuild archive 靜默失敗。

個人帳號用 Automatic Signing 可以先跑通；若你計畫上架，建議盡早按 App Store Connect API Key 文件化金鑰，別把所有希望壓在 GUI 點選上。我的做法是：在 Xcode 的 Signing & Capabilities 裡勾自動管理，確認 Team 選對；然後在遠端桌面裡親自跑一遍 Archive，讓所有鑰匙圈授權在有人值守時完成。之後再嘗試無人值守的 CLI Archive，成功率會高很多。

遠端簽章最容易忽略的一點

雲 Mac 重啟或工作階段過期後，login keychain 可能重新上鎖。發版前執行 security unlock-keychain -p '…' ~/Library/Keychains/login.keychain-db（密碼用 vault 管理，別寫進 repo），並確認 Distribution 憑證仍在「我的憑證」裡。否則 Xcode GUI 能 Archive，CLI 卻在夜間失敗。

第一次 Archive：從「能跑」到「能交付」

Archive 和 Debug 建置是兩條路。我在 Xcode 裡選 Any iOS Device (arm64)，Product → Archive，Organizer 裡出現第一條歸檔紀錄時，比模擬器裡點 App 還踏實——因為那代表Release 設定、最佳化等級、簽章鏈都走通了。CLI 等價指令如下：

Shell · Release Archive（需有效簽章）

xcodebuild archive \
                  -scheme MyFirstApp \
                  -configuration Release \
                  -archivePath build/MyFirstApp.xcarchive \
                  -destination 'generic/platform=iOS' \
                  CODE_SIGN_STYLE=Automatic \
                  DEVELOPMENT_TEAM=XXXXXXXXXX

匯出 IPA 可以用 Organizer 的 Distribute App，或繼續 xcodebuild -exportArchive。我當晚只做到 Archive + 本機驗證 IPA 結構，沒有急著上傳 TestFlight——對第一次 iOS 來說，Archive 成功本身就是里程碑。若你下一步要自動化，團隊級流水線如何分層、為何 Archive 不宜與 PR 混池，可參考 Cloud Mac 支撐 iOS CI 的容量規劃；個人第一次跑通不必一步到位上三台機器，但提前知道「Archive 該隔離」能少走很多彎路。

遠端 Xcode 的真實手感：能接受，但要會分工

老實說，遠端開發不是本機 MacBook 那種「鍵盤和螢幕一體」的流暢，但在可接受的延遲下完全能完成 iOS 首發。我的體會：

寫程式：Windows + VS Code Remote SSH 改 Swift，體驗接近本機。
調 UI / Simulator：必須 RDP 或螢幕分享，延遲取決於區域與頻寬。
編譯與 Archive：放雲 Mac 上跑，別試圖在 Windows 上交叉編譯 iOS。
資產與 repo：只用 Git，禁止隨身碟在兩台機器間拷工程——遠端 Mac 上的 DerivedData 可以重建，Git 歷史不能亂。

雲 Mac 的另一項隱性收益是環境乾淨：專門用於 iOS 建置的使用者與鑰匙圈，不會和你個人筆電上亂七八糟的全域工具鏈打架。對於「偶爾做 iOS 的後端工程師」，這種隔離比買一台 Mac 放在桌上吃灰更務實。

我的時間軸（供你對照）

階段	耗時（約）	產出
連線、裝 Xcode、clone repo	1～2 小時	遠端 Shell + 桌面可用
新建工程、Simulator Debug	2～3 小時	模擬器裡可點的 App
簽章與鑰匙圈除錯	1～2 小時	Automatic Signing 穩定
首次 Release Archive	30～60 分鐘	.xcarchive / 可匯出 IPA

第二次做同類專案時，Archive 通常能壓到半小時以內——瓶頸會從「會不會」變成「快取與簽章是否常駐」。這也是很多人第一台雲 Mac 用訂閱而不是日租的原因：DerivedData 和鑰匙圈狀態值得留在同一台機器上。

給「第一次 iOS」的從 0 到 Archive 清單

如果你也要在沒有本機 Mac 的情況下驗證 iOS，可以按順序打勾：

租合規 cloud mac（Apple Silicon，記憶體建議 ≥16GB）。
SSH + RDP 雙通道就緒；區域盡量靠近你。
安裝 Xcode，接受授權，安裝額外元件。
Apple Developer 註冊 Bundle ID，Xcode 裡 Signing 無紅色報錯。
Simulator Debug 與 xcodebuild build 均通過。
有人值守完成一次 GUI Archive，再試 CLI。
（可選）export IPA，對照 App Store Connect 要求準備上架中繼資料。

做到第六步，你已經比大多數停在「搜 xcode windows」的人走得更遠——因為你手裡有一份真正能交付的歸檔，而不只是模擬器裡的 Demo。

下一步往哪走

若只是個人 App：雲 Mac 訂閱 + 手動 Archive 足夠。若開始每週發版：把同一台機器註冊為自託管 Runner，PR 只跑測試、main 才 Archive。別在第一次跑通前就過度設計 CI——但 Archive 成功那天，就該把「建置機」從「臨時租的桌面」升級成「有名字的發布節點」。