On this page (8 sections)
Apple’s transfer criteria (as published)
- Neither account is in a pending or changing state, and both have accepted the latest paid and free agreements. If the transferor accepted the EU Alternative Terms Addendum, the recipient must accept it too.
- The app has at least one version released to the App Store and is not available for pre-order anywhere.
- The app’s status is not Processing for Distribution, Waiting for Review, In Review, Accepted, Pending Developer Release or Pending Apple Release.
- In-app purchases are in one of these states: Approved, Ready to Submit, Developer Removed from Sale, Rejected. Apple-hosted asset packs must not be Waiting for Review or In Review.
- In-app purchase product IDs must not collide with any product ID already in the recipient’s account.
- Mac apps that used the sandbox and share an Application Group Container with other Mac apps, and Apple Arcade apps, cannot be transferred.
Source: App Store Connect Help, App transfer criteria and Overview of app transfer (verified 22 September 2026).
What stays and what moves
| Item | After the transfer |
|---|---|
| Reviews, ratings, users, update path | Retained — users keep receiving updates |
| Bundle ID and App ID | Unchanged; the App ID moves to the recipient (a wildcard App ID is converted to an explicit one) |
| In-app purchases and subscriptions | Move with the app; the recipient must generate a new app-specific shared secret so the old owner’s servers lose access |
| TestFlight | Must be turned off before transfer: remove all builds and testers, clear test information |
| Xcode Cloud data | Must be removed before transfer |
| Sales / payments history | Transferor keeps pre-transfer data; recipient sees post-transfer sales; App Analytics history goes to the recipient |
| Promo codes | Cannot be generated by the transferor afterwards |
| Webhooks | Transfer to the recipient (delete first if unwanted) |
| Alternative marketplaces (EU) | App stays only on marketplaces both parties added beforehand |
The services that need real migration work
Sign in with Apple
User identifiers are scoped to the developer team. Before the transfer you must generate a transfer identifier for every user in your database (Apple’s user migration API), ungroup the app if it shares a Sign in with Apple group, and decide whether the Service ID moves. After the transfer the recipient exchanges those identifiers for new team-scoped IDs. Skip this and every Sign in with Apple user is locked out of their account.
Push notifications (APNs)
Existing APNs certificates keep working until they expire, but the recipient must create new APNs certificates or keys under their team and update the push servers (including Firebase Cloud Messaging or any third-party push provider). Plan a cut-over, not a cliff.
Auto-renewable subscriptions and server validation
Generate an app-specific shared secret before the transfer and share it with the recipient so subscriptions keep validating; the recipient then rotates it. App Store Server Notifications and App Store Server API keys are per team — the recipient needs new keys and the backend needs re-configuration.
Apple Pay
“The merchant ID isn’t transferred along with the app.” Transactions continue while the original certificates are valid; the first update submitted by the recipient needs a new merchant ID and payment-processing certificate.
Keychain sharing
Keychain sharing works only until the app is updated; the recipient rebuilds the keychain entitlement and users log in once more. Plan the messaging.
iCloud, CloudKit and Wallet
iCloud containers, user data storage and KVS identifiers transfer — but if the app shares a CloudKit container with other apps, those apps lose access. Wallet passes that receive updates from your service must be re-issued with a new identifier.
Game Center
Multiplayer compatibility, groups, merged leaderboards and matchmaking are removed or reverted and must be set up again by the recipient.
Scenarios
| Scenario | What to watch |
|---|---|
| Agency → client | Client enrolls in the Apple Developer Program as an organisation (D-U-N-S) first; agreements accepted; certificates, APNs keys and App Store Connect API keys re-issued so the agency retains nothing |
| Individual → organisation | Apple can convert some individual accounts; otherwise a transfer to the new organisation account with all migrations above |
| Sale of the app | Due diligence on statuses, IAP states, Sign in with Apple usage, and any App Store Connect API integration; revenue cut-over |
| Same company, new team | Still a full transfer in Apple’s eyes — Sign in with Apple and APNs migrations apply |
Get the statuses right first
The most common reason a transfer cannot start is a version sitting in Waiting for Review or Pending Developer Release, an in-app purchase in review, or a lapsed agreement on one side. Release or remove those, accept the agreements on both accounts, then initiate. Reference: App Store Connect Help, App and submission statuses.
Recommended sequence
- Check the criteria: statuses, IAP states, pre-orders, agreements, product-ID collisions, sandbox/Arcade exclusions.
- Back up all app information (metadata, screenshots, localisations, pricing) — it leaves your account after the transfer.
- Generate Sign in with Apple transfer identifiers; export the app-specific shared secret; document APNs, Apple Pay, CloudKit and keychain dependencies.
- Turn off TestFlight (builds, testers, test information) and remove Xcode Cloud data.
- Initiate the transfer (Account Holder); the recipient accepts.
- Recipient: new APNs keys, new shared secret, new server API keys, new merchant ID, exchange Sign in with Apple identifiers, rebuild signing with the recipient’s certificates and profiles, submit an update.
Moving the Android version as well? See Google Play app transfer — different criteria, different breakages.
Checklist
- Agreements accepted on both accounts; no pending account changes
- No version or in-app purchase in a blocking status; no pre-orders
- Sign in with Apple transfer identifiers generated for all users
- App-specific shared secret exported; server API / notification keys planned
- APNs cut-over planned with the push provider
- Apple Pay merchant ID and certificates planned for the first update
- TestFlight and Xcode Cloud cleared; metadata backed up
- First update from the recipient’s account submitted and approved
How App Rejection Fix can help
Apple moves the app record. Everything the app depends on stays behind unless somebody migrates it, and most of that is engineering rather than paperwork.
- Pre-transfer audit: what the app actually uses — Sign in with Apple, APNs, subscriptions and shared secrets, Apple Pay merchant IDs, iCloud and keychain groups, App Groups, associated domains, Game Center — and which of those break at the account boundary.
- Eligibility check against Apple’s transfer criteria before anyone starts, so the request is not refused after the commercial agreement is signed.
- A cut-over plan with the order of operations and the window in which push, purchases or sign-in could degrade.
- The migrations themselves: new push credentials and provider cut-over, capability and entitlement re-creation, bundle-identifier-bound services, server-side receipt and App Store Server API credentials.
- The first post-transfer build: re-signing under the recipient’s team, signing and provisioning fixes, and a release that proves the migration worked.
Account ownership, identity and agreements stay with you — we never act as the account holder. The initial review is free; migration work is scoped and quoted separately. Apple decides whether a transfer is approved.
Frequently asked questions
Why would Apple refuse an app transfer?
Apple publishes transfer criteria the app must meet before the transfer can be initiated, and they are checked against the app's current state — things like the app having at least one released version, no pending agreements or contracts on either side, and no dependencies Apple does not allow to move. Check the criteria before any commercial agreement is signed; a refused transfer after a sale is an expensive discovery.
Related: App Store App Transfer
What stops working after an App Store transfer?
Anything bound to the old team rather than to the app record. In practice: APNs authentication keys and push certificates, Sign in with Apple configuration, subscription shared secrets and App Store Server API credentials, Apple Pay merchant identifiers, iCloud containers, App Groups and keychain sharing groups, associated domains, TestFlight and Xcode Cloud setup. The first build from the receiving account also has to be signed under the new team, which is where signing and provisioning errors tend to appear.
Related: App Store App Transfer, iOS Code Signing & Profiles
Do existing users lose their purchases or have to reinstall?
No — the app record, its App Store identity and its install base move, so users keep the app and their purchase history. What can break for them is anything the app talks to: push notifications if the APNs cut-over is not planned, sign-in if Sign in with Apple is not migrated, and entitlement checks if the receiving account's server credentials are not in place. Plan the cut-over so those are live before, not after, the transfer completes.
Related: App Store App Transfer