Transfer an app to another developer account and the ratings, the reviews and the users all come with it.

What has to be true before either store will move the app

Apple publishes its preconditions on a page called App transfer criteria. Neither account can be in a pending or changing state, and both parties must have accepted the latest version of their paid and free agreements. The app needs at least one version released to the App Store, and cannot currently be available for pre order in any country or region. Six statuses block it outright: Processing for Distribution, Waiting for Review, In Review, Accepted, Pending Developer Release and Pending Apple Release.

The in app purchase rules catch handovers hardest. Every product must be Approved, Ready to Submit, Developer Removed from Sale or Rejected, and no product ID can match one already in the recipient's account. Apple-hosted asset packs cannot sit Waiting for Review or In Review. Two kinds of app cannot be transferred at all: Apple Arcade apps, and Mac apps that used the sandbox and share an Application Group Container Directory.

Google's list is shorter. Both Play developer accounts must be registered and active, which Google defines concretely: you can sign in to the original, and the target account's registration is complete with no header message asking why you cannot publish. A paid app, or one with in app products, needs an active payments profile on the target account. Google's transfer page does not state that the app must already be published, so the released version rule looks like Apple's alone.

Apple, App Store Connect Help: App transfer criteria (read 3 October 2026)

The cleanup that happens before you initiate

Four jobs on Apple's side come before you click anything. Turn TestFlight beta testing off: remove every build and tester, and clear each field under Test Information for every localization. Remove all Xcode Cloud data for the app, which Apple puts in Settings under the Xcode Cloud tab. If the app offers auto renewable subscriptions, generate an app specific shared secret and give the code to the recipient first. Then back up metadata, pricing and sales figures, because the app leaves your account once the transfer completes.

Google's cleanup is mostly about services pointed at the app. Unlink any Firebase project from the original account and relink it to the target one. Add the target account as an Owner on the Google Developers Console projects behind game services and other Google APIs, and give it permissions in Google Analytics. Finish any open translation project, because Google says an app cannot be transferred while one is running. Ad SDK integrations, AdMob included, must be updated inside the APK afterwards or traffic stays credited to the old account. Both sides also need a current account: apple developer program enrollment covers the Apple half.

Apple advises telling the recipient about every capability and App Store configuration the app uses, naming keychain sharing, Game Center and push notifications. Write that list down now. No console hands over a repository, a signing key or an environment variable.

The two procedures, and why only one is self service

Apple's transfer runs inside App Store Connect and only the Account Holder can start it. In Apps, open the app, click App Information under General in the sidebar, scroll to the Additional Information section and click Transfer App. You may be prompted for a two factor verification code. Enter the Apple Account and Team ID of the recipient's Account Holder, agree to the terms and click Request Transfer. The app keeps its previous status with Pending App Transfer added, and the request expires if nobody accepts within 60 days.

The recipient's Account Holder accepts in the Business section, where the alert appears under Agreements, in App Transfers, behind a Review button. They supply a support URL, a marketing URL and a privacy policy URL where the app had those, plus App Review and App Store contact information. Completion takes up to two business days at status Processing App Transfer, or Waiting for Export Compliance if Apple needs encryption documentation. Either side can cancel while the transfer reads Waiting for Recipient.

Google's transfer is a request, not a button on the app. You submit it from the app transfer page in Play Console, the target developer approves it, and Google says support replies within two business days. The fiddly input is the identifier. You need the developer registration transaction ID for both accounts, found in the owner's inbox under developer registration fee, or in Google Payments under Activity. Google says to drop the leading part of the order ID, so 0.G.123456789012345 is pasted as the digits only. Under Play App Signing the target account can also request a new upload key, or a key upgrade so Play signs new installs with a new app signing key. If the plan is to retire the app instead, remove an app from the store is another procedure.

Google Play Console Help: Transfer apps to a different developer account (read 3 October 2026)

What does not travel with the app

Money and history split at the transfer date. Apple keeps your access to sales and payments from before the transfer and nothing after, while the recipient sees only what happens from the transfer forward. App Analytics is different: you lose the app's analytics entirely, and the recipient gets data from 1 April 2015 or the app's first availability, whichever came later. On Google Play, orders created before the transfer stay in the original account, so a refund means going back there or using the Google Play Developer API.

Credentials break the next release rather than the transfer. The Apple Pay merchant ID does not move, so a new one is needed before an update ships. APNs certificates stay valid until they expire, after which the recipient's team generates new ones or uses APNs keys of its own. New provisioning profiles have to be created against the transferred App ID and distribution certificate. Keychain sharing works only until the app updates, and users then sign in once more. One hard stop sits on the Play side: private apps created with the managed Google Play iFrame cannot be transferred at all. And one loss is permanent, whoever ends up owning the app: Apple will not let anyone generate new promo codes for it once it has been transferred. Featuring nominations do not transfer either.

Then the question under the procedure: should the other party have owned the listing from the start? App Store Review Guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. Read plainly, that points at the client's own account holding the record on day one, which turns a transfer into something nobody has to do. Who owns the code and the keys is the companion question: what you actually own.