Articles
React Native or native development?
The right question is not which technology is better, but what your app needs to do. This article separates the cases where each path makes sense, including those where React Native is not the answer.
6 min read
AC Alcateia builds apps with React Native, so it has a side in this discussion. That is why it is worth starting with what usually gets forgotten: the choice of technology rarely decides whether an app succeeds. A poorly trimmed scope sinks a project on any stack.
What changes in practice
Native development means writing the app twice: once for Android and once for iOS, each with its own language, tools and team. React Native means one TypeScript codebase that runs on both systems, using real native components on screen and dropping down to native code when a feature requires it.
The practical consequence shows up in maintenance. With two codebases, every fix is made twice and the platforms tend to drift apart: one gets the new feature before the other, and the difference turns into support work. With one codebase, the fix is made once.
When React Native is the right choice
- Business and operations apps: field data collection, checking, work orders, process approvals.
- Service products: scheduling, orders, tracking, customer areas, loyalty.
- Apps tied to an existing web system that need to share rules and visual identity.
- First versions and MVPs, where reaching users quickly matters more than optimizing what has not been validated yet.
- Small teams: one codebase is the difference between maintaining the product and not being able to.
When native pays off
- Games and apps with heavy graphics or intensive frame-by-frame animation.
- Advanced video, audio or image editing, with continuous processing on the device.
- Heavy use of very platform-specific features, such as deep system integrations, complex widgets or uncommon accessories.
- Companies that already have two mature native teams: switching stacks there is a cost, not a saving.
The middle ground few people mention
React Native is not a closed box. When a feature needs something the library does not provide, the native module can be written in Kotlin or Swift and used from TypeScript, including with the modules of React Native's current architecture. In other words, the decision is not "all or nothing", but where native code is worth it.
What about Flutter?
Flutter solves the same problem in a different way and is a legitimate choice. For most companies, the most practical difference is the surrounding ecosystem: if your team already works with React on the web, React Native reuses knowledge, libraries and even part of the business rule code. If none of that exists, the comparison is more balanced and comes down to who will maintain the app afterwards.
How to decide in five questions
- Does the app depend on continuous graphics performance? If so, consider native.
- Is there a web system that shares rules with it? If so, a React and React Native base saves twice.
- How many people will maintain it a year from now? The smaller the team, the more a single codebase matters.
- How urgent is it to be in both stores at the same time? A single codebase delivers both together.
- Which device features are essential? List them before choosing: that is where the exceptions appear.
Frequently asked questions
Are React Native apps slow?
Apps get slow because of poor decisions, not because of React Native. In practice, slowdowns usually come from poorly built lists, data fetched at the wrong time or unoptimized images, problems that exist just as much in native apps. For the kind of app most companies need, the performance difference is not noticeable to users.
Can a React Native app be published in both stores?
Yes. The app is published normally on the App Store and Google Play, following the same rules and reviews as any other app. Apple's review assesses what the app does, not the technology used.
Can a native app be migrated to React Native gradually?
Yes. New React Native screens can live inside an existing native app. It is worth it when the goal is to stop maintaining two diverging codebases, but it is not automatic: it requires assessing what exists before promising a timeline.
Keep reading
- App development
The service, from scoping to store publishing.
- How much does it cost to build an app?
What changes the price of a project.
- Cases
Projects published by AC Alcateia.
Request a quote
Want to apply this to your project?
Tell us what the app needs to do. The first conversation is free.