Should you modernise or rewrite your Android app?
Every release takes longer. A small change breaks something unrelated. The developer who understood the awkward parts has left. Before committing to a rewrite, work out which problems actually require replacement.
My starting point
I would first assess whether the existing app can be stabilised and improved in useful steps. A rewrite becomes a stronger option when a clearly defined part cannot reasonably meet the product’s requirements, and there is a credible plan to replace it while supporting existing users.
An old language or UI framework, by itself, is not enough to make that decision.
What is actually blocking the product?
“The app is legacy” describes its history. It does not tell you whether the next investment should go into the interface, the build, the backend connection or a difficult handover.
Start with a recent change that was unexpectedly hard. Which parts took the time? Was it understanding the behaviour, waiting for builds, fixing regressions, or getting a release out? Bring the evidence: a failing user journey, a pipeline run, a crash report or the work needed for one feature.
If the main problem is slow feedback from builds and tests, investigate that before replacing product code. Build and test improvements can be scoped separately from an app redesign.
Compare the scope, not just the technology
There are more choices than maintaining everything unchanged or starting again. Use this as a discussion aid, not an automatic verdict.
| Approach | Worth considering when | What to establish first |
|---|---|---|
| Stabilise the current app | A small number of failures or release problems are blocking otherwise useful software. | Can the team reproduce the problem and protect the affected behaviour with suitable checks? |
| Modernise incrementally | The product still fits its purpose, but changes are expensive and some dependencies, modules or screens need attention. | Can one area be improved and released without changing the whole system at once? |
| Replace a defined part | A specific boundary, such as the interface or an integration, needs substantial change. | What remains in place, and how will the replacement preserve the behaviour users depend on? |
| Rebuild the application | The team can show why the current foundation cannot reasonably support the agreed requirements. | Is the scope understood, and can the team support the existing app, migrate users and validate the replacement? |
A representative feature can test the proposed approach. Choose something that crosses the boundaries you are worried about. A polished settings screen will tell you little about an unreliable device connection.
Two examples from my work
J&C Bachmann: modernising alongside continued development
The existing Java application needed ongoing development and a gradual move to Kotlin. My work covered modernising and extending the Android app, alongside its Node.js backend and Vue.js portal.
That is an example of improving an established product while continuing to work across its surrounding platform. It does not imply that every Java application needs replacing. Read the J&C Bachmann project details.
Zuriga: replacing the interface within an existing product
For Zuriga, I took over an existing Kotlin Multiplatform app connected to a coffee machine. I rebuilt the Android and iOS interface with Compose Multiplatform and improved the BLE-related business logic, working with the design team.
The scope was specific: a new interface and improvements to machine communication within an existing product. Calling that simply “a rewrite” would hide the boundaries that mattered. Read the Zuriga project details.
Neither example is a time or cost estimate for your app. They illustrate different scopes of change.
What a replacement has to account for
A new codebase still has to deal with your users’ existing accounts, stored data, device behaviour and integrations. Before comparing proposals, ask what happens to each of those during the transition.
- Existing behaviour: which workflows must stay the same, including the awkward cases that are not written down?
- Data and integrations: what must remain compatible with the backend, local storage, authentication and connected hardware?
- Ongoing support: who fixes urgent problems in the existing app while replacement work is underway?
- Release and recovery: how will the team test the transition, detect problems and recover if an update fails?
Ask for assumptions and exclusions alongside the estimate. “Rebuild the app” is not a useful scope if it leaves migration and ongoing support unaccounted for.
Does moving to Compose require a full rewrite?
No. Android’s Compose migration guidance describes an incremental approach in which Views and Compose coexist. A team can introduce new screens and migrate existing UI over time. That makes a staged UI migration possible; it does not settle the wider architecture or business decision for your product.
What to bring to an initial review
You do not need a perfect specification to start. These questions make the first conversation more useful:
- What does the app do, and which users or devices depend on it?
- Which change or failure is causing the most trouble? Include one concrete example.
- Can the team build and release the current version from the repository?
- Which backend services, hardware connections and local data must continue to work?
- What is the next product requirement, and which deadline or budget constraints are already known?
- Who can explain the current behaviour and maintain the result after the work?
A useful review should help distinguish immediate blockers from longer-term improvements, identify unknowns that need investigation, and define a first piece of work that can be checked against the real product. Agree the review’s scope and outputs before it starts.
Need a second pair of eyes on your Android app?
I offer focused reviews and hands-on modernisation work. Tell me what the app does and what is blocking progress; a short description is enough for an initial conversation.