How to Package After App Store Connect App Transfer? 2026 Handover Checklist

Apple’s App Transfer documentation confirms that the app keeps its Bundle ID while the associated App ID moves to the receiving team. That single rule does not make the old build machine a complete handover. For packaging after App Store Connect App Transfer, the receiving team should rebuild signing, push, and upload access, then complete a real Archive and TestFlight upload before retiring the old environment. Keep both environments available during that verification period.

Who should read this

Selling developers can use this checklist to prepare source code, signing assets, build files, and service access before the transfer. Buyers can use it to restore publishing under the new team. Small teams maintaining a remote Mac or CI runner can use it to define the handover, rollback, and shutdown boundaries.

An App Transfer changes ownership inside Apple’s systems. It does not automatically move every operational dependency around the app. Source code, private keys, CI variables, build scripts, archived artifacts, server-side credentials, and files stored on a remote Mac still require a separate handover.

Apple states that the Bundle ID is retained and that the associated App ID transfers to the recipient. However, the transfer rules vary by capability. Apple Pay Merchant ID, for example, does not follow the app transfer. Sign in with Apple also requires a dedicated migration process rather than an assumption that user identity handling will remain unchanged.

The seller should therefore create an inventory that separates these objects:

• App Store Connect app record
• Bundle ID and associated App ID
• Team ID and signing team
• Apple Distribution certificates
• Development certificates
• Provisioning Profiles
• APNs certificates or keys
• App Store Connect API keys
• Webhooks and server callbacks
• Source repository and dependency lockfiles
• Xcode project settings and build configurations
• Archives, exported IPA files, dSYM files, and release notes
• Remote Mac accounts, scripts, runners, and credential stores

The receiving developer should not treat access to the old Xcode project as proof that the app can still be released. The project may open successfully while export signing, push notifications, entitlements, or App Store Connect authentication still fail.

Apple’s App Transfer overview explains the objects and conditions that Apple handles. The handover document must cover everything outside that transfer scope.

Before starting the transfer, the seller should produce a release package that another team can restore without opening the original developer’s personal account.

First step: verify transfer eligibility

Check the app’s current status against Apple’s App Transfer criteria. Confirm that the app is not blocked by an unresolved agreement, incompatible review state, or another transfer condition. The seller should also document the current App Store version, build number, release state, and pending review activity.

Do not rely on a screenshot alone. Export the relevant records or write them into the handover document:

• Current version and build number
• Active release channel
• TestFlight groups and testers
• App Store Connect roles
• Current Bundle ID
• Enabled capabilities
• Current export method
• Last successful Archive and upload
• Known release blockers

The official transfer initiation procedure should be followed for the account action itself. The build handover is a separate workstream.

Second step: preserve the build inputs

The seller should deliver the project in a reproducible state, not only the source repository. Include the exact dependency declarations, scripts, environment variable names, build schemes, export options, and documentation for any generated files.

The package should identify where each item is stored without exposing credentials:

• Repository location: <REPOSITORY_URL>
• Production scheme: <PRODUCTION_SCHEME>
• Bundle ID: <BUNDLE_ID>
• Team ID: <OLD_TEAM_ID>
• Archive path: <ARCHIVE_PATH>
• Export options path: <EXPORT_OPTIONS_PATH>
• CI runner label: <RUNNER_LABEL>
• Secret name: <SECRET_NAME>

Never place a private key, API key, password, or token directly in an article, ticket, repository, or handover note. A reference such as <APP_STORE_CONNECT_KEY_ID> is useful; a real key is not.

Third step: record capability-specific dependencies

A normal app can have several capabilities that change the handover risk. The seller should mark each one as enabled, disabled, or requiring migration.

Pay special attention to:

• APNs production and development delivery
• Associated Domains
• Keychain Sharing
• iCloud containers
• Sign in with Apple
• Apple Pay
• Game Center
• Mac Catalyst
• Webhooks
• In-app purchases
• Background modes

Apple’s Sign in with Apple migration note should be treated as a separate operational task. A successful IPA export does not prove that existing users will authenticate correctly after the transfer.

Keep the old signing and upload environment available until the receiving team has produced an installable TestFlight build and verified the important online capabilities. Delete access only after the evidence is stored.

The receiving developer should first verify that the transferred app is visible in App Store Connect and that the expected historical builds, roles, and records are available. The app record, App ID, sales information, analytics visibility, user data, and service credentials should not be treated as one object.

Can the original Xcode build machine still be used after the transfer?

It may still open the project and may still build during a transition, but it should not be treated as the buyer’s final publishing environment. The old machine may contain the seller’s Team ID, old profiles, personal Keychain entries, expired API credentials, and CI secrets. The safe approach is to use it only for comparison or rollback while the receiving team creates a clean signing path.

The buyer should create or confirm the receiving team’s signing assets. Apple’s Provisioning Profile creation instructions provide the official account workflow. The exact profile type depends on the distribution method and the project’s current configuration.

The buyer’s acceptance checklist should include:

• The transferred Bundle ID appears under the receiving team.
• The required capabilities are enabled for the receiving App ID.
• The receiving Team ID is used by the project and export settings.
• A new distribution certificate or valid receiving-team signing method exists.
• A new Provisioning Profile matches the Bundle ID and capabilities.
• Keychain access groups match the intended application identifiers.
• iCloud containers and entitlements point to the expected resources.
• APNs server authentication is ready under the receiving team.
• App Store Connect upload authentication is owned by the receiving team.

Rebuild push delivery separately

Does APNs need to be configured again after an App Transfer?

The old push certificate may remain usable during its original validity period, but that is a transition condition, not a durable ownership plan. Apple’s APNs TLS certificate documentation explains the certificate-based connection. The receiving team should create the required new certificate or key, update the server, and test both token registration and message delivery.

The seller should not send the buyer a complete personal Keychain or an unfiltered copy of the old certificate store. Instead, document the configuration and rotate credentials through the receiving team’s account. Verify:

• The app receives a fresh device token.
• The server accepts the expected token format.
• A test notification reaches a TestFlight installation.
• Production and non-production endpoints are not accidentally mixed.
• The server logs identify the new credential without exposing its value.

Recreate App Store Connect upload access

App Store Connect API keys and upload credentials are separate from the app’s Bundle ID. The buyer should create receiving-team credentials and inject them into the new build process through the remote Mac’s secret mechanism or CI secret store.

Keep these values as placeholders in documentation:

• Issuer ID: <ISSUER_ID>
• Key ID: <KEY_ID>
• Private key path: <PRIVATE_KEY_PATH>
• Team ID: <NEW_TEAM_ID>
• Bundle ID: <BUNDLE_ID>

The upload process should be tested independently from the Archive process. Apple’s build upload guide describes the upload path, while the build status reference defines the distinction between upload, processing, and later build states.

A green Archive in Xcode is therefore only one checkpoint. It does not prove that Apple accepted the upload, completed processing, made the build available to TestFlight, or preserved the app’s runtime behavior.

The remote Mac maintainer should separate machine access from account ownership. A machine can remain online while its users, Keychain items, runners, and signing identities change.

For packaging after App Store Connect App Transfer, the maintainer should establish a repeatable environment with:

• A documented Xcode selection
• A fixed project and dependency path
• A known macOS user for the receiving team
• A controlled signing entry point
• Secret injection rather than copied private files
• A reproducible Archive command
• A reproducible IPA export command
• A controlled upload command
• Logs stored outside personal home directories
• A rollback copy of the previous build configuration

The receiving team should avoid copying the entire original user directory or Keychain. That approach may preserve hidden credentials, personal certificates, stale profiles, and unrelated private data. It also makes later incident review difficult because the new team cannot identify which identity signed a build.

A remote Mac can be useful when the buyer needs a persistent macOS environment without immediately purchasing dedicated hardware. We recommend reviewing the JEXCLOUD remote Mac options only after the account and signing responsibilities are clear. The service choice cannot replace Apple account verification or capability migration.

How should the first Archive be completed on a remote Mac?

Use the receiving team’s account and follow a controlled sequence:

1. Log in to the approved remote Mac user, not the seller’s personal session.
2. Confirm the intended Xcode path and project revision.
3. Resolve dependencies from the lockfile or documented package state.
4. Check the Bundle ID, Team ID, schemes, and entitlements.
5. Select the receiving team’s signing method.
6. Run a clean build or the project’s documented validation command.
7. Create an Archive from the production scheme.
8. Inspect the Archive signing identity and entitlements.
9. Export an IPA with the receiving team’s distribution settings.
10. Upload the build with receiving-team credentials.
11. Wait for App Store Connect processing.
12. Install the TestFlight build and test critical online features.

The same sequence should be tested through the graphical Xcode workflow and through SSH or CI if those paths will be used in production. A successful GUI Archive cannot substitute for a failed headless build, because CI may use another user, another Keychain, another path, or another environment variable set.

For teams that need an always-available build host, a JEXCLOUD remote Mac deployment can be considered after the acceptance criteria are written. The key requirement is not merely remote access. It is traceable signing, repeatable output, and controlled credential ownership.

The final release owner should collect evidence from each role rather than accepting verbal confirmation. The seller confirms what was delivered. The buyer confirms what was recreated. The maintainer confirms what the machine executed. The release owner confirms that the resulting build is safe to distribute.

When should the old build environment be disabled?

Disable the old environment only after the new team has completed a real Archive, IPA export, App Store Connect upload, processing, TestFlight installation, and capability test. If any of these checkpoints remains unverified, keep a restricted rollback path and limit old-account access rather than deleting it immediately.

The transfer should pause when:

• The receiving team cannot see the transferred app.
• The Bundle ID or App ID does not match the project.
• Required capabilities are missing.
• The new signing profile does not include required entitlements.
• APNs registration or delivery fails.
• Sign in with Apple migration is incomplete.
• The upload succeeds but processing fails.
• TestFlight installation succeeds but a core online feature fails.
• The build can be produced only from the seller’s personal Keychain.
• Logs cannot identify the signing and upload path.

Compare the handover states

Map each asset to the right action

Use this final acceptance matrix

Before the transfer, the seller should complete the inventory, archive the build inputs, record capabilities, and document the last known release. During acceptance, the buyer should confirm the transferred app, recreate signing and upload access, and run the remote Mac workflow under the new team. After TestFlight validation, the maintainer should rotate credentials, remove unnecessary users and runners, and preserve evidence without retaining shared private keys.

The current approach—continuing to rely on the seller’s Mac—has three concrete weaknesses: ownership remains unclear, personal Keychain data can become a hidden dependency, and a seller-side credential change can interrupt a production release. A freshly purchased Mac avoids some sharing concerns but creates hardware cost, setup work, maintenance responsibility, and a machine that may sit idle between releases.

For a temporary takeover, migration window, or small team that needs a persistent macOS build host without buying another device, renting a Mac from JEXCLOUD can provide a cleaner separation between the receiving team’s environment and the seller’s old workstation. It is still not the best fit for a long-term, heavy, always-on workload that requires physical peripherals or complete hardware control. For a short or uncertain handover, however, a dedicated remote Mac with controlled access can make the new signing and TestFlight path easier to verify.

Use the transfer checklist to decide whether to continue dual-track operation, switch fully to the new environment, or pause the release. The decisive evidence is not that Xcode opened the project. It is that the receiving team produced, uploaded, processed, installed, and tested a release build without depending on the seller’s private credentials.