Apple 官方的 Xcode App 分發流程明確涉及 Archive、Distribute App、上傳三個關鍵階段。你的選擇應該從發布方式開始，而不是看到「自動簽名」就假設所有工作都能使用雲端簽名。
症狀： Organizer 可以上傳，但 xcodebuild 或 fastlane 在遠端 Mac 上找不到私鑰。
最快解法：單人手動發布先選雲端管理式證書；無人值守匯出配置受控的本地 Apple Distribution 簽名身份；人工與 CI 並行的小隊則採用雙軌，分開帳號、Keychain 與發布權限。
先按發布角色選擇 Xcode 雲端簽名 vs 本地簽名
這篇適合三類人：透過 Xcode Organizer 手動上傳 TestFlight、想減少證書維護的獨立開發者；需要使用 xcodebuild、fastlane 或 CI Runner 無人值守簽名的自動化維護者；以及多人共用遠端 Mac、必須限制私鑰和 Apple 帳號權限的小型團隊。
先分清楚幾個容易混淆的實體：
- 雲端管理式證書：由 Apple 的開發者帳號管理流程提供，不等同於「所有指令列任務都在 Apple 伺服器上完成簽名」。
- 本地 Apple Distribution 身份：包含證書、公私鑰和可被本機 Keychain 使用的簽名材料。
- Provisioning Profile：把 App ID、簽名用途與授權條件組合起來，不能視為證書本身。
- 自動管理簽名：Xcode 協助處理簽名設定，不代表 CI 一定擁有私鑰。
- App Store Connect 權限：決定帳號能否管理 App、測試版本或提交發布，與 macOS 使用者的本機權限是兩層控制。
| 發布角色 | 優先方案 | 原因 | 必須驗證 |
|---|---|---|---|
| 單人、Organizer 手動發布 | 雲端管理式證書 | 少處理證書匯入與輪換 | Archive、匯出、TestFlight 狀態 |
fastlane、xcodebuild、CI |
受控本地簽名 | 無人值守流程需要本機私鑰可用 | Keychain 解鎖、Profile、匯出日誌 |
| 人工發布加 CI | 雙軌 | 將便利性與可控回退分開 | 兩條路徑都能完成驗收 |
Apple 對雲端管理式證書的用途與限制，應以官方 Cloud-managed certificates 說明為準。不要把「Xcode 可以自動處理」延伸解讀成「fastlane 不需要本地簽名資產」。
單人用 Organizer 發布：先降低維護面
如果你的主要工作是打開 Xcode、建立 Archive、選擇 Distribute App，再把版本送往 TestFlight，雲端管理式證書通常是較省維護的起點。你不需要為每次遠端 Mac 重建都手動搬移完整簽名材料，但仍要確認 Apple Developer Program 身份、Team 選擇、Bundle ID 和 App Store Connect 存取權限。
| 檢查項目 | 雲端管理式證書的判斷 | 常見誤區 |
|---|---|---|
| Xcode Signing & Capabilities | 可先讓 Xcode 自動管理 | 以為所有 Target 都會自動一致 |
| Archive | 檢查實際簽名身份 | 只看建置成功，不看 Archive 詳情 |
| Distribute App | 以 Organizer 的驗證結果為準 | 把本機編譯成功當成可上架 |
| TestFlight | 確認 App Store Connect 的處理狀態 | 只保存 IPA，不保存上傳結果 |
Xcode 自動簽名是否仍要把分發證書匯入遠端 Mac？
不能只用專案設定回答。Organizer 的自動流程可能由 Xcode 協助完成簽名管理，但實際需求會受 Target、Distribution 方法和帳號狀態影響。請在該遠端 Mac 建立一次測試 Archive，查看簽名身份、Profile 名稱和 Organizer 驗證訊息；不要預先把可匯出的私鑰散布給所有使用者。
Apple 的證書分類與用途可對照Certificates overview。完成一次真實 TestFlight 上傳後，至少留下以下證據：
- Archive 的建立時間與專案版本號。
- Organizer 顯示的簽名身份和 Team。
- 匯出後 IPA 的檔名、Bundle ID 與版本。
- App Store Connect 顯示已收到並處理中的版本狀態。
- 若失敗，保存脫敏後的錯誤訊息，而不是只截取成功畫面。
CLI 與 fastlane：把本地簽名身份當成部署依賴
自動化流程與手動 Organizer 的差別，在於它不能等待你在圖形介面登入、點擊同意或解鎖私鑰。xcodebuild -exportArchive、fastlane 或 CI Runner 需要在指定 macOS 使用者下找到可用的 Keychain、證書私鑰和 Provisioning Profile。
| 自動化環節 | 需要確認的本地條件 | 失敗時先查什麼 |
|---|---|---|
| 建置 Archive | Scheme、Team、Bundle ID | 建置日誌與簽名設定 |
| 匯出 IPA | ExportOptions 與 Profile | exportArchive 日誌 |
| 簽名 | Apple Distribution 證書及私鑰 | Keychain 中是否成對存在 |
| 上傳 | App Store Connect 登入或授權方式 | 上傳工具的權限與回應 |
fastlane 無人值守打包能否直接使用雲端管理式證書？
不要預設可以。能否使用，必須由你實際執行的 fastlane、Xcode 建置環境、簽名資產與匯出日誌共同證明。若 Runner 沒有私鑰、Keychain 在重啟後未解鎖，或 Profile 不符合 ExportOptions，流程就會在匯出階段停止。Apple 的分發簽名文件可用來核對簽名產物，而不是用來推論第三方自動化工具的全部行為。
較穩妥的做法是：
- 建立專用 macOS 使用者，不使用日常管理員帳號跑 CI。
- 將 Apple Distribution 證書、私鑰和 Profile 放在受控 Keychain。
- 只讓 CI 服務帳號讀取必要項目。
- 把 Team ID、Bundle ID、Keychain 名稱和路徑全部改成環境變數或明顯占位符。
- 對
Archive、exportArchive和上傳分別保存日誌。 - 先在測試 App 驗證，再套用到正式 App。
Apple 對簽名身份同步與共享的說明，請參考團隊簽名證書同步文件。匯出、刪除或撤銷證書前，先確認仍有可用的備份和人工發布路徑；否則一次清理可能同時中斷 CI 與緊急上架。
共用遠端 Mac：用四層隔離縮小私鑰外洩範圍
多人共用 iOS 打包機時，最危險的做法不是選錯雲端或本地，而是讓所有人共用同一個 macOS 登入會話、同一個 Keychain 和同一個 Apple 帳號。遠端 Mac 的完整 root 權限也不應等同於每位協作者都能讀取分發私鑰。
多人共用 iOS 打包機，如何避免分發私鑰外洩？
把權限拆成 Apple 帳號、macOS 使用者、Keychain、CI 服務帳號四層。開發者只提交程式碼；發布負責人管理必要的簽名與上傳授權；CI 只讀取執行任務所需的資產。不要把私鑰放在共用桌面、專案儲存庫或未加密的環境變數檔案。
Apple 的App Store Connect 角色權限表應逐項對照。能管理 App 的人，不一定應能匯出分發私鑰；能登入遠端 Mac 的人，也不一定需要提交正式版本。
針對外包、短期維護者或臨時 Runner，可按以下條件選擇：
- 只需手動驗證：使用雲端管理式證書，撤銷遠端 macOS 使用者即可收回本機入口。
- 需要固定自動化：使用專用本地簽名身份，限制 Keychain 可讀範圍。
- 不應接觸發布憑據：讓協作者只提交程式碼，由受控 CI 或發布負責人執行。
- 多個 App 共用環境：按 App 或團隊拆分簽名資產，別追求一套身份通吃所有專案。
提醒：雲端簽名失敗後，不要立即撤銷所有證書改成本地方案。先保留原流程，複製一個測試 Target，確認失敗點是帳號權限、Profile、Keychain，還是匯出工具本身。
雲端簽名失敗後，是否應該改用本地 Apple Distribution 證書？
只有在你的發布任務確實需要可被 CLI 讀取的私鑰，或已用實際日誌證明雲端管理流程無法滿足該路徑時，才建立受控本地身份。建立前先備份現有可用設定，記錄影響的 Team、Bundle ID、CI 工作和回退步驟；不要把一次簽名失敗當成整套方案不可用。
用一次完整驗收決定單軌或雙軌
單次簽名成功不等於生產環境可用。你要測試 Archive、IPA 匯出、上傳、主機重啟，以及權限撤銷後的結果。下面清單可直接交給發布負責人執行：
- [ ] 用測試 Bundle ID 建立 Archive，記錄實際簽名身份。
- [ ] 在相同遠端 Mac 匯出 IPA，保存 ExportOptions 與脫敏日誌。
- [ ] 驗證 IPA 的 Bundle ID、版本、架構和嵌入 Profile。
- [ ] 將測試版本上傳至 App Store Connect，保存處理狀態。
- [ ] 重啟遠端 Mac，確認 Keychain、CI 服務與必要權限能否恢復。
- [ ] 暫停一名協作者的 App Store Connect 權限，確認其無法繼續發布。
- [ ] 對本地簽名身份做回退演練，確認仍有人工 Organizer 路徑。
- [ ] 對雲端管理流程做一次失敗記錄，確認團隊知道何時切換，而不是臨時撤銷證書。
如果你只是偶爾手動發布，通過 Organizer 的完整驗收後，雲端管理式證書通常足夠。若你每天依賴 CI、fastlane 或夜間無人值守匯出，應把本地 Apple Distribution 身份視為部署元件。若兩種工作都存在，雙軌最合理，但兩條路徑必須共用清晰的版本和權限規則，不能共用一個無法追蹤的管理員帳號。
需要遠端 Mac 時，你可以先查看 MACCOME 的繁體中文遠端 Mac 方案，再用實際 Archive、IPA 和 TestFlight 上傳驗證環境。若你目前的設備無法提供獨立使用者、持久 Keychain 或重啟後恢復，問題不一定在簽名選擇，而在打包主機的控制邊界；此時租用具備完整權限的 MACCOME 遠端 Mac，通常比反覆更換證書方案更容易驗收。需要按地區比較時，也可參考香港 Mac 遠端算力方案，先以短期測試完成整條發布路徑，再決定是否長期使用。