TL;DR. Transferring an app to another Apple Developer account keeps its Bundle ID, ratings, and reviews intact — Apple’s own docs confirm the app “retains its reviews and ratings” throughout. Only the Account Holder role can initiate or accept a transfer, and while it’s pending (up to 60 days) the sending account cannot touch metadata, pricing, or in-app purchases. TestFlight testing, Xcode Cloud data, Apple Pay merchant IDs, APNs push certificates, and Wallet passes all need to be re-set up on the receiving side — none of that carries over automatically.

Indie developers run into app transfers for a few reasons: selling an app outright, an agency handing a finished build back to a client’s own account, or moving from a sole-proprietor account into a company one before scaling paid ads. The ratings history is usually the first thing people worry about losing. It isn’t the part that actually catches people off guard.

Do ratings and reviews survive an App Store Connect app transfer?

Yes. Apple’s App Store Connect Help is explicit: “during and after the transfer, the app retains its reviews and ratings, and users continue to receive updates.” The Bundle ID also stays fixed and can’t be changed once a build has shipped against it, so the app’s identity and its review history move together — this only applies to a true account-to-account transfer of the same app, not to copying reviews onto a rebuilt app with a new Bundle ID, which Apple doesn’t support at all.

Who can initiate or accept an app transfer?

Account Holder is the only role permitted on either side — the sender needs Account Holder to start it, and the recipient needs Account Holder to accept it. That’s narrower than the four-role set (Account Holder, Admin, App Manager, Marketing) that can edit your keyword field and subtitle day to day, so an Admin who normally manages your listing can’t move the app to a new account without the Account Holder logging in to do it themselves.

To start one: in App Store Connect, open the app, go to App Information under General, scroll to Additional Information, and select Transfer App. After two-factor authentication and an eligibility check, you enter the recipient’s Apple Account email and Team ID and submit the request.

What has to be true before an app is eligible to transfer

Apple checks a specific list of conditions before it lets a transfer go through:

  • The app must have at least one version already released to the App Store — you can’t transfer something that’s never shipped.
  • It can’t currently be available for pre-order, and it can’t be sitting in Processing for Distribution, Waiting for Review, In Review, Accepted, Pending Developer Release, or Pending Apple Release.
  • In-app purchase products must be in Approved, Ready to Submit, Developer Removed from Sale, or Rejected status — anything else blocks the transfer.
  • The recipient can’t already have an app using the same in-app purchase product IDs.
  • Apple Arcade apps can’t be transferred at all.
  • Both accounts need to have accepted their current paid and free Apple Developer Program agreements, and if the app used the Alternative Terms Addendum for EU apps, the recipient has to accept that too.

The metadata freeze you need to plan around

This is the part that actually affects ASO work: once a transfer is submitted, the sending account cannot modify app metadata, pricing, or in-app purchases until the recipient accepts it — and the recipient has up to 60 days to do that. If you’re mid-negotiation on a sale and you also had a keyword field rewrite or a subtitle change queued up, submit that change and let it go live before you start the transfer, not after. Once the transfer is pending, it’s locked, and there’s no way to push it through faster than the recipient’s response time.

The freeze runs the other way too: on acceptance, the recipient has to supply their own Support URL, Marketing URL and Privacy Policy URL (mandatory if the app already had them), App Review contact info, App Store contact info, and either accept the app’s existing App Privacy disclosures or fill them out fresh. Any open App Review communications get closed automatically as part of the handoff. None of that is optional — a transfer with an unprepared recipient can sit for weeks with the listing effectively locked while they gather it.

What doesn’t carry over and needs rebuilding

A handful of technical pieces don’t move with the app and need to be redone on the recipient’s account:

  • TestFlight — beta testing should be turned off for all beta builds before you initiate the transfer.
  • Xcode Cloud — all related workflow data has to be removed from the app before transfer.
  • Apple Pay — the merchant ID isn’t transferred; the recipient creates a new one.
  • Push notifications — the recipient’s team has to generate a new APNs certificate to keep sending pushes.
  • Wallet passes — these need to be reissued with a new pass type identifier after the transfer completes.
  • Auto-renewable subscriptions — if the app has them, the sender needs to share the app-specific shared secret with the recipient before handing off, or subscription validation breaks.

iCloud data, containers, and key-value storage identifiers do transfer automatically once the recipient accepts.

Before you click Transfer App

  1. Ship any pending keyword field, subtitle, or pricing change first — none of it can move once the transfer request is submitted.
  2. Turn off TestFlight beta testing and clear Xcode Cloud data from the app.
  3. Confirm the recipient has an Account Holder who’s ready to log in and accept — the 60-day clock only helps if they’re actually prepared to act inside it.
  4. If the app has auto-renewable subscriptions, hand over the shared secret separately; the transfer doesn’t do it for you.
  5. Brief the recipient on what they’ll be asked for on acceptance — support/marketing/privacy URLs and App Review contact info — so the transfer doesn’t stall on missing information.