Sharing code between platforms: my approach to ReactJS and React Native

Hybrid technologies have been employed for quite a while in mobile application development. Frameworks such as PhoneGap and Ionic come with an appealing motto: Develop once, run everywhere. And they actually do what they promise: you write a web-based app once and release it everywhere, from iOS to Android and the Gates of Mordor, as long as it gives support.

I do believe that they play an important role in the mobile app development scene: the huge community of web developers can write mobile app code and are able to deploy fast. But, in my opinion, the idea of developing one shared application for all platforms is dead per se.

That’s where React Native lands. It has a slightly different motto: Learn once, write everywhere. It might seem the same but with a closer look, you’ll spot the difference: it’s still JavaScript code, but with a dedicated one for each platform. And that changes everything. Each platform has its peculiarities and user expectations vary from one to another.

React Native implements a bridge between web and native components. Instead of reinventing the wheel, it leverages the hard work designers and engineers at Apple and Google have done to release their native SDKs. As an alternative to having dedicated apps developed with Objective-C (or Swift) and Java (or Kotlin), you’ll have dedicated apps written in Javascript. This way it’s easier to process your application logic, store state and take use of the huge JavaScript technology stack, and still deliver the looks and feels of a native application, bypassing the use of WebViews by rendering native ones.

At this point you might be wondering…

…the title said something about code reusability and this guy keeps talking development philosophy. Sorry about that, it’s part of the thinking process. I just want to emphasize: don’t expect full reusability on the UI components. You’ll be able to use a couple of generic widgets seamlessly across both platforms, but that’s the beautiful thing of React Native, it encourages and gives the tools to write dedicated UI code for each platform when needed: it’s as simple as adding a `.ios.js` or `.android.js` suffix.

React Native not only solves the performance issue present on other hybrid solutions, it improves the application quality with a native user experience.

Now let’s say you have already implemented a React web application. It’s up and running, you have used the whole Redux pattern stack, configured webpack for bundling, created actions, reducers, all HTTP requests for API integration, tests, etc. You don’t want to re-implement everything (even if it’s just copying and pasting from the webapp). It’s not just a matter of development time, you would have to manually keep track of updates on both of them, fix bugs on both codebases, and so on. Reusing code is a good idea in the short and long terms.

Sold! Tell me how…

You can easily inject your web application code as a dependency of your mobile code, using npm. This way you normally access your actions, reducers or helper functions from React Native as any other dependency. And further on, it’s possible to separate the logical part, that is shared between applications, in a different directory.

The view part will have to be done from scratch. Not only because it’s necessary to replace the HTML elements with React Native components, but also because the components will probably have a very different behaviour on the mobile app.

Wait a second, if all platforms share so much code, why don’t we put everything under the same codebase? Well, source code is not the only part of it, each project has a very distinct development environment, build scripts, tests and so on. They could actually reside in separate folders under the same repo: mobile, web and modules. But what if someone has to release a bug fix on a webapp component, it affects other devs that are only working on the mobile components and the other way around. That’s not scalable. Splitting is good.

Wrapping Up

React Native still has a lot to evolve and it doesn’t replace real native coding, yet. But it opens mobile development doors for a huge number of web engineers, that now are a few API docs away from building good-quality mobile applications. It makes possible to share most of the core logic between web and mobile applications, not only reducing development time, but also creating applications with a more consistent behavior. Together with a native look and feel, it improves user experience and product standards.

Interested on seeing a sample application on this subject? Drop me a line and I’ll be glad to prepare part 2!