Migrating a Fitness App to React Native without Losing 8 Years of Business Logic

Audit first, and be prepared for the answer to be rewrite. This client’s app was on Titanium SDK, and the business logic was interconnected enough that a partial migration would have left two half-systems to maintain in parallel. We reviewed the source code before proposing anything. That review is also where the timeline estimate came from.

The question you are answering is whether the logic inside the app is worth more than the code carrying it. For this client, it clearly was.

By what the product has to do next. React Native was confirmed during the code audit against one requirement the client set: a single codebase serving iOS and Android, because they were entering new markets and could not afford to build every feature twice. Measured against the alternatives on the table in 2018, this saved 40% of development effort.

Different requirements would give a different answer. Deep integration with, or dependencies on, platform-specific APIs, a desktop target, or an existing in-house skill set all change the calculation.

Not if the logic is treated as the specification. The Titanium code could not be ported, so every rule inside it had to be re-expressed in React Native intact: scheduling, client management, progress tracking, workout programming, and the connections between them. Extracting and verifying those rules took longer than writing the React Native code that replaced them.

That is how this project has run since 2018. The client’s developers owned the backend the whole way through. We owned the mobile front end and QA. Later, their engineers joined the mobile work directly alongside ours, which only worked because the interface between the two sides had been agreed first.

Yes. This client did, partway through, and the engagement moved from a dedicated development team to team augmentation. We now supply React Native and QA specialists as they are needed.

Most vendors treat that transition as a downgrade. It is the normal shape of a long engagement: a full team gets you through a migration, and specific skills keep the product moving afterwards.

Pick a style guide stricter than feels comfortable and hold to it. On this project, functionality decisions came from user feedback, so the requirements moved constantly, and two teams were writing in the same repository. The Airbnb React/JSX Style Guide was one of the strictest complete guidelines available in 2018, and we adopted it whole rather than picking from it.

It covers most of it. React Native gave this app native components and custom elements where platform behaviour genuinely differed, and shared everything else. The 80% figure is what that came to in practice in 2018. There is still platform-specific work; there is far less of it.

On this project, eight more years so far. After the upgraded app launched we continued feature development, then shifted to supplying engineers on request as the client’s own team grew into the work. MobiDev’s average client retention is 5+ years, and more than half of our clients have been with us 8+ years.

Yes. React Native was right for this client, not right by default. We also migrate to Flutter and to .NET MAUI, including Xamarin apps that need to come off a stack Microsoft has stopped feeding.

Most of this work arrives the same way this project did: a framework that was a sensible choice years ago and now blocks everything. Titanium here. Cordova, PhoneGap, Xamarin, and old Ionic elsewhere. The audit picks the target, and the answer follows from what the product has to do next, not from which framework we like.

Still viable, and this project is the argument. The codebase we wrote in 2018 is still taking new features in 2026, which is the only durability test that means anything. React Native’s new architecture landed as the default in late 2024, Meta ships it in its own products, and the tooling around it has consolidated.

“Better” depends on the product. Flutter tends to win where the interface is heavily custom and animation-led. React Native wins where you live inside device APIs, on-device ML, or AR. React Native wins where the team already writes JavaScript, where web and mobile should share logic, and where feature velocity across both platforms matters more than squeezing the last frame out of the UI.

The framework question is smaller than the one behind it: which stack can your team still hire for, and still ship on, in eight years.

You rarely need a full rewrite to add AI. You do need a stack that can accept a modern SDK.

The practical order is: audit what your current stack can physically support, put the model work where the data already lives, and modernize only the parts standing in the way. Sometimes that is the mobile front end alone, as here. Sometimes it is one service. Rewriting everything first is the expensive way to find out.

The situation is the same on both platforms, and the roadmap decides it, not the language.

Start here: are you adding a second platform?

If no, stay native. Both iOS and Android let you migrate gradually, so you can move module by module instead of freezing feature work for a rewrite. How smooth that is depends on the existing codebase, so it is worth assessing before you commit to a schedule. Staying native also gets you new OS APIs on release day, first-party toolchains, and no framework layer between you and the device.

If yes, the next question is whether a cross-platform stack covers the functionality you actually need. If it does, one codebase beats building every feature twice. That was this client’s call: they set a single requirement in the audit, one codebase for iOS and Android, because they were entering new markets. If it does not (heavy on-device processing, deep hardware access, platform-specific UI), go native on both and accept the duplication.