畫面上已顯示 Archive Succeeded，但 App Store Connect 仍未出現可送審構建。

最快的判斷方式是：不要把 Archive 成功當作發布完成。Xcode 27 iOS App 發布前驗收至少要通過身份資訊、構建產物、簽名能力、上傳狀態與 App Store Connect 關聯五類檢查；遠端 Mac 可以承載重複建構與上傳，但最後仍須用實際 TestFlight 或送審構建完成閉環。

這篇文章適合第一次提交 iOS App 的獨立開發者，用一份清單完成從 Archive 到 App Store Connect 的首次驗收。
正在維護遠端 Mac 打包機、或使用腳本與 CI 自動上傳的小型團隊，也可以用它檢查常駐環境是否具備可重複發布能力。

最後更新於 2026 年 9 月 22 日。版本與分發規則核對自 Apple Developer 的 Xcode 發布記錄、Xcode 分發文件，以及 App Store Connect 的構建管理說明；Xcode 27 正式版與 Xcode 27.2 Beta 分開處理，Beta 行為不直接推論為正式版規則。

先用發布結果界定「驗收通過」

發布鏈路不是單一成功或失敗訊息，而是多個彼此獨立的交付狀態。Apple 的 Xcode 分發文件將 Archive、匯出、上傳與測試或發布分成不同步驟；因此，CI 日誌中的成功訊息不能取代平台上的最終確認。

狀態 應查的證據 通過標準 未通過時的動作
Archive 成功 Xcode Organizer 中的 Archive 產物屬於預期 Target，且可開啟詳細資訊 回到構建設定及 Target 身份資料檢查
IPA 匯出成功 匯出資料夾、ExportOptions 設定 產生符合分發用途的 IPA，而不是模擬器或 Debug 產物 重新確認分發方式、簽名身份與 Profile
上傳完成 上傳工具訊息與上傳紀錄 平台已收到該 Bundle ID、版本號及 Build 號 保存錯誤日誌，先不要重複盲目上傳
Processing 完成 App Store Connect 構建清單 構建狀態完成，沒有仍在處理的阻斷訊息 查看平台錯誤與警告，按新 Build 號重新處理
TestFlight 可用 測試分發頁面及實際安裝 構建在正確 App 版本下，可分配給測試者 檢查合規問答、測試群組與構建關聯
可送審 版本提交頁面 該構建可被選取，且必要資料沒有阻斷 補齊平台欄位，再重新進行提交前複核

Apple 也提醒，構建上傳後需要在 App Store Connect 完成處理，發布者才能在相應流程中使用它；App Store Connect 上傳構建說明應作為狀態判斷的依據。

先核對專案身份與版本歸屬

版本身份錯誤通常不會在「按下 Archive」時立即暴露，卻會在上傳後造成構建找不到、歸入錯誤版本，或無法選作送審構建。驗收時應從最終 Archive 或匯出產物反向確認，而不是只截取 Xcode 專案設定頁。

  • [ ] Bundle ID 與 App Store Connect 中的 App 記錄一致。
  • [ ] 本次 Archive 使用正確的 Target，而不是測試 Target、白標 Target 或模擬器專用 Target。
  • [ ] Team、平台目標及簽名團隊屬於正確的開發者帳戶。
  • [ ] Version Number 對應準備提交的 App 版本。
  • [ ] Build Number 或 Build String 與本次產物唯一對應。
  • [ ] 最終 Archive 詳細資料中的身份值，與預期提交資料一致。
  • [ ] 若是首次建立 App 記錄，已先確認 Bundle ID 與平台資料符合新增 App 記錄的官方流程。

版本號與 Build 號不是同一個欄位。版本號通常決定構建要歸入哪個 App 版本；Build 號則用來區分同一版本下的不同構建。新增版本、向現有版本追加構建，以及重新處理上傳失敗的產物，不能混用同一套處置方式。若一個構建已經上傳並被平台接受，重新提交相同內容時應先確認平台是否要求新的 Build 號，而不是只改本機檔名。

Apple 的構建與元資料說明可用來核對平台實際收到的身份資訊。這一步的證據入口應優先使用平台資料與 Archive 詳細資訊，不能以本機工作區的檔案名稱代替。

再驗證 Archive、IPA 與簽名鏈

「能夠建構」不等於「能夠分發」。模擬器構建、Debug 構建、Release Archive 與可分發 IPA 的用途不同，任何一種都不能自動替代另一種。

  • [ ] Archive 來自預期的 Release 分發設定，而非 Debug 或模擬器工作流程。
  • [ ] IPA 是從本次 Archive 匯出，不是從另一個舊 Archive 或本地暫存檔複製。
  • [ ] IPA 內的 Bundle ID、版本號與 Build 號，和 Archive 詳細資料相符。
  • [ ] 簽名身份屬於本次分發用途，沒有誤用開發簽名。
  • [ ] Provisioning Profile 與 Target、Team 及分發目的匹配。
  • [ ] Entitlements 沒有因匯出設定而遺失或加入不應存在的權限。
  • [ ] dSYM 與本次 Archive 產物一起保存，並可在日後對應崩潰符號化。
  • [ ] 匯出設定檔、Archive 路徑、IPA 雜湊或檔案識別資料已寫入交付紀錄。

Apple 的分發準備文件適合用來核對提交前的分發條件。對獨立開發者而言，最容易忽略的是「簽名成功」只證明當下環境能完成某項操作，不代表這份 IPA 一定使用了正確的 Profile，也不代表它已經與 App Store Connect 的目標版本關聯。

遠端 Mac 環境還要增加三項檢查：Keychain 是否能在非互動式流程中取得必要憑據、腳本是否因權限或解鎖狀態不同而產生另一份產物，以及斷線後能否找回原有 Archive、匯出檔與日誌。若腳本依賴人工點擊、暫存目錄或當次登入工作階段，便不應宣稱具備可重複發布能力。

按照平台狀態完成交付回查

上傳工具回報成功，只能證明檔案已交給平台處理，不能證明 Processing 已完成。若使用遠端 Mac iOS 打包流程，執行者應把上傳時間、版本號、Build 號、錯誤日誌與平台回查結果一併留存，讓另一位成員能夠重現判斷。

需要特別區分以下情況：

  • 上傳成功但尚未 Processing：等待平台處理完成，不能立刻判定可測試或可送審。
  • Processing Failed：先讀取平台提供的錯誤內容，再決定修正設定或建立新的 Build 號。
  • Processing Complete 但構建找不到：檢查 Bundle ID、平台版本與帳戶團隊是否一致。
  • 構建存在但無法選取：檢查該構建是否仍有合規、版本欄位或其他提交阻斷。
  • 重複上傳舊 Build 號：不要把檔名改掉當成新構建；應依平台對該 Build 號的狀態決定是否重新建構。

App Store Connect 的構建狀態與元資料頁面是平台端證據入口。若本機 Transporter 或命令列退出碼與平台顯示互相矛盾，應以平台狀態及其錯誤訊息作為下一步判斷依據。

將 TestFlight 與送審關聯列為最後門檻

TestFlight 的構建顯示 Complete，並不代表可以直接送審。發布者仍需確認構建位於正確的平台版本下，並且在提交頁面中實際可被選取。Apple 的選擇送審構建說明可用於核對這個關聯步驟。

  • [ ] 在正確的 App 版本頁面找到本次 Build 號。
  • [ ] 構建已完成平台處理，沒有停留中的錯誤或警告阻斷。
  • [ ] Missing Compliance 或出口合規問題已按實際使用情況回答。
  • [ ] 測試分發設定沒有把構建限制在錯誤的測試群組。
  • [ ] 版本提交頁面可以選取該構建。
  • [ ] 至少完成一次實際 TestFlight 安裝或最終提交前安裝驗證。
  • [ ] 測試結果使用本次 IPA，而不是本機 Debug 版本。
  • [ ] 提交前重新核對版本號、Build 號、發行說明與必要平台資料。

這個最後門檻特別重要，因為「後台看得到構建」和「審核流程能使用構建」是兩個不同判斷。若構建已完成處理卻不能選取，應先留存畫面與狀態資料，再檢查版本歸屬、合規欄位及帳戶權限，不要立即重建一份內容相同的 IPA。

FAQ：把五個常見判斷放到實際流程中

Xcode 27 Archive 成功後還要檢查什麼？
Archive 只代表封存產物建立成功。還要核對 Bundle ID、版本號、Build 號、簽名身份、Entitlements、Provisioning Profile 與 dSYM，確認能匯出分發 IPA，並完成上傳、Processing、TestFlight 或送審關聯。

iOS App 的版本號和 Build 號怎麼驗收？
版本號應對應 App Store Connect 中準備提交的版本，Build 號則要與本次 Archive、IPA 及平台構建清單一致。新增版本、同版本追加構建與失敗後重新上傳，處理方式不同；最終值不能只依賴 Xcode 專案設定頁。

App Store Connect 上傳後如何確認構建關聯正確？
在構建清單中同時核對 Bundle ID、版本號與 Build 號，再確認 Processing 已完成；接著進入對應版本的提交頁面，確認該構建可被選取。上傳工具顯示成功而平台仍在處理時，不能視為關聯已完成。

遠端 Mac 打包發布前需要檢查哪些項目？
除了 Xcode 與專案身份，還要檢查 Keychain 解鎖、簽名憑據注入、非互動式腳本權限、Archive 與 IPA 保存、日誌留存，以及斷線後的任務恢復。遠端 Mac 只負責執行建構與上傳，不代替平台完成最終確認。

TestFlight 構建 Complete 後可以直接送審嗎？
不能直接推定。Complete 只說明平台處理已完成，仍要確認構建位於正確 App 版本下、可以在提交頁面選取，並處理出口合規、Missing Compliance、測試分發與其他阻斷；完成一次實際安裝或提交前複核後才算通過。

用兩張表完成發布前的責任交接

如果由一人完成全部工作，仍建議把「檢查對象、證據入口、停止條件」寫入發布紀錄。這能避免遠端 Mac 上傳成功後，另一位成員誤以為平台已完成處理。

驗收指標 主要負責人 必須保存的證據 立即停止條件
身份與版本 開發者或發布負責人 Archive 詳細資料、平台構建資料 Bundle ID、版本號或 Build 號不一致
產物與簽名 建構環境維護者 Archive、IPA、匯出設定、dSYM IPA 不是本次 Archive 匯出，或簽名用途不符
上傳交付 CI 或遠端 Mac 維護者 上傳日誌、時間、平台回查畫面 只有本機成功，平台沒有對應構建
Processing 狀態 App 管理者 平台狀態、錯誤與警告 狀態失敗、長時間未完成或版本歸屬不明
TestFlight 與送審 提交負責人 實際安裝結果、提交頁面 構建不能選取或存在合規阻斷

下表則用來選擇執行環境，而不是比較某個環境的理論效能。官方發布規則仍然以 Xcode 與 App Store Connect 文件為準；遠端環境的價值在於是否能穩定保存產物、憑據流程與交付紀錄。

發布方式 適合情況 發布前必查 不適合直接承擔的工作
本機 Mac 偶發提交、需要人工操作或實體裝置 本機 Xcode、Keychain、Archive 保存 長時間無人值守的重複上傳
遠端 Mac 需要常駐建構、腳本上傳或多人共用流程 遠端連線、憑據注入、日誌、斷線恢復 代替 App Store Connect 做最終送審判斷
CI 串接遠端 Mac 需要固定觸發條件與可追蹤產物 Runner 權限、環境版本、失敗重試、產物保存 未經人工核對就把退出碼視為發布完成
純本機模擬器流程 只驗證介面或基本執行 測試用途與構建類型 代替 Release Archive、IPA 或 TestFlight 驗收

Xcode 27 正式版本與 Xcode 27.2 Beta 必須分開管理。若團隊正在評估 Beta，應把它標記為獨立驗證環境，保留正式版可重現的發布路徑；Apple 的 Xcode 發布記錄是核對版本狀態與更新內容的入口，不應以社群個案代替正式規則。

讓遠端 Mac 成為可回溯的發布環境

完成這份清單後，判斷重點就不再是「有沒有一台 Mac」，而是每次發布是否都能拿出同一組證據：正確身份、同一次構建的 Archive 與 IPA、可驗證的簽名、平台處理狀態，以及能夠實際選取的 TestFlight 或送審構建。

若只是偶爾提交，購買或長期維護一台常駐打包機未必划算；本機操作通常更直接，也不必額外處理遠端連線、Keychain 與任務恢復。相反地，若團隊需要反覆 Archive、夜間上傳、失敗後重跑，臨時共用本機容易遇到環境漂移、磁碟空間不足、憑據不在場與任務中斷後難以追溯等問題，此時可評估 RUVCLOUD 的遠端 Mac 方案作為執行環境。

RUVCLOUD 不能取代 App Store Connect 的最終確認，也不會讓錯誤的 Bundle ID 或簽名設定自動變正確；它較適合被放在可重複建構、匯出與上傳的那一段。若發布頻率不高，可先按需使用；若需要長期維持遠端 Mac 打包流程，再依照方案與計費資訊評估是否值得固定一個可回溯的發布環境。