App Store Connect 應用程式轉讓 2026：交接前後如何驗收？

App Store Connect 應用程式轉讓 2026：交接前後如何驗收？

Apple 官方將應用程式轉讓拆分為資格、發起與接受等不同環節，而不是一個完成後所有服務都自動搬家的按鈕。App Store Connect 應用程式轉讓概述與資格文件均顯示，正確做法是先核准轉讓條件，再凍結高風險變更，接著交接商店資料、程式資產與關鍵服務，最後由接收方驗證權限、登入、訂閱、推送和發布能力。

獲勝者：分層驗收方案。 如果交易包含已上架 App、訂閱、Apple 登入或持續發布，不能只以「轉讓已接受」作為交割完成條件。遠端 Mac 可以用來建立隔離、可留證的 macOS 工作環境，但不能取代帳戶持有人權限，也不能繞過 Apple 的官方流程。

這篇文章適合三類人員：

  • 準備出售、收購或接管海外 App 的業務負責人，需要界定商店所有權與完整營運資產的差異。
  • 負責 App Store Connect、訂閱、登入及商店素材交接的營運人員，需要逐項簽署驗收結果。
  • 為新團隊準備獨立 macOS 環境、權限與資料歸檔的專案經理或 IT 協作人員。

商店所有權轉讓，和完整業務交接並不是同一件事

一個 App 的交接至少包含兩層：

  • 平台層：App Store Connect 中的 App 記錄、產品頁、版本、商店地區、評論與評分等。
  • 業務層：程式碼儲存庫、建置流程、伺服器、網域、客服信箱、分析工具、付款服務、推送系統及第三方帳戶。

Apple 平台上的轉讓成功，只能證明平台層的某些權利已依官方流程移交。Git 儲存庫、伺服器環境、網域註冊商和客服渠道，仍要按照雙方合約另行交割。

轉讓期間 App 可能仍可在商店提供下載，但這不代表以下服務不需要處理：

  • 自動續期訂閱的收據驗證與收入報告。
  • Sign in with Apple 使用者識別資料。
  • APNs 推送憑證、伺服器金鑰和通知佇列。
  • iCloud、Apple Pay、Wallet 或鑰匙圈共享等實際啟用的能力。
  • App 內購買項目、測試人員與後續版本發布權限。

交割開始前，雙方應先寫下三項內容：轉讓方帳戶持有人、接收方帳戶持有人，以及什麼情況算作停止交易或暫停上線。不要以營運人員的口頭確認取代帳戶持有人的正式判定。

第一個場景：資格合格，才值得安排轉讓窗口

Apple 的轉讓條件會受到帳戶協議、App 狀態、預購、審核流程、App 內購買項目和其他關聯設定影響。條件不是「雙方都同意」這麼簡單，應以Apple 官方轉讓條件在當日的內容為準。

資格檢查可按以下方式執行：

  1. 由轉讓方帳戶持有人登入 App Store Connect，記錄帳戶協議與付款、稅務相關狀態。
  2. 確認目標 App 的目前發布狀態，列出進行中的審核、預購、版本提交與 App 內購買項目。
  3. 由接收方帳戶持有人確認其 Apple Developer Program 帳戶可接收 App，並準備組織資料與聯絡資料。
  4. 將官方條件逐項標記為「符合」、「待處理」或「不適用」。
  5. 對協議頁面、資格結果及任何阻斷提示製作脫敏截圖，不展示團隊 ID、真實帳戶、憑證或密鑰。
  6. 只有當雙方帳戶持有人確認沒有未解決阻斷項目，才安排發起與接受的交接窗口。

這裡要區分兩種問題。若只是協議尚未接受、某項狀態尚未結束，通常屬於「暫時不符合」。若 App 類型或關聯配置不在 Apple 當前支援範圍，則可能是「目前無法轉讓」。反覆提交不會替代資格判斷。

第二個場景：商店資料可交付，不代表歷史資產全部共享

轉讓前，轉讓方應把商店資料整理成可核對的檔案包。至少包括：

  • App 名稱、描述、關鍵字、支援網址、行銷網址與私隱政策網址。
  • 各地區本地化文字、圖示、螢幕截圖及 App 預覽影片。
  • 定價、銷售地區、App 內購買項目與訂閱產品清單。
  • 歷史版本、發布記錄、審核溝通及拒審修正紀錄。
  • 銷售、下載、退款與訂閱相關報告，並註明資料截止日期。
  • 程式碼儲存庫、建置腳本、環境變數清單和第三方服務對照表。

每份檔案都要附上四個欄位：儲存位置、資料截止時間、可存取人員、雙方確認狀態。這比把大量檔案丟進一個共享資料夾更容易追查遺漏。

接收方應在接受轉讓前準備新的支援網址、聯絡信箱、私隱政策網址及內部客服責任人。若等到接受完成後才尋找這些資料，商店頁面、客服回覆和合規文件可能出現短暫斷層。

評論、評分、Bundle ID 或歷史商店記錄的處理，必須逐項對照 Apple 官方轉讓概述，不能用團隊過往案例推定本次結果。對於未被官方明確列為自動移交的資料，應暫時視為需要另行歸檔。

第三個場景：訂閱與登入要驗證服務鏈，而不是只看 App 頁面

自動續期訂閱

先把「商店中的產品」和「伺服器中的驗證流程」分開檢查。接收方需要知道：

  • 哪些訂閱產品仍在銷售。
  • 交易收據由哪個系統驗證。
  • 伺服器使用哪些密鑰、憑證或環境設定。
  • 使用者恢復購買時，帳戶如何對應。
  • 轉讓期間出現失敗時，由哪一方負責回滾或客服補救。

Apple 的轉讓文件會針對訂閱、App 內購買及相關能力說明處理方式；若 App 實際啟用了這些功能，就應逐項提供配置證據，而不是只截取 App Store Connect 首頁。

Sign in with Apple

Sign in with Apple 的風險在於：App 商店所有權變更，並不等於舊使用者資料已在新團隊伺服器完成映射。Apple 提供了Sign in with Apple App 與使用者遷移文件，技術人員應依該文件處理使用者識別資料。

驗收時至少要使用脫敏測試帳戶確認：

  1. 新使用者能否完成登入。
  2. 舊使用者能否對應原有業務帳戶。
  3. 私隱轉寄電郵是否仍能送達客服或交易通知。
  4. 登出後重新登入，是否建立重複帳戶。
  5. 轉讓後的伺服器日誌是否能區分失敗原因。

推送與其他 Apple 能力

如果 App 使用 APNs、Apple Pay、iCloud、Wallet 或鑰匙圈共享，應先在資產清單中列出實際啟用項目，再為每一項指定技術負責人。沒有使用的能力不必為了「完整」而增加交接工作，但已使用的能力不能因為商店頁面仍可開啟就視為正常。

第四個場景：團隊權限交接，應採最小權限而非共享帳戶

Apple 帳戶角色的權限範圍不同，應參照Apple 官方帳戶角色說明安排人員。推薦的責任分工如下：

  • 帳戶持有人：核准轉讓、接受轉讓及處理帳戶層級協議。
  • 營運人員：核對產品頁、本地化內容、價格、評論與發布記錄。
  • 技術人員：負責建置、憑證、推送、登入、訂閱和伺服器驗證。
  • 財務人員：確認報告、付款、稅務與收入交割範圍。
  • 專案經理：維護交割清單、責任人、證據位置和整改期限。

禁止共享 Apple Account 密碼、雙重驗證碼或私密金鑰。接收方應按Apple 官方接受轉讓流程由自己的帳戶持有人操作；轉讓方也不應要求新團隊交出個人登入資料。

遠端 Mac 在這裡的價值是環境隔離和留證，而非取得額外平台權限。雙方可以使用獨立 macOS 使用者、獨立瀏覽器工作階段和指定專案資料夾，分開保存脫敏截圖、核對檔案與交接紀錄。但實際登入仍必須由獲授權人員完成。

如果團隊需要多人分時區協作，可先閱讀遠端 Mac 多人協作與權限隔離指南，再決定是否需要按專案分開工作環境。這能減少瀏覽器工作階段混用、檔案誤傳和帳戶誤操作，但不會改變 Apple 的角色規則。

用條件分支決定：通過、限期整改，還是暫停交割

驗收不應只有「完成／未完成」兩個狀態。可按以下條件作出決策：

  • 若 Apple 官方資格已核對，雙方帳戶持有人完成操作，商店資料與程式資產均有位置和責任人，登入、訂閱、推送及發布回歸全部通過，則判定為通過交割。
  • 若 App 可正常展示和下載，但某項非核心資料仍缺少歸檔，且不影響登入、付費或發布，則判定為限期整改；清單必須寫明負責人與完成條件。
  • 若 轉讓資格尚未確認、帳戶協議存在阻斷、訂閱驗證失敗或舊使用者無法登入，則回退至暫停交割，不得只因商店頁面仍可見而放行。
  • 若 接收方沒有後續建置與發布能力，或憑證、描述檔和推送配置無法確認，則先完成技術交接，再安排正式營運切換。
  • 若 轉讓方尚未確認 App 已從原帳戶移除，則不要撤銷原團隊的必要協作權限；但也不能繼續保留不必要的管理權限。

可用以下命令建立本地驗收目錄，避免把真實密鑰放入檔案名稱或截圖：

mkdir -p app-transfer/{eligibility,store-assets,services,permissions,regression}
touch app-transfer/README.md
printf "evidence_status=pending\n" > app-transfer/README.md

預期輸出：

evidence_status=pending

這個命令只負責整理證據位置，不會檢查 Apple 帳戶，也不會替代 App Store Connect 操作。完成後，README 應補上負責人、資料截止時間、證據連結和「通過／整改／暫停」判定。

轉讓後回歸：接收方要證明可以繼續營運

接收方完成接受後，應按照實際功能執行回歸，而不是只確認 App 出現在新帳戶中：

  1. 核對團隊成員與角色，移除不再需要的權限。
  2. 確認建置所需憑證、描述檔、簽署設定與發布流程。
  3. 開啟產品頁，檢查名稱、描述、本地化內容、支援網址和私隱政策網址。
  4. 下載目前版本，驗證更新流程與首次啟動。
  5. 以測試帳戶驗證登入、登出、帳戶恢復及私隱轉寄電郵。
  6. 以測試購買流程核對訂閱、恢復購買和伺服器驗證。
  7. 驗證推送通知、客服連結及 App 內重要外部服務。
  8. 確認 TestFlight 測試人員、測試版本和後續發布責任已交給新團隊。

Apple 官方發起轉讓說明可作為流程證據來源，但每個 App 的回歸範圍仍取決於實際啟用的服務。轉讓方確認 App 已從原帳戶移除後，才按交割協議回收人員、裝置、儲存庫和第三方服務存取權。

最終驗收證據可歸入五類：

  • 商店可見性。
  • 使用者服務連續性。
  • 後續發布能力。
  • 程式與業務資產歸屬。
  • 舊團隊權限回收。

常見交接疑問，應以官方條件逐項核對

FAQ 中的重點不是記住某個固定操作順序，而是確認本次 App 實際使用的能力。Apple 可能更新後台入口、角色限制或技術處理規則，因此正式交割前仍應重新查看官方文件。

若目前方案只靠個人電腦、共享瀏覽器和跨時區即時傳檔，常見缺點是環境容易混用、證據分散，且帳戶操作責任難以追蹤。若再加上臨時 VPN 或不固定的雲端桌面，連線品質、IP 來源和權限邊界也可能變成新的交割風險。

對需要長期穩定重負載、實體 USB 裝置或固定本地硬體的團隊，購買自有 Mac 仍可能更合適。若只是為了本次 App 轉讓、資料核對與轉讓後回歸，SFTPMAC 的遠端 Mac 可作為按專案隔離的臨時 macOS 工作環境；使用者可先查看美國節點遠端 Mac 方案，再按交割週期評估是否租用。它能改善環境與留證安排，但不會保證轉讓成功，也不會替帳戶持有人完成 Apple 流程。