Replatforming an old mobile app without losing your users

01Why mobile rewrites fail differently

A web rewrite can run behind a router split, with a percentage of traffic on the new implementation and instant rollback. Mobile has no equivalent - the user has one app, and you replace it wholesale.

That means the usual de-risking tools are unavailable and the release is all-or-nothing. Combined with store review and slow adoption, a bad rewrite release is weeks to recover from.

It also means feature parity is not negotiable in the way it is on web. Users who lose a feature they relied on leave a one-star review, and the aggregate rating is slow to recover.

02The sequence that keeps you shippable

Incremental migration is possible on mobile and is nearly always the right call for an app with real users.

• Start by extracting business logic out of the UI into plain, testable code. This is valuable whether or not you complete the migration, and it is the largest single reduction in rewrite risk.
• Introduce the new framework alongside the old one for a single, low-risk screen. Both major cross-platform frameworks support embedding into an existing native app.
• Migrate screen by screen, shipping each in a normal release. Users see incremental change rather than a new app.
• Keep navigation authoritative in one place during the transition, or the two stacks will disagree about back behaviour in ways users notice immediately.
• Stop when the remaining screens are stable and rarely changed. Full migration is a goal, not an obligation.

03What to fix while you are in there

A replatform is the cheapest moment to fix things that are hard to change later - the data layer, the navigation contract, the analytics schema. These are structural and touching them separately costs more.

It is also the moment to remove features nobody uses. Migrating dead surface is pure cost, and usage data usually shows a meaningful fraction of screens with negligible traffic.

Resist the temptation to redesign simultaneously. Changing the implementation and the interface at once makes every regression ambiguous - you cannot tell whether something is broken or intentionally different.

04Judging whether it is worth it

Replatform when the current stack blocks hiring, when the framework no longer receives security updates, or when routine changes take multiples of what they should. Those are structural reasons.

Do not replatform because the code is unfamiliar or the framework is unfashionable. A boring app that ships reliably is not a problem to be solved, and the users cannot tell what it was built in.