React Native app takeover
A React Native app that nobody can build is a common handover failure: the agency had the right Node, Xcode and Android tooling, and none of that came with the code. Meanwhile the stores moved. Since April 2026 the App Store requires builds from Xcode 26, and from August 2026 Google Play requires updates to target Android 16. Solve With Software takes the code into your repository, gets it building on current tooling, moves the accounts and keys into your name, and upgrades the app in stages so updates ship again.
Free · 1 hour · no obligation
Why a React Native app stalls
React Native moves fast, and an app pinned to a 2021 version has a lot of ground to cover. The native modules it depends on have been replaced or abandoned. The Expo SDK it was built on, if it used one, has had several majors since. The new rendering architecture became the default in late 2024, and older native modules don't work with it.
Then the stores add their own clock. An update that can't be built with current Xcode can't be uploaded to the App Store. An update that doesn't target current Android can't be published on Google Play. So an app that runs fine on customers' phones today can't be changed at all, which is the definition of stuck.
What we usually find
JavaScript that's readable and a project that won't build. Node pinned to nothing. A lock file from the year it shipped. Native modules with no maintainer. A Podfile that resolves to versions Xcode won't accept. Signing certificates that expired. A Google Play keystore on the agency's machine. Push notifications through a Firebase project in the agency's account.
The application logic is usually fine. What's missing is a home, current tooling, and the keys.
The accounts and keys you need to own
Mobile apps have an ownership problem that web apps don't. The Apple Developer account, App Store Connect access, the signing certificates and provisioning profiles. The Google Play Console account and the upload key, plus whether Play App Signing holds the app signing key or the agency does. The Firebase project for notifications and often for the backend. The push certificates. Any third-party SDK keys.
If the Android upload key is lost and Play App Signing was never enabled, the app cannot be updated under its existing listing at all. That's the single most important thing to establish on day one, and the assessment does.
The paths
Take it over and get it building. Repository in your organisation. Node, Xcode and Android tooling pinned to versions that work. Accounts and keys moved or re-established. A build that runs on a clean machine for both platforms, then through the test tracks. This is the first stage, always.
Upgrade in stages. React Native version by version with the official upgrade helper, native modules replaced where abandoned, Expo SDK brought current if it's an Expo app. Each step builds and ships to a test group before the next.
Rebuild in Flutter. When the codebase is small and the upgrade would touch most of it anyway, or when the native modules can't be replaced. The backend and the design carry across. We build in Flutter, so this is a path we'd take ourselves, and the assessment says whether it's cheaper than the upgrade for your app.
The assessment gets the app building, audits the modules and the accounts, and prices each path as a fixed number.
Your data
Usually behind an API or in Firebase, and it stays where it is, in an account you own. Nothing reaches your users until it has proven itself somewhere else: a build tested against a staging backend, released to a test group through TestFlight and the Play internal track, then to the store.
What it costs
The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a React Native app it gets the project building in a clean environment, audits the native modules and the accounts, and prices the takeover and the upgrade as fixed numbers. What drives the price and the payment terms each have a page.
The risks of waiting
Two dates that have already passed: Xcode 26 for the App Store since April 2026, Android 16 targeting for Google Play from August 2026. An app that can't meet them can't ship a fix. After that: an operating system update that breaks something in the app and no way to respond, a lost keystore, a lapsed developer account, and modules whose vulnerabilities nobody is patching.
How we approach it
Keys and accounts first, then a build, then stages. Marc Allington builds mobile apps in Flutter and has taken over React Native codebases, so the trade-off between upgrading and rebuilding is one we make on evidence rather than preference. Everything we build runs in your own accounts, with full source code and ownership transferring to you on final payment.
The technical checklist for a React Native takeover
| Check | Why it matters |
|---|---|
| React Native version, Expo or bare, and whether it builds on a clean machine | Sets the upgrade distance and the first failure. |
| Native modules: which, which are abandoned, which work with the new architecture | The upgrade's real cost. |
| Apple Developer account, certificates, profiles: whose name, do they exist? | Without them no iOS build ships. |
| Google Play account, upload key, Play App Signing: whose name, is the key findable? | A lost key without Play App Signing means a new listing. |
| Backend: API or Firebase, in whose account | The data and the notifications live here. |
| Store status: last release, current targets, pending rejections | How far from shippable it is today. |
| Push, analytics, crash reporting, third-party SDKs and their keys | Each is a dependency and a credential. |
| Tests and CI | Usually none. The safety net comes before the first upgrade step. |
Each answer goes into the report with its stage and a fixed price.
Questions
What people ask before they book.
Why won't our React Native app build?
Usually tooling. The agency's machine had the right Node, Xcode and Android versions and yours doesn't, and the project pins none of them. Getting it building on a clean machine with pinned versions is the first job and tells us everything else.
We don't have the Android keystore. Is the app lost?
If Play App Signing was enabled, no: Google holds the signing key and the upload key can be reset. If it wasn't, the existing listing can't be updated and a new listing is needed. Establishing which is the first thing we do.
Would you rebuild it in Flutter?
Only if the assessment shows it's cheaper than upgrading, which happens when the app is small or its native modules can't be replaced. We build in Flutter ourselves, so it's a real option, not a sales pitch.
It's an Expo app. Does that help?
Usually, yes. Expo handles a lot of the native tooling, and bringing an old Expo SDK current is a known path. Old Expo apps that ejected are the harder case.
How long until we can ship an update?
It depends on how far the versions have drifted and whether the keys exist, which the assessment measures. The shape is the usual one: a build in the test tracks within about six weeks, then upgrade stages, each priced before you commit.
Start with a free consultation
An hour on your system, online or by phone. From there we size the assessment, from £395 + VAT, and give you an exact price before you commit.
Want the numbers first? See how pricing works.
Written by Marc Allington, founder. .