Apple App Transfer: What Breaks After the Move

An Apple app transfer moves an iOS app from one App Store Connect account to another while it stays live, keeping its reviews, ratings, bundle ID and existing users, who carry on receiving updates. The Account Holder of the sending team starts the request, the receiving Account Holder has 60 days to accept, and Apple then takes up to two business days to complete it. The painful parts sit around those steps, because TestFlight data, App Groups, Apple Pay merchant IDs and Sign in with Apple user identifiers don’t simply follow the app, and most breakage shows up in the new team’s first update.

Apple documents all of this across four help pages and a technote, organised by feature rather than by the order you’d do things. This piece puts it in that order, flags the problems users only see after the first new build, and covers what Apple’s pages skip, which is choosing between an app transfer and an account handover, and what to do when the previous developer won’t cooperate.

What does an Apple app transfer actually move?

The transfer moves the app record and its public history, so from a user’s point of view nothing changes. Apple states that the app retains its reviews and ratings, remains available for download during and after the transfer, and that users continue to receive updates. The bundle ID and App ID move into the recipient’s developer account, which keeps the listing, its ranking history and every install intact.

Some of the app’s configuration travels with it too. iCloud containers and key-value storage identifiers move along with the user data stored in them, and auto-renewable subscription configuration transfers as long as the teams exchange an app-specific shared secret. A Sign in with Apple Services ID tied to the primary App ID transfers unless the sender removes it first, and Game Center leaderboards and achievements come along, reverting to their original status if they were grouped.

What stays behind is mostly developer tooling. TestFlight data must be cleared beforehand, Xcode Cloud data has to be removed, and App Groups, Apple Pay merchant IDs and Game Center matchmaking configuration don’t transfer. App bundle history isn’t viewable afterwards, so Apple tells the sending team to record it before starting.

Can your app be transferred right now?

Your app can be transferred only if it meets every one of Apple’s transfer criteria, and a few ordinary situations block it. The two that stop teams most often are an app that was never released and a build sitting in review.

The app needs at least one version released to the App Store, and it can’t be available for pre-order in any country or region. It also can’t be in any of these states:

• Processing for Distribution or Waiting for Review
• In Review or Accepted
• Pending Developer Release or Pending Apple Release

A transfer and a release therefore can’t overlap, so plan a quiet period with nothing submitted. In-App Purchase products each need a status of Approved, Ready to Submit, Developer Removed from Sale or Rejected. Neither account can be in a pending or changing state, and both must have accepted the latest paid and free agreements.

One blocker is easy to miss. In-App Purchase product IDs on the app can’t match product IDs on any app already in the recipient’s account, which bites studios that reuse a naming scheme like premium_monthly across clients. Apple Arcade apps can’t be transferred at all, and a Mac Catalyst app needs both its iPad and Mac versions transferred, iPad first.

Should you transfer the app or the Account Holder role?

Transfer the app when only this app is changing hands, and transfer the Account Holder role when the whole developer account belongs with someone else. Picking the wrong one either moves too little or hands over apps that were never part of the deal.

The app transfer suits the most common handover, where an agency or previous owner has your app in an account alongside other clients’ apps. Both accounts carry on existing afterwards, each with its own team, agreements and banking.

Handing over the account works through the Account Holder role, and Apple limits it tightly. For an organization membership, the current Account Holder can pass the role only to an employee on the team with the legal authority to bind the organization to agreements. The new holder enables two-factor authentication, verifies their identity where their region supports it, and accepts the Account Holder Transferee Agreement. That route fits a company whose developer lead is leaving, and it doesn’t fit a sale between two businesses.

Individual memberships are narrower than that. Apple grants an Account Holder transfer for an individual member only when a minor reaches the age of majority and takes over from a guardian, or when the Account Holder has died, and both need Apple Developer Support. If your app sits in a freelancer’s personal account, the app transfer is your only route.

What has to be cleared out before you start?

The sending team has to strip out anything Apple won’t carry across and hand over anything the receiving team needs, before the request goes in. Getting this order wrong is the usual reason an attempt stalls at the criteria check.

TestFlight comes first, because Apple requires every build and tester to be removed and the Test Information fields cleared. That wipes your beta groups, so export the tester list if you want the same people invited from the new account. Xcode Cloud data has to go too, and the new team builds its own workflows afterwards.

Auto-renewable subscriptions need a handshake between the teams. The sending team generates an app-specific shared secret and gives it to the recipient, who needs it before accepting so their servers keep validating receipts, and who generates a new secret of their own once the transfer completes.

Then back up whatever won’t be visible later, including metadata, pricing, sales data and bundle history. Settle ownership of the source code and signing assets at the same time, because Apple says code and build assets are exchanged directly between the teams rather than through App Store Connect. If you’re buying the app, get the repository in hand before anyone clicks Transfer App, and our piece on source code escrow explains why a contract clause is a poor substitute for holding the code.

Why is Sign in with Apple the riskiest part?

Sign in with Apple is the riskiest part because its user identifiers belong to a developer team rather than to the app, and migrating them has a hard deadline. Apple’s technote TN3159 gives the teams a 60-day period from the date the transfer completes, and the user migration endpoint is active for both teams only during that window.

The sending team works before initiating the transfer. For every user, it obtains an access token and generates a transfer identifier, using the existing user ID, the recipient’s Team ID, the app’s client ID and its own client secret, and it has to ungroup any apps grouped for Sign in with Apple. The receiving team then exchanges each transfer identifier for a user identifier scoped to its own team, and confirms the migration by checking each user’s credential state. Private relay email addresses go through the same process where they apply.

Apple states the token endpoint has no rate limiting, so batch migration of a large user base is practical, and the real risk is the calendar. If the 60 days pass first, Apple’s documented recovery is to transfer the app back to the original team, prepare the identifiers properly and transfer it again, with another round of frozen metadata and waiting. Have the migration script written and tested before the request goes in.

What breaks for users after the first update?

Most user-facing breakage arrives with the first build the new team ships under its own Team ID, not on transfer day. Apple describes each item, but they’re spread across a long page organised by feature, so they’re easy to miss.

Keychain sharing is the one users notice. Apple says sharing keeps working until the app is updated, after which the recipient has to rebuild the keychain with their own Team ID, and existing users have to log in again once because the update can’t read the token stored under the old team. Warn users in the release notes, and test login and password reset hard before that release, since every active user will pass through them within days.

Push notifications and payments need new credentials. APNs certificates stay valid until they expire, and after the transfer the recipient generates new certificates or uses an APNs key, then updates their notification servers. The Apple Pay merchant ID doesn’t transfer at all, so the recipient needs a new one when submitting an update, although transactions keep working while the original certificates remain valid.

Wallet passes that need updates have to be reissued with new identifiers, a shared CloudKit container cuts off every other app using it, and Game Center matchmaking rules have to be recreated. The receiving team also creates new provisioning profiles tied to the transferred App ID. RapidLabs scopes that first post-transfer release as its own piece of work during an app takeover for exactly this reason.

How do you initiate and accept the transfer?

The sending Account Holder starts it from the app’s page in App Store Connect, and the receiving Account Holder accepts it from the Business section. The sender’s side takes a few minutes once the criteria pass:

1. Open the app, choose App Information under General, and scroll to Additional Information.
2. Click Transfer App, entering a two-factor verification code if prompted.
3. Click Continue if every criterion passes, or cancel and fix what’s flagged.
4. Enter the recipient Account Holder’s Apple Account and the recipient’s Team ID.
5. Agree to the terms and click Request Transfer.

The app then sits in Pending App Transfer, and the request expires after 60 days if nobody accepts. The sending team can’t edit metadata, pricing, availability or In-App Purchases meanwhile, open App Review conversations are closed, and either side can cancel from App Transfers under Agreements in Business.

The recipient clicks Review under App Transfers and enters a support URL, a marketing URL and privacy policy URL if the app had them, and App Review and App Store contact details. They choose whether every team member gets access or only Admin and Finance roles, review the existing app privacy details, and accept. Line up the recipient before the sender clicks anything, because every pending day is a day you can’t fix a pricing mistake, and our look at App Store review time covers the waits that follow.

What happens to your sales data and analytics?

Sales and payments history splits at the transfer date, while App Analytics goes entirely to the new owner. Apple states that the sending team keeps payments and sales data from before the transfer and gets nothing afterwards, and the recipient sees payments and sales data only for transactions after it.

App Analytics works the other way round. The recipient gets App Analytics data going back to April 1, 2015, or to the app’s first availability if that’s later, and the sending team loses access to it. Anyone valuing the app or settling a revenue share needs the financial reports exported before the move, because the buyer never sees that revenue history inside their own account.

How is it different from a Google Play app transfer?

Both stores keep reviews, ratings and users intact, but the paperwork and trouble spots differ enough that one plan can’t cover both. Apple’s process runs entirely between the two Account Holders inside App Store Connect, while Google’s goes through a request its support team reviews.

	Apple App Store	Google Play
Who starts it	Sending Account Holder, in App Store Connect	Original account, with the receiving account approving
Time limit or hold	Request expires after 60 days unaccepted	Account ownership transfer has a seven-day security hold
Completion time	Up to two business days after acceptance	Support replies within two business days
Testing tracks	TestFlight builds and testers removed first	Test groups on every track stay behind
Biggest trap	Sign in with Apple 60-day migration window	Ad SDKs and service links need updating

For an app on both stores, run the two transfers as separate projects under one shared release freeze. Our breakdown of Google Play app transfer covers the Android half in the same detail.

What if the previous developer won’t cooperate?

There’s no unilateral route, because only the Account Holder of the account currently holding the app can initiate a transfer. A signed contract, proof of payment or your company’s trademark doesn’t change who can click Transfer App, and Apple’s help pages describe no alternative path.

Your remaining options are limited ones. If anyone at your company was ever added to that developer team, check what role they still hold, since an Admin can at least see the app’s configuration. If the app sits in an organization account your company legally controls, the Account Holder role transfer may apply, and Apple Developer Support is the channel for disputes over account control.

The last resort is a new app record under your own account, which gives you control and costs every review, rating and existing install. That’s why RapidLabs asks about store account access before looking at any code when a business brings us an app from a previous developer.

Planning an iOS transfer users never notice

An Apple app transfer is a short sequence of clicks surrounded by a long list of preparation, and the preparation decides whether users notice anything. The criteria check, the TestFlight wipe and the frozen metadata only affect your team. The keychain re-login, the Sign in with Apple deadline and the new push and Apple Pay credentials reach customers, and they all land in the new team’s first release.

Two decisions carry most of the weight. Confirm early whether you need the app transfer or the Account Holder role, and if the app uses Sign in with Apple, finish the migration work before the request goes in. If you’re inheriting the code along with the listing, an app maintenance audit before that first release shows what you’ve taken on, and teams that don’t want that capability in-house can move the app onto a mobile app maintenance arrangement once the transfer lands.