Your developer has vanished: a 12-point app takeover checklist

The message usually arrives as a question with a hidden emergency inside it. "Our developer isn't replying. Can you update our app?" Sometimes the developer has moved on, sometimes the agency has closed, sometimes there was a falling out. The app is still in the store and still being used, which is why nobody noticed how much of it lives in someone else's accounts.

We take over apps like this, and the first thing we do is the same every time: go through a list of everything the app depends on and find out who controls each one. This guide is that list, in the order we work through it, with what to check, what good looks like and what to do when the answer is "we don't know". Use it before you call anyone, and you will know how big the problem actually is.

Before you start: two questions

Is the app in your Apple developer account or theirs? Open the App Store listing and look at the seller name under the app's title. If it is your company, the app record is in an account you should be able to reach. If it is the developer's name or their agency, the app lives in their account and getting it back is a transfer, which we cover in point 3.

Do you have the source code? Not a zip from two years ago; the code that built the version in the store today. If you are not sure, assume not until point 5 is done.

Everything else follows from those two answers.

The 12-point checklist

1. The Apple Developer Program membership

Every app on the App Store sits inside a Developer Program membership that someone pays for and someone legally holds. Find out whose it is, when it renews and whether it will. The fee is 99 USD a year or the local equivalent ^[1]. If it lapses, "your apps will no longer be available for download and you won't be able to submit new apps or updates" ^[2]. We have seen apps vanish from the store because a freelancer's card expired.

Good looks like: a membership held by your company, with the Account Holder role on someone employed by you, auto-renew on and the renewal date in a calendar.

If it is theirs: you need the app transferred to your own membership (point 3). Start your own enrolment now; organisation enrolments take time to verify.

2. App Store Connect access and roles

Even when the membership is yours, the people with access may not be. App Store Connect has roles from Account Holder and Admin down to Developer, Marketing, Finance, Sales and Customer Support ^[3]. The Account Holder is the one role that cannot be delegated: it is "the only user that can" sign legal agreements with Apple, renew the membership, request App Store Connect API access, remove auto-renewable subscriptions from sale and create Developer ID certificates ^[3].

Good looks like: the Account Holder is a director or owner, at least one more Admin is on staff, the departed developer's user has been removed, and every API key they created has been revoked.

Check: Users and Access in App Store Connect, including the Keys tab. A key the old developer still holds can upload builds and change your listing.

3. The app record, and whether it needs transferring

If the app is in the developer's account, Apple allows it to be transferred to yours while it stays on sale. "During and after the transfer, the app retains its reviews and ratings, and users continue to receive updates" ^[4]. Both Account Holders have to act: theirs initiates, yours accepts.

The app has to meet Apple's criteria. It must have at least one version released to the App Store; it cannot be waiting for review, in review or pending release; in-app purchases must be in an approved, ready-to-submit, removed or rejected state; both accounts must have accepted their latest agreements; and the in-app purchase product IDs cannot clash with any already in your account ^[5].

Some things do not come across. Push notification certificates have to be regenerated (keys can be reused or regenerated), an Apple Pay merchant ID has to be recreated, TestFlight testers and builds have to be removed beforehand, and you lose promo codes and any Game Center group membership ^[4]. For auto-renewable subscriptions, the transferor must generate an app-specific shared secret before the transfer and share it with you ^[4]. Your sales reports start from the transfer date; Apple's App Analytics history does come across to the recipient ^[4].

If the developer will not cooperate: a transfer needs their Account Holder to initiate it, so this becomes a contractual conversation. Check what your agreement says about ownership (point 11) before you have it.

4. Certificates, profiles and signing keys

To ship an update, the build has to be signed by your team. Check who holds the distribution certificate and its private key, the provisioning profiles, and the push notification key or certificate. Apple allows only one of each distribution certificate type per team, and only the Account Holder or an Admin can create them ^[6]. An expired or revoked certificate means "you'll no longer be able to upload new apps or updates signed with the expired or revoked certificate" ^[7].

Good looks like: certificates created from a machine you control, the private keys and the push authentication key (the .p8 file) stored in your password manager, and a note of every expiry date.

If the developer has them: revoke the distribution certificate and create a new one. Nothing already on the store is affected if your membership is valid ^[7]. Be careful with push: revoking a push certificate stops notifications until a new one is in your backend.

5. Source code and the repository

Find the repository, not a copy. Check who owns the organisation or account it lives in, that every branch and tag is there, and that the tag or commit for the version currently in the store is identifiable. Then check what is not in the repository: configuration files, API keys, signing settings and build scripts that lived on the developer's laptop.

Good looks like: the repository is owned by your company's organisation on your chosen host, the ex-developer's access is removed, and a tagged commit matches the live build number.

If you have no code at all: ask for it, citing your contract. If it really is gone, you have two honest options, rebuilding or building a new version from what is live, and you should hear the price of both before deciding.

6. Can you actually build it?

Having the code is not the same as being able to ship it. Clone the repository on a clean machine and build the exact version in the store. Note the Xcode version, the dependencies and anything that fails. Apple's current rule is that uploads must be built with Xcode 26 or later with an iOS 26 SDK ^[8], so a project that was last built two years ago may not upload even if it compiles.

Good looks like: a documented build that succeeds on a fresh machine, with a list of the secrets it needs and where they come from.

If it does not build: this is the single biggest cost driver in a takeover, and the reason we insist on doing it in the audit rather than after we have quoted.

7. Backend, hosting and databases

If the app talks to a server, find out where the server runs and who pays for it. Cloud accounts, database hosting, file storage, serverless functions, email sending and third-party APIs each have a billing owner and a set of credentials.

Good looks like: every account under your company's billing with your card, two people with owner access, credentials rotated after the old developer's access was removed, and a tested backup of the database.

If the server is in their account: request a transfer of the project or account, or export the data and redeploy. Do not let an unpaid invoice on an account you cannot see be the thing that takes your app down.

8. Domains, DNS and email

The app's privacy policy URL and support URL are in its App Store listing and must keep working. Universal links, sign-in redirects, the apple-app-site-association file, and the app-ads.txt file if you run ads all depend on a domain you control. So does the email address Apple sends review messages to.

Good looks like: the domain registered to your company at a registrar you can log in to, auto-renew on, DNS in an account you own, and the App Store Connect contact email on your domain.

Check: who the registrant is, when it expires, and where the DNS is hosted. These are often three different places.

9. Third-party SDK and service accounts

List every SDK in the app and the dashboard that goes with it: payments and subscriptions, push notifications, analytics, crash reporting, advertising mediation, authentication providers, maps, customer support chat. Each one has an account, an API key in the app, and often a webhook pointed at your backend.

Good looks like: an inventory with the owner, login and keys for each, moved to accounts in your name, with the ex-developer removed. Payment and subscription services deserve the most care, because they hold money and customer records.

Why it matters for review: Apple requires your privacy label to cover third-party code in the app ^[9], so you need to know what each SDK collects before you can keep the label accurate.

10. Analytics, crash reports and monitoring

Somebody needs to be able to see whether the app is working. Check that you have access to Apple's App Analytics and crash data in App Store Connect and Xcode, and to any third-party analytics or crash tool the app uses. If the app is being transferred to your account, Apple's App Analytics history comes across to you and the previous owner loses access to it ^[4].

Good looks like: one person on your side who looks at crashes weekly, and an agreed threshold for what counts as urgent.

11. Privacy, legal and ownership

Three documents matter. The contract with the developer, which should say who owns the code and the accounts. The privacy policy, which should describe what the app actually does and live at a URL you control. And the privacy label in App Store Connect, which Apple requires to be accurate and which you can update at any time without a new build ^[9]. If the app is sold in the EU, trader status is required to submit updates ^[8].

Good looks like: an intellectual property assignment or a clear ownership clause, a privacy policy you can edit, a privacy label that matches the SDK inventory from point 9, and a list of any data processors with agreements in place.

If the contract is silent on ownership: take advice before relying on the code being yours. A transfer in App Store Connect moves the app record; it does not settle who owns the work.

12. The release process

Finally, work out how a change gets from code to the store. Who can upload a build, who ticks the in-app purchases onto a submission, what the review notes say, whether a demo account exists and still works, whether TestFlight is used, and how the backend is deployed alongside an app release.

Good looks like: a written release checklist, a successful test release to TestFlight done by your new team, and review notes that explain the app to a stranger. Apple asks for "full access to your app" including demo accounts and explanations of non-obvious features ^[10], and reviewers will ask again if the notes are stale.

Then do a real update. The fastest way to find what the checklist missed is to ship a small, low-risk release. Until you have done that, you do not know you can.

If there is an Android version too

Google Play has its own transfer process. Both accounts must be registered and in good standing, you need the registration transaction IDs for both, and Google says its team processes requests within 2 business days ^[11]. Users, ratings, reviews, subscriptions and statistics transfer; reports, test groups and promotions do not ^[11]. Run the same twelve points for the Play Console, the signing key and the Android build.

How we run a takeover

Our takeover audit is this checklist done for you, from £650 for an app and from £350 for a website, with a written report whether or not you carry on with us. We list everything the product depends on and help you get control of it in your own name; we build the code ourselves and run it on current devices; we check dependencies, security updates, crash reports and the store listing; and we give you a plain-English report of what works, what is at risk and what to fix first, with a fixed price for each fix.

After that, most apps move onto our App care plan at £450 a month, which covers each year's iOS update, App Review changes, crash fixes, listing upkeep, certificate and key renewals and 4 hours of changes. Apple's Developer Program fee stays with you, deliberately, so the account stays yours. We built our own apps on exactly this footing: our own membership, our own repositories, our own domains, and nothing we could not rebuild from scratch tomorrow.

If you have read the twelve points and the answer to most of them is "we don't know", that is normal. It is also the moment to act, before a renewal date does it for you.