React Native development
One codebase for both platforms halves the ongoing maintenance, and ongoing maintenance is where mobile budgets actually go. The question is only whether your app is the kind that fits — and most business apps are.
Discuss your projectWhen we reach for it
- Apps built from screens, forms, lists and a camera, which covers most business and marketplace applications
- Products that need to ship on both platforms with one team and one release cadence
- Teams already writing React, where the component model and much of the tooling carries across
- Anything where over-the-air updates for the JavaScript layer are a meaningful operational advantage
When we don’t
- Sustained background execution — continuous location, long-running audio — where the native APIs are the substance
- Heavy on-device media or graphics processing, where you would write the native module anyway
- Apps whose entire value is feeling exactly like the host operating system, down to the scroll physics
This half is the useful one. A firm that has never declined to use a technology has never chosen one.
What we have learned about the parts of React Native that bite — written from projects rather than from documentation.
The maintenance argument
Two native codebases means every feature is specified once, built twice, tested twice, reviewed twice and fixed twice. The build cost roughly doubles; the maintenance cost more than doubles, because the two implementations drift and the divergence has to be managed forever.
React Native collapses that, and the collapse compounds over the app’s life. This is the argument that matters — the initial build saving is real but modest next to five years of not maintaining two things.
Where the native boundary sits
React Native is not a sandbox. When a feature genuinely needs the platform, you write a small native module and call it from JavaScript, and having done that a few times you learn which features are worth the boundary and which are not.
What we look for at the start is whether the app’s hardest requirement sits on that boundary. If the single most important thing your app does needs a native module, and there is no maintained community one, the calculation changes and we will say so.
Release mechanics matter more than people expect
A web bug is fixed in twenty minutes. A mobile bug is fixed in twenty minutes and then waits for review, during which every user still has the broken version. Over-the-air updates for the JavaScript layer — within what the platform rules permit — materially change that arithmetic, and are a genuine operational advantage of this approach.
We also assume the first store submission will be rejected and plan for it, because both stores reject builds for reasons that were never in your plan.
React Native, applied
The shapes of system this technology is actually good at, rather than the ones it is capable of.
Usually alongside
- TypeScript
- Expo
- React Navigation
- Reanimated
- SQLite
- Firebase
- Fastlane
- Detox
- Field and workforce applications, including offline-first capture
- Marketplace and commerce apps for both platforms
- Customer self-service apps with authentication and payments
- Delivery and logistics apps built for cheap Android hardware
- Internal tools that need to work away from a desk
React Native, answered
Is React Native as good as a native app?
For the kind of app most businesses need — screens, forms, lists, a camera, some offline capability — the difference is not something users notice, and where it exists it is usually down to implementation rather than to the framework. It becomes noticeable when the app depends on sustained background execution, heavy on-device media processing, or an interface that must match the operating system down to its scroll physics. We assess your specific requirements and say which category you are in before any budget is committed.
Expo or bare React Native?
Expo, for most projects. The managed build service, over-the-air updates and configuration plugins remove a large amount of tooling maintenance that has nothing to do with your product, and the constraints people remember from earlier versions no longer really apply — you can add native code and still use it. Bare makes sense where you have substantial existing native code, or a native dependency with no Expo support, or a hard requirement to control the build environment entirely.
Can you add features to our existing React Native app?
Yes, and the first step is a health check rather than a feature. React Native moves quickly, and an app more than about two versions behind usually has dependency issues that will surface the moment anything is touched — sometimes as a build that will not produce a store-compliant artefact at all. We assess version currency, store compliance and dependency health first, tell you what needs doing before feature work is safe, and then get on with the features.
Where this shows up
- BuildMobile App DevelopmentReact Native when one codebase is genuinely enough. Native when it isn’t — and we will tell you which before you commit a budget.Read more
- GrowUI/UX DesignProduct design and design systems. Usually the first thing that turns out to be wrong, and the cheapest thing to fix.Read more
- RunQA & Software TestingAutomated regression suites where they pay for themselves, and exploratory testing where they don’t. We tell you which is which.Read more
Building with React Native?
Whether it is a new build, a takeover or a second opinion on an architecture someone else chose — the first conversation is free and we will tell you if the stack is wrong for the job.