Messages unread for a week, the last invoice paid, and the build you were promised on Friday never arrived. If your app developer disappeared, the urge is to find a replacement today. Don’t, yet. The first job is making sure you control everything the app depends on, because a new developer can’t help you if nobody can log in to the Play Console.
This plan works for any stack: native iOS and Android, Flutter, React Native, or a web app.
Day one: confirm the app developer disappeared, and write it all down
People go quiet for ordinary reasons: illness, a family emergency, a lost phone. Send one clear message on every channel you have (email, WhatsApp, the project tool) saying what you need and by when, say 48 hours. Keep it calm and factual. It’s the message you might later show a lawyer.
At the same time, start a spreadsheet of every service the app touches. If you don’t know, search your email for receipts and signup confirmations. Typical rows:
- domain registrar and DNS;
- source code host (GitHub, GitLab, Bitbucket);
- Apple Developer account and App Store Connect;
- Google Play Console;
- cloud and backend (AWS, Google Cloud, Firebase, Azure, a VPS, Vercel);
- payment gateway (Stripe, Razorpay, PayU and so on);
- email, SMS and push providers, maps and analytics keys;
- any AI provider, such as an OpenAI account with a card on file.
For each one, note whose name it’s in and whether you can log in. That column decides the rest of your week.
Days two and three: secure the accounts you own
For every account in your name, log in, check who else has access, remove the developer’s personal user, and turn on two-factor authentication. Change the passwords they knew.
Be careful with API keys and server credentials. Rotating them is right, but a key the developer hard-coded into the app or the backend will break production the moment you revoke it. Remove their user access first, which is safe. Rotate the keys once someone has checked where each one is used, ideally the developer who’ll take over.
Accounts in the developer’s name are the hard part, and the store accounts matter most.
Apple
If the app is published from your own Apple Developer account, you’re in good shape: the Account Holder or an Admin can revoke and recreate signing certificates and provisioning profiles, so a new developer can ship updates. If it’s published from the developer’s account, the app can be moved to yours using App Store Connect’s app transfer. The Account Holder of the current account starts it and the Account Holder of yours accepts it, so you need their cooperation.
Google Play
New apps on Google Play are enrolled in Play App Signing, which means Google holds the app signing key and the developer only had an upload key. If that upload key is lost, someone with the right Play Console access can request an upload key reset, and you can keep updating the app. The dangerous case is an older app that was never enrolled and whose signing key the developer kept. Google’s documentation is blunt that a self-managed signing key can’t be reset if it’s lost. Without it, you can’t publish updates to that listing. If that’s your situation, getting the keystore file and its passwords is the single most important thing to ask for. Like Apple, moving an app between Play developer accounts needs the current account owner to act.
Days three and four: get the source code
If the repository is in your organisation, clone it somewhere safe today and check the latest commit date against what you were last shown. If it’s in their account, request a full copy in writing, pointing to the IP and handover terms in your contract if you have them.
If you get nothing, know what you’re left with. For a web app you have whatever’s deployed, which is usually minified and hard to work with. For a mobile app you have compiled binaries, which aren’t a realistic starting point. Your backend’s database and cloud functions, if they’re in your cloud account, are usually the most valuable thing you still hold. Take a backup or export of the database now, before anything else changes.
If code recovery turns into a dispute, talk to a lawyer about your options. We can’t advise on that part.
Day five: audit before you hire
Once you control the accounts and have the code, get an independent technical audit before signing with a replacement. A useful audit answers:
- Does the project build from a clean machine using only what’s in the repository?
- Are secrets committed to the code (API keys, database passwords, private keys)?
- Does the code match what’s live in the stores and on the server?
- Which features are finished, half-built or missing compared with what you paid for?
- Are the dependencies current, or is the app months behind on SDK and OS requirements? Apple and Google both raise their minimum requirements regularly, and an abandoned app falls behind fast.
- Is there any documentation, and are there tests?
The answers tell you whether to continue the codebase, refactor parts of it, or rebuild. Sometimes a rebuild is the honest answer. More often the code is salvageable once someone careful is reading it. When we moved a fintech client’s app from GetX to BLoC, we changed its core architecture without throwing the app away. A rewrite isn’t automatically the right call.
If you’re in the middle of this now, orithLabs can run the audit, help you recover store access and keys, and then keep the app updated through our maintenance and support service, or just hand you a clear report so you can choose who takes it on.