Why React Native
- Shared skills — React developers can contribute to the mobile app, so one team covers web and mobile.
- Shared code — business logic, API clients, validation and design tokens can be reused across web and mobile.
- Native UI — components render to real iOS and Android views, and the New Architecture improves performance.
- Fast updates — over-the-air updates for JavaScript changes, within store rules.
Expo or bare React Native?
For most new apps we start with Expo, which speeds up builds, updates and access to device APIs, and still allows custom native modules. Bare React Native makes sense for apps with unusual native requirements or existing native codebases.
What we build
Companion apps for web products
Mobile versions of your SaaS or portal using the same APIs.
Marketplaces & on-demand apps
Listings, real-time status, chat and payments.
Membership & community apps
Content, events, messaging and subscriptions.
Internal tools
Approvals, inspections and dashboards for staff on the go.
Our React Native stack
Sharing code between web and mobile — realistically
A common hope is “write once, run on web and mobile”. In practice, the biggest savings come from sharing everything that is not user interface: API clients, data models and TypeScript types, validation rules, business logic, feature flags and analytics events. These typically represent a large share of an application’s complexity, and sharing them means a bug fixed once is fixed everywhere.
User interface is usually written separately for web and mobile, because the interaction patterns differ — hover states, keyboard navigation and large screens on the web; gestures, bottom tabs and native transitions on phones. A shared design-token package keeps colours, typography and spacing consistent across both. We organise this in a monorepo so web and mobile teams work from the same source of truth.
Keeping React Native apps healthy
React Native moves quickly, and apps that are not upgraded regularly become difficult to update. We keep the framework and key libraries on supported versions, prefer well-maintained libraries with New Architecture support, and monitor crashes and performance with Sentry or Crashlytics. For older apps stuck on outdated versions, we plan stepwise upgrades, often moving them to Expo to simplify builds and future upgrades.
React Native, Flutter or native?
React Native is one of several good ways to build a mobile app. The right choice depends on your team, your product and how much of it you want to share with the web.
| React Native | Flutter | Native (Swift / Kotlin) | |
|---|---|---|---|
| Language | JavaScript / TypeScript | Dart | Swift and Kotlin |
| UI approach | Real native components | Own rendering engine | Platform UI frameworks |
| Code sharing | iOS, Android and some web logic | iOS, Android, web and desktop | None between platforms |
| Best fit | Teams with React or TypeScript skills | Highly custom, brand-led UI | Device-heavy or performance-critical apps |
| Hiring | Large JavaScript talent pool | Growing Dart community | Separate iOS and Android specialists |
We help you choose honestly — see Flutter development and cross-platform development for the alternatives.
The New Architecture and performance
Modern React Native has moved to what the project calls the New Architecture: a new rendering system and a faster way for JavaScript to talk to native code. The practical result is smoother animations, quicker startup and native modules that are easier to write. New projects use it by default, and older apps can usually be upgraded in stages.
- Hermes engine — compiles JavaScript ahead of time for faster startup and lower memory use.
- Efficient lists — virtualised lists such as FlashList keep long feeds smooth.
- Animations on the UI thread — Reanimated and gesture libraries avoid stutter during heavy JavaScript work.
- Image handling — caching and correctly sized images, which are a common cause of slow screens.
- Profiling — measuring on real mid-range Android devices, not just the latest iPhone.
When you need native code
Most features are covered by mature community libraries, but some apps need direct access to platform capabilities. In those cases we write native modules in Swift or Kotlin and expose them to the React Native code, so the rest of the app stays shared.
- Custom Bluetooth or hardware integrations
- Background processing beyond standard libraries
- Home-screen widgets, watch apps and app extensions
- Platform payment, wallet or identity features
- Performance-critical media or camera processing
How a React Native project runs
-
Discovery & design2–3 weeks
User flows, design system and decisions on Expo, navigation and state management.
-
Foundations1–2 weeks
Project setup, authentication, API layer, error tracking and CI/CD with automated store builds.
-
Feature sprints2-week cycles
Working builds on test devices every sprint through TestFlight and Google Play internal testing.
-
Hardening1–2 weeks
Accessibility review, performance profiling, crash fixes and store listing preparation.
-
Launch & iterate
Phased store release, monitoring and a prioritised backlog for the next version.
Questions to ask a React Native partner
- Which React Native and Expo versions do you start new projects on, and how do you keep them current?
- How do you test on real Android devices, not just simulators?
- When would you recommend writing a native module instead of adding a library?
- How do you handle over-the-air updates without breaking store rules?
- Who owns the Apple and Google developer accounts and signing keys?
- What does your hand-over include if we bring development in-house later?
If you need engineers to join your own team instead, see hire React Native developers.
State, data and offline support
Most React Native complexity lives in how data moves through the app. We keep it predictable with a small set of proven tools: TanStack Query or a similar library for server data and caching, a lightweight store such as Zustand or Redux Toolkit for app state, and a local database such as SQLite or WatermelonDB when the app must work offline.
- Optimistic updates so actions feel instant
- Background sync and retry when the connection returns
- Conflict rules for data edited on several devices
- Secure storage for tokens using the Keychain and Android Keystore
These decisions are made in the first weeks of the project because they are expensive to change once many screens depend on them.
We also document every architectural decision as it is made, so a future team — yours or ours — understands why the app is built the way it is and can change it with confidence.
That record is part of the hand-over package, alongside setup guides and release instructions.
Timeline and budget
| App type | Typical timeline | Typical budget (USD) |
|---|---|---|
| MVP for both stores | 10–14 weeks | $35k – $75k |
| Mobile companion to an existing web app | 8–14 weeks | $30k – $70k |
Typical ranges to help you plan. Your written estimate comes after a free discovery call.
Hiring React talent for your own team? See hire React developers.
This page is part of Mobile App Development Services — see the full overview for related services, approach and pricing.