When a business asks for an app "on iPhone and Android", the first technical decision is whether to build it once with a cross-platform framework or twice, natively, in Swift for iOS and Kotlin for Android. I build most client apps in React Native, including Pro Clean+, the NeonTask technician app and Local Meals. That is not because native is bad. It is because, for the kind of apps most businesses need, React Native gives a better balance of cost, speed and quality.
Here is how I think about the choice, including the cases where I would not use React Native.
What React Native actually is
React Native lets you write the app in JavaScript or TypeScript using React, and renders real native UI components on each platform. It is not a web page in a wrapper. Buttons, lists, text inputs and navigation are native views, and you can drop down to Swift, Kotlin or Objective-C for anything that needs it.
In practice most of the code is shared between iOS and Android. Some parts are platform-specific: permission prompts, certain UI conventions, push notification setup, store configuration.
Where React Native wins
One team, one codebase. A feature is designed, built and tested once for both platforms. Bug fixes land on both at the same time. For a small business or a startup, that alone often decides it.
Shared knowledge with the web. If your admin panel or website is in React or Next.js, as many of mine are, the same language, patterns and sometimes code (validation rules, types, API clients) can be shared. That keeps the whole product consistent.
Fast iteration. Development is quick, with fast reloads while building. For product teams still finding out what users want, faster iteration is worth a lot.
Over-the-air updates for JavaScript changes. Some fixes can be delivered without a full store review, within the stores' rules. Native code changes still need a normal release.
Mature ecosystem. Navigation, maps, camera, image picking, local storage, push notifications and payments all have well-maintained libraries.
Where native still makes sense
Heavy graphics, games or advanced animation. If the core of the app is a 3D scene, a game loop or complex real-time graphics, native or a game engine is the right tool.
Deep platform integration. Apps that live inside the OS, such as complex widgets, watch apps, car integrations, advanced background processing or unusual hardware access, involve a lot of native code anyway. At some point the shared part is too small to justify the framework.
Brand-new OS features on day one. Native code gets access to new Apple and Google APIs immediately. Cross-platform libraries usually follow, but not always on day one.
A team that is already native. If you already employ strong iOS and Android engineers, rewriting their world in React Native rarely makes sense.
Performance: the real picture
Performance worries usually come from older experiences. For business apps, forms, lists, maps, bookings, catalogues, photos, chat, a well-built React Native app feels native to users. Where it struggles is usually caused by how it was built: rendering huge lists without virtualization, doing heavy work on the JavaScript thread, or loading giant images. These are fixable engineering problems, not limits of the framework.
If your app needs to process video frames in real time or run heavy computations on the device, that part can be written natively and called from React Native.
Cost and time
Two native apps mean two codebases. Even with shared design and backend, you are building, testing and maintaining each feature twice. React Native removes most of that duplication. It does not remove all of it: you still test on both platforms, configure both stores and handle platform differences. The saving is real, but it is not a clean half.
The bigger cost difference shows over time. Every feature, every bug fix and every redesign for the life of the app happens once instead of twice.
What about Flutter?
Flutter is the other serious cross-platform option, and it is a good framework. The choice between Flutter and React Native usually comes down to the team and the rest of the stack. I prefer React Native because it shares a language and mental model with React and Next.js on the web, which I use for admin panels and websites. For a product with a web side, that is a practical advantage.
A practical way to decide
Ask these questions about your app:
- Is the core of the app forms, lists, content, maps, booking, ordering, messaging or dashboards? If yes, cross-platform is a strong fit.
- Does it need a web admin or website too? If yes, React Native plus React or Next.js keeps everything in one ecosystem.
- Is the main feature heavy graphics, real-time media processing or deep OS integration? If yes, consider native for that app.
- Do you need to be first on new OS features? If yes, native has an edge.
- Who maintains it in two years? A single codebase is easier to hand over.
For most businesses asking for an app, booking, delivery, catalogues, loyalty, field work, internal tools, the answers point to React Native.
What a good React Native project looks like
Choosing the framework is the easy part. What makes the app good is how it is built:
- TypeScript throughout, so mistakes are caught before users see them.
- A clean API layer, with the backend doing the business logic. For example, a .NET Core or Next.js API that the app and the admin share.
- Proper handling of slow and dropped connections. On mobile data almost anywhere this is not optional, see offline-tolerant apps.
- Right-to-left support from the start if Arabic is needed.
- Crash reporting, so you know when something breaks.
- A repeatable build and release process for both stores.
A note on upgrades
React Native moves quickly, and so do its libraries. A project that skips upgrades for two years can face a painful jump. Budget for regular, small upgrades as part of maintenance, the same way you would for any framework. Native apps have the same issue with yearly OS and SDK changes, so this is a cost of having an app, not a reason to avoid React Native.
Summary
Use React Native when your app is mostly business logic and UI, you want both platforms, and you want one team to own it for years. Use native when the heart of the app is graphics, hardware or deep OS features. If you are not sure which your app is, it is almost always the first.
If you are deciding how to build your app, have a look at my work and get in touch. I can help you choose based on what your app actually needs to do.