App Store Connect App Transfer後はどうパッケージ化する？2026年引き継ぎチェックリスト

App Store Connect App Transfer後のビルドでは、旧チームの署名や公開用認証情報をそのまま使わず、受け手側でBundle IDとCapabilityを確認してから新しい署名・APNs・アップロード経路を構築します。今週は旧環境をすぐ停止せず、実際のArchiveとTestFlight確認が終わるまで短期間の二重運用にしてください。

このチェックリストは、Appを譲渡する開発者、Appを受け取る独立開発者、リモート Macや自動ビルド環境を管理する小規模チーム、そして最終リリースを承認する担当者向けです。ソースコードだけを受け渡して、公開できる状態まで移ったと判断してしまうケースを防ぎます。

Appleの公式説明では、App Transfer後もAppのBundle IDは保持され、関連するApp IDは受け手へ移ります。一方、Appの所有権が変わったことは、ソースコード、秘密鍵、CIの認証情報、リモート Mac内のユーザー環境まで自動で移ることを意味しません。

App Transferの公式概要と転送条件の一覧を基準に、次の四つを別々に判定します。

• App Store Connect上でAppと過去のビルドが受け手のチームから見えること。
• 受け手のTeamとBundle IDで署名できること。
• Archive成功後にIPAを書き出し、App Store Connectへアップロードできること。
• TestFlightで実際にインストールし、プッシュ通知やログインなどの主要機能を確認できること。

XcodeにArchiveが表示された時点は、まだ完全な引き継ぎ完了ではありません。コンパイル成功、アップロード成功、処理完了、TestFlightでの利用可能状態は、それぞれ別の検査項目です。

譲渡側の責任は、Appの表示情報だけでなく、受け手が同じリリース工程を再現できる材料を残すことです。App Transfer開始前のApple公式手順でアカウント条件と契約状態を確認し、未処理の審査や契約上の保留がないかを確認します。

次の項目を、秘密情報そのものと手順書に分けて保存してください。

• リポジトリ、依存関係、Xcodeプロジェクト、ビルドスクリプト。
• Bundle ID、entitlements、Capabilities、Associated Domains、Keychain Sharing。
• 過去に公開したArchive、IPA、dSYM、バージョン情報、切り戻し用の成果物。
• APNsの証明書またはキー、プッシュサーバーの接続先、更新手順。
• App Store Connect API、Webhook、CI Runner、環境変数の名前と用途。
• iCloud、Sign in with Apple、Apple Pay、Game Center、Mac Catalystの利用有無。

Appleは、転送後のコードとビルド資産を当事者間で直接引き渡すよう案内しています。Apple Pay Merchant IDはAppの転送に含まれないため、Apple Payを使うAppは通常の署名確認だけで完了したと扱わないでください。

注意：元のKeychain全体や旧チームの秘密鍵を、受け手のユーザーアカウントへコピーする方法は、短期的に成功しても責任範囲が不明確になります。新しい認証情報を発行できる状態を優先し、旧秘密鍵は共有せず、必要な証拠だけを安全に保管します。

受け手は、App Store ConnectにAppが表示されることだけでなく、App IDとBundle ID、Capabilities、過去のビルド、権限範囲を確認します。Appの記録、App ID、売上や分析情報、ユーザーデータの扱いは同じものではないため、転送後に見える範囲を管理画面で個別に確認します。

署名の再構築は、次の順番で行います。

1. 受け手のApple DeveloperチームでBundle IDの状態とCapabilitiesを確認します。
2. XcodeプロジェクトのTeam、Bundle Identifier、entitlementsを新しいチームに合わせます。
3. 受け手のDistribution証明書とProvisioning Profileを作成します。Provisioning Profileの公式手順では、App ID、証明書、端末や配布方式の組み合わせを確認して作成します。
4. Keychainアクセス、Associated Domains、iCloudコンテナ、プッシュ設定など、実際の機能に関係するCapabilityを個別に検証します。
5. 旧証明書をすぐに失効させず、受け手の新しい証明書で同一ソースをArchiveできることを確認します。

「すべての証明書が自動的に移る」というコミュニティ上の経験談を、Appleの確定仕様として扱ってはいけません。旧プッシュ証明書が有効期間内に使える場合でも、今後の運用では受け手側の証明書またはキーへ切り替えます。APNsのTLS構成はAppleのAPNs証明書に関する説明に照らして確認します。

Sign in with Appleを利用する場合は、Appの転送だけでなくユーザー移行の処理も対象になります。Sign in with Appleユーザー移行の技術資料を確認し、ログイン識別子の扱いを通常の署名変更と混同しないようにします。

リモート Macでは、旧担当者のホームディレクトリを引き継ぐのではなく、受け手のアカウントと認証情報を分離した環境を作ります。Xcode、Swift Package、CocoaPodsなどの依存関係、署名の入口、ログの保存場所、IPAの出力先を明示し、GUI操作とSSHまたはCI操作の両方を確認します。

受け入れ側の検査は、次の順に進めます。

• Xcodeでプロジェクトを開き、警告と署名対象を確認する。
• GUIからArchiveを作成し、Bundle IDとentitlementsを成果物で確認する。
• IPAを受け手の署名で書き出し、出力ファイルとログを保存する。
• SSHまたはCIから同じビルドを実行し、ユーザー依存のパスやKeychain参照がないか調べる。
• App Store Connectへアップロードし、Appleのビルド状態説明で処理結果を確認する。
• TestFlightでインストールし、プッシュ通知、ログイン、内課金、クラウド機能などを実機で確認する。

アカウント名、Team ID、Key ID、Bundle ID、ファイルパス、ログ、キーは、手順書では必ず<TEAM_ID>、<BUNDLE_ID>、<KEY_ID>のようなプレースホルダーに置き換えます。実際の秘密情報をブログ、チケット、共有チャットへ貼り付けないでください。

App Transfer後のビルドで、旧環境を残すか、新環境へ切り替えるかは、次の条件で判断できます。

• 旧環境を短期間残す
  受け手側のArchiveが未確認、APNs切り替えが未完了、またはTestFlightで主要機能を確認できていない場合です。旧環境は復旧用に限定し、新規の恒常運用先にはしません。

• 新しいリモート Macへ切り替える
  受け手の署名でArchiveとIPA書き出しが成功し、App Store Connectのアップロード処理とTestFlightインストールまで確認できた場合です。ログ、成果物、実行者を追跡できることも条件にします。

• 正式リリースを保留する
  Bundle IDは合っていても、APNs、Sign in with Apple、Apple Pay、iCloud、内課金などのオンライン機能が確認できない場合です。コンパイル成功だけで本番公開へ進めません。

JEXCLOUDのリモート Mac環境を候補にする場合も、常駐ビルドが必要か、root権限を分離したいか、既存CIからSSHで接続するかを先に決めてください。必要な期間だけ環境を用意する場合は、Macレンタルの利用プランと、ログ・認証情報を誰が管理するかを照合します。

App Transfer後も以前のXcodeビルドマシンは使えますか？

短い移行期間の確認用として使える場合はありますが、旧チームのKeychain、署名証明書、API Keyをそのまま新しい運用環境にするのは避けます。受け手側で新しい署名経路を構築し、同じソースからArchive、IPA書き出し、アップロード、TestFlightインストールまで確認してから旧マシンを停止します。

App転送後、Apple Distribution証明書とProvisioning Profileはどう扱いますか？

転送後にすべての証明書やプロファイルが同じ状態で受け手へ移るとは判断しません。旧証明書が有効期間内に使える場合でも、それは暫定確認に限定し、受け手のチームでDistribution証明書とProvisioning Profileを作り直し、Bundle IDとCapabilityの組み合わせを確認します。

App Store Connectの転送後、APNsの設定は再構成が必要ですか？

必要です。旧プッシュ証明書が有効期間内に動作する可能性はありますが、受け手は今後の運用に使う証明書またはキーを新しく用意し、プッシュサーバーの認証情報を更新します。証明書の差し替え前に、本番通知を壊さない検証用経路と切り戻し手順を残しておきます。

Appを受け取った後、リモート Macで最初のArchiveを行う手順は？

まずXcodeと依存関係を固定し、受け手のTeam、Bundle ID、署名方式をプロジェクトへ反映します。次に新しい証明書とProvisioning Profileを用意し、GUIのArchiveだけでなくSSHまたはCIからの実行、IPA書き出し、App Store Connectへのアップロード、TestFlightでのインストールまで順に確認します。

App Transfer前にXcodeとApp Store Connectの何を保存すべきですか？

ソースコードだけでなく、ビルドスクリプト、依存関係の固定情報、entitlements、Capability一覧、既存のArchive、dSYM、署名方式、プッシュ設定、API連携、Webhook、環境変数の一覧を整理します。秘密鍵やトークンを共有フォルダーへ無造作に置かず、受け手が再発行できる情報と、引き継ぎ証拠として保管する情報を分けます。

最終リリース担当者は、次のチェックをすべて満たした時点で切り替えを承認します。

• [ ] 譲渡側がソース、スクリプト、成果物、依存関係を整理した。
• [ ] 受け手がApp Store ConnectのApp、Bundle ID、過去ビルドを確認した。
• [ ] 受け手の証明書、Provisioning Profile、Capabilitiesを再構成した。
• [ ] APNs、Sign in with Apple、Apple Pay、iCloudなど特殊機能を個別に確認した。
• [ ] リモート MacでGUI、SSHまたはCIのArchiveを確認した。
• [ ] IPAを書き出し、App Store Connectへのアップロード処理を確認した。
• [ ] TestFlightから実機へインストールし、主要機能を確認した。
• [ ] ログ、成果物、設定変更、実行者を追跡できる状態にした。
• [ ] 旧Runner、Webhook、API Key、アカウント権限を停止する判断を記録した。

現在の方法が、旧担当者のMacを共有し続ける形や、古いKeychainに依存する形なら、担当者が離れた時点で再現性が失われ、証明書の更新や障害対応も属人化します。物理Macを新たに購入して常時稼働させる方法もありますが、初期費用、保守、電源、回線、遠隔復旧の負担が残ります。

短期間の移行検証や、受け手専用のビルド環境をすぐ用意したい場合は、JEXCLOUDのリモート Macを候補にすると、環境を分離しながらArchive、署名、TestFlightの確認を進められます。ただし、長期にわたる高頻度の大規模ビルドや物理ポートが必要な作業では、自社管理のMacが適する場合もあるため、必要な稼働期間と復旧責任を比較して選んでください。