How to Transfer an App Store Listing to a New Owner: Apple's Rules, Google's Process, and What Does Not Move

Buying or selling a published app is two transactions wearing one coat. There is the software — a repository, some documentation, a build that works — and there is the listing, which is the part that carries the reviews, the ratings, the ranking history and every person who already installed the thing. The software moves in an afternoon. The listing moves through a process neither party controls, with criteria that will quietly block it and a list of things that do not come along at all. This is that process, on both stores, with the blockers up front.

TL;DR:

  • Apple's transfer is self-service and needs only two facts from the buyer: their Apple Account and their Team ID. Google's is a support request that needs a transaction ID from the receiving account's registration payment.
  • The app keeps its bundle ID, its App Store ID, its reviews, its ratings and its installs. It loses TestFlight, Apple Pay merchant IDs, Wallet passes, Game Center matchmaking and all provisioning profiles.
  • The 60 days is the acceptance window, not a minimum age for the app. Apple's only liveness criterion is one version released to the App Store.
  • Most failed transfers fail before they start: an unaccepted agreement, a build sitting In Review, or an in-app purchase product ID that collides with one in the buyer's account.
  • Prepare in this order — clear TestFlight, generate Sign in with Apple transfer identifiers, export the reports you are about to lose. None of it can be done afterwards.

Table of Contents

The Two Mechanisms, Side by Side

The two stores solved the same problem in opposite ways, and knowing which one you are dealing with changes what you ask the other party for.

Apple — App Transfer Google Play — app transfer
Who can act Account Holder only, on both sides Account owner, on both sides
What the sender needs from the buyer Apple Account and Team ID Developer ID and the registration transaction ID
Who decides Nobody — it is self-service once criteria are met Google, as a reviewed request
Acceptance window 60 days, then the request expires Not published as a fixed window
Processing time Up to two business days after acceptance Google documents a response within two business days
App stays live? Yes, throughout Yes
Can be cancelled By either side, while Waiting for Recipient Before Google approves it

The asymmetry that matters: Apple will not let you start a transfer that cannot succeed — the criteria are checked when you click. Google will let you file a request and then tell you no. So on Apple the work is in clearing the criteria; on Google the work is in getting the paperwork exactly right the first time.

Apple's Criteria, and What Each One Blocks

These are the published criteria, each with the thing that actually trips it.

Criterion What trips it
Neither account may be in a pending or changing state, and both parties must have accepted the latest paid and free agreements A buyer who enrolled last week and never opened the Agreements tab. The single most common cause of a stalled handover.
The app must have at least one version released to the App Store An app that was built and never shipped cannot be transferred at all — there is nothing to move. Sell it as source.
The app cannot be available for pre-order anywhere A regional pre-order nobody remembered setting up.
The app cannot be Processing for Distribution, Waiting for Review, In Review, Accepted, Pending Developer Release or Pending Apple Release A routine update submitted the day before. You either ship it or withdraw it; you cannot transfer around it.
In-app purchase products must be Approved, Ready to Submit, Developer Removed from Sale or Rejected A half-created subscription left in a draft state months ago.
In-app purchase product IDs cannot match product IDs on any app in the recipient's account A buyer who reuses tidy identifiers like com.company.pro.monthly across their portfolio. Nothing can be done except rename on one side — and renaming a live product ID is not free.
Apple-hosted asset packs cannot have versions Waiting for Review or In Review Downloadable content mid-review.
Mac apps that used the sandbox and share an Application Group Container Directory with other Mac apps cannot be transferred A Mac app that shares state with its own companion utility.
Apple Arcade apps cannot be transferred Nothing. This one is absolute.

Pro Tip: Note what is not on that list: there is no minimum age, no revenue floor and no restriction on iCloud. The "your app must have been live 60 days" rule repeated across the broker blogs is a misreading of the 60-day acceptance window, and the "iCloud entitlements block a transfer" rule stopped being true long enough ago that Apple now documents iCloud containers as transferring.

What Moves, What Does Not, and What You Do About It

This is the table worth printing. The left column is what a buyer assumes they are getting; the right column is the work neither side budgeted for.

Item Moves? What to do about it
Bundle ID Yes Nothing — and nothing can change it. It is the old owner's identifier forever.
Numeric App Store ID and product page URL Yes Nothing. Existing links and press coverage keep working.
Reviews, ratings and ranking history Yes Nothing. This is the entire reason a transfer beats a resubmission.
Everyone who already installed it Yes Nothing. They receive your next update as an update.
App ID — wildcard IDs become explicit Yes Expect the identifier to arrive pinned to the bundle ID rather than wild.
iCloud user data, iCloud containers, KVS identifiers, CloudKit containers Yes Embed the full KVS value in new provisioning profiles. If a container was shared with the seller's other apps, those apps lose access.
Sign in with Apple Service ID Yes, unless removed first But the user identifiers need work — see below.
Game Center leaderboard identifiers Yes Nothing; they keep their original IDs.
Accessibility Nutrition Label details and URLs Yes Update the URL to one you control.
TestFlight builds, testers and test information No Seller must turn beta testing off and clear builds, testers and Test Information for every localisation before transferring.
Xcode Cloud data No Seller removes it beforehand. Buyer rebuilds any CI from the repository.
Provisioning profiles No Buyer creates new profiles in their own account, associated with the transferred App ID and their distribution certificate.
APNs certificates Valid until expiry They keep working, then stop. Generate a new key in the receiving team and point your push servers at it before that happens.
Apple Pay merchant ID No Existing transactions run on the old certificates until they expire. Buyer creates a new merchant ID before shipping an update.
Wallet pass identifiers No Passes must be reissued under new identifiers. Plan a migration if customers hold live passes.
Game Center matchmaking, group membership, multiplayer compatibility No Rebuilt by the buyer. Grouped apps come out of their group and leaderboards revert.
Keychain sharing Until the next update Buyer updates keychain group definitions in Xcode to their own Team ID. Anything stored under the old group is unreachable after that build ships.
Promo codes Existing ones only No new codes can be generated after the transfer. Issue what you need first; they stay valid four weeks.
Nominations and app bundle history No Not viewable afterwards. Seller should export and hand them over as files.
Sales and payment data Split at the line Seller keeps everything before the transfer and loses access after; buyer gets everything from the transfer onwards.
App Analytics Reversed Seller loses access entirely. Buyer gains the app's history from 1 April 2015 or launch, whichever is later.

Two of those deserve a sentence more than a table cell.

Sign in with Apple. The Service ID transfers, but the per-user identifiers your database is keyed on do not simply carry over — the seller has to generate transfer identifiers for every user in the database so the buyer can map the old identifiers to the new ones. If the app has ten thousand Sign in with Apple accounts, this is a migration with a script, not a checkbox, and it has to happen while the seller still has the account. Get it in writing before money moves.

The bundle ID. It cannot be changed once a build has been uploaded, which means you inherit the seller's reverse-DNS identifier permanently. Nobody sees it in the store, but your crash reports, your analytics, your keychain groups and your App Store Connect API calls will all say somebody else's company name for as long as the app exists. It is cosmetic, it is unavoidable, and it surprises people — so decide now that it does not bother you.

Subscriptions, Receipts and the Shared Secret

Auto-renewable subscriptions survive a transfer, which is the good news. The mechanism underneath them needs one deliberate handoff.

Receipt validation uses a shared secret. Apple's instruction is that the app must be using an app-specific shared secret rather than the account-wide one before the transfer, and that the seller provides that secret to the buyer — otherwise the buyer's servers cannot validate anything the moment the app lands. Then, straight after accepting, the buyer generates a fresh app-specific secret, which is what stops the previous owner's infrastructure from continuing to read subscription state for customers who are no longer theirs.

Pro Tip: Write both halves of that into the purchase agreement: the seller supplies the working secret at handover, and the buyer rotates it within a stated number of days. The first protects the buyer's revenue; the second protects the seller from being able to see data they should not. Both parties want both.

Google Play: A Request, Not a Handshake

Google's version is administrative rather than technical, and the thing that holds it up is almost always the transaction ID.

The sending account files a transfer request in Play Console. It needs the target account's developer ID and the registration transaction ID — the payment reference from when that account paid its 25 USD one-time developer registration fee. It is found by searching the account owner's email for the developer registration receipt, or in Google Payments under Activity. Google's documentation is explicit about one trap: the receipt shows something like 0.G.01234567890123456789.token.0123456789012345 and you must strip the leading portion before the token. Get this wrong and the request bounces.

Other prerequisites worth clearing first:

  • Both accounts registered and active, and the source account and every app in it policy-compliant.
  • A payments profile on the target account if any app is paid or sells anything.
  • Translation projects finished. An open one blocks the transfer.
  • Reports downloaded. Bulk export, payout and earnings reports do not transfer and are not recoverable afterwards.
  • Integrated services re-permissioned. Firebase, Google Analytics and Play Games access do not follow the app; grant the new owner access deliberately.
  • Play App Signing considered. Think about who holds the upload key and what that means before, not after.

What moves: users, download statistics, ratings, reviews, subscriptions, content ratings, store listing, and policy and documentation submissions. What does not: those reports, test groups, integrated-service permissions, and ad SDK integrations, which need a new release to change. Private apps created through the managed Google Play iFrame cannot be transferred at all. One commercial detail that catches smaller sellers: for accounts on the reduced service-fee tier, a transferred app's earnings count towards the annual totals of both account groups in the transfer year.

The Handover Checklist, In Order

Order matters here more than completeness. Several of these items are impossible to do after the transfer clears.

Seller, before initiating

  • Accept the current paid and free agreements. Confirm the buyer has too.
  • Ship or withdraw any version in review. The app must be in a settled state.
  • Turn off beta testing; remove every build and tester; clear Test Information in every localisation.
  • Remove Xcode Cloud data.
  • Switch to an app-specific shared secret and prepare to hand it over.
  • Generate Sign in with Apple transfer identifiers for every user in the database.
  • Ungroup grouped Sign in with Apple apps, and take the app out of any Game Center group.
  • Export everything you will lose: analytics history, sales reports, nominations, bundle history, promo codes you still want issued.
  • Check in-app purchase product IDs against the buyer's account for collisions.
  • Confirm no pre-order is live in any region.

Buyer, before accepting

  • Enrol, and accept every agreement — paid and free. If the seller distributes under the EU alternative terms, you must agree to those too.
  • Add any alternative app marketplaces the app is distributed on. The app stays available only on marketplaces both sides added before the transfer.
  • Get the app-specific shared secret in hand.
  • Have a privacy policy URL and a support URL ready — you are asked for them at the moment you accept.
  • Check your account for in-app purchase product IDs that collide with the app's.

Buyer, after accepting

  • Generate a new app-specific shared secret, and update your servers.
  • Create new provisioning profiles against the transferred App ID and your distribution certificate.
  • Generate an APNs key in your team and move your push servers to it before the inherited certificates expire.
  • Create a new Apple Pay merchant ID if the app takes Apple Pay.
  • Reissue Wallet passes under new identifiers.
  • Rebuild Game Center matchmaking rules, group membership and multiplayer compatibility.
  • Update keychain group definitions to your Team ID, knowing the old group's contents become unreachable.
  • Point webhooks at your own servers.
  • Review the App Privacy section. If the previous owner's disclosures were deleted or never made, you must complete it before submitting a new version.
  • Re-verify Regulated Medical Device contact details and the accessibility URL, where they apply.

Where Transfers Actually Fail

In roughly descending order of how often it is the real cause:

  1. An unaccepted agreement on the receiving side. New accounts have agreements waiting, and nothing proceeds until an Account Holder reads them. This is a five-minute fix that routinely costs a week, because nobody looks there.
  2. A build in review. Someone submitted a routine update and forgot to mention it.
  3. Colliding in-app purchase product IDs. The only unpleasant one on this list, because the fix is to rename a product ID in a live account.
  4. The wrong person on the call. Only an Account Holder can initiate or accept. An Admin cannot, however senior they are.
  5. A truncated Google transaction ID. Entirely avoidable, endlessly repeated.
  6. TestFlight not cleared. Easy to miss because the criteria do not fail loudly on it until you are already in the flow.
  7. Expectations, not mechanics. A buyer who believed analytics history, TestFlight testers and the Apple Pay merchant ID were included, and discovers otherwise after paying. This post exists mostly to prevent this one.

How It Runs When You Buy From Us

Every published app in the catalogue is sold with the listing, not just the code, so the transfer is part of the purchase rather than an extra. Concretely:

  1. You pay once, by card. The project leaves the catalogue when the payment clears — each is sold once, to one owner.
  2. The complete source archive downloads immediately on the page, and the link is emailed as well.
  3. A short form appears where you paid, asking for the two things Apple needs: your Apple Developer Team ID and the Apple Account that owns your developer account. Both are in App Store Connect under Membership.
  4. We open the transfer in App Store Connect. Apple emails you to accept it — usually within a working day. No app moves without your side agreeing, which is Apple's design, not our policy.
  5. Reviews, ratings, ranking history, keywords and the existing install base come with it. You publish the next update from your own account.

The preparation list above is ours to do, and it is done before anything is listed: nothing in the catalogue is sitting in review, every project has a released version, and TestFlight is clear. What remains on your side is the buyer column — enrol, accept the agreements, and have a privacy policy URL ready for the moment you accept.

You can browse what is currently for sale, each listing with its own price and what the handover includes.

Sources

Apple and Google both revise these pages. Everything above was checked against them in October 2026; treat the criteria as current-as-of rather than permanent, and follow the links before you plan a deal around a detail.

FAQ

How do I transfer an app to another Apple Developer account?

The Account Holder on the sending account opens the app in App Store Connect, goes to App Information, clicks Transfer App, and enters the recipient's Apple Account and Team ID. The recipient's Account Holder then accepts it from the Business section of their own App Store Connect, supplying a support URL, a privacy policy URL if the app had one, and App Review contact details. Only an Account Holder can act on either side. The transfer expires if nobody accepts it within 60 days, and once accepted Apple takes up to two business days to complete it. The app stays on the App Store throughout.

What transfers with an app and what does not?

The app keeps its bundle ID, its numeric App Store ID, its reviews and ratings, its ranking history and everyone who already installed it. iCloud and CloudKit containers, the Sign in with Apple Service ID and Game Center leaderboard identifiers come across too. What does not: TestFlight builds and testers, which have to be cleared before the transfer; Xcode Cloud data; the Apple Pay merchant ID; Wallet pass identifiers; Game Center matchmaking rules; and provisioning profiles, which the new owner creates from scratch. The seller keeps sales data from before the transfer and loses access to everything after it.

How long does an App Store transfer take?

There are two clocks, and neither is the one people worry about. The recipient has 60 days to accept the request before it expires, and once they accept, Apple says the transfer can take up to two business days to complete — the app shows a Processing App Transfer status and neither side can edit metadata, pricing or in-app purchases until it clears. The real time goes on preparation: clearing TestFlight, generating Sign in with Apple transfer identifiers and exporting the reports you are about to lose all happen before anyone clicks Transfer App.

Can you transfer an app that has active subscriptions?

Yes, and subscribers keep their subscriptions, but there is one step you cannot skip. The app has to be using an app-specific shared secret rather than the account-wide one before it moves. The seller passes that secret to the buyer so receipt validation keeps working through the handover, and the buyer generates a fresh one immediately after accepting, which cuts the old owner's servers off. One criterion catches people out: in-app purchase product IDs on the app cannot match product IDs on any app already in the receiving account.

How is a Google Play app transfer different from an App Store transfer?

Apple's is self-service; Google's is a support request. On Google Play the sending account starts a transfer in Play Console and has to supply the target account's developer ID plus the transaction ID from that account's 25 USD registration payment, and Google then reviews it — their documentation says within two business days. Installs, ratings, reviews, subscriptions and the store listing move across. Bulk export, payout and earnings reports do not, so download them first. Test groups and integrated service permissions have to be rebuilt, and changing ad SDKs needs a new release.