Code Reusing Made Easy with React Native

Code Reusing Made Easy with React Native

React Native has really become a hot topic in the last few months. As a product owner or technical director, you’re probably wondering why it’s getting so popular. What kind of problems with mobile app development does it solve? Let’s assume you’ve got a greenfield project you need to ship in couple of months. Why is React Native worth checking out before you decide to go fully native, or opt for the web-view solution? Let’s find out.

The technology

The concept of a multi-platform app isn’t something completely new. We’ve already had the opportunity to observe the rise of wonderful ideas behind Ionic, Cordova and Xamarin. Even though those frameworks have brought a lot to the mobile market, none of them could dominate over native apps. When I first saw the concept of React Native at a React.js conference last year, I knew I’d have to put my hands on it at some point. That was mostly because React Native seemed to solve two major inconveniences I experienced during Ionic app development: performance and native feel. Indeed, the new tool seemed to be better at those. Later, I found there’s more amazingness. One of the cool things was the amount of code you could share between Android, iOS and web platforms.

So why is it so cool these days?

You could say the main advantage of React Native is that it allows you to ship to all three platforms much faster than with the traditional approach. That’s true, but you can’t assume development time could be simply reduced by a factor of three. This is mentioned in the official documentation. That kind of assumption can be quite dangerous.
Creating an app using this toolset allows the developer to use the same code in different environments. For example, some containers and state management, like a number of reducers and action creators. However, the feeling the user might have using iOS would be quite different than the ones s/he has while using a laptop. Thus, you should consider the time to improve the feeling of the app on specific platforms. You might be questioning the coolness of React Native right now, as you’ve just read it does not necessarily speed up the date of your app’s big release. Just check out the next paragraph before you decide to close the tab.

Developer experience

A really good aspect of React Native is the familiarity with the tools and concepts experienced by both frontend and Mobile developers. Ionic demanded some knowledge of Angular, requiring Mobile devs to learn a completely new framework. Xamarin required learning a programming language that hasn’t been used on either Android nor iOS natively. React Native seems to be on the edge of both worlds.
According to Tal Kol from Wix who gave an excellent talk at ReactNext 2016, the time required to grasp the basic ideas of the platform is exactly the same for developers who (like me) are mostly familiar with JavaScript and web technologies, and for Android/iOS developers mostly focused on their specific platforms. Transforming frontend developers into multidisciplinary units, working along with a dedicated iOS or Android developer was another great idea I picked up from his talk. That drives us to what some consider as the biggest and brightest advantage of RN: simplicity and ease of use.

JavaScript everywhere

Let’s add more beauty to this solution. The toolset you might be familiar with through developing single page web apps with the React/Redux ecosystem has its own place in the React Native world. It’s easy to apply the same state management patterns you might have used on the web. The community around React Native has done a magnificent job of developing and maintaining packages like React Native Router (react-native-router-flux). This makes the problem of navigation easier to deal with. Also, quite a number of presentational components (or even ready-to-use ‘Bootstrap-like’ presentational libraries) are present. All these packages, and the helpfulness of the community, makes the frontend developer more comfortable in working with RN.

What about good old Ionic?

That drives us to yet another assumption about the beauty of React Native. If you’ve developed an Ionic app before, or managed a team who’s done that, you might have encountered the problem of rendering performance on old devices. That’s mostly because the JavaScript code has been managing the same elements as on the web. To display them, you had to use a web browser-like view. React Native, on the other hand, uses native platform components, so your JavaScript code doesn’t have to deal with DOM elements.

Can I solve all my problems with JavaScript only, then?

The JavaScript environment is close to fulfilling the promise it made to the Java community a couple of years ago about a single universal language that runs on every device. However, it’s unwise to drop every other technology. React Native would be a great choice for a number of applications, but I guess there are many applications using such deeply specific APIs where the use of JS would hardly be applicable. Nevertheless, the React Native community gives a lot of examples of advanced usage of the hardware APIs of some devices, thereby making the communication between them and the React-like interface easier.

Maintenance of a single codebase vs maintenance of number of them

Every single application has a lifecycle. Once your app hits the AppStore or Google Play, it goes through some time of after-deploy feature development. It starts making money. Then, you might start considering moving some of your developers to another project. To keep the app on track and quickly react to any bugs and feature-requests, the native approach would require at least one iOS developer and at least one Android developer. If your app’s codebase has been mostly written in JavaScript by multidisciplinary JS developers, you might reduce that number a bit. Also, as JS is probably the world’s most popular programming language, it’s reasonably easy to find a JavaScript developer who can quickly jump into a RN project.

Back to the initial question

So again, let’s say you’re a technical director or project manager. Your goal is to deliver an iOS and Android app. Considering the advantages of JavaScript tools and community, would you still stick to native technologies? Or would you be keen to check out something new? Something that actually can improve the maintainability and reasonability of the codebase?