App Store Connect App Transfer 後怎麼打包？2026 交接清單

結論：App Store Connect App Transfer 後打包，不要直接沿用原團隊的簽名與發布憑據。 本週先由接收方確認 Bundle ID、App ID 與 Capabilities，再在遠端 Mac 建立新的簽名、推送及上傳鏈路；轉讓前後保留短期雙軌環境，並以一次真實 Archive 和 TestFlight 上傳作為切換門檻。

這篇適合準備出售 App、整理交接資料的開發者，也適合剛接手專案、需要恢復發布能力的獨立開發者。若團隊維護遠端 Mac、CI Runner 或常駐打包機，本文可用來界定誰負責憑據、誰負責驗收，以及何時可以退役舊環境。

App Transfer 改變的是 App 在 Apple 生態系統中的歸屬，不等於原始碼、私鑰、CI 憑據、遠端 Mac 使用者目錄及外部服務已經完成轉移。Apple 的官方說明指出，App 轉讓涉及 Bundle ID、App ID、版本與建置資料等不同範圍；轉讓方仍須直接交接程式碼及建置資產，不能把 App Store Connect 頁面上的歷史建置當成完整備份。Apple App Transfer 概覽

轉讓方還應先核對 App 是否符合 Apple 的轉讓條件、帳號協議狀態、版本與審核狀態；這些條件應以Apple 官方轉讓條件及發起 App 轉讓說明為準，而不是依照社群對「所有資料都會跟著 App 走」的概括說法處理。

轉讓前的工作重點不是清理電腦，而是把另一個團隊需要的「可重建資訊」整理成文件與可驗證的交付物。

• [ ] 記錄 App Store Connect 中的 App、Bundle ID、App ID、主要版本及現有建置，並分開標示哪些是商店記錄、哪些是本機產物。
• [ ] 匯出專案使用的 Capabilities 清單，例如 Push Notifications、Associated Domains、Keychain Sharing、iCloud、Sign in with Apple 或 Mac Catalyst。
• [ ] 保存 Xcode 專案設定、依賴版本、鎖定檔、環境變數名稱、Export Options、建置腳本及 CI 設定；密鑰值不要直接寫入一般文件。
• [ ] 交接可追溯的 Archive、IPA、dSYM、隱私清單與回滾版本，並記錄產生它們的 Xcode 與建置參數。
• [ ] 列出 APNs、App Store Connect API、Webhook、內購、Apple Pay、iCloud 及其他外部服務的管理責任，標記需要接收方重新產生的項目。
• [ ] 說明遠端 Mac 的登入方式、專案路徑、Runner 名稱、日誌位置及失敗後的復原步驟，但不要把整個原團隊使用者目錄打包交付。

Apple 明確指出，Apple Pay Merchant ID 不會隨 App Transfer 一起轉移；因此，包含 Apple Pay 的 App 不能只靠重新產生 Distribution 憑證完成接管。Sign in with Apple 也有獨立的使用者遷移要求，應參考Apple 的 Sign in with Apple 轉讓技術說明，不要把登入使用者識別碼當成一般 App 資料處理。

提醒： 「舊機仍然可以打包」與「新團隊已經接管發布能力」是兩個不同判定。前者只代表某組本機資產尚未失效，後者還必須包括新團隊簽名、上傳認證、推送及 TestFlight 安裝驗證。

接收方接受轉讓後，先不要急著撤銷原團隊的所有資產。應先在 App Store Connect 確認 App 已出現在新團隊，並核對歷史建置、使用者角色、銷售與分析資料的可見範圍；App Store 記錄、App ID、Bundle ID、程式碼及外部服務並不是同一種資產。Apple 接受轉讓的官方步驟可作為帳號驗收起點。

接著按下列順序建立新鏈路：

1. 確認識別資料。 從新團隊帳號核對 App 的 Bundle ID、App ID、Team ID 及 Xcode 專案中的產品識別值，避免把測試 target 或另一個 App 的設定誤套進正式 target。
2. 重建能力映射。 逐項比對 Capabilities 與 entitlements，尤其是 Associated Domains、Keychain Sharing、iCloud、Push Notifications、Sign in with Apple、Game Center 及 Mac Catalyst。
3. 建立新簽名入口。 由接收團隊產生適用的 Apple Distribution 憑證與 Provisioning Profile，並限制私鑰只出現在需要簽名的環境。Apple 建立 App Store Connect Provisioning Profile 的文件說明了建立描述檔時需要對應 App ID 與簽名資產。
4. 更新推送服務。 舊推送憑證在原有效期內可能仍可運作，但不能因此跳過重建。接收方應建立新的 APNs 憑證或金鑰，更新推送伺服器的安全設定，並確認環境、topic 及裝置 Token 的使用方式。APNs TLS 憑證設定文件是核對推送入口的主要依據。
5. 替換上傳與 CI 憑據。 App Store Connect API Key、Issuer ID、Key ID、Webhook Secret 及 CI Secret 分開管理；文件中只保留 <TEAM_ID>、<KEY_ID>、<BUNDLE_ID> 等占位符，不要留下可重用的真實值。

遠端 Mac 的價值在於讓接收方重新產生可追溯的建置，而不是把原團隊的完整登入狀態搬到另一個人手上。若目前使用的是 JEXCLOUD 的遠端 Mac，應先依照遠端 Mac 使用入口確認登入方式與環境責任，再把專案、依賴及新憑據分層接入。

接管時可依序操作：

1. 固定工具鏈。 記錄可接受的 Xcode、SDK、Ruby、Bundler、CocoaPods 或 Swift Package 依賴版本；版本名稱是環境識別資料，不代表已完成發布驗收。
2. 建立乾淨工作目錄。 專案放在新的工作路徑，使用接收方的帳號與權限；不要直接複製原團隊的 ~/Library/Keychains 或整個使用者目錄。
3. 先做圖形介面 Archive。 在 Xcode 中選擇正確 Scheme 與 target，確認簽名團隊、Bundle ID、entitlements 及 Archive 內容。
4. 再做自動化 Archive。 透過 SSH、CI Runner 或 fastlane 執行同一專案，將 <PROJECT_PATH>、<SCHEME>、<BUNDLE_ID> 等值寫成占位符，並把完整日誌保存到受控位置。
5. 分開驗證 IPA 匯出與上傳。 Archive 成功不等於 IPA 匯出成功；IPA 匯出成功也不等於 App Store Connect 已接受。Apple 對建置上傳流程有獨立說明，可參考官方上傳建置文件。
6. 核對處理狀態。 上傳後等待 App Store Connect 顯示可用狀態，再檢查版本號、建置號、簽名與 TestFlight 安裝；Apple 的建置狀態說明應作為狀態判讀依據。

這裡要特別分開四個結果：編譯完成、Archive 建立、上傳成功、TestFlight 可安裝。最後還要測試推送、登入、內購、雲端同步、深層連結或 Apple Pay 等與能力設定相關的線上功能，否則只驗證 Xcode 的綠色成功訊息，仍可能在正式發布後失效。

App Transfer 完成後，原本的 Xcode 打包機還能繼續使用嗎？

可以短期保留，但不應視為新團隊的正式打包機。原環境可能仍持有有效的簽名或推送資產，然而它的 Keychain、CI 權限與上傳入口仍屬於原團隊。接收方完成新鏈路驗證前，舊機可作回退；完成後才按日誌、產物及權限清單退役。

App 轉讓後，Apple Distribution 憑證和 Provisioning Profile 怎樣處理？

不要把「App ID 轉移」理解為所有簽名資產自動轉移。接收方應重新檢查 Team ID、Bundle ID、Capabilities、entitlements 及 Profile，建立自己的 Distribution 簽名入口。舊資產只保留到並行驗證完成，私鑰不應透過共用壓縮檔或未加密聊天工具交付。

App Store Connect 轉讓後，APNs 是否需要重新設定？

需要重新安排推送設定。部分舊推送憑證可能在原有效期內繼續有效，但這只是過渡條件，不是長期方案。接收團隊要建立新的推送憑證或金鑰，更新後端保存位置，並以接收方簽名的 TestFlight 版本驗證通知註冊、送達及失敗回應。

接手 App 後，如何在遠端 Mac 做第一次 Archive？

先在新團隊確認 App、Bundle ID 與能力，再在遠端 Mac 安裝或選定可接受的 Xcode 與依賴。使用接收方的新憑據完成圖形介面 Archive，接著做 IPA 匯出與上傳；最後以 App Store Connect 的建置狀態和 TestFlight 安裝結果結案，不能只看本機 Archive 是否成功。

App Transfer 前應備份哪些 Xcode 和 App Store Connect 資料？

重點是讓接收方能重建，而不是備份一台電腦。應整理原始碼、依賴鎖定檔、Scheme、建置腳本、Export Options、歸檔與 dSYM、Capabilities、APNs、API、Webhook 及回滾紀錄。Apple Pay Merchant ID、登入使用者遷移和外部雲端服務則要另列交接責任，不要混入一般 App 資料清單。

正式切換前，轉讓方、接收方及遠端 Mac 維護者應各自簽署自己的完成條件：

• [ ] 轉讓方已交出可重建的原始碼、建置資產與風險清單，沒有把真實私鑰放在一般交接檔。
• [ ] 接收方已看到正確的 App Store Connect App、Bundle ID、App ID、歷史建置及必要權限。
• [ ] 新 Distribution 憑證、Provisioning Profile、entitlements 與 Team ID 已在遠端 Mac 驗證。
• [ ] 新 APNs 憑據已接入推送伺服器，測試版本的推送結果可追溯。
• [ ] 圖形介面 Archive、SSH 或 CI Archive、IPA 匯出及上傳均有日誌和產物。
• [ ] App Store Connect 已完成建置處理，TestFlight 可安裝，核心登入、推送、內購或雲端功能已實測。
• [ ] 新環境通過前，舊 Runner、Webhook、API Key 及簽名存取權沒有被提前撤銷。
• [ ] 新環境通過後，才撤銷不再需要的舊權限，並保留必要的交接證據。

若 Bundle ID 或能力設定未對齊，應暫緩正式發版；若新環境只差外部服務驗證，則維持雙軌並修正該服務；只有當新簽名、上傳、TestFlight 和核心線上功能都完成，才適合停用舊打包機。

對於需要常駐建置、完整 root 權限或獨立帳號環境的團隊，直接把舊 Mac 當作永久方案，通常會留下原團隊 Keychain、權限未清理、硬碟空間與維護責任不清等問題；臨時借用個人 Mac，則容易受到使用者登入狀態、版本漂移和人員離開影響。若只是需要一個可控的過渡建置環境，租用 JEXCLOUD 的遠端 Mac，會比把整套舊憑據長期留在私人電腦更容易界定責任；可先從遠端 Mac 方案按接管週期安排環境，待新發布鏈路穩定後，再決定是否保留長期租用。