How to Transfer an App Between Developer Accounts: App Store and Google Play

Before you start

• Sign the purchase agreement and put payment into escrow first.
• Agree in writing what is included: app record, code, backend, domain, accounts and a support period.
• Make sure the buyer has an active developer account of the right type. Apple: an Apple Developer Program membership. Google: a registered, active Play Console account, plus an active payments profile if the app is paid or has in-app products.
• The seller should list every capability the app uses (push notifications, Sign in with Apple, keychain sharing, Game Center, subscriptions), so the buyer can maintain them.

Transferring an app on the App Store

Apple's process runs through App Store Connect. The seller's Account Holder starts the transfer and the buyer's Account Holder accepts it. The app must meet Apple's transfer criteria. The app can stay live for download during the transfer, and it keeps its reviews and ratings.

What the seller prepares

• TestFlight: turn off beta testing by removing all builds and testers, and clear the test information fields for every localisation.
• Xcode Cloud: remove all Xcode Cloud data for the app.
• Sign in with Apple: generate a transfer identifier for each user in your database, and ungroup the app first if it is grouped with others.
• Auto-renewable subscriptions: generate an app-specific shared secret and give it to the buyer before the transfer, so they can update their servers. Once the transfer completes, generate a new one so nobody outside your organisation still holds the old secret.
• Mac Catalyst apps: transfer both the iPad app and the associated Mac app.
• Other cases: alternative app marketplaces, regulated medical device declarations and fixed-odds betting in Brazil each have their own requirements in Apple's guide.

What stays with the app

• Reviews and ratings.
• The bundle ID, which cannot be changed once a build has been uploaded.
• iCloud containers and the associated App ID.
• Webhooks and OS data transfer settings, which the buyer can update.

What does not carry over

• Push notifications: the buyer's certificates stay valid until they expire, and then new APNs certificates or keys are needed.
• Promo codes: no new codes can be generated after a transfer.
• Game Center: matchmaking configuration must be recreated, and multiplayer compatibility with other apps has to be re-added.
• Apple Pay merchant ID: a new one is required for updates.
• Keychain sharing: works only until the next update. The buyer must rebuild with their own Team ID, and users sign in once again.
• Wallet passes: need to be reissued with a new identifier if they are updated from the app.
• Shared CloudKit containers: other apps on the seller's account that share the container lose access to it.

Sales data and analytics

The seller keeps access to payments and sales data from before the transfer but not after. The buyer only receives payment and sales information for transactions from the transfer onward, so the seller should export their history and share it as part of the sale. The buyer gains access to analytics data going back to the app's launch, and the seller loses access to it, though historical performance stays visible in Sales and Trends.

Transferring an app on Google Play

1. The original account owner submits a transfer request to the target account owner, using the request form linked from Google's transfer help page.
2. The target account must be registered and active, with an active payments profile for paid apps and in-app products.
3. Google's support team reviews the request and replies within two business days.
4. Both accounts must comply with Google Play policies.

What does not transfer

• Bulk export, payout and earnings reports. The seller should export these first.
• Promotions, though promo codes already issued stay valid.
• Closed testing groups, which the buyer must recreate.
• Permissions and linkages to integrated services.
• Private apps created with the managed Google Play iframe.

Orders created before the transfer remain in the original account. The buyer can request a new upload key if they have any security concern, and can ask for an app signing key upgrade for new installs. Google notes that apps with in-app purchases can be unpublished during the transfer, so schedule it for a quiet period.

The parts the stores do not handle

The store transfer moves the app record. Everything else has to be handed over separately, and this is where most delays happen:

• Source code: repository access or an archive, plus build and release notes. The seller is responsible for exchanging the code and build assets directly with the buyer.
• Backend: transfer ownership of Firebase, Supabase, cloud hosting and databases, and confirm the buyer can deploy.
• Subscription and analytics tools: RevenueCat projects, analytics, crash reporting, push and email providers.
• Ad accounts and payments: ad network apps, tax and payout details for the buyer's own accounts.
• Domain, website and social accounts if they are included.
• Credentials: once everything is handed over, the buyer should rotate every API key, secret and password, and the seller should remove their own access.

A simple timeline

1. Agreement and escrow: contract signed, funds held.
2. Preparation: seller completes the store-specific steps above and exports reports and data.
3. Store transfer: seller initiates, buyer accepts, and for Google, support reviews.
4. Technical handover: code, backend, tools and credentials.
5. Verification: buyer confirms full access, ships a test update, and checks that subscriptions and revenue tools work.
6. Release of funds: escrow is released only after the buyer confirms everything works.
7. Support window: a short period, often 30 days, for questions.