Transferring an app to another developer account: what breaks

The short answer

You can transfer an app to another developer account without losing your listing. On Apple, ratings, reviews and the bundle ID are kept, the app stays available during and after the transfer, and users keep receiving updates. On Google Play you keep users, statistics, ratings, reviews and subscriptions.

What isn't painless is everything else. There's a long list of things to prepare before you press the button, and a few that break no matter what — and that your users will notice. The worst of them: on iOS, shared keychain access stops working once the app is updated, so your users will have to sign in again, once. If that catches you by surprise on transfer day, you get a support spike and a dip in reviews.

This is the list, in order.

Apple: what to do before you press transfer

Auto-renewable subscriptions

They need an app-specific shared secret. The transferor generates it and hands it over; the recipient must have it before accepting the transfer and update their servers with it. Afterwards, the recipient generates a new one.

Skip this and receipt validation breaks on the new owner's server. In other words: paying subscribers losing access.

TestFlight and Xcode Cloud must be emptied

• TestFlight: turn off beta testing, remove all builds, all testers and clear the Test Information fields in every localization. TestFlight data and tester information are not transferred.
• Xcode Cloud: remove all of its data from Settings → Xcode Cloud in App Store Connect.

These are requirements, not suggestions: without them the transfer doesn't proceed.

Sign in with Apple: the one that needs the most lead time

If your app uses Sign in with Apple, apps must be ungrouped before initiating the transfer. And the important part: you must generate transfer identifiers for every user in your database, using the REST endpoint Apple publishes for exactly that.

Translated: this is a data migration job, with its script and its execution window. Skip it and the identifier Apple gives each user changes namespace, and you can no longer recognise your own users after the handover.

If you don't want the associated Service ID to transfer, remove the association beforehand — otherwise it goes with the app.

Apple Pay and Wallet don't travel

• Apple Pay: the merchant ID does not transfer. Transactions keep working with the original certificates until they expire, but the recipient must create a new merchant ID before submitting any update.
• Wallet: passes that need updating must be reissued with new identifiers, so they're signed with the recipient's certificates. Previously issued passes become inactive, and users must be told to download the new ones.

If your product is a loyalty card or a ticket, that isn't a technical detail — it's a communications campaign.

iCloud and CloudKit: watch the shared container

iCloud containers, KVS identifiers and user data do transfer. The problem shows up if that CloudKit container is shared with other apps on the transferor's account: those other apps lose access. They can no longer read from or write to it.

It's the classic case of a company with several apps sharing data. Before transferring one, find out who else is using that container.

Keychain sharing: this is where users feel it

Keychain access only works until the app is updated. When submitting the update you have to rebuild it: in Xcode projects, replace the Xcode-defined keychain group with the recipient's, using their Team ID.

Direct consequence, and worth writing into the comms plan: the user will have to sign in again, because the app can no longer retrieve their authentication token.

Push, Game Center and the rest

• APNs: certificates remain valid until they expire; after that the new owner generates their own. Keys can be reused or regenerated, but servers must be updated with whichever is chosen.
• Game Center: the app is removed from the multiplayer compatibility matrix and from groups. Leaderboards revert to their original status — group ones keep the grp. prefix, merged ones lose it and revert to their original IDs — and the recipient must ship an update with the new IDs. Matchmaking configuration is not transferred: it gets rebuilt.
• Mac Catalyst: the iPad app and the Mac app transfer separately and in that order, iPad first. If the Mac app isn't transferred, the recipient can't create a new one from the iPad app.
• App Bundles: bundle history can't be viewed after the transfer. Document it first.
• Nominations: not transferred. Hand them over manually.

Google Play: shorter, with two traps

The process is simpler but has requirements that catch people out.

What you need before starting:

• Both accounts registered and active.
• The registration transaction ID for both accounts. Find it in the developer registration fee email or in Google Payments. Formats look like 01234567890123456789.token.0123456789012345 or Registration-1234ab56-…, and when submitting you must remove the first portion (the 0.G. or the digits before token).
• An active payments profile on the target account if there are paid apps or in-app purchases.
• Permissions updated on integrated services — Firebase, Google Analytics, AdMob — before the transfer.

Google's support team reviews and replies to transfer requests within two business days.

What transfers: users, statistics, ratings, reviews, subscriptions, content rating and the store listing.

What doesn't: bulk export, payout and earnings reports; promotions (though previously issued promo codes remain valid); test groups, which must be recreated; integrated service permissions and linkage settings; and pre-transfer orders, which stay with the original account.

The two traps:

1. A private app created with the managed Google Play iframe cannot be transferred. Ever. If it was published under the wrong account, you republish and redeploy.
2. Translation projects must be completed first, and ad SDK integrations require an APK update afterwards.

Who keeps the data

Agree this in writing beforehand, because afterwards it isn't negotiable:

	Transferor	Recipient
Sales and payments	Only pre-transfer	Only post-transfer
App Analytics	Loses all access	History from 1 April 2015 or first availability
Promo codes	No new ones after transfer, whoever owns it	Existing ones valid for 4 weeks

The transferor losing all App Analytics access is what usually causes the argument. If you need that history, export it first.

The right order

1. Inventory: capabilities, services, shared containers, who else uses what.
2. Export analytics, reports and everything that doesn't travel.
3. Generate the subscription shared secret and hand it over.
4. Migrate Sign in with Apple identifiers, user by user.
5. Empty TestFlight and Xcode Cloud.
6. Prepare the comms plan: re-login, reissued passes.
7. Gather the Google transaction IDs and fix Firebase/AdMob/Analytics permissions.
8. Transfer. iPad first, then Mac if there's Catalyst.
9. Ship the update: rebuilt keychain, new merchant ID, new Game Center IDs.

The lesson, arriving late

Everything above exists because someone published the app under the wrong account. Usually the agency's.

The developer account — Apple's and Google's — should be in the client's name from day one, with the agency invited as a team member. It costs nothing at the start. Once the project is in production with subscriptions, Sign in with Apple and keychain in play, it costs a small project and a support spike.

It's the first thing we look at in a technical audit of a mobile app: before the code, who holds the keys.

---

Primary sources, consulted on 14 August 2026: Overview of app transfer in App Store Connect Help, and Transfer apps to another developer account in Google Play Help.