Native iOS and Android app takeover
A native app has two codebases, two toolchains and two sets of store rules, and an old one usually fails all of them at once: Objective-C or early Swift that current Xcode rejects, Java or early Kotlin that won't target current Android, and accounts and keys in the developer's name. Solve With Software takes both codebases over, brings each up to what the stores accept now, moves the accounts and keys into your name, and then modernises the app in stages or rebuilds it once in Flutter with the backend kept, on a fixed price from the assessment.
Free · 1 hour · no obligation
Why a native app stalls
Because the platforms move every year and the app didn't. Apple raises the minimum Xcode and SDK for App Store uploads each spring; since April 2026 that's Xcode 26 and the iOS 26 SDK. Google raises the target Android version each summer; from August 2026 updates must target Android 16, and apps that don't target Android 15 stop being visible to new users. An app last built in 2020 fails both, and the longer it's left, the more deprecated APIs, removed frameworks and changed permissions stand between it and a build.
Add the human side: the developer who knew the Objective-C left, the Swift is a version nobody has the toolchain for, and the Android project opens in a Gradle version that no longer exists.
What we usually find
Two projects in different states. The iOS one in Objective-C, or Swift from a version several majors back, using frameworks Apple has since removed. The Android one in Java with a support library that became AndroidX years ago, and a build that fails before it starts. A shared backend that's usually fine. Certificates that expired. A keystore on someone's old laptop. A Firebase project in the developer's account.
The app's logic and design are usually worth keeping. The toolchain around them has moved on without them.
The accounts and keys you need to own
This matters more for native apps than anything else, because there's no way around it. The Apple Developer account and App Store Connect access, the signing certificates and provisioning profiles. The Google Play Console account, the upload key, and whether Play App Signing holds the app signing key or the developer did. Push certificates. The backend and Firebase accounts. Third-party SDK keys.
If the Android signing key is lost and Play App Signing was never enabled, the existing listing cannot be updated and the app has to be republished as a new one, losing its reviews and its install base. Establishing where the keys are is the first thing the assessment does.
The paths
Take it over and get it building. Both projects into your repository. Current Xcode and Android tooling. The deprecated and removed APIs replaced, one at a time, until each project builds and passes the store checks. Accounts and keys moved into your name. Builds into the test tracks. This is the first stage, always, and it's the one that makes updates possible again.
Modernise in place. Objective-C to Swift and Java to Kotlin file by file, with the app shipping throughout. Newer frameworks (SwiftUI, Compose) for new screens while old screens stay until they're rebuilt. The right path when the app has a long future on both platforms and the native experience matters.
Rebuild once in Flutter. One codebase for both platforms, the backend and the design carried across, the two old projects retired when the new one has proven itself through the test tracks. The right path when the app is small, when maintaining two native codebases is the thing the business can't sustain, or when both projects need so much work that a rebuild is cheaper. We build in Flutter, and the assessment compares it on cost.
The assessment gets both projects building, audits the accounts, and prices each path as a fixed number.
Your data
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, with the previous version still live until the new one is trusted.
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 native app it gets both projects building in a clean environment, lists what the stores reject, establishes the accounts and keys, and prices the takeover, the modernisation and the rebuild as fixed numbers. What drives the price and the payment terms each have a page.
The risks of waiting
An app that can't ship a fix, because it can't be built for what the stores accept, which is the position of most apps last built before 2024. An app that disappears from Google Play search for new users because it targets an old Android. A lost keystore. A lapsed developer account, which takes the app off the store entirely. And the annual step-up in requirements that makes every year of delay more expensive than the last.
How we approach it
Keys and accounts first, then a build on each platform, then the decision between modernising two codebases and rebuilding one. Marc Allington has built native iOS and Android apps and builds mobile apps in Flutter now, so the comparison is made from both sides. 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 native app takeover
| Check | Why it matters |
|---|---|
| iOS: language and version (Objective-C, Swift N), and does it build with current Xcode? | The distance to a build the App Store will accept. |
| Android: language, Gradle and target SDK, and does it build with current tooling? | The distance to a build Google Play will accept. |
| Apple Developer account, certificates, profiles: whose name, do they exist? | Without them no iOS build ships. |
| Google Play account, upload key, Play App Signing | A lost key without Play App Signing means a new listing. |
| Deprecated and removed frameworks and APIs in each project | The size of the first stage. |
| Backend, Firebase, push, third-party SDKs and their keys | Each is a dependency and a credential. |
| Store status: last release, current targets, visibility, pending rejections | How far from shippable it is today. |
| Shared logic between the two projects | Decides how much a Flutter rebuild would save. |
Each answer goes into the report with its stage and a fixed price.
Questions
What people ask before they book.
Do you handle both iOS and Android?
Yes. A native app is two projects and they're taken over together, because the accounts, the backend and the release process are shared even where the code isn't.
We don't have the Android signing key. 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, which loses reviews and installs. Establishing which is the first thing we do.
Should we rebuild it in Flutter?
Sometimes. One codebase instead of two is a real saving if the app is small or both projects need heavy work. It's a worse answer when the app depends on native features that matter. The assessment prices both and says which.
It's Objective-C. Can that still be built?
Yes. Current Xcode still compiles Objective-C. What usually fails is the removed frameworks and the changed permissions around it, which are fixed one at a time until the project builds and passes the store checks.
How long until we can ship an update?
It depends on how far each project is from a build the stores accept, and whether the keys exist, which the assessment measures. The shape is the usual one: both platforms in the test tracks within about six weeks, then 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. .