Take Over an App From Another Developer

Which situation are you in?

The work depends on who owns the accounts today. Find your row, then use the checklist below.

Situation	What to do
Your company owns every account	Add the new team as users, check they can build and release, then remove the old team.
Apple membership is your company’s, but the old developer is Account Holder	They transfer the Account Holder role to an authorised person at your company.
Play Console account is yours, but the old developer is owner	They nominate your person as account owner. After a 7-day hold, your person completes verification.
The app sits in the developer’s own Apple or Google account	Use Apple’s and Google’s app transfer processes, covered below.
Code, rights or cooperation are missing	See the section on an uncooperative developer.

Do these five things before you tell your developer

It’s much easier to collect access while the relationship is still working.

Read your contract. Find the IP clause, the handover clause and any notice period.
List every account and service the app uses. The checklist below is a good start.
Review who has admin access to what, and ask for owner access to anything in your company’s name.
Download what you can now: store reports, analytics exports, design files and a database backup.
Pay any undisputed invoices. It removes the easiest reason for a delay.

Then give notice in writing, with the list of what you need and a date.

The full handover checklist

Tick each item only when your company holds the top-level access, not when you’ve been invited as a user.

Use this as your handover list. Add anything specific to your app.
Item	What “done” looks like	Why it matters
Source code	Every repository in your GitHub, GitLab or Bitbucket organisation, with full history and the commit that matches the live version	Mobile app, backend, admin panel and infrastructure code are often in separate repos
Apple Developer account	Your organisation holds the membership, with your authorised person as Account Holder	Only the Account Holder can transfer apps or accept agreements
App Store Connect	Your Account Holder or Admin login works	Releases, subscriptions, reviews and sales data
Google Play Console	Your account owns the app	Releases, subscriptions and the app signing settings
Android signing	The upload keystore, its passwords and key alias in your password manager. For older apps without Play App Signing, the app signing keystore.	Android updates must be signed with the right key
Apple keys	New APNs, Sign in with Apple and App Store Connect API keys created in your team	Use your own team’s keys. Don’t take over another agency’s shared logins.
Expo / EAS project	Project moved to your Expo organisation, credentials downloaded	EAS holds build credentials and over-the-air updates
Cloud accounts	AWS account, or Firebase and Google Cloud Owner role, controlled by your company	Whoever holds these controls your data and your bill
Database and file storage	A recent backup you have restored once	Your users’ data is the hardest thing to replace
Domain and DNS	You are the registrant, and you can log in to the DNS host	Your website, email and API addresses all hang off it
Payments and subscriptions	Stripe, RevenueCat or similar owned by you	Your revenue and your customers’ billing history
Other services	Email sending, push, analytics, crash reporting, maps and AI providers in your accounts	Each has its own keys. Password reset emails stop if email sending breaks.
Secrets and environment variables	A full list, then rotated after handover	Old keys in the old team’s hands are a security risk
Designs and docs	Figma files owned by your team, plus how to build, test and release	Saves days of detective work
Test accounts	Logins for each user role, including the one used for App Review	Apple needs a demo login, or a demo mode, to review apps with accounts

The handover is done when the new team has built the app on a clean machine, deployed to staging, and shipped one small release. Check login, purchases and restores, and push notifications on that release.

Moving the iOS app: Apple’s transfer process

If the app was published under the old developer’s Apple account, it must be transferred to yours. The app keeps its bundle ID, reviews and ratings, and users keep getting updates (Apple).

Apple’s conditions

From Apple’s app transfer criteria, checked October 2026:

At least one version must have been released on the App Store.
It can’t be on pre-order anywhere.
No version can be Waiting for Review, In Review, Accepted, Processing for Distribution, Pending Developer Release or Pending Apple Release.
Both accounts must have accepted the latest paid and free agreements, and neither can be in a pending or changing state. If the old account accepted the EU Alternative Terms Addendum, yours must too.
In-App Purchases must be Approved, Ready to Submit, Developer Removed from Sale or Rejected. Their product IDs can’t clash with any in your account.
Apple-hosted asset packs can’t be Waiting for Review or In Review.
Apple Arcade apps can’t be transferred. Nor can sandboxed Mac apps that share an app group container with other Mac apps.

Older guides say apps with certain entitlements can’t move. Apple’s current criteria don’t list a general entitlement block. Some capabilities need work, covered below.

The steps

Enrol your company in the Apple Developer Program (US$99 a year) and note your Team ID.
The old developer turns off TestFlight testing, removes builds and testers, clears the Test Information fields, and deletes any Xcode Cloud data.
If the app has auto-renewing subscriptions, they generate an app-specific shared secret and give it to you. You update your server before accepting.
Their Account Holder starts the transfer in App Store Connect with your Account Holder’s Apple Account and Team ID (Apple).
Your Account Holder accepts within 60 days under Business, entering support, privacy and review contact details (Apple).
Processing takes up to two business days. Then you create new provisioning profiles in your account.

Sign in with Apple users

This needs care, or users can end up with duplicate accounts. Grouped apps must be ungrouped before the transfer starts. The old team generates a transfer identifier for each user, before the transfer or within 60 days after. Your team then exchanges them for your own user identifiers within 60 days of accepting (Apple).

Map the new identifiers in your database and test login before release.

What needs fixing afterwards

Push: old APNs certificates work until they expire. Use a new or existing APNs key from your team, and update the server.
Keychain sharing: switch to your Team ID. Users have to log in once more after the next update.
Subscriptions: generate a new shared secret so the old team loses access.
Apple Pay, iCloud, App Groups, Wallet and Game Center each have their own steps in Apple’s overview.

If the app is already in your account

Sometimes the app sits in your company’s account, but the old developer is the Account Holder. Then you don’t need an app transfer. The Account Holder transfers that role to someone at your company with authority to sign contracts (Apple).

This only works for organisation accounts. Apple won’t change the Account Holder of an individual account, except for a minor coming of age or a death. If your app is in a developer’s personal account, it needs an app transfer.

Moving the Android app: Google Play transfer

Google’s app transfer moves users, ratings, reviews, subscriptions and policy declarations to your account (Google). Older orders and their refunds, earnings reports, promotions and test groups stay behind.

If the whole Play Console account is yours and only the owner is wrong, you may not need an app transfer. Organisation accounts and personal accounts that don’t earn money can change owner directly. There’s a 7-day hold, then the new owner verifies their details (Google).

Create your company’s Play Console account. It costs US$25 once and needs a D-U-N-S number for an organisation.
Finish registration until nothing in the account says it can’t publish.
Find your account’s transaction ID. Search your inbox for “developer registration fee”, or check Google Payments.
If the app sells anything, set up a payments profile first. If your default currency differs, apps with only in-app products are unpublished until you check prices and republish.
The old developer checks the app meets Play policy and downloads any reports they need. Then they submit the request on the app transfer page with your transaction ID.
You approve the request. Google says support replies within two business days.
Relink Firebase, Google Cloud projects, ad accounts and testing groups in your account.

Play App Signing vs the upload key

Most Android apps use Play App Signing. Google holds the app signing key and your team holds a separate upload key (Google). Google has required app bundles for new apps since August 2021, which means Play App Signing. Older apps may still sign with their own key.

Your situation	What happens
Play App Signing on, you have the upload key	Carry on. Store the key safely.
Play App Signing on, upload key lost	Make a new key and request an upload key reset in Play Console. Expo’s docs note a 72-hour wait before the new key works.
Play App Signing off, you have the keystore	Updates work. Consider enrolling the app in Play App Signing now.
Play App Signing off, keystore lost	Google can’t reset it, so the app can’t be updated. A new listing is the usual path, and users must install it.

Worried the old team kept the upload key? Request a reset after the transfer.

Expo, cloud, domains and the rest

Expo and EAS

Many React Native apps build on Expo’s EAS. The EAS project moves separately from the store records (Expo). Go to Project settings, then General, then Transfer project. The person doing it must be Owner or Admin on both Expo accounts. A project can only be moved a limited number of times (Expo).

If the old developer can’t join your account, Expo suggests an escrow organisation. They create it, make you an Owner and move the project in.

Before the move, run eas credentials and download the Android credentials (Expo). That gives you a credentials.json file and the keystore it points to. Keep both in a password manager, never in git.

Firebase and Google Cloud

Add your company’s Google account as an Owner on the project, then remove the old developer. Owners manage access, billing and deletion. Firebase support only acts on admin requests from project Owners (Firebase). Then move billing to your own billing account.

Check whether the project sits inside the old developer’s Google Cloud organisation. If it does, they may keep control at that level.

AWS

If the app has its own AWS account, there are two routes. If you run an AWS Organization, invite the account to it. Since November 2025 it can move directly from the old developer’s organisation to yours (AWS).

Either way, take root control. For a standalone account, the root user changes the root email to your address (AWS). Then reset the root password, set up MFA on your device and update the billing and security contacts. Delete the old team’s IAM users and roles, because moving the account doesn’t remove them.

If your app shares an AWS account with other clients, plan a move into a new account of your own.

Domains and DNS

For a .com.au, check who the registrant is. If it’s the old developer, they start a change of registrant through their domain provider. Your company signs a new licence, pays the licence fee and must be eligible to hold it (auDA). Moving registrars is separate. It needs an authorisation code, which goes to the registrant’s email.

Copy every DNS record first. Missing MX, SPF or DKIM records break email quietly.

Privacy during the handover

A handover moves personal information, so plan it. Businesses with annual turnover over $3 million must follow the Australian Privacy Principles, as must some smaller ones (OAIC).

List who can access production data, including subcontractors and anyone overseas. Overseas access can bring APP 8 duties, usually handled with contract terms.
Remove the old team’s access, and agree in writing how they delete their copies.

What a code audit checks

Before quoting new features, the new team should check what they’re inheriting. Ours usually take one to two weeks. We score each area from 1 to 5. The output is a written report of risks, blockers, estimates and a plan for the next release.

Our internal audit scorecard. Eight areas, scored 1 to 5, for a total out of 40.
Area	1 looks like	5 looks like
Build and release	Won’t compile, or needs files only the old team has	One command builds, with written release steps
Platform currency	Can’t meet Google’s Android 16 (API 36) target, or Apple’s Xcode 26 rule	Current SDKs, a recent React Native or Expo version
Security	Secret keys exposed in the code or git history, open endpoints	Secrets in a vault, least-privilege access, rotated keys
Privacy	No idea what’s collected, data logged in plain text	Mapped to the APPs, with deletion and retention handled
Structure	Every change breaks something else	Clear modules with a consistent pattern
Tests and CI	None	Tests on the risky paths, run on every change
Infrastructure	Clicked together in a console, no record	Defined in code, such as CDK or Terraform
Running costs	Paying for idle servers or oversized plans	Costs scale with use, with alerts set

As a rough guide, 30 or more means carry on and improve as you go. Between 20 and 29 means a focused clean-up before big new features. Under 20 starts the rebuild conversation. A single serious issue, like a lost signing key or an open database, outranks the total.

Store rules make platform currency urgent. From 31 August 2026, Google Play updates must target Android 16 or higher, with extensions to 1 November 2026 (Android Developers). Since 28 April 2026, App Store uploads must be built with Xcode 26 or later and the iOS 26 SDK (Apple). A neglected app may not be able to ship a fix until it’s upgraded.

Rebuild or refactor?

Fixing keeps working code and lets features keep shipping. A rebuild usually pauses new features until it’s done. Decide on evidence, not frustration.

Signal	Points to refactor	Points to rebuild
Audit score	20 or more out of 40	Under 20
Framework	Supported, with a clear upgrade path	Abandoned, or no realistic upgrade path
Build	Builds after some fixes	Nobody can build it from the code provided
Data model	Sound, even if the code around it is messy	Wrong for where the product is going
Cost to fix	Well under the cost of a rebuild, with few unknowns	Close to a rebuild, with many unknowns
Users	Many active users and subscriptions	Few users, so a fresh start costs little

A hypothetical example, in AUD ex GST: an audit prices the fixes at $40k and a rebuild at $70k. The fixes are 57% of a rebuild, so both deserve a proper look. If a rebuild also cuts hosting by a net $1,500 a month, that’s $18,000 a year in its favour.

Even in a rebuild, the backend and data can often stay. If user identity and the data schema stay compatible, accounts carry over. Test that before launch. The new app can then ship as an update to the same listing.

If the old developer won’t cooperate

This is general information, not legal advice. Talk to a lawyer before you threaten anything.

Check what you already control. If the store, cloud and key service accounts are yours, you can usually keep the app running while you sort out the rest.
Read the IP clause. Copyright in a contractor’s work generally stays with them unless it’s assigned in a signed, written document. If your contract assigns it to you on payment, and you’ve paid, you have a strong position. A licence to use and modify the code can also be enough for another developer to maintain it.
Check the clauses on moral rights, attribution and changes to the code. Ask your lawyer how they apply to your app.
Send a written request listing each item, the clause that covers it and a deadline.
Use the dispute resolution clause in your contract, such as negotiation then mediation.
If you’re a small business, the Australian Small Business and Family Enterprise Ombudsman can help with business-to-business disputes and point you to low-cost mediation.

The Australian Consumer Law may also help. Business purchases under $100,000 including GST get the consumer guarantees, such as due care and skill (NSW Government). Whether they apply, and what remedy you get, depends on your case.

Apple and Google transfers both need the current owner to start them. If they refuse, get advice before you commission a replacement listing. A new app needs code you have the rights to, and it loses the old reviews. Subscriptions and users don’t move across by themselves.

How we take over an app

We’ve taken over apps from other developers and we look after live client apps. Our order is accounts, then the audit, then a small first release, then the roadmap. A small early update proves the release pipeline works before anyone relies on it.

After that, the app moves onto a monthly support plan, and our maintenance cost guide shows typical costs. Still choosing a team? Read how to choose an app developer, or see our React Native work.

Common questions

Can I update my app without the original developer?

Yes, if you have the source code, the right to modify it, access to the store accounts and the services it depends on. Android also needs the right signing credential. If the upload key is lost and the app uses Play App Signing, Google can reset it. If the app signs with its own key and that key is lost, the app can’t be updated.

Do I lose my reviews and ratings if I change developers?

No. Changing who maintains the app doesn’t need a new listing. A formal transfer to a new Apple or Google account also keeps the reviews, ratings and users. You only lose them if you publish a brand new listing.

How long does an app transfer take?

The platform part is quick. Apple processes an accepted transfer in up to two business days, and Google says support responds to Play transfer requests within two business days. Apple’s 60 days is the deadline to accept, not the expected time. The prep, like setting up accounts and getting a D-U-N-S number, often takes longer than the transfer.

Will users have to reinstall or log in again after a transfer?

No reinstall is needed, because the app keeps its listing and users keep getting updates. Some users may need to log in once more, for example if the app uses keychain sharing. Sign in with Apple users need their identifiers migrated, or they may end up with duplicate accounts.

What happens to subscriptions when an app is transferred?

They move with the app on both stores. On iOS, the old team shares an app-specific shared secret before the transfer so your server keeps validating receipts. You then generate a new one. Earnings from before the transfer stay with the old account.

How much does it cost to take over an app?

It comes in parts: setting up your own accounts, the handover itself, a code audit, any fixes the audit finds, then ongoing support. Store accounts cost US$99 a year for Apple and US$25 once for Google. The audit and fixes depend on the size of the app and how far it has fallen behind the store requirements.

How to take over an app from another developer