不要先從「哪個上傳按鈕比較方便」開始。真正的判斷條件是：這個 Archive 會交給誰測試，以及它將來是否可能成為外部測試或正式提交的候選版本。

Apple 將 Internal Only 構建標記為內部構建。它只能加入內部測試組，不能加入外部測試組，也不能提交給客戶或送交 App Store。這不是測試者權限不足時才會出現的暫時錯誤，而是構建分發資格本身的限制。Apple 對內部測試者與構建範圍的說明清楚區分了兩者。

Xcode 上傳時該選 TestFlight Internal Only 還是 TestFlight 與 App Store？
如果 Archive 只會給團隊成員檢查，且不會進入外部測試或正式發布流程，選 Internal Only。只要產品經理、客戶、社群測試者或未來的 App Store 候選版本在計畫內，就選普通 TestFlight 與 App Store 分發。判斷時要看「這個構建的最終資格」，不是只看今天要不要做內測。

團隊成員不是一般外部測試者

內部測試者必須是 App Store Connect 團隊中的成員，並具備相應帳號與角色。你可以把 Internal Only 想成「已經知道風險、屬於團隊範圍內的人先驗證」，而不是一個沒有發布限制的 TestFlight 草稿。Apple 的內部測試者資格說明也指出，測試者能看到哪些構建，會受其團隊身分與構建關聯影響。

外部測試者則是另一條路線。客戶、合作夥伴、付費試用者或透過公開連結加入的使用者，不屬於你的 App Store Connect 團隊。這類測試通常要使用外部測試組、邀請電郵或公開連結；首次提供給外部測試者時，也要留意 Apple 對外部測試的審查與資訊要求。外部測試者邀請規則可作為設定依據。

TestFlight Internal Only 構建可以改成外部測試嗎？
不能把已上傳的 Internal Only 構建直接「轉換」成外部測試資格。你需要依照普通 TestFlight 與 App Store 分發方式重新建立並上傳適合外部測試的構建。不要把改測試組、改邀請電郵或重新整理 App Store Connect 頁面，誤當成更改構建分類。

為什麼 TestFlight 構建不能添加到外部測試組？
常見原因不是外部測試組壞掉，而是該構建在上傳時已被標記為 Internal Only，或構建尚未完成處理、尚未符合可分派狀態。先核對構建分類與 App Store Connect 的處理狀態，再檢查測試組與版本關聯；不要一看到不能加入就撤銷證書。App build statuses 說明可用來辨認處理中的構建、可測試構建及錯誤狀態。

Internal Only 最適合三種情況：

• 實驗功能只給團隊成員檢查。
• 除錯開關、開發用 API 或未完成介面不應交給外部使用者。
• 這個構建明確不會成為外部測試或 App Store 候選版本。

它不適合以下情況：

• 你可能在幾天後邀請外部測試者。
• 你想讓同一個 Archive 逐步走完內測、外測與正式提交。
• 你的發版分支由 CI 自動上傳，人工很少重新確認分發資格。
• 構建已包含候選版本的簽名、環境設定與發布說明。

內部測試構建以後還能提交 App Store 嗎？
如果這裡指的是 Internal Only 構建，答案是否定的。它的核心作用正是阻止開發構建進入外部測試與 App Store 提交鏈路。需要正式提交時，應以正確的分發方式重新 Archive、簽名並上傳；不要把重新上傳描述成零成本的切換。

重新建置可能牽涉版本號、Build number、簽名設定、環境變數、依賴快取及審核用設定。Apple 的構建上傳文件提供上傳方向，但不代表你的 CI 會自動保留所有發布條件。對小團隊而言，錯誤選擇通常帶來的不是幾個按鈕操作，而是重新確認版本與重新排程驗收。

場景案例：單人開發者的雙重需求

假設你每天由 CI 建立一個開發構建，自己和一名合作開發者先檢查資料同步；每兩週再邀請一批外部測試者體驗候選版本。若所有 Archive 都使用 Internal Only，內部驗證很安全，但外部測試鏈路會在構建資格上中斷。

更穩妥的做法是：

1. develop 或實驗分支建立 Internal Only Job。
2. release 分支建立普通 TestFlight 與 App Store Job。
3. 外部測試與正式提交 Job 必須加入人工批准。
4. 兩個 Job 使用不同的簽名與 App Store Connect 權限。
5. 版本號與 Build number 在產物名稱中清楚標示，避免拿錯 Archive。

這不是把步驟拆得越多越好，而是把「只可內部驗證」與「具有發布資格」的風險分開。

遠端 Mac 自動上傳如何區分內部測試和正式構建？
不要只靠 CI 變數中的一個 UPLOAD_MODE 字串。應同時把分支、Scheme、Export 設定、簽名材料、App Store Connect API 權限與人工批准條件綁在一起。這樣即使有人誤觸發內部 Job，也不會順手取得正式發布能力。

在遠端 Mac 上，可以按以下五步建立分流：

1. 先固定分支規則。
   內部驗證只接受開發分支；候選發布只接受受保護的發布分支。不要讓任意 Pull Request 直接觸發正式上傳。

2. 分開 Scheme 與 Export 設定。
   內部驗證使用清楚標記為 Internal 的 Scheme；候選發布使用另一套經審核的 Export 設定。兩者不可只靠檔名區分。

3. 分離簽名私鑰與 API 權限。
   內部 Job 只取得完成內部驗證所需的最低權限。正式發布 Job 的私鑰與 App Store Connect 憑證應放在受限的 Secret 儲存區，不能在一般測試任務中全域可讀。

4. 把上傳方式寫入 Job 記錄。
   每次任務記錄分支、Scheme、Export 方法、構建分類與批准者。不要記錄真實 API Key、Team ID、Bundle ID、主機地址或私鑰內容。

5. 在上傳後驗證構建資格。
   CI 成功不等於 App Store Connect 已產生正確資格。要再核對 Internal 標記、可選測試組與後續提交資格；任一項不符，就停止推進，不要自動通知外部測試者。

若你的本地 Mac 無法長時間保持開機，或磁碟空間不足以穩定保存 Xcode 與 Archive，可以先參考遠端 Mac 開發環境方案。對需要固定執行 CI 的團隊，也可以先了解 KVMNODE 遠端 Mac 服務所提供的遠端主機使用方式，再按你的簽名與權限要求設計 Job。遠端主機只是執行環境，分發資格仍要由你的 Xcode 設定、CI 權限與 App Store Connect 流程負責。

不要只在設定檔中檢查文字。用脫敏後的真實構建各跑一次，才能確認上傳方式、簽名與 App Store Connect 顯示結果一致。

內部驗證構建

• [ ] 從開發分支建立 Archive，並在產物名稱標明 Internal。
• [ ] 上傳後確認 App Store Connect 顯示為內部構建。
• [ ] 核對只能選擇內部測試組，不能加入外部測試組。
• [ ] 由一名團隊成員完成安裝、更新與基本功能驗證。
• [ ] 確認 CI 日誌沒有暴露憑證、私鑰、電郵或主機資訊。

候選發布構建

• [ ] 從受保護的發布分支建立另一個 Archive。
• [ ] 核對使用的是普通 TestFlight 與 App Store 分發方式。
• [ ] 確認構建可以按規則關聯外部測試組。
• [ ] 由批准者檢查版本說明、環境設定與簽名狀態。
• [ ] 在正式提交前確認構建具備後續 App Store 分發資格。

驗收失敗時，應該先撤銷證書或清理 Archive 嗎？
不應把這些動作當成預設修復方式。先確認上傳時選用的分發方式，再看構建分類、處理狀態與測試組可見範圍。只有在證據指向簽名或憑證問題時，才處理簽名材料；否則撤銷證書可能讓原本正常的其他 Job 一起失效。

兩種工作流的決策對照

三種常見情況的選擇卡

如果你已經採用自託管 Runner，建議另外檢查 Runner 標籤、Secret 可見範圍與人工批准條件。若只有一台常駐 Mac，至少也要用 Job、Scheme 和權限隔離，而不是讓每次提交都沿用同一套發布憑證。

TestFlight Internal Only 的價值，在於把「只供團隊驗證」這條邊界寫死；它不是一個日後可以隨時轉成正式版本的暫存區。只要構建可能交給外部測試者，或可能成為 App Store 候選版本，就應在 Archive 前選擇普通 TestFlight 與 App Store 分發。

若你目前的方案是讓本地 Mac 長期執行 CI，常見限制是設備可能關機、硬碟空間被 Xcode 與 Archive 佔用，以及簽名憑證與發布任務難以隔離；若改用一般雲端環境，又可能遇到 macOS 工具鏈、連線方式和持續在線能力不符合需求。對需要固定執行內部驗證與候選發布的團隊，KVMNODE 的遠端 Mac 可作為較容易常駐的執行環境；你仍需自行保留分支保護、憑證隔離與 App Store Connect 驗收流程。

如果你只是偶爾建置，購買或租用專用 Mac 未必划算；但當 CI 必須持續在線、又不想讓日常電腦承擔發布任務時，先用 KVMNODE 建立一台獨立遠端 Mac，再按上面的雙通道清單驗收，通常比把 Internal Only 與正式發布混在同一個 Job 更容易控制風險。