Upgrades and maintenance
React Native upgrades, migrations and maintenance
Bringing an app that has fallen behind back onto a current version, with a plan rather than a weekend.
This is the work I get called about most, and it is the work I like. An app that has been running for three years, on a React Native version two years old, with a dependency tree where half the packages have a major release nobody applied. It still works. It also cannot take a new iOS SDK, and nobody wants to be the person who starts.
I have taken apps from React Native 0.63 to 0.79 without breaking the people already using them. The method is unglamorous: read the upgrade diffs between every intermediate version rather than jumping, list the dependencies that will break before touching anything, replace the abandoned ones, and move in commits that each leave the app running.
The same engagement usually turns into performance work, because the reason someone finally calls is that the list drops frames on a mid-range Android. That part is measurement first. Render profiling and CPU traces, then list virtualisation, image pipelines and build size, with numbers before and after rather than an opinion.
What you end up with
- A written audit before any code changes, with the risky dependencies named
- Version upgrade in reviewable steps, each one shippable
- New Architecture adoption where the dependency tree allows it
- Profiled performance work with before and after measurements
- A dependency policy so it does not happen again
Where this has shipped
LexVid
Inara Consultancy Services, 2024 to 2025
Continuing legal education video that keeps working on a train.
How it is built
Multitax
Inara Consultancy Services, 2025
Tax filing on a phone, where the form is a tree rather than a form.
How it is built
The R&I Guys
Inara Consultancy Services, 2025
A social product on both stores, TypeScript from the first commit.
How it is built
Questions
How long does an upgrade take?
The honest answer is that it depends on the dependency list, not the version gap, and I can tell you after an audit rather than before. A codebase with fifteen well-maintained dependencies moves in days. One with a custom bridge module and three abandoned packages takes weeks, and most of that is replacing the abandoned packages, not the upgrade itself.
Will the app keep working for existing users?
That is the whole constraint. Upgrades go out the same way features do: in stages, behind a staged rollout, with the previous build ready to promote back. The versions in between are not shipped to anyone, they are just how the diff stays readable.
Can you just tell us how bad it is?
Yes, and that is frequently the right first step. A fixed-price audit that reads the codebase and comes back with the real state of it, what is safe, what is abandoned, what will break, and what it would cost to fix. You can then hand that document to anyone. It does not oblige you to hire me for the work.
Tell me what you are building.
A sentence about the product and where it is stuck is enough to start. I answer every mail myself, including the ones where the answer is that I am not the right person.