Unity 6.3 LTS iOS 建置：2026 Windows 怎麼打包？

Unity 6.3 LTS iOS 建置的結論很明確：Windows 可以完成 Unity 專案開發並匯出 Xcode 專案，但最後的 Archive、程式碼簽名與 App Store Connect 上傳仍要在 macOS 上使用 Xcode。低頻發版時，把已生成的 Xcode 工程交給臨時遠端 Mac；若經常產生 TestFlight 建置，則應在常駐遠端 Mac 上同步 Unity 源碼，讓 Unity 匯出、Xcode 建置和上傳可以分階段重試。

本週建議動作：先用一份脫敏專案完成一次「Windows 匯出 → 遠端 Mac 編譯 → Archive → TestFlight 上傳」驗證，再決定採用臨時或常駐的遠端 Mac，不要先購買實體 Mac 或急著改動證書。

這篇適合：

• 在 Windows 上完成主要開發、首次準備發布 Unity iOS 版本的個人開發者。
• 需要反覆產生 TestFlight 建置，但不想購買及維護實體 Mac 的小團隊。
• 正把手動匯出流程改造成可重複遠端建置任務的 Unity 專案維護者。

提醒：截至 2026 年 8 月 29 日，Unity 官方已確認 Unity 6.3 屬於 LTS 版本；但 Xcode、App Store Connect 上傳門檻及 Unity 補丁相容性都可能調整。下文的版本判斷應以發布前重新核對的官方文件為準。

Unity iOS 建置不是「在 Windows 按下 Build 就得到可上傳 IPA」的一個動作，而是兩個有不同失敗原因的階段。Unity 官方的 iOS 建置流程說明指出，Unity 會先產生 Xcode 工程，之後再由 Xcode 完成應用程式建置；另一份Unity 建置 iOS 應用程式的方法文件也將這兩個階段分開描述。

因此，Windows 能不能直接得到可上傳的 iOS IPA，答案通常是否定的；Windows 可以完成內容製作和工程匯出，但不能取代 macOS 上的 Xcode 發布階段。Unity 官方文件亦提醒，iOS 的最終應用程式建置由 Xcode 負責，不能把「成功生成 Xcode 工程」當成「已完成發布」。

開始前先確認三件事：

• Apple Developer 帳戶具備團隊成員、憑證或建置所需的相應權限。
• Unity 專案的 Bundle ID、Apple Developer 中的 App ID，以及 App Store Connect 的 App 記錄彼此一致。
• 專案、Packages、原生插件及建置腳本已納入版本控制；不要只保存一次生成的 Xcode 工程。

Unity 6.3 LTS 不代表任何 Xcode 版本都能永久相容。Unity 的發布說明、系統需求和 iOS 建置文件需要在同一輪檢查；例如 Unity 6000.3.0f1 發布說明可用來確認 6.3 LTS 的官方發布資訊，而 Unity 6 系統需求文件則提供編輯器環境的官方邊界。這些資料不能被解讀成未來補丁或 Apple 上傳政策永遠不變。

先在 Windows 端記錄：

• Unity Editor 的完整版本字串，以及是否安裝 iOS Build Support。
• Packages/manifest.json 和鎖定檔的提交版本。
• 目標平台、架構、Development Build、符號檔及產物輸出目錄。
• 專案中所有原生插件、CocoaPods 設定和 PostProcessBuild 腳本。

再在遠端 Mac 端記錄：

• macOS 版本、Mac 的處理器架構，以及 Xcode 安裝位置。
• xcode-select 指向的 Xcode 路徑和命令列工具狀態。
• Team ID、Bundle ID、簽名方式，以及憑證和 Provisioning Profile 的取得方式。
• 建置日誌、Unity 匯出選項和每次提交對應的提交雜湊值。

可以先用最小空專案走一次完整鏈路。若空專案無法匯出或 Xcode 命令列無法找到工具，先修正環境，不要把正式專案的插件錯誤混在一起。Xcode 的發布前驗證與 Archive 準備方式，應以 Apple 的準備 App 進行分發文件為準。

這裡的核心取捨不是「哪一台電腦比較快」，而是每次建置是否能重新產生同一份工程。兩條路徑的適用條件如下：

Windows 端生成 Xcode 工程

低頻專案可以在 Windows 端選擇 iOS 平台並生成工程，接著完整傳輸輸出目錄。不要只複製看似主要的 .xcodeproj，還要檢查工程引用的庫、原生資源、插件、符號檔和建置後處理結果是否都在傳輸範圍內。

建議依序操作：

1. 在版本控制中建立本次建置提交，記下 Unity 版本、Packages 鎖定狀態及建置設定。
2. 清理上一輪輸出目錄，建立新的 Xcode 工程目錄，例如 <XCODE_PROJECT_DIR>。
3. 由 Windows 執行 Unity 匯出，將 <UNITY_PROJECT_PATH>、<BUILD_TARGET> 和 <XCODE_PROJECT_DIR> 都替換成實際值。
4. 將整個工程目錄以保留檔案結構的方式傳到遠端 Mac，不要經過會忽略隱藏檔或符號連結的壓縮流程。
5. 在遠端 Mac 檢查工程引用是否完整，再用 Xcode 開啟並先執行一般編譯。

實際指令中的專案名稱、路徑、Bundle ID、Team ID、憑證、密碼及 API Key 都應使用自己的安全變數或明顯占位符，例如 <PROJECT_NAME>、<TEAM_ID>、<APP_STORE_CONNECT_API_KEY>，不要把真實密碼寫進 Shell 歷史或儲存庫。

遠端 Mac 是否一定要安裝完整 Unity Editor？

答案取決於選擇的路徑。若 Windows 已經生成完整 Xcode 工程，遠端 Mac 的任務主要是 Xcode 編譯、簽名和上傳，因此不一定需要完整 Unity Editor；但若希望遠端 Mac 從 Unity 源碼重新匯出工程，就必須安裝與專案一致的 Unity Editor、iOS Build Support、Packages 及相關插件。

這也是常見的錯誤判斷：團隊將 Unity 工程傳到遠端 Mac，卻沒有確認遠端是否能執行同一個 Editor；或者只安裝 Unity，卻漏掉 iOS Build Support，最後把環境缺件誤判為 Xcode 問題。正式導入前，應先在空專案和脫敏正式專案各完成一次匯出驗收。

工程抵達遠端 Mac 後，不要一開始就處理憑證。先確認生成工程可以被 Xcode 開啟，並完成不涉及發布的基本編譯；這一步能把 Unity 匯出錯誤、原生插件錯誤和 Apple 簽名錯誤分離。

接著按照以下順序驗收：

• Team：確認 Xcode 專案選中的團隊與 Apple Developer 權限一致。
• Bundle ID：確認工程設定、Apple App ID 和 App Store Connect 記錄一致。
• Signing：決定使用自動簽名或受控的憑證與 Provisioning Profile，不要在多台機器任意建立新憑證。
• Entitlements：逐項檢查推播、Sign in with Apple、Keychain Sharing 或其他能力是否與 App ID 一致。
• 原生依賴：檢查 CocoaPods、Swift/Objective-C 插件及 PostProcessBuild 是否真的在遠端環境執行。
• 產物：只有成功產生可分發 Archive，才算完成「首次建置」階段。

若使用命令列，應把每個階段的退出狀態寫入日誌，並保存 <ARCHIVE_PATH>、<SCHEME_NAME>、<WORKSPACE_PATH> 等占位變數所代表的實際值。不要把 Archive 成功等同於簽名配置正確：有些問題只會在分發驗證時出現。

Unity 生成的工程被手動修改後，下一次重新匯出可能會覆蓋修改；因此，應把可重建的設定放回 Unity 專案、插件設定或建置腳本中，避免 Windows 和遠端 Mac 同時修改同一份生成工程。

Apple 將「本機建置成功」、「簽名成功」、「完成上傳」和「App Store Connect 後台處理完成」視為不同狀態。依照 Apple 的透過 Xcode 分發測試版和正式版本說明，先在 Xcode 對 Archive 執行驗證，再選擇上傳；不要因為 Xcode 已產生 Archive，就直接認定 TestFlight 已可測試。

可按照這個順序操作：

1. 在 Xcode Organizer 選取正確的 Archive，確認版本號、建置號和簽名資訊。
2. 執行 Validate，先處理 Bundle ID、Entitlements、架構或簽名錯誤。
3. 通過驗證後執行 Distribute App，選擇適合 TestFlight 的上傳流程。
4. 在 App Store Connect 確認 App 記錄、版本號和建置號能正確關聯；Apple 也提供上傳建置版本的官方步驟。
5. 上傳後查看處理狀態和交付日誌；若建置沒有立即出現，先按照建置上傳狀態說明判斷是仍在處理、處理失敗，還是被拒絕。

如果 Xcode 顯示上傳完成但 TestFlight 看不到建置，不應立即重建或更換證書。先記下建置號、上傳時間、處理狀態與錯誤訊息，再對照 App Store Connect 的交付結果。Apple 的發布建置測試文件也可用來確認發布前測試步驟，這比反覆點擊 Upload 更容易定位問題。

當專案開始頻繁發布，生成 Xcode 工程的交接方式會逐漸暴露出傳輸負擔和環境漂移問題。此時較合理的做法，是在遠端 Mac 保存建置腳本，讓以下工作可以各自重試：

• Unity 從指定提交匯出 Xcode 工程。
• Xcode 執行 Archive。
• 對 Archive 執行驗證與簽名。
• 上傳到 App Store Connect。
• 收集 Unity、Xcode 和上傳工具的日誌。

把快取、憑據和產物分開管理。Unity Library 或 Xcode DerivedData 可以按建置策略重建；憑證私鑰和 App Store Connect API Key 則應由安全儲存或環境變數提供，不能與 Xcode 工程一起打包。每次建置都要輸出唯一的版本號、建置號和提交雜湊，否則失敗後很難知道測試人員拿到的是哪一份產物。

本週至少做三次恢復演練：

• 只有 Unity 源碼變更，確認可重新匯出並完成 Archive。
• 只變更一個原生插件，確認 CocoaPods 或 PostProcessBuild 失敗時能單獨重試。
• 暫時移除建置憑據，確認流程會在簽名階段停止，而不是產生看似成功但不能上傳的檔案。

何時選臨時遠端 Mac，何時保留常駐環境？

若一個專案只是偶爾提交版本，生成 Xcode 工程後交給臨時遠端 Mac，通常較容易控制成本；此時應完整保存工程、日誌和使用的建置設定。若專案需要持續產生 TestFlight 建置，或已有自動化觸發器，則常駐遠端 Mac 更適合，因為 Unity Editor、Xcode、插件和憑據管理可以固定在同一個可驗收環境。

在 Windows 端完成主要工作後，若不想維護一台只在發布時使用的實體 Mac，可以先查看 JEXCLOUD 的遠端 Mac 方案，再依照實際發版頻率選擇租用週期。若只是驗證一次完整流程，先用真實專案測試比只用空專案估算更可靠。

Windows 目前方案的隱性成本，通常不在 Unity 編輯本身，而在工程傳輸、原生插件不一致、憑證只能由特定電腦保管，以及每次發布都要重新手動確認 Xcode 狀態；單純購買一台 Mac 又會帶來硬體折舊、硬碟空間、系統更新和長期維護責任。對需要臨時或週期性 iOS 建置的獨立開發者而言，租用 JEXCLOUD 的遠端 Mac，能先取得可連線的 macOS 建置環境，再按專案的實際發布頻率決定租用週期，而不必先承擔一台專用實體 Mac 的固定成本。真正長期、穩定且高負載的團隊，或需要本地 USB、實體測試裝置的工作，仍應評估自購 Mac 或保留本地設備；遠端租用最適合先驗證 Unity 6.3 LTS iOS 建置鏈路，以及承接沒有必要全天佔用本地硬體的發布任務。

完成 Windows 專案整理後，建議先在 JEXCLOUD 的 Mac 租用選擇建立一次可重複的匯出、Archive 和 TestFlight 上傳流程；確認插件、簽名與恢復演練都能通過，再決定是維持臨時租用，還是保留常駐的遠端 Mac。