Both stores move an app between developer accounts without users noticing. Who clicks what, what the receiving accounts cost, what carries over, what stays behind and what blocks a transfer.
Who clicks the button that moves your app? Not you. On both stores the account that holds the app today starts the transfer, and the account receiving it approves. The transfer itself is free. The receiving accounts are not: a Google Play developer account is a one-time US$25, and the Apple Developer Program is 99 USD a year. Google's support team answers within two business days of your approval. Apple gives your Account Holder 60 days to accept, then takes up to two business days to finish.
If the old developer has stopped replying, getting your code, keys and store accounts back comes first. Everything below assumes someone on the other side is still willing to click.
Who can transfer an app to another developer account
Google's page names only one role: the owner of the receiving account approves. The request itself goes in from the current account through Play Console.
Apple is strict. Only the Account Holder of the current team can start a transfer in App Store Connect, and only the Account Holder of your team can accept it. Admins can't do either, so find out who holds that role on both sides before you set a date.
Set up the receiving accounts before anyone starts
Both forms ask for the receiving account's details, so it has to exist already.
On Google Play that means the US$25 fee, by card, and a choice between a personal and an organization account. An organization account can't be created without a D-U-N-S number, which is free from Dun and Bradstreet but can take up to 30 days. Personal accounts created after 13 November 2023 can't release an app until a closed test has had at least 12 testers opted in for 14 consecutive days, and Google's page on that rule says nothing about transferred apps. I wouldn't gamble a live app on the answer: open the organization account.
Apple charges 99 USD per membership year. An organization needs a legal entity that can sign contracts (no trading names or DBAs) and a D-U-N-S number unless it is a government body. The person who enrols becomes the Account Holder and must have authority to bind the company, and the legal name becomes the seller name on every listing.
Google Play: how to transfer an app to another developer account
- Check both accounts can sign in and have finished registration. A "Why can't I publish" notice in the app header means the registration is incomplete.
- Clear any policy problem on the original account or on any app being transferred.
- If the app is paid or sells in-app products, set up an active payments profile on the receiving account.
- Download the payout, sales and earnings reports from the old account before you submit. They don't come across.
- Find the registration transaction ID for both accounts: search each inbox for "developer registration fee" and strip any prefix before the token.
- The current owner submits the transfer request in Play Console, you approve it, and support responds within two business days.
App Store: how to transfer an app to another developer account
- Send the old team the Apple Account email of your Account Holder and your Team ID.
- They switch off TestFlight, remove any Xcode Cloud data, and back up the metadata, pricing and sales history, because the app disappears from their account at the end.
- In App Store Connect they open App Information, scroll to Additional Information and click Transfer App.
- They enter your details, agree to the terms and click Request Transfer. The app's status gains "Pending App Transfer", and the request expires after 60 days.
- Your Account Holder opens Business, then Agreements, and clicks Review under App Transfers. You re-enter the app's support and privacy policy URLs and its contact details, and choose who on your team can see the app.
- Accept. The status reads "Processing App Transfer" for up to two business days, or "Waiting for Export Compliance" if Apple needs documents.
What carries over and what stays behind
| Item | Google Play | App Store |
|---|---|---|
| Installed users | Transfer. Nobody reinstalls. | Transfer. The app stays on sale and users keep getting updates. |
| Ratings and reviews | Transfer, with comments and download statistics. | Transfer. |
| Subscriptions and in-app products | Subscriptions transfer. Earlier orders and their refunds stay with the old account. | Products transfer if their IDs don't clash with your other apps. Auto-renewing subscriptions need the app-specific shared secret handed over. |
| Sales and earnings reports | Stay behind. Download them before the request goes in. | Split at the transfer date. |
| Signing | Play App Signing stays with the app. You can request a new upload key, or a key upgrade for new installs. | You create new provisioning profiles. Push certificates on your team stay valid until they expire. |
| Linked services | Firebase, Analytics, Cloud projects and ad SDK links are relinked by hand. | iCloud containers transfer. The Apple Pay merchant ID doesn't, and the first update needs a new one. |
What blocks a transfer on Google Play
- A policy violation on the original account or on any app in the request.
- A paid app or in-app products with no active payments profile on the receiving side.
- Private apps built with the managed Google Play iFrame. These can't be transferred to another developer account at all.
- A different default currency on the receiving account doesn't block the move, but an app with in-app products is unpublished until you republish it with checked prices. Paid app prices are converted automatically.
What blocks a transfer on the App Store
Apple's criteria check stops on the first six. The last two come from Apple's overview page, as things the old team clears before it clicks Transfer App.
- No version has ever been released to the App Store.
- The app is available for pre-order anywhere.
- The app is in one of six statuses: Processing for Distribution, Waiting for Review, In Review, Accepted, Pending Developer Release or Pending Apple Release.
- An in-app purchase product ID matches a product ID on any app already in your account, which happens when one developer built two apps from a copied configuration.
- Either account is in a pending or changing state, or either side hasn't accepted the latest paid and free agreements.
- It is an Apple Arcade app. Those can't be transferred.
- TestFlight is still on, Xcode Cloud data is still attached, or the build still carries the App Replacement entitlement.
- The app is grouped with others for Sign in with Apple. Ungroup them before the request goes in.
The first week after the transfer
On the Apple side, create provisioning profiles under your team for the transferred App ID before anyone builds. Keychain sharing works until your first update, then the keychain group has to be replaced with one that carries your Team ID, and users sign in once more. If the app sells auto-renewing subscriptions, the app-specific shared secret is handed over before the transfer and regenerated afterwards, so nobody outside your company can validate your receipts.
On the Google side, request a new upload key if the old developer still holds the current one, relink Firebase and any ad SDKs to projects you own, and recreate the closed testing track.
None of this needs the old developer, so it belongs in week one. If nobody on your side wants to own the list, an app takeover audit that moves the code, keys and store accounts into your name does both transfers and a build from source in the same five days.
Sign in with Apple users have a 60-day clock
Every Sign in with Apple user carries an identifier and a private relay email scoped to the developer team, and neither works for a new team. Apple's way round this is a transfer identifier per user: the old team generates one for each account through Apple's user migration endpoint, before you accept or up to 60 days after, and sends you the user data with the team-scoped identifier and private email stripped out. Your team exchanges each one for a new team-scoped identifier within 60 days of accepting. Skip that and a returning user can't be matched to their existing account.
So the day you accept, put two dates in the calendar: day 50 for the identifier exchange, and the expiry date of your push certificate, because a new APNs certificate or key has to be loaded on your server before then.
Questions people ask before an app transfer
Do users have to reinstall the app after a transfer?
No, on either store. Google moves the installed users with the app, and Apple keeps the app on sale throughout, so updates keep arriving from the new account. The one exception is sign-in: an iOS app that uses keychain sharing asks users to sign in once after your first update.
Can an app be transferred while it's in review?
Not on the App Store. Waiting for Review and In Review are two of the six statuses Apple's criteria check rejects, so the build has to be approved or withdrawn first. Google's page doesn't block on review status, but any publishing issue shown in the app header has to be resolved before the request goes through.
How long does an app transfer take?
Google responds within two business days of the receiving owner's approval. Apple depends on the other side: the request waits up to 60 days for your Account Holder to accept, then processing takes up to two business days.
Does it cost anything to transfer an app?
Neither store charges for the transfer. You pay for the receiving accounts: US$25 once on Google Play and 99 USD a year with Apple. If the old Google Play account is closed afterwards, Google support can refund its registration fee.
What happens to the Android signing key?
Play App Signing stays with the app, so Google keeps signing releases. If the old developer still holds the upload key, you request a new one from the Play app signing page; Google's own wording is that a lost upload key does not lock you out of your app. If you want a fresh signing key as well, you request a key upgrade, which applies to new installs.
