React Native
One team, two platforms, until the hardware disagreed.
Three shipped apps, one shared web-and-mobile team, and a clear line where the framework stopped being enough on its own.
The verdict
For a product with mostly forms, lists and dashboards, React Native is a good default, because one team ships iOS and Android together. Where a screen depends on a sensor, a camera, or a platform-specific permission flow, budget separate native work rather than trusting the bridge to cover it.
We have shipped React Native on ExtraaJe, Shift Link and TankAware. All three needed a phone in someone's hand. An employee checking points on a shift, a healthcare worker clocking in, a contractor logging a tank reading on site. None of them were simple form apps by the end.
The shared codebase held for navigation, lists, and most of the UI. It stopped holding once the app had to read a sensor, verify a face, or behave correctly with no signal. That is where a build slows down, and it is worth planning for before the estimate is set.
In short
5 things that decide this
- 01One React Native codebase covered iOS and Android for standard screens on all three apps, and let the same engineers work the web dashboard and the mobile app.
- 02TankAware reads live IoT tank-level sensors from petroleum sites, some with weak or no signal, which forced local queuing and retry logic the framework does not provide out of the box.
- 03Shift Link's clock-in uses GPS and facial recognition. Both needed native modules and platform-specific permission handling that plain React Native components could not do alone.
- 04Upgrading the framework version across three apps has never been a one-line bump. Native dependencies and OS permission changes force a real test pass every time.
- 05ExtraaJe is the clean case: a rewards app with no sensors, where one Supabase backend served both the React web dashboard and the React Native app with almost no platform-specific code.
For someone comparing mobile frameworks
React Native lets a team write one JavaScript codebase and ship real iOS and Android apps, not web pages in a wrapper. Most UI code runs once and renders through each platform's native components. A list or a button looks and scrolls like the platform it is on.
The gap shows up at the hardware. Camera access, background location, biometric prompts and hardware sensors each have their own iOS and Android APIs. React Native reaches them through native modules, either from a library or written by hand, and that code is platform-specific by nature.
Where it stands
Good at
- One team ships both platforms. On ExtraaJe, the same engineers who built the React web dashboard also shipped the mobile app, against one Supabase backend.
- Standard app screens, forms, lists and navigation, come out fast, because the component model is the same one a React web team already knows.
- A large library ecosystem covers common device needs before a team has to write a native module from scratch.
- Over-the-air updates can ship a JavaScript fix without a new app-store review, which matters when a compliance rule changes and a store review would take days.
Weak at
- IoT and sensor data do not fit cleanly. TankAware reads tank-level sensors from petroleum sites with unreliable connectivity, and the JavaScript bridge does not queue or retry data on its own. We built that logic ourselves.
- Camera and biometric features push past the framework fast. Shift Link's GPS and facial-recognition clock-in needed native modules and separate permission handling on iOS and Android, not a shared component.
- Upgrading the React Native version is not routine. Native dependencies and OS-level permission changes mean every upgrade across our three apps needed a full manual test pass, not an automated one.
- Field conditions expose the gap between a demo and a working app. A contractor on a petroleum site with no signal is a real test case a simulator does not cover, and TankAware needed offline handling that took real engineering time.
What we run it on, and where native code stepped in
ExtraaJe is a gamified rewards app for a European workforce. Employees check points and redeem rewards from their phone; HR runs the rules from a React web dashboard. Both sit on one Supabase backend. The mobile app needed almost no native code beyond standard notifications, since there was no sensor or biometric requirement to work around.
Shift Link is a workforce compliance platform for healthcare and logistics staffing. Workers clock in with GPS and facial recognition, and documents are checked and tracked for expiry automatically. The clock-in flow needed native camera and location modules on both platforms, tuned separately for each one's permission prompts.
TankAware is the hardest case. It is an AI and IoT platform for petroleum site inspections, streaming real-time data from tank-level sensors. Many sites sit out in the field with weak signal. The mobile app had to queue readings locally and sync when connectivity returned, which React Native does not give you by default.
- Screen typeForms, lists, dashboards stay in shared React Native components.
- Hardware accessCamera, GPS, biometrics or sensors push the screen toward a native module.
- ConnectivityField conditions with weak signal need local queuing the framework does not provide.
- DecisionShared code by default. Native modules where the OS, not the UI, decides what is possible.
TankAware's sensor sync and Shift Link's clock-in both landed on the right of this line. ExtraaJe stayed almost entirely on the left.
Production builds on this stack
Common questions
01Is React Native good enough for production in 2026?
Yes, for most app shapes. It has run three of our production apps across forms, dashboards and live data screens. It stops being enough on its own once your screen depends on a sensor, a camera or a biometric prompt, where native modules do the real work.
02Can React Native handle IoT or sensor data?
It can, but not without extra engineering. TankAware streams tank-level sensor data from petroleum sites with patchy connectivity, and we had to build local queuing and retry logic ourselves. The framework does not include that out of the box.
03Does React Native save time over building two native apps?
For the shared parts, yes. One team built ExtraaJe's web dashboard and mobile app together against one backend, a real saving when you are staffing the build. That saving shrinks on apps like Shift Link, where camera and location features needed separate native work on each platform anyway.
04How risky are React Native version upgrades?
Riskier than a typical web dependency upgrade. Native modules and OS permission changes mean every upgrade across our three apps needed a full manual test pass on real devices, beyond the automated one.
Related
- Hire React Native developers →Engineers who have shipped React Native against sensors, cameras and offline field conditions.
- React Native vs Flutter →The cross-platform decision this review sits next to.
- Native vs React Native →When a fully native build earns the extra work over one shared codebase.
- Mobile app development →How we scope a mobile build before picking the framework.
