Will React Native Save You Money? A Word from a Developer

React Native is changing the mobile world. There’s no doubt why “Cut costs in half, and everything will work out beautiful and smooth” attracts mobile app owners to cross-platform technologies. But I would like to put a cat among the pigeons and talk about the development reality from the business perspective. Let’s see a few important factors to consider when choosing the right technology for your mobile app.

When you think about the mobile technology stack from a business perspective, probably the first thing that comes to your mind nowadays is React Native, the framework for building native mobile apps using JavaScript and React, that’s been on everyone’s lips for a while.

React Native allows to share code between platforms, provides the so-called hot reloading of an app so that developers do not waste their pricey time on recompiling the code and cut deployment time because of tools like code push that enables pushing updates directly to users’ devices.

Keeping all of that in mind, you might fall into a trap. You start to think that almost all your code could be shared, everything will look awesome and native, and you’ll cut costs maybe not by 50%, but we’re biased with this number. With this post, I would like to broaden your perspective and put more factors into consideration when developing a mobile app with React Native.

How React Native can affect Design and UX

Let’s start with mentioned code sharing and UI.

“Learn once, write everywhere” – that’s a selling tagline used by React Native itself. I mentioned it because there’s a common misconception about this framework, which you could put in the categories of Write once, use everywhere. and that brings us to UI. You have to really think over the audience of the app, how you want your app to look and maybe what’s most important, how you want your app to feel like.

If you aim for a quick MVP and use a generalized, platform-agnostic UI without overthought using patterns, React Native is the way to go. Despite some minor flaws and differences in styling, UI will be done in no time compared to developing separately for both Android and iOS.

Learn once, write everywhere.

But… In the end, in most cases, you want to provide a product with a native feeling to assure that users blend into the app without thinking how to use or navigate it. And that would bring us to developing separate UI’s for both platforms, still in JS of course, in the name of the slogan Learn once, write everywhere. So if you would like to have a rich, native-feeling UI, you won’t save much on that.

Is my desired feature set right for React Native?

A list of native APIs supported by React Native is growing all the time, but the truth is that it’s still small, and community libraries are sometimes a bit risky to use due to the rapid development of React Native. Since we look at it from the cost perspective, you should find out what your app should really do and how complex it is as quickly as possible.

If the app requires using some complex Map/Localization functions, built-in sensors, advanced Bluetooth, Health Kit, In-App Purchases or other platform-dependent frameworks, then cost-effectiveness of doing that in React Native drops significantly. How come?

First of all, it adds even more complexity. You need additional help from native developers, so they can implement desired features on the native side and create the bridge in order to use those features with React Native. That means instead two developers, we’ve got three.

In my opinion, the less *bridging* you have, the better and more maintainable app you’ll get. Of course, in most cases avoiding it is inevitable, but I would put bridging complexity as a general rule of thumb when choosing React Native as a cost-effective way to develop native apps.

Can I go with only one JS guy?

In general – yes, with additional help from native developers. The amount of their help depends on the bridging needs. Mostly because of some animation flaws and the fact that many native components in React Native are underdeveloped or do not exist. Sometimes it is more efficient to write custom components in native code.

For example, even simple things like flat lists tend to be flaky comparing to native solutions. That’s especially important when app aims to provide flawless native experience. The desired minimal team would be of course 2 React Native developers with the native background. So they can do everything by themselves without engaging more programmers into the project, which always takes extra time. But they are a rare species. Usually, React Native teams consist of developers with web background and native mobile developers added ad hoc.

How about app maintenance?

The maintenance of the app is usually the cost that business owners do not take into account at first. In the case of React Native, it is really important to do so. Even when you use all the advantages that React Native gives to save money on development, they can be easily wasted on the lack of constant maintenance.

This framework is so new and develops so quickly that it is quite normal to introduce breaking changes every quarter at least. You wouldn’t want to leave the app for even six months with no updates. In this case, the technical debt adds up very quickly and it’s troublesome to repay.

The best way to avoid that is to have a good long-term business relationship with the development team so the app is updated frequently. It is extremely important to take those costs into consideration. Of course, apps that are developed natively also have to be maintained, but the source code changes usually once a year, not every month as it is in React Native.

When the costs meet reality

React Native gives a great opportunity to speed up the development of native apps, but it’s not a silver bullet, and may not be the best choice for certain kinds of apps. In my opinion, React Native suits best to platform-agnostic (in the context of UI), content-based apps that mainly use the UI and Networking libraries.

The matter of UI is mostly a business decision, but when it comes to the feature set, reaching out to professionals that have the know-how of development native app in both ways is the way to go. They will assess if desired functionalities match specifics of React Native.

Wrapping up

React Native is mostly chosen because of its cost-effectiveness. But the savings on development are hugely dependent on the UI choices and feature set, which determine a percentage of shared code between platforms and assistance of native developers. May I mention again that you should be aware of higher maintenance costs. Because of React Native’s rapid development, the app might become a legacy one in no time without frequent updates.

Have you been considering the development of your app in React Native? Or maybe you prepare to play it safe and will rather go for surefire native technologies? Share your thoughts in the comments!

P.S. At 10Clouds, we have a bunch of talented and experienced mobile developers working in React Native and native technologies alike. If you’re looking for a team to get your mobile product running, get in touch with us!