Taking Over an App Somebody Else Built

Usually, but how easily depends on one thing: whose name the developer accounts are in. If the Apple and Google accounts belong to your company and the previous developer was only added as a user, you remove their access and carry on. If the accounts are in their name, the app legally sits in their organisation and you need either their cooperation or a platform transfer process. Both stores have a route for moving an app or an account between organisations, and both need action from the current owner. Where that cooperation genuinely never comes, the remaining path is a fresh listing under your own account, which costs you the install base, the ratings and the existing links. That is why we start every takeover with the account inventory rather than with the code.

Not necessarily, and this is where the two platforms differ sharply. On Android, if the app is enrolled in Google Play App Signing then Google holds the key that signs what users install, and losing your upload key is recoverable through a reset request — you generate a new one and carry on updating the same listing. If the app is not enrolled and the original app signing key is genuinely gone, no new build can ever update that listing, and the only route is a new listing under a new package name. On iOS the picture is better: certificates and provisioning profiles are generated from your Apple developer account and can be revoked and reissued at will, so a lost certificate file is an inconvenience. The thing you cannot regenerate on either platform is access to the account itself.

Not if we update the existing listing, which is the plan in almost every case. As long as the app keeps the same bundle identifier on iOS or the same package name on Android and is signed with the same signing identity, a new version is an update: installed users get it automatically, the ratings history stays, the store URL stays, the deep links keep working and whatever search ranking the listing has accumulated is preserved. Publishing a second listing instead resets all of that to zero on day one. A new listing is a last resort forced by a lost signing key or an unrecoverable account, never a convenience.

Keep it, more often than people expect. A working app that annoys you still contains years of small corrections for real-world cases nobody wrote down, and a rebuild throws all of them away and rediscovers them one support ticket at a time. A rebuild also produces nothing a user can see for months, while the old app still has to be maintained alongside it. We recommend rebuilding when the project genuinely cannot be built and signed any more, when parts of the source are missing, when the framework it was written in has no upgrade path left, or when the app is small enough that a rebuild is a few weeks rather than a few quarters. Otherwise we stabilise what is there and replace it in pieces.

They should not, and we treat that as a requirement rather than a nice outcome. Account identifiers stay stable, the old authentication method keeps working alongside the new one for a transition period, and anyone already signed in stays signed in through the update. Data held on the device is migrated on first launch after the update, which is the step that needs the most care: a device migration cannot be rolled back, because you cannot un-install a version somebody already has. The harder case is an app where accounts were anonymous and tied to the device or to a local database — there we design a claim flow rather than pretending the data can always be matched to a person.

It is quoted as a fixed price before we start, based on the size of the codebase and how much of it exists, so there is no open-ended hourly meter. What you get is a written report rather than a conversation: what stops you shipping today, what will get the app rejected or delisted at the next platform deadline, what your users are already feeling in crashes and start-up time, and what is genuinely fine and should be left alone. Each item carries an effort range. The report is yours to keep and to show to another developer whether or not you hire us, and it names the parts of the existing work that were done well, because most inherited codebases have some.

First we establish whether it still builds at all against current platform tooling, because that is the difference between an inconvenience and a dead end. An app in an abandoned framework often keeps running on phones for a long time while quietly becoming impossible to update, and the deadline that finally forces the issue is usually a platform requirement rather than a user complaint. If a supported upgrade path exists we take it. If not, the honest recommendation is a rebuild in something current, staged so the existing listing, users and ratings carry across rather than starting again beside them.