TestFlight 是什麼？從第一次邀請到成功安裝的新手完整教學

資料核實日期：2026 年 9 月 17 日。本文以 iPhone、iPad 為主。Apple 的介面和規則會更新，請以文中連結的官方說明，以及你實際看到的頁面為準。

你做出了一款 App，想先請朋友試用，卻還沒準備好正式上架 App Store。直接傳原始碼不行，傳一個安裝檔，對方也不一定能安裝。

這就是 TestFlight 要解決的問題。

大家說的「TF」，通常就是 TestFlight 的簡稱。這是 Apple 提供的測試版分發服務：開發者上傳測試版，邀請其他人安裝，收集回饋，再發布改進後的版本。測試人員安裝的是實際在裝置上執行的 App，不是螢幕截圖或網頁示範。[1][2]

先記住 3 句話：

• 內部測試的對象是具備相應 App Store Connect 權限的成員。
• 外部測試適合朋友、客戶和社群使用者，不需要給他們開發者後台權限。
• 每個建置版本最多可測試 90 天，從上傳當天開始計算。通過測試版審查，不等於正式上架。[1][3]

如果你只是收到別人傳來的連結，可以先看第 9 節「測試人員如何安裝」；如果你要把自己的 App 提供給別人測試，就從頭開始。

1. TestFlight、App Store Connect 和 App Store 分別是什麼？

可以把一款新 App 想成一家還在試營運的店：TestFlight 幫你邀請大家來體驗，App Store 則是正式開門營業的管道。試營運也有期限和規則，並不是繞過審查的後門。

這 3 個名稱很像，功能卻不一樣：

表格較寬時可左右滑動；使用鍵盤的讀者可先將焦點移至表格，再使用方向鍵。

你從 App Store 下載的是 TestFlight 這個工具，再透過它安裝別人邀請你測試的 App。某款 App 出現在 TestFlight 裡，不表示你已經能在 App Store 搜尋到它。[1][3]

Apple 用 TestFlight 串起「發布版本—邀請測試—收集問題—更新版本」的流程。現在使用 TestFlight，開發者不必逐一收集測試人員的裝置識別碼，也不需要為每位測試人員個別製作佈建描述檔。[2]

但它不會幫你寫好 App，不會證明所有功能都正確，也不會自動把測試版變成正式版。即使通過測試版審查，也不能保證 App 沒有漏洞或不會遺失資料。測試陌生 App 時，不要拿僅有的 1 份重要資料冒險。

2. TestFlight 的歷史：它並不是 Apple 從零打造的

了解這段歷史，就能理解為什麼舊教學中的名稱、人數和操作方式會不同。

• 2011 年 1 月：第三方服務公開推出。當時測試尚未發布的 iPhone App，經常得處理裝置識別碼、安裝檔和描述檔，再透過電腦上的 iTunes 同步。TestFlight 讓無線安裝方便了許多。這裡指的是從封閉測試轉為公開服務的時間，不是公司的登記成立日期。[H1]
• 2012 年 3 月：宣布遭 Burstly 收購。TestFlight 當時仍是第三方產品。[H2]
• 2014 年 2 月：Apple 收購 Burstly。TestFlight 隨母公司一同納入 Apple。[H3]
• 2014 年 10 月：Apple 宣布透過 iTunes Connect 開放電子郵件邀請測試。iTunes Connect 是現在 App Store Connect 的前身，當時最多可邀請 1,000 人。請注意，這是歷史數字。[H4]
• 2017 年 7 月：可邀請的外部測試人數擴增至 10,000。[H5]
• 2018 年 9 月：Apple 推出公開邀請連結。開發者不必先逐一收集電子郵件地址，也能透過分享連結招募測試人員。[H6]

如今 TestFlight 已支援 Apple 的多個平台，包括 iPhone、iPad、Mac、Apple Watch、Apple TV 和 Apple Vision Pro。本文以 iPhone 為例，不代表它只能測試 iPhone App，也不代表它能分發 Android App。[2][3]

3. 先認識 5 個詞：測試版、版本、建置版本、群組和審查

測試版（Beta）：仍在驗證和改進的 App 版本，可能存在問題。

版本（Version）：例如 1.0、1.1，用來標示對外發布的版本。

建置版本（Build）：某一次具體封裝產生的 App。例如 1.0（12），意思是版本 1.0、建置編號 12。修好一個問題後，可以上傳 1.0（13）：對外版本相同，但安裝內容已經不同。[7]

群組（Group）：決定哪些人能收到哪些建置版本。你可以建立「團隊」和「搶先體驗」2 個群組，提供相同或不同的建置版本。1 個群組可以有多個建置版本，同一個一般建置版本也可以分配給多個群組。[2][5][6]

測試版審查（TestFlight App Review）：Apple 針對外部測試進行的審查，與正式在 App Store 發行的審查不同。[1][6]

記住這個關係，就不容易搞混：App 是整個專案，建置版本是其中某一份具體的安裝內容，群組決定誰可以試用。公開邀請連結屬於外部群組，不是永遠綁定某一個建置版本。

4. 開始之前，發布者和測試人員分別需要準備什麼？

發布者需要準備的項目

1. 有效的 Apple Developer Program 會員資格。Apple 目前的標準費用為每年 99 美元，各地區的價格可能不同，部分符合資格的機構可以申請費用減免。TestFlight 包含在相關會員服務中，不是另外購買的測試人員訂閱方案。[4]
2. 正確的 App Store Connect App 記錄。App 的識別碼、簽署和上傳內容必須相符，不能隨意加入另一款 App 的安裝檔。[7]
3. 足夠但不過度的帳號權限。帳號持有人、管理員、App 管理員或開發者角色可以上傳建置版本；管理外部測試則需要帳號持有人、管理員或 App 管理員角色。能上傳，不代表能操作所有外部測試設定。[6][7]
4. 測試資料。包括 App 說明、接收回饋的電子郵件地址，以及希望大家測試的內容；外部審查還需要聯絡資訊，以及能讓審查人員實際登入或使用功能的存取方式。[6][8]
5. 可供測試的裝置和時間。上傳成功不等於已經確認能安裝，也不等於主要功能都已驗證。

不要把自己的 Apple 密碼傳給朋友。請別人測試 App，應該傳送邀請，而不是共用管理帳號。

一般測試人員需要準備的項目

你只需要 Apple 帳號、相容的裝置、TestFlight 和有效的邀請。不需要付費加入開發者計畫，也不需要進入開發者後台。[1][3]

截至本文資料核實日，Apple 測試人員說明頁面列出的 iPhone、iPad 需求是 iOS 16、iPadOS 16 或以上版本。但個別 App 可能要求更新的作業系統，公開邀請也可以依裝置和系統版本篩選。能安裝 TestFlight，不代表能安裝裡面的每一款 App。[3][6]

如果你使用公司或學校提供的管理式 Apple 帳號，要特別確認資格：Apple 的外部測試說明明確指出，這類帳號不能用來測試建置版本；內部測試說明則另外指出，在保留網域中建立的管理式帳號不能用於測試。遇到這類情況，應查看對應的說明頁面與組織政策，不要誤以為是邀請連結故障。[5][6]

5. 內部測試和外部測試到底有什麼不同？

最重要的差別是後台身分和權限，不是你和對方熟不熟，也不是邀請是否透過電子郵件寄出。

表格較寬時可左右滑動；使用鍵盤的讀者可先將焦點移至表格，再使用方向鍵。

符合內部測試人員資格的角色包括：帳號持有人（Account Holder）、管理員（Admin）、App 管理員（App Manager）、開發者（Developer）、行銷（Marketing），同時必須能存取這款 App。[2][5]

私下透過電子郵件邀請朋友，通常仍應選擇外部測試。外部不等於公開；你完全可以只邀請幾個人，不啟用公開連結。

不要為了少一道審查，就給一般測試人員管理員權限。那不是讓人能安裝 App 的開關，而是真正的後台管理權限。

另一項容易忽略的限制是：個人開發者帳號最多可以新增 50 位 App Store Connect 使用者。因此，TestFlight 的「100 位內部測試人員」上限，不代表每個個人帳號都能額外建立 100 個後台成員。[9]

6. 如何新增 Build？先分清楚「上傳」和「加入測試群組」

這其實是 2 件事：

• 上傳建置版本：將已封裝的 App，從開發或建置工具傳送給 Apple。
• 為群組新增建置版本：從已上傳且可用的建置版本中，挑選一個提供給這個群組。

App Store Connect 測試群組中的「新增建置版本（Add Builds）」，不是把原始碼拖進去就會自動產生 App，也不是上傳本機檔案的按鈕。[5][6][7]

第一次發布，後台還沒有這款 App，該怎麼辦？

由帳號持有人、管理員或 App 管理員角色進入 App（Apps）→「+」→ 新增 App（New App），選擇平台，填寫 App 名稱、主要語言、App 識別碼（Bundle ID）、用於後台管理的 SKU 等必要資訊，再設定成員的存取範圍並建立。App 識別碼必須與專案一致；如果還不知道該用哪個識別碼，先向負責封裝的人確認，不要隨意選擇另一款 App 的識別碼。

如果無法建立，請檢查帳號持有人是否已接受最新協議。建立 App 記錄只是在後台建立管理入口，不代表已經上傳或上架。[15]

使用 Xcode 上傳的基本步驟

如果你已經有一個 iOS 專案，可以依照這個順序操作：

1. 檢查 App 識別碼和簽署團隊，是否與 App Store Connect 的 App 記錄相符。
2. 為這次上傳設定未使用過的建置編號，例如從 1.0（12） 增加到 1.0（13）。
3. 選擇用於實體裝置分發的目標，點選 Product → Archive 建立封存檔，不要上傳模擬器版本。
4. 在 Window → Organizer → Archives 中選取封存檔，點選 Distribute App。若要用於一般 TestFlight 測試和後續正式發行，請選擇 TestFlight & App Store；自訂流程中則對應 App Store Connect 分發。依照介面指示完成簽署與上傳。[16]
5. 上傳後，前往 App Store Connect → App（Apps）→ 你的 App → TestFlight 查看。
6. 等待 Apple 處理。遇到出口合規問題時，應依 App 實際使用的加密情況如實填寫，不能為了繼續操作一律選擇「未使用加密」。
7. 處理完成且建置版本可用後，再將它加入內部或外部測試群組。

Xcode Cloud、Transporter 等工具也可用來上傳。使用不同工具，不代表能跳過 Apple 的處理、合規、群組分配和外部審查程序。[7] 各上傳工具和 SDK 的最低要求會調整，操作時請查看 Apple 目前的上傳要求。建置時使用的 SDK 版本，不等於 App 允許安裝的最低系統版本。[18]

留意「僅限內部測試」這個選項

TestFlight Internal Only 是由上傳方式決定的限制：這類建置版本只能加入內部群組，不能用於外部測試，也不能向正式使用者發行。如果之後需要外部測試或正式發行，必須用適當的方式上傳新的建置版本，不能只是將原本的建置版本換到另一個群組。[5][6]

但反過來說，一般建置版本先加入內部群組，不會因此自動變成「僅限內部測試」的建置版本。不要把「目前提供給內部成員試用」和「這次上傳的內容只能供內部使用」混為一談。

如果你在 AirBuild 開發 App

你可以請 AirBuild 協助準備可分發的建置版本、簽署、上傳，以及設定測試群組和邀請。先說清楚你要「發布到 TestFlight」，以及對象是團隊成員還是外部朋友；接著連結或確認有權限的 Apple 開發者團隊，並確認測試說明、接收回饋的電子郵件地址、審查聯絡人，以及是否開放公開連結。

Apple 的處理、外部審查、人數和有效期限規則仍然適用。交付時應確認具體的版本與建置編號、哪個群組已經可以使用，以及外部審查是否仍在等待中。AirBuild 協助完成流程，不等於能繞過 Apple 審查，也不代表在模擬器上驗證，就已涵蓋所有實體裝置的行為。

以上是 AirBuild 工作方式的說明，不是 Apple 強制要求使用某個工具；沒有 Mac 上的本機 Xcode，也不表示你必須學會所有封裝細節，才能與他人協作發布。

7. 如何新增內部測試人員？留意這裡有 2 次邀請

適用對象：你自己，以及確實需要存取 App 後台的協作成員。

第 1 次：讓對方成為有權限的後台使用者

由帳號持有人（Account Holder）、管理員（Admin）或 App 管理員（App Manager）角色新增使用者：

1. 進入 使用者與存取權限（Users and Access）→ 人員（People）。
2. 點選「+」，填寫姓名和電子郵件地址。
3. 指派適當的角色；如果角色允許限制 App 範圍，就只授予需要的 App 權限。不要一律給管理員權限。管理員、財務角色，以及取得報告或憑證等額外資源存取權的使用者，無法將存取範圍限制在個別 App，設定權限前要先確認清楚。[9]
4. 寄出邀請，讓對方接受並啟用後台存取資格。

Apple 目前說明，這種後台使用者邀請會在 3 天後到期，到期後可以重新寄送。它不是接下來的 TestFlight 邀請，更不是建置版本的 90 天期限。[9]

如果對方原本就有符合資格的角色和該 App 的權限，可以略過這個步驟。

第 2 次：將人員和建置版本加入內部測試群組

1. 進入 App → 你的 App → TestFlight。
2. 點選 內部測試（Internal Testing）旁的「+」，建立群組，例如「團隊」。
3. 開啟群組，選擇 邀請測試人員（Invite Testers），或測試人員列表旁的「+」。
4. 勾選符合資格的後台成員，加入群組。
5. 點選 新增建置版本（Add Builds），選擇已處理完成、可供測試的建置版本。
6. 填寫 測試重點（What to Test）並加入。
7. 請對方在裝置上安裝 TestFlight，接受測試邀請，再安裝 App。[5]

不是「名單裡有人」就算完成。群組還要有可用的建置版本，對方也必須實際接受邀請並安裝。

找不到要邀請的人？先檢查對方是否已接受後台邀請、角色是否符合資格，以及是否有這款 App 的存取權限，不要立刻重複上傳 App。

部分內部群組可以啟用自動分發，但不要假設所有來源的建置版本都會自動加入所有群組。Apple 目前的說明特別指出，Xcode Cloud 建立的建置版本，需要在 App Store Connect 中手動加入群組。[5]

8. 如何新增外部測試人員？

適用對象：朋友、客戶、早期使用者、社群測試人員。第一次把 App 分享給其他人時，通常比較適合使用這個方式。

先準備一個能接收建置版本的外部群組

由帳號持有人、管理員或 App 管理員角色操作：

1. 如果還沒有內部群組，先建立一個。Apple 目前的外部測試教學將「先建立內部群組」列為必要條件；這不表示必須先正式上架，也不表示外部測試人員必須先成為內部成員。[6]
2. 進入 App → 你的 App → TestFlight。
3. 在 測試資訊（Test Information）中填寫測試版描述、接收回饋的電子郵件地址，並補齊審查所需的聯絡資料。如果需要登入，請提供有效的審查存取方式與操作說明，確保相關伺服器可正常使用。不要拿真實使用者的私人資料當作示範資料。[6][8][14]
4. 點選 外部測試（External Testing）旁的「+」，建立群組，例如「搶先體驗」。
5. 進入群組，點選 新增建置版本，選擇平台、版本和具體的建置版本。
6. 填寫 測試重點，例如「新增一筆記錄，離開後重新開啟，確認記錄是否還在」，不要只寫「隨便試試」。
7. 視需要勾選 自動通知測試人員（Automatically notify testers）。
8. 依頁面狀態選擇提交審查或開始測試，等待所有必要的審查完成。
9. 透過電子郵件、公開連結，或同時使用這 2 種方式邀請測試人員。[6]

第 1 次通過後，是不是就都不用審查了？

不是。

首次提交外部測試的建置版本需要完整審查；同一版本的後續建置版本可能不需要完整審查，但不能保證之後永遠免審。Apple 也要求重大測試版更新在分發前提交測試版審查。[6][14]

審查所需時間不固定。不要向別人保證「上傳後幾分鐘一定能安裝」，或「24 小時內一定通過」。

如果新增建置版本時沒有勾選自動通知，核准後還要執行 通知測試人員（Notify Testers）：在 TestFlight 左側的 建置版本（Builds）下選擇平台和版本，再點選該建置版本狀態列中的通知入口。已核准、已分發和對方已安裝，是 3 件不同的事。[6]

方式 1：透過電子郵件邀請

開啟外部群組，點選 測試人員（Testers）旁的「+」。你可以輸入新測試人員的電子郵件地址、選擇現有的測試人員，或匯入名單。[6]

對方收到的是測試邀請，不會因此取得 App Store Connect 的管理權限。

方式 2：建立並分享公開連結

開啟外部群組的測試人員頁面，選擇 建立公開連結（Create Public Link）：

1. 選擇 對所有人開放（Open to Anyone），或 依條件篩選（Filter by Criteria）。
2. 視需要設定連結的招募人數上限，可設為 1–10,000 人，但仍受這款 App 的外部測試總人數上限約束。
3. 如果選擇篩選，請設定目標裝置和系統版本條件。
4. 確認後複製實際產生的連結，傳給朋友，或放到社群、電子郵件或網站上。[6]

連結通常以 https://testflight.apple.com/join/… 開頭。請複製 Apple 產生的真實連結，不要自行編造後面的代碼，也不要將 App Store Connect 管理頁面的網址當作安裝連結。

QR Code 也可以指向同一個連結，但它不是另一種分發方式，更不能繞過審查。

分享連結前，確認 4 件事

• 目標外部群組內有你想分享的建置版本。
• 必要的審查已通過，而且已開始分發。
• 建置版本尚未到期，且與目標裝置相容。
• 連結已啟用、有剩餘名額，而且篩選條件沒有排除目標使用者。[3][6]

連結能開啟，不代表新版本一定能安裝。舊的建置版本仍可使用，也不代表最新的建置版本已分發給這個群組。

公開連結可以被繼續轉傳，並不是保密名單。如果只想邀請指定的幾個人，建議優先使用電子郵件邀請，並在 App 自己的帳號權限中做好存取控管。

透過公開連結加入的人，其姓名和電子郵件地址預設不會顯示在 TestFlight 測試名單中，但安裝日期、使用階段和當機等資訊仍然可見。對方主動提交回饋時，也可能提供電子郵件地址。這不代表對 Apple 或 App 本身的登入系統完全匿名。[3][6]

日後更新建置版本時，通常可以沿用同一個外部群組的連結，不必每次重新招募所有人。你也可以在 管理（Manage）中修改篩選條件、人數限制，或停用連結。停用連結只是關閉新加入的入口，不等於刪除已安裝的 App、註銷 App 帳號，或清除伺服器資料。[6]

9. 測試人員如何安裝、更新、回報問題和退出？

收到邀請後，請在要用來測試的 iPhone 或 iPad 上操作：

1. 從 App Store 安裝 Apple 官方的 TestFlight。
2. 開啟邀請郵件或公開連結。
3. 依頁面提示進入 TestFlight，選擇 接受（Accept），再點選 安裝（Install）。
4. 閱讀測試重點，然後開始使用。
5. 有新的建置版本時，可在 TestFlight 更新，也可以啟用自動更新。已加入測試的人可能直接看到 更新（Update）或 開啟（Open）。[3]

一般外部測試不需要開發者的密碼，不需要後台角色，也不需要先建立專用的沙箱帳號。

手機已經有正式版，會同時安裝 2 份嗎？

通常不會。同一款 App 的 TestFlight 測試版會取代裝置上的 App Store 版本。[3]

因此，請先備份或匯出重要資料。測試版可能會改變資料格式，舊版本不一定能讀取新版本寫入的資料；不要認為切換版本就一定不會遺失資料。

如果開發者仍提供其他有效的建置版本，你可以透過 先前的建置版本（Previous Builds）選擇。這不是永久保存所有歷史版本的下載庫。[3]

怎麼回報問題，開發者最容易看懂？

在 TestFlight 中開啟該 App 的頁面，點選 傳送測試版回饋（Send Beta Feedback）。在支援的系統上，也可以在測試 App 中拍攝螢幕截圖後傳送回饋；當機後可能會出現分享補充資訊的提示。[3]

比起「不能用」，這樣寫更有幫助：

我使用［裝置型號］、［系統版本］，App 是［版本與建置編號］。開啟設定後切換語言，再返回首頁，預期文字會一起切換，但首頁實際上仍顯示原本的語言。重複試了 2 次都遇到同樣的情況，附上螢幕截圖。

不要把密碼、付款資訊或其他人的隱私資料直接截進圖片裡。透過 TestFlight 提交的回饋也會提供給 Apple；App 自行提供的意見回饋功能則是另一個管道。[3]

不想繼續測試，該怎麼辦？

進入 TestFlight 中該 App 的資訊頁面，選擇 停止測試（Stop Testing）。如果已有正式版本，可以再到 App Store 下載或購買。只有測試版、尚未正式發行的 App，不一定有正式版可以換回。[3]

停止測試不等於刪除你在 App 中註冊的帳號；帳號和雲端資料需依 App 自己的規則處理。

10. 在 TestFlight 裡付款，會真的扣款嗎？

從 TestFlight 安裝的 App，透過 Apple App 內購買進行的測試交易會使用沙箱，不會實際扣款。這也包括透過 StoreKit 測試訂閱。[3][10]

「沙箱」可以理解為購買流程的演練環境：App 可以讀取商品資訊、發起測試購買、回復購買項目、處理交易通知，但不會因此產生真實的銷售收入。[10]

這裡最容易誤會的，是沙箱的適用範圍。

不扣款，不代表正式版永久免費

Apple 明確說明，測試期間的 App 內購買不會以購買記錄的形式轉移到 App Store 正式版。不要向測試人員承諾「現在點一次，正式上線後就永久享有會員資格」。[3]

如果開發者另外決定贈送 App 帳號權益，那是自己的業務安排，不是 TestFlight 自動提供的規則。

測試訂閱的時間，也不等於實際計費時間

針對自動續訂訂閱，Apple 目前的 TestFlight 測試人員說明是：無論原本的訂閱週期長短，測試時都按每天續訂，1 週內最多續訂 6 次。使用沙箱帳號的進階控制項還可以調整續訂速率；不要把其他沙箱情境的「5 分鐘」、「12 次」等參數，直接套用到一般 TestFlight 測試。[3][10]

這些加速規則是為了測試續訂和到期，不能當作正式使用者的帳單週期。

只有 Apple 購買管道會自動使用沙箱，不是整款 App

TestFlight App 仍然可能：

• 連線到正式伺服器，修改真實記錄；
• 寄出真實的電子郵件或訊息；
• 刪除真實帳號或資料；
• 開啟實際收款的網頁；
• 使用 Apple App 內購買以外的付款方式。

網頁付款、Apple Pay 和 StoreKit App 內購買是不同的事。不能因為 App 來自 TestFlight，就認為網頁結帳或現實中的業務操作一定不會花到真錢。開發者需要另外設定測試資料、伺服器和其他付款環境。[10]；App 系統範圍說明

每位測試人員都要建立沙箱帳號嗎？

不需要。一般 TestFlight 安裝和購買測試可以使用平常的 Apple 帳號。[10]

只有需要清除購買記錄、調整進階測試設定等控制功能時，開發者才需要依 Apple 文件設定 Sandbox Apple Account。進階步驟可能需要登出「媒體與購買項目」，影響裝置上已購內容的存取；這不是一般測試人員安裝前必須做的事，更不應該隨意要求別人登出整台裝置的 iCloud。Apple 建議考慮使用專用的測試裝置。[10]

如果畫面顯示購買成功，但 App 沒有解鎖功能，仍應向開發者回報。商品設定、交易驗證、權益授予、回復購買項目和續訂處理，都需要正確實作。沙箱購買成功，不代表正式付款、收入入帳和所有訂閱邏輯都正確。

11. TestFlight 有哪些限制？

表格較寬時可左右滑動；使用鍵盤的讀者可先將焦點移至表格，再使用方向鍵。

90 天到期後，重新寄出邀請有用嗎？

沒有。期限屬於建置版本，不屬於個別測試人員。較晚加入的人不會重新獲得完整的 90 天。到期後，測試版就無法繼續開啟，開發者需要提供新的有效建置版本。[3]

如果希望測試不中斷，應在舊建置版本到期前上傳、分發新的建置版本，並提醒大家更新。新的建置版本有自己的期限，不會延長舊建置版本的使用期限。

可以長期靠 TestFlight 販售 App 或測試名額嗎？

不要把它當成繞過正式發行的銷售管道。

Apple 審查指南 2.2 要求測試 App 遵守審查規則，並以公開發行為目的；也禁止以任何形式的對價交換 TestFlight 測試版分發，包括作為群眾募資的回饋。簡單來說，不能把「付費加入群組才能取得測試版」當作正常的 TestFlight 分發方式。[14]

12. 常見問題：別人為什麼無法安裝？

表格較寬時可左右滑動；使用鍵盤的讀者可先將焦點移至表格，再使用方向鍵。

這些是排查方向，不是看到一句錯誤訊息，就能判定根本原因。[3][5][6][11]

特別提醒：後台綠色的「測試中（Testing）」狀態，也可能只是內部群組正在使用。要判斷外部使用者能否安裝，必須核對目標外部群組、具體的建置版本，以及該群組的可用狀態。[11]

「準備提交（Ready to Submit）」、「等待審查（Waiting for Review）」、「測試版審查中（In Beta Review）」和「準備測試（Ready to Test）」也不是同一個階段。尤其是準備測試，仍可能需要新增測試人員或完成手動通知。[11]

13. 開發者要去哪裡看回饋，如何繼續發布新版？

進入 App → 你的 App → TestFlight → 回饋（Feedback），可以查看 螢幕截圖（Screenshots）與 當機（Crashes），並依版本、裝置等條件篩選。能否從 App 內提交回饋，也會受到群組設定影響。[12]

先處理能重現的問題，再進行下一輪：

1. 修正問題，使用新的建置編號封裝並上傳。
2. 等待處理，完成必要的合規程序。
3. 將新的建置版本加入目標群組，完成必要的外部審查。
4. 更新測試重點，依設定通知測試人員。
5. 請目標群組中的人確認實際安裝的版本與建置編號，並重新測試原本的問題。

上傳記錄、群組名單和審查核准都很重要，但最後仍須確認：目標使用者確實安裝了目標建置版本。

只提供一張內部測試的螢幕截圖，不能證明所有外部使用者都能安裝；能在模擬器中執行，也不能取代裝置上的實際安裝結果。

14. 如何結束測試，或正式上架？

先確認你想停止的是哪一件事：

• 不再招募新使用者：停用外部群組的公開邀請連結。
• 調整誰能收到哪些建置版本：管理測試人員、群組和建置版本分配。
• 停止某個建置版本的新安裝：進入建置版本詳細資訊，選擇 使建置版本到期（Expire Build）。不要把這個操作理解成遠端刪除所有手機上的 App，或清除雲端帳號。[6][13]
• 正式發行：準備 App Store 正式版本所需的資料，選擇符合資格的建置版本，另外提交正式審查。[1][2]

透過一般 TestFlight 上傳且符合資格的建置版本，可以選來提交正式審查；不一定只因為要上架，就必須重新封裝。但如果實際程式碼有變更，就需要上傳新的建置版本；「僅限內部測試」的上傳也不能用於正式發行。[2][5]

通過 TestFlight 審查，不會自動發布到 App Store。反過來說，正式版上架也不會自動結束仍有效的測試版；測試結束與使用者切換版本，都需要分別安排。[1]

15. 給第 1 批測試人員的邀請，可以直接這樣寫

想請你幫忙試用［App 名稱］的早期版本。

請先從 App Store 安裝 Apple 官方的 TestFlight，再用 iPhone 開啟［實際邀請連結］，接受邀請並安裝。

這一輪想請你重點測試：［1 到 2 個具體任務］。支援的裝置和系統：［實際要求］。

這是測試版，可能有問題，重要資料請先備份。如果遇到異常，可以使用 TestFlight 的「傳送測試版回饋」，告訴我你做了什麼、預期會怎樣，以及實際發生了什麼，最好附上螢幕截圖和版本號碼。

請把方括號替換成實際資訊。確認目標外部群組中的建置版本確實可以安裝後，再傳送邀請；不要先大量傳送還在等待審查的連結，卻告訴大家已經可以使用。

發布前，最後檢查這 10 項

• □ 我依帳號權限選擇了內部或外部測試，沒有為了方便而授予過多權限。
• □ 目標建置版本已處理完成，沒有尚未解決的分發障礙。
• □ 目標群組確實包含這個建置版本。
• □ 必要的外部審查已通過，需要的通知也已寄出。
• □ 我已檢查採用的邀請方式：電子郵件邀請寄給了正確的人；如果使用公開連結，它已啟用且仍有名額。目標裝置和系統也符合要求。
• □ 測試描述、接收回饋的電子郵件地址和測試重點都確實且有用。
• □ 測試人員知道這是測試版，也知道它可能取代正式版。
• □ 我已分清楚沙箱購買與真實伺服器、網頁付款和實際操作。
• □ 我已查看建置版本的到期時間，並安排後續更新。
• □ 目標使用者中，已有人確認實際安裝了目標建置版本，而不只是開啟邀請網頁。

第一次把 App 發布出去，真正的終點不是「上傳完成」，而是對的人安裝了對的版本，知道該測試什麼，也知道如何把問題回報給你。

資料來源與延伸閱讀

以下資料於 2026 年 9 月 17 日核實。歷史事件採用當時的報導或 Apple 當年的公告；現行規則則以 Apple 官方說明為主。操作介面可能隨語言和版本而變動。