What React Native is
A way to build genuinely native iOS and Android apps in JavaScript and React. The interface elements are the real platform ones, not a web page in a wrapper, so it looks and scrolls like an app because it's one.
technologies / react native
One codebase, both stores, when that's honest.
iOS and Android from shared code, including an app of our own. We use it where it genuinely fits and say so where native is the better answer.
why react native
What sharing a codebase actually saves.
The saving is real but it's not fifty per cent of everything, and anyone promising that has not shipped one.
Budget
Most screens written once
Forms, lists and navigation are shared. The saving is largest in the parts that are the same on both platforms.
Team
The same people as the web
React and TypeScript skills carry over, so a web team can maintain the app instead of hiring twice.
Native
Native modules where needed
Bluetooth and background work drop to native code. Our own tag-scanning app does exactly this.
Releases
Ship both at once
One pipeline builds and submits both platforms, which keeps versions from drifting apart.
01
What we build with React Native
Apps for iOS and Android from one codebase
One team, one language, both stores. For most business apps the platform differences are small enough that this is simply cheaper.
Apps that talk to hardware over Bluetooth
Our own app pairs, provisions and reads the tags we built. Bluetooth in React Native is real work, and we have done it.
An app on top of an existing web product
Reusing the validation, pricing and API layer you already have rather than writing a second version of your business rules.
Offline-capable field apps
Inspections, deliveries, stock counts, where the phone must keep working with no signal and reconcile later.
Taking over an app whose developer has gone
We start with a build: getting the thing to compile and ship from a clean machine is usually the first real problem.
the essentials
What React Native actually is.
Written for someone deciding, not for someone who already knows. Skip it if you do.
Why one codebase is worth it
Because most of an app isn't the platform-specific part. Screens, navigation, state, API calls and business rules are written once, and the ten per cent that genuinely differs is written twice on purpose. That's close to half the cost of two native teams.
Where it stops being the right answer
Heavy graphics, games, serious video or audio processing, or an app whose whole appeal is a platform feature the moment it ships. For those, native is the honest recommendation and we'll make it.
The maintenance reality
React Native releases often and depends on native modules that lag behind. An app left untouched for two years is a difficult upgrade rather than an impossible one, but the stores force your hand: Apple and Google both require builds against recent SDKs, so an app that's never updated eventually can't be updated.
Store
You can't ship an update
Usually an SDK requirement you have missed, or a build nobody can reproduce. Both are fixable and both get worse with time.
Cost
Two native teams building the same screens
Worth an honest comparison. Sometimes two teams is right; often it's history rather than a decision.
Version
React Native 0.68 or older
Before the new architecture. The upgrade path exists but lengthens every release you skip.
questions
Straight answers.
Will it feel like a real app?
Yes for the great majority of applications. Users notice bad design far more than the rendering layer. Where an interaction has to be perfectly smooth, that screen can be native.
When would you refuse React Native?
Heavy real-time graphics, deep platform integration, or an app whose entire value is one demanding native feature. We'll say so before you commit budget.
Can it use Bluetooth and the camera?
Yes. Our own tag-tracking app scans Bluetooth devices continuously in the background, so this is ground we have covered.
Will it feel like a real app?
Yes, because it's one. The controls are the platform's own. What gives an app away is usually lazy navigation and missing loading states, not the framework.
Can we start with the app and add a web version later?
Yes, and sharing the logic layer between them is the point. It's worth deciding that at the start so the boundaries are drawn in the right place.
Tell us what you want to build or improve.
A few lines are enough to start. You get a reply within two working days.