App takeover
Need someone to take over an existing mobile app?
RapidLabs helps teams regain control of neglected, abandoned, or poorly documented iOS and Flutter codebases with a structured takeover audit, release-risk review, and practical recovery plan.
Best fit
Use this when...
Scope
What RapidLabs delivers
Clear next step
Email RapidLabs with the app link, current code/access situation, previous vendor status, and what release or business outcome is at risk.
If it is not a fit, RapidLabs will say so early and point you toward a better path.
Handover
What actually has to change hands in a mobile app takeover?
Source code is the part everyone asks about, and it's rarely the part that blocks the next release. The app itself lives inside accounts that Apple and Google control, and those accounts move between owners on published rules that don't bend for your deadline. A takeover that skips this tends to stall a fortnight later, when someone discovers the build can't be signed or push notifications quietly stopped arriving.
Moving an app between Apple developer accounts
Apple lets you transfer an app while it stays available on the App Store, and the app keeps its ratings, its reviews and its Bundle ID, so users carry on receiving updates as normal. The eligibility rules are narrow: the app needs at least one version already released to the App Store, it can't be available for pre-order in any country, and it can't be sitting in a state such as Waiting for Review, In Review, Pending Developer Release or Pending Apple Release. Both accounts have to be clear of any pending or changing state, both parties need to have accepted the current agreements, and Apple Arcade apps can't be transferred at all.
Several things break quietly during the move, and they explain why a handover that looked finished starts producing support tickets a week later. TestFlight beta testing has to be switched off, with every build and tester removed before the transfer begins, and any Xcode Cloud data has to be cleared out first as well. Existing push certificates stay valid until they expire, after which the receiving team has to generate a new one, while teams using keys instead need to generate or reuse an APNs-enabled key on the receiving account and then point their push servers at it.
The subtler items catch people out more often. Apple Pay merchant IDs don't travel with the app, so the next update needs a new one created on the receiving account. Sign in with Apple requires a transfer identifier generated for every user in your database beforehand, and grouped apps have to be ungrouped first. Keychain sharing has to be rebuilt against the new team, which signs every user out once. Apps offering auto-renewable subscriptions need an app-specific shared secret generated and passed across. The previous owner also loses App Analytics access for that app and keeps only the sales and payment records from before the transfer, which matters if anyone still needs that history for accounting.
Moving an app on Google Play
Google Play runs a separate process with its own paperwork. Both accounts have to be registered and active, and you need the registration transaction ID for each of them. A newly created receiving account carries the US$25 registration fee, and Google's own documentation says its support team reviews and replies to transfer requests within two business days. Earnings and payout reports, promotions, test groups and integrated service permissions all stay behind, and any app wired into Analytics, Firebase or AdMob needs those connections sorted out on the receiving side before the move rather than after it.
RapidLabs checks this against your actual situation during the takeover audit, because the right sequence changes completely depending on who currently holds the accounts and what state the app is in. Getting the order wrong is how teams end up unable to ship a hotfix during the two weeks they most need one. If your releases are already being held up at review rather than at handover, how long App Store review actually takes is the more useful starting point.
The decision
Should you fix the existing app, rebuild it, or stop?
Most takeovers land in one of three places, and the honest answer usually surfaces within the first few days rather than after a month of exploratory work. The point of paying for an audit is getting that answer in writing before you commit a budget to any of the three.
Fixing in place is the right call when the app runs, the crashes trace back to a handful of identifiable causes, and the build can be reproduced on a clean machine by someone who has never seen it. That last condition does more work than it appears to. A codebase nobody can build without the original developer's laptop is a fundamentally different problem from a codebase that is merely untidy, and the two get confused constantly because both feel equally frightening from the outside.
Rebuilding selected areas fits the case where the app works for users but one part of it, often payments, data sync or the login flow, can't be changed safely by anyone. Replacing that one area while leaving the rest alone costs far less than a full rewrite, and it keeps the store listing, the reviews and the existing install base exactly where they are. Teams reach for the total rewrite far too readily here, usually because the existing code is unpleasant to read rather than because it's genuinely unsalvageable.
Pausing, or stopping altogether, is the recommendation when the app can't be built, can't be signed, and nobody can reach the accounts and services it depends on. That's an uncomfortable conversation, and it's considerably cheaper than six months of paid archaeology on a codebase that was never going to come back. RapidLabs would rather say it in the first week than bill you for discovering it slowly.
Whichever way it goes, the plan comes with numbers attached rather than adjectives. If the recommendation is fixing in place, what mobile app maintenance actually costs sets realistic expectations for what keeping the app healthy runs per month afterwards.
Related
If the app is already crashing or blocked from shipping, mobile app stabilization can start before the handover review is finished. Still deciding whether to fix, rebuild, or walk away? An app maintenance audit gives you that decision in writing. Once the handover is complete and the app is stable, mobile app maintenance keeps a senior engineer on it going forward. Agencies inheriting a client's stalled mobile project can route the same work through an agency mobile partner arrangement instead.
Not sure which of those applies to your app yet? Talk to a senior engineer about your app and you'll get a straight read on the handover risk before anyone quotes you for work.
Mobile app takeover: frequently asked questions
What does a mobile app takeover actually include?
It starts with a review of whatever you can give access to: the codebase, the build and signing setup, the dependencies, the release process, and the App Store Connect and Google Play accounts. The output is a written picture of where the handover risk sits, which release blockers matter first, and whether the sensible path is fixing the app in place, replacing selected parts, or pausing work. RapidLabs maps the risk before proposing any implementation work.
Can you take over the app if the previous developer still owns the store account?
Often yes, but the route depends on who holds what. Apple supports transferring an app between developer accounts while it stays live on the App Store, and Google Play has its own transfer process, so a cooperative previous owner is usually enough. If nobody can reach the previous developer and the app sits in their account, the realistic options narrow to recovering account access through Apple or Google directly, or publishing a fresh listing and accepting the loss of ratings and installs. The takeover audit tells you which situation you are actually in.
Does transferring an app to a new developer account lose its ratings and reviews?
No, an app transferred through Apple's official process keeps its ratings, its reviews and its Bundle ID, and users carry on receiving updates without reinstalling anything. Some things do stay behind: promo codes cannot be generated again afterwards, the previous owner loses App Analytics access for that app, and Apple Pay merchant IDs do not move with it. On Google Play, earnings and payout reports, promotions and test groups also remain with the original account.
What if the previous developer will not respond or hand anything over?
That situation is common enough to have a standard first move, which is establishing exactly what you already control before spending anything on code. Ownership of the store accounts, the source repository, the signing certificates, the backend services and the domain all get checked separately, because teams frequently own more than they think and occasionally own less. RapidLabs works through that list during the audit and tells you honestly which pieces are recoverable and which ones will have to be rebuilt.
How long does a mobile app takeover take?
The takeover audit itself runs three to five business days once access is in place, and access is usually what sets the real pace. Store account transfers add their own waiting time on top, since Apple and Google both run those on their own schedules rather than yours. Any implementation work after the audit gets estimated separately, because a fair number depends on what the review actually finds rather than on a guess made beforehand.
What if the codebase turns out to be too broken to keep?
Then RapidLabs says so early rather than billing for a slow discovery of the same conclusion. A codebase that cannot be built on a clean machine, cannot be signed, and depends on services nobody can access is a different problem from one that is simply messy, and the two deserve different answers. In many cases the honest recommendation is replacing one contained area, such as payments or the login flow, while leaving the rest of the app and its store listing untouched.
Do you take over Android apps as well as iOS?
RapidLabs works primarily with native iOS and Flutter apps, which covers Android where the app was built with Flutter, plus the backend services these apps usually depend on such as Firebase and Supabase. A pure native Android codebase written in Kotlin or Java is worth asking about rather than assuming, and RapidLabs will tell you before any work starts whether it is a genuine fit or whether you would be better served elsewhere.