Blog
6 reasons to choose React Native for your next cross-platform build
Jul 21, 2019,

As an iOS team lead, I’ve been 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 for a particular scope which in distinct cases, results in choosing cross-platform builds. When this happens, we’re faced with yet another head-scratcher since 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 and 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 are listed here in the base of our own “meandering” experience and might not match public opinions to which each author is entitled to. So, without any further delay, let’s dig into this React Native piece of cake.

A SHORT DEFINITION

React Native is 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 are used to manipulate native components, which 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 and minor aids to their PHP base won’t do and It was time to find a more flexible, more native solution to the ever-growing web.

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, to improve reaction times at the user interaction level. By August 2011, ReactJS has been deployed 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.

With the growth of Mobile Web, Facebook understood that their bet on HTML was more likely to generate churn. Since their platform was complicated enough, a native fork to Android and iOS was required, yet way too expensive (from the technical debt perspective) outlining a critical challenge they had to solve 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, Facebook released their first React Native preview as part of the React JavaScript Configuration and by March of the same year, React Native was released as open source, enabling a worldwide community to improve and build on existing code.

It’s no wonder that 2 years ago, most developers that focused on native development (including myself) were somewhat skeptical regards any app built on anything else but SWIFT or Objective-C – at the time React Native was 1 year old and the community’s contribution hasn’t been as valuable as it is today.

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 RN 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 are built on ReactJS, VueJS or MEAN stack. Since most of the JS paradigms used by the above-mentioned stack are supported by RN, porting a web application to a mobile one is less painful and slashes debugging in half, especially when you get two mobile builds with only 20% of native code involved.

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) and 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 are often reduced by 50%.

3. Renders into platform-specific code
One of the things that makes RN one of our most favourite frameworks is that 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 that separates components and framework threads into separate elements (or instance of elements), enabling usage of standard HTML tags.

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 (as a standard SWIFT or Java build would), RN will execute a given build using the host platform’s JavaScript engine, eliminating 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. 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, while the rest of your app would resemble a JS base. Also, since there are hundreds of Native Package Modules (further as NPMs) – you can actually simplify your code (especially when using ES2016’s async/await syntax), 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 (as compared to using JS only). 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. 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. 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 matters of security, that might seem a bit frightening, however, since Facebook is policing that GitHub Branch, this combo enables a fast-paced growth for RN while maintaining developer trust. In 2018 alone, the framework has been enriched by experts with several additions such as:

  • React Native 0.56 – a new 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.