Traduttore, traditore

an expression known in the literary world which means translator, traitor. More precisely, it exposes the impossible nature of translation because even the best translation is always far from perfect, and thus can be condemned as a betrayal to the original text. Translation is not an exact science, even the simplest word can never be rendered with its exact equivalent into another language— Kimon Friar.

Cross-platform frameworks, like React Native, act as translators between native platforms and their common interface, and thus, have an impossible task at hand. If you spoke both English and Spanish, would you read Shakespeare in Spanish? Likely not, no matter how awesome the Spanish language is!  Similarly, no matter how awesome React Native may be, all other things being equal, I would choose native over React Native..

If you can go native, go native

Whoa…
that can't be right!
React Native is a very capable solution, with a large number of well known apps built using it, like: Facebook, Instagram, Salesforce, Tesla, Walmart, Pinterest, and many more. In fact, around one third of the projects we build at Rocket Insights are written using React Native, including financial planning apps, healthcare apps, reader apps, etc. But, we have also been asked to port existing React Native apps to native, something I find to be a great reminder that React Native isn't always the best choice for all projects. To avoid such situations, it is important to understand the strengths and limitations of each technology. There are plenty of great posts out there that cover these in detail, instead, I’ll dig a bit further into the meta layer  in search of a quick way to decide if React Native is the right solution for your project.

One of React Native's most attractive features is the ability to write once, run everywhere (not always true in practice, depending on the project's platform specific needs). This is possible because of a layer that sits between the native platform and your code, yet, there is a cost to having a middleman both in terms of performance, and maintenance.  

On one hand, there is a performance cost (at runtime). Negligible for most apps, though it can become a problem for apps that require a lot of UI animations and redrawing. The maintenance cost, on the other hand, has the potential of becoming a big problem, particularly for complex applications with many third party dependencies. Not only do you need to worry about updates to each of the native platforms, but also updates to React Native itself. Oftentimes these updates are quick and simple, other times they are tedious, time consuming, and costly. In some ways this is a fear of the unknown. It is inevitable for things to develop, grow and improve, but in practice, the extra layer increases the risk of complications. For this reason I tend to go native when possible.

Are these risks worth the financial savings of using React Native? I’ve heard numerous times the argument that writing an app in React Native costs half of what is costs to write it natively —i.e. twice: iOS + Android. Except that when you account for other costs —like QA, design, CI/CD, etc.— the difference becomes smaller and smaller. If you then account for the extra maintenance risks mentioned above as well as the development of native modules for more complex apps, all of the cost benefits disappear.

At Rocket Insights, we’ve seen the cost benefits of React Native vs native go from a best case of around 25% savings for small and simple projects, to no cost benefit —or even more costly— for larger / more complex projects. I like to think that in most situations, when considering React Native over native, money shouldn’t be part of the equation!

Then, when is React Native appropriate?

When it was released in 2015, React Native quickly gained popularity. It provided an alternative approach to the existing hybrid solutions at the time. It offered the benefits of being cross-platform, while addressing their biggest limitations and drawbacks.

React Native is similar to other existing platforms in that it uses web concepts and languages to write mobile apps, but different in that the resulting app is a first class citizen —an actual native app with native components. It is in many ways the ideal solution for writing cross-platform mobile apps, and our preferred framework at Rocket when native is not an option.

Going back to the translation analogy, while we wouldn’t read a translation of a language we speak natively, in practice we use translations in our everyday lives to understand things otherwise inaccessible to us. We accept that sometimes what gets lost in translation is not as important as the information itself. Translations broaden the reach of knowledge, which would otherwise remain a prisoner to the limits of its creator’s language.

sometimes what gets lost in translation is not as important

It is no different with React Native, sometimes it’s necessary to accept the tradeoffs.

Thus, these are there are two things I look for when deciding if it makes sense to use React Native:

Peculiarity
The decision would be simpler if there was an easy way to measure how much of the app's needs —present and future— are supported out of the box by React Native, vs how much will require custom implementations. As an agency, having worked on many projects (both native and React Native), we can make a more informed decision, but if I tried to make a rule of thumb, I’d bundle all that complexity as the app’s "peculiarity". Think of it as a level that measures how common and simple vs special and complex an app is.

The more common, the more likely it is that the existing components and features that React Native supports out of the box will be sufficient. On the other hand, if the app has very specific needs, or it has to support the latest features that are very specific to a given OS, then the peculiarity value would be higher. It is a way to measure the risk level of React Native becoming a problem either during development or down the road (because of issues already mentioned).

This is not to say that complex apps can’t be written using React Native, but there is a point where writing native modules for everything is way more costly than just writing the app natively.

Team Expertise
Learning a new language just to be able to understand a book is not practical. Similarly, sometimes it makes more sense to use an existing team that already knows the technology. The ability to tap into an in-house team of web engineers is invaluable. There are, of course, mobile specific traits to be learned, but React plus web development knowledge can be useful. So if you have a team of React developers and no native iOS / Android developers, perhaps writing the app in React Native is for you (assuming there’s no need to write native modules).

Writing an app is a big investment, so it’s natural to look for a solid foundation, one that will not limit the app to reach its full potential, and one that will be as resilient as possible to future changes. Both native and React Native have strengths and weaknesses, and using the right approach can save time, frustration, and money. Native, the more conservative approach, might not always be most efficient way. While React Native’s strengths come at a cost with a higher long term risk of potential complications and lack of flexibility. Understanding these risks, the project vision, and product reach can help your team make the best decision.