Blog

6 reasons to choose React Native for your next cross-platform build

As an iOS team lead, I fall accused of favoring native development over cross-platform. I must confess that two years ago, this statement might’ve been true. But since working at EBS, my vision shifted a bit. Here, each project challenges our team to follow the best fitting technologies. Particular scopes result in choosing cross-platform builds. When this happens, we face yet another head-scratcher. There are lots of cross-platform frameworks to consider, each of them with a set of benefits as well as disadvantages. In nearly 70% of those cases we’ve chosen React Native. No wonder this post comes to share our view on why React Native (in our own opinion) is one of the best cross-platform frameworks to pick from […] and how this impacts our development lifecycle.

Please note, the advantages as well as shortcomings of this framework listed here rely on our own “meandering” experience.  These might not match public opinions to which each author subscribes. So, without any further delay, let’s dig into this React Native piece of cake.

A SHORT DEFINITION

React Native – an open-source, mobile-oriented framework, delivered and maintained by both: Facebook and the Open Source Community. We use it to build Android, iOS and UWP applications for Web resources based on React. As compared to hybrids or so-called cross-platform alternatives, React Native does not use HTML/CSS to replicate a native view. Instead, messages from the JavaScript thread end as manipulation means of native components. This results in a close to Native interface.

REACT NATIVEs ORIGINS

Back in 2011, Facebook reached the critical number of one trillion-page views. With this milestone, their team understood that performance optimization via custom fixes to their PHP base won’t do. It was time to find a more flexible, more native solution to the ever-growing web.

React Native

That’s how Jordan Walke and his Facebook team came up with React. A JavaScript Library that came as an addition to their existing base. Its’ role: improve reaction times at the user interaction level. By August 2011, ReactJS  to Facebook’s news feed and later (2012) on Instagram (one of their recent acquisitions). To enrich ReactJS’s base, Facebook Open-Sources its library at JSconf US in May 2013 and due to a huge community contribution, ReactJS grew from a library to an entire web framework.

The challenge

With the growth of Mobile Web, Facebook understood that their bet on HTML leaned towards generating churn.  Their platform (already complicated enough)  required an Android and iOS port, yet native apps proved way too expensive […] at least from the technical debt perspective […] outlining a critical challenge they in the nearest future.

Yet again, the solution came from the same engineer (Mr Jordan Walke) as he found a way to generate UI elements for iOS from a background JavaScript thread. Following-up on his discovery, Facebook organized an internal Hackathon to build on this prototype and generate native apps with this fresh technology.

At the beginning of 2015, a React Native preview emerged as part of the React JavaScript Configuration powered by Facebook. By March of the same year, React Native released as open source, enabling a worldwide community to improve and build on existing code.

It’s no wonder that 2 years ago, most native-focused developers (including myself) glanced skeptically at the newcomer. Any app built on anything else but SWIFT or Objective-C would simply not do.  And a 1-year toddler such as React Native left us cold. Factor in the community’s contribution (quite scarce at the time) for our lack of confidece.

Things have changed and after 2 years of experimenting with React Native (further as RN), there are over a dozen reasons it is our top-choice when cross-platform stands for a business requirement.

react native best chop dawg language

Photo credit: https://www.appbrain.com/stats/libraries/details/react_native/react-native

Why is React Native a top-choice when deciding on a cross-platform build?

The actual list of benefits is quite extensive.. But to give you an overall idea, we’ve narrowed them down to the most essential ones.

1.Serves as a true WEB to Mobile Gateway

At least at EBS, our rudimentary web applications run on ReactJS, VueJS or MEAN stack. Most of the JS paradigms power the above-mentioned stack match RNs’ support sheet. That means, porting a web application to a mobile one becomes less painful and slashes debugging in half. Especially when two mobile builds emerge with only 20% of native coding.

2.Easy to learn and deploy across React Web teams

One of the top advantages’ RN delivers is code resemblance with JavaScript. This makes it super friendly to web developers (especially those familiar with React). It also enables organizations to build multi-purpose teams instead of dedicated mobile and web teams. This way, everyone uses the same programming paradigm and execution times fade by 50%.

3. RN Renders into platform-specific code

One of the things that makes RN  great: it acts differently when compared to its alternatives. While the other ones translate JavaScript code into web views and act as wannabe-native UIs […] using rudimentary animations[…] they still act and make use of the same resources your browser would and do not interact directly with the device.

As opposed to competitors, ReactJS makes use of components that describe their own appearance, while the framework itself handles rendering. It does so by making use of a hardware abstraction layer. This one separates components and framework threads into separate elements (or instance of elements), enabling usage of standard HTML tags.

React Native

Following the same principle, RN makes use of the same abstraction model […] also called the abstraction bridge […] to invoke the actual APIs on Android and iOS. This way, on Android, the UI is rendered as “native views” […] while on iOS, RN components render to real UI Views.

All of this can be accomplished by writing an awful lot of standard JavaScript, CSS, and HTML code. Instead of compiling down to native code, RN will execute a given build using the host platform’s JavaScript engine. This eliminates blockage risks related to main UI threads.

Due to that, one can exploit native performance benefits without having Objective-C or Java-specific skills. Respectively, other cross-platform solutions (Ghm-Ghm Cordova) could never match RN’s native performance and outstanding looks.

4. RN Can make use of native code

If your business model requires direct access to platform APIs while maintaining the cross-platform model, RN is your solution. Even if there’s no framework module (yet) to accomplish a business objective (like deploying some multi-threaded, high performance, or hi-load code used for image processing or managing streams from a database), you can always make use of real native code within your build.

Yes, this implies you should have some iOS and Android devs on the project too… But their workload would consist of about 20% of your mobile project. The rest of your app would resemble a JS base. There are hundreds of Native Package Modules (NPMs). These can actually simplify your code making it easier to maintain, scale and even refactor.

For instance, performance-wise, combining native code into your RN codebase would actually build the premise of a snappier app. Since RN invokes native module methods on a separate thread, app processes are not intercalated and a native call would not interrupt other ongoing threads, thus delivering you a near-to-native performance.

To pile-up on the advantages of combining native with RN, you get a distributed resource consumption model. Since RN uses (mainly) the GPU, you have more CPU resources available for those heavy-lifting native methods. Despite the fact that this model could require more battery power, the benefits it delivers outweigh this minor drawback, which is still invisible to the end-user’s eye.

Warping-up RN’s ability to include native code would not only be useful for those who require an initially extended cross-platform build, but also for those who refactor older solutions onto ReactJS since you can actually use some of your old native code instead of translating everything to RN components.

5. RN – A unique code-base for iOS and Android

Ok, ok… There is no current solution on the market to deliver that at 100% (at least yet), but RN is the closest one that could help you reach that goal. About 80% of the RN code is re-usable which means a lot when compared to both: other cross-platform and native builds.

In addition, RN is compatible with other platforms and since its open source, bottlenecks are solved every day by a global network of talented developers. This enables writing NPMs in a JS comparable language and them it to RN’s codebase, delivering a gateway to native features which aren’t yet supported by the framework and reducing code-dependent bottlenecks.

6. RN – Built, improved and chosen by experts

This is one of the main reasons we’re sticking with React Native. In our humble opinion, this framework has been built by experts for experts. It is no wonder RN survived all competition and exceeded them in both: performance and User Experience.

In merely 2 years, this framework made it from “a thing Facebook uses” stage to actually fitting native application standards of developers with different backgrounds.

Besides reaching Android, iOS audiences as well as users of more “exotic” platforms like those using Windows Universal Platform-enabled devices or Linux Smart-TVs, RN made its way across business models such as SoundCloud, Uber, Myntra and Discord. Without any doubt, RN is no longer a “Facebook-only” framework.

In fact, some of the most used RN components are not related to Facebook in any way, most of them coming from various backgrounds with impressive JS-related experience. In 2018 alone, the framework has been enriched by experts with several additions such as:

React Native 0.56 

anew version that enables developers to prepare ready-to launch Android apps through its improved support of Java/Kotlin […]

React Native 0.57

introducing more Apple-related native UI components and enabling compatibility for iOS 12 builds […]

React Native 0.58

delivers Improved compatibility and support for AWS […]

React Native 0.59

adds Hooks support enabling state and other React component usage without writing a class; delivers Improved compatibility and support for integrating Native code and Modules […]

Following RNs growth rhythm, any developer can confidently go with such a build, knowing actual experts keep an eye on that GitHub resource.

ENDNOTE

As mentioned, while these reasons might seem essential to us, there might be split opinions regarding the best cross-platform framework out there. We’ve only shared what an entire team thinks (as opposed to an individual) and frankly, looking at those 2000 React Native contributions and over 15,000 commits on GitHub, we’re quite convinced in our position. Nevertheless, we’re always open to a good debate and would love to hear from you in the comment section. If you’ve enjoyed this read, please express your appreciation by hitting those share/like options below and make sure to follow us on Facebook, Twitter or Linkedin to get non-intrusive updates.

For all those interested in building their next-level, cross-platform, disruptive and outstanding app – we have a special treat.

If you Schedule a Call, our Business Development representatives will make that click worth your while, delivering you a Value-Add, non-obligation consultancy call with one of our top-rated Business Analysts and System Architects.