Contents7
The scenario is common: the app was delivered, it is in use, then the developer disappears. They closed down, changed careers, or no longer reply. Nothing breaks in the first month. Then a user reports a bug, Apple or Google announces a new requirement, a third-party service changes its terms, and the company discovers it knows neither where the code is nor who holds the accounts.
The good news: an abandoned app can almost always be taken over. The condition: doing things in the right order.
In short
An app is not just code: it is also accounts, hosting, a database, third-party services and access keys.
Code written by an outside developer does not automatically belong to you: the contract decides.
The stores impose updates on fixed dates; an app nobody can rebuild eventually cannot be updated at all.
The method fits in three rules: measure before touching, secure before improving, reduce the scope before working on it.
Take over, rebuild part of it or replace it is decided after the assessment, not before.
What makes an app exist
Before talking about code, list everything the app needs to run. The list is longer than you might think.
- The source code, and above all its complete repository, with the history of changes and how to build it.
- The Apple and Google developer accounts, which hold the listing, the reviews and the app’s users, as publishing under your own developer account explains.
- The hosting and the database, with their backups.
- The domain name and the DNS configuration.
- The connected services: email sending, notifications, payments, maps, analytics, each with its own account and bill.
- The keys and secrets that tie all this together, and which will have to be changed.
For each line, a single question: is it in your name, or the developer’s?
What really belongs to you
This is often the surprise. In France, Article L113-9 of the Intellectual Property Code gives employers the rights to software created by their employees in the course of their duties. That automatic transfer does not cover software developed by consultants or outside contractors, lawyer Garance Mathias points out in a feature on software rights. For a contractor’s code, it is the contract that organises the assignment of rights. Rules differ from one country to another, which is one more reason to read the contract first.
Key takeaway
Read the contract before anything else
The contract signed with the developer says what was assigned to you: the code, the documentation, the graphic assets, and for which uses. If it says nothing, get legal advice before modifying or redistributing the code. The same contract often says who holds the accounts.
Accounts can be recovered more easily than people think, provided their holder cooperates. Apple provides for transferring an app to another account: during and after the transfer, the app keeps its reviews and ratings, and users continue to receive updates, according to App Store Connect Help. Google Play likewise moves users, download statistics, ratings and reviews to the new account, after a review by its team, according to Play Console Help. If the holder is gone for good, the app often has to be republished under a new account, starting from zero on reviews.
The deadlines that will not wait
An app that runs is not an app that can be updated. Apple and Google raise their requirements regularly, and an app nobody can rebuild with recent tools ends up stuck.
- 28 April 2026
Apps uploaded to Apple must be built with Xcode 26 and the iOS 26 SDK, according to Apple’s requirements page.
- 31 August 2026
On Google Play, new apps and updates must target Android 16, and an existing app that does not target at least Android 15 stops being available to new users on recent Android versions, according to Play Console Help.
- 1 November 2026
End of the extension Google grants on request to apps that need more time.
In practice, the first update of an app abandoned a year or two ago is almost never a small fix: it is an upgrade of tools and libraries. Better to know that before promising a fix for next week. It is one of the items in an app’s maintenance budget.
Taking over without breaking everything
We apply to an app the three rules of our method for taking over digital assets: measure before touching, secure before improving, reduce the scope before working on it.
- Measure.
Who uses it, how often, for what? Which features are really used? A complete, dated copy of the code and the database serves as the starting point.
- Secure.
Recover the access, add a second administrator on every account, change every key and password the former developer knew, check that backups exist and can be restored.
- Assess.
Does the code build? With which versions? Are there tests? Do the data access rules hold? That last point is checked against the list in app security.
- Reduce.
Features nobody uses do not deserve an upgrade. Removing them lightens everything else.
The order matters. Fixing a bug before changing the keys means working on an app whose access someone else still holds. Upgrading before measuring means paying for screens nobody opens.
Take over, rebuild part of it, or replace it
The assessment points to one of three paths. None is better on principle.
Take over the existing code
The code builds, its structure is readable, the data is sound
Users keep their habits and their data
The tool upgrade still has to be paid for
Rebuild all or part of it
The code no longer builds, or every fix breaks something else
The database and accounts are kept, the interface is rebuilt
It is a chance to move to a single codebase for web, iPhone and Android
A third path exists: replacing the app with off-the-shelf software, if the need has become standard since the first build. The grid in custom or off-the-shelf applies as is. And if the back end is a service such as Supabase or Firebase, taking it over follows the same rules as the rest, with the specifics of each described in Supabase, Firebase or your own server.
Making sure it does not happen again
An app hands over well when it was designed to. Three points are enough to change the situation next time.
- Everything in your name from the start: developer accounts, hosting, domain, third-party services, code repository. The developer works with access you can withdraw.
- A written assignment of rights in the contract, for the code as well as the documentation.
- An app that builds and checks itself.
From the field
What makes Challenge Us easy to hand over
In Challenge Us, a group-challenge app we developed, every change is checked automatically and previewed online before release, and a changelog can be read inside the app. The details are in the Challenge Us case study. A team taking over the code would find how to build and check it written down in the repository, not in someone’s head.
These requirements go into the app’s requirements document, and they weigh little on the price of an app compared with what they prevent. The other topics on the journey have their article: the clickable prototype, PWA or native app, the field team app and its offline mode, notifications, subscriptions, the client portal, AI in an app, low-code or code and vibe coding, whose apps generated without review are often the ones that need taking over.
Our app development starts with written scoping, including for an existing app to take over.
Frequently asked questions
Can my former developer keep my app’s code?
It depends on the contract. For software created by an outside developer, the assignment of rights is not automatic in France: it has to be provided for in the contract. If the contract is silent or ambiguous, get legal advice before modifying the code. In any case, ask in writing for the complete repository and the access to be handed over.
Can an app published under the developer’s account be recovered?
Yes, through a transfer, which both Apple and Google offer: the app keeps its reviews, ratings and users. The account holder must initiate the transfer. If they have disappeared, the app has to be republished under your own account, starting from zero on reviews.
How much does taking over an abandoned app cost?
It depends on the assessment: code that builds with recent tools is taken over quickly, code stuck on old versions needs an upgrade that can be heavy. That is why the assessment comes before the takeover quote, not the other way round.
Is it better to rebuild everything?
Not on principle. Rebuilding is expensive and costs users their habits. You take over when the code builds and stays readable; you rebuild part of it when every fix breaks something else. The database and the accounts are kept in almost every case.
Sources
- Solutions Numériques, intellectual property rights in software (new tab)solutions-numeriques.com
- App Store Connect Help, overview of app transfer (new tab)developer.apple.com
- Play Console Help, transfer apps to a different developer account (new tab)support.google.com
- Apple Developer, upcoming requirements (new tab)developer.apple.com
- Play Console Help, target API level requirements (new tab)support.google.com
Solutions Numériques, intellectual property rights in software
Read on solutions-numeriques.com(new tab)Play Console Help, transfer apps to a different developer account
Read on support.google.com(new tab)Jim · founder of Brain Plus AI
Also in web and mobile apps
Practical guide7 min
Publishing an app under your own developer account
The developer account that publishes an app holds its listing, reviews, users and revenue. Opened in your company’s name, it keeps you independent from your provider, as long as you start early.
Practical guide6 min
App maintenance: the budget after launch
A live app has three cost lines: running it, the updates imposed by Apple, Google and libraries, and its changes. The first two are not optional, and each can be priced line by line.
Understand7 min
App security: accounts, sign-in and data
The most common flaw in an app is not a guessed password, it is a forgotten access rule that lets one user read another’s data. Here is what really protects your users’ accounts and data.