Native vs Cross Platform

Native vs React Native

Mobile applications have traditionally been written in native languages. With the rise of React Native, a growing number of popular mobile apps (such as Facebook, Instagram, Pinterest, Uber, Discord, SoundCloud, Skype…) are being partially or completely rewritten in React Native. This leads to the question: Should mobile developers use React Native for mobile development instead of going full native with Java or Swift?

Well, there is no correct answer for it, it depends on the requirements. Here in this post, I will compare them in detail.

Native application:

A native application is one that is developed for use on a particular platform or device. As it is built for the use on a particular device and its OS, it has the ability to use device-specific hardware and software. It can provide optimized performance and take advantage of the latest technology, such as Biometrics or Augmented Reality, as compared to web apps or mobile cloud apps developed to be generic across multiple systems.

React Native Application:

React Native is a framework for building native iOS and Android applications using JavaScript. It uses native components to render a user interface (UI). It gives the same native look and feel while still providing extra portability and a familiar methodology. React Native is a framework created by Facebook to enable a smooth and easy cross-platform mobile development. JavaScript is the primary programming language for React Native. The JSX extension is included by default to facilitate writing declarative UI components.

In Android development, you write views in Kotlin or Java; in iOS development, you use Swift or Objective-C. With React Native (RN), you can invoke these views with JavaScript using React components. For example, a native TextInput will have a corresponding RN component which can be directly imported into the JS code and used like any other React component. Hence, the developer will be writing the code just like for any other React web app but the output will be a native application. Because React Native components are backed by the same views as Android and iOS, React Native apps look, feel, and perform like any other apps. We call these platform-backed components Native Components.

One big difference is that React Native runs the JavaScript code in a separate thread, so the user interface does not block and animations should be silky and smooth.

JavaScriptCore comes default in iOS. But in the case of Android, RN bundles the JavaScriptCore along with the application. This increases the app size. Hence the Hello World application of RN would take around 3 to 4 megabytes for Android. Facebook has open-sourced Hermes, a small and light weight JavaScript engine optimizing for running in React Native Android app (since RN 0.60.2). It brings a really big advancement on mobile development with React Native as it will give the Android Applications built with RN a significant boost in performance, along with a smaller build size and less memory usage.

In a React Native app, the JavaScript logic runs in a dedicated thread, while the rest of the app runs in what we’ll call “the native realm.” JavaScript handles the business logic of the application, while the native realm renders the UI and manages device interactions. These two domains rely on something called “the Bridge” to communicate.

The JavaScript thread and the native realm can’t have a direct conversation — they are unable to listen, respond to or cancel events and operations happening on the opposite side. Instead, they pass serialised messages back and forth via asynchronous message queues. This system “bridges” the gap. For example, React Native may send a message to the native realm saying “render this button.” Upon receipt (ie. the next time it checks the message queue), the native realm completes the render. Later on, when the user clicks on this button, the native realm dispatches a message to the JavaScript thread informing it of the action, triggering some associated application logic, which will then result in a UI update being pushed back into the queue for the native realm … and so on.

Due to the disconnected and asynchronous nature of this bridge, some performance issues can arise. For example, queues can get bogged down, say for example if the user is rapidly scrolling through a long and complicated list — many “user has scrolled” and “draw this new UI” updates fly back and forth. For a similar reason, animations can also be a point of concern. In reality, most of the time these kinds of performance deficits are negligible to the user; however, they are still something developers need to be aware of so they can be designed around.

Both iOS and Android have a similar architecture with subtle differences. If we consider the big picture, there are three parts to the RN platform:

  1. Native Code/Modules: Most of the native code in case of iOS is written in Objective C or Swift, while in the case of Android it is written in Java / Kotlin. But for writing our React Native app, we would hardly ever need to write native code for iOS or Android.
  2. Javascript VM: The JS Virtual Machine that runs all our JavaScript code. On iOS/Android simulators and devices React Native uses JavaScriptCore.
  3. React Native Bridge: React Native bridge is a C++/Java bridge which is responsible for communication between the native and Javascript thread. A custom protocol is used for message passing. Below is the diagram to illustrate how RN works internally.

Native vs React Native app

Why Native?

Pros and Cons of Native App:

Native App is the preferred choice for large scale, big brand mobile services like Facebook, Snapchat, Banking apps. Fully dedicated solutions, due to high quality and superior performance are still the weapon of choice for demanding customers looking do develop their apps for B2C or C2C purposes. If you’re looking to develop a Ferrari among apps, you are going to choose Native. No compromise on quality, no compromise on performance and definitely no compromise on the cost and development time. The following table provides a more detailed comparison of why native over RN.

Why React Native?

Pros and Cons of React Native Development

The choice of available, ready made React Native framework is currently somewhat limited.

All in all React Native is a maturing and valuable alternative to native developments. Native still leads the race when the need is for top standards in quality and performance. The advantages of dedicated software are not questionable at present.

Augmented Reality in Mobile Apps:

Augmented Reality (AR) apps are increasingly getting popular across industry. Mobile platforms like Apple and Google are continuing to deliver new and improved AR toolkits for developers. Google offers ARCore for Android developers, while the iOS platform offers ARKit 1.5 loaded with enhanced AR-based features for building immersive AR applications. While both toolkits are seemingly complete and richly featured for their respective platforms, they are platform-specific and don’t allow cross-platform rendering.

ViroReact is a fully-fledged cross-platform library created by ViroMedia. It helps developers to deliver a perfect cross-platform AR app experience by utilising custom renderer that can wrap both ARCore and ARKit, respectively, for the Android and iOS platforms. It has good support from the team as well. But I don’t recommend to use it for complex / performance-based applications because of the React-Native javascript thread which can lead to event congestion and lags. So, in case performance matters, I’d recommend full-native solutions instead.

Conclusion

React Native’s growing popularity should not be underestimated though. For certain purposes, like B2B services it seems a better option. Better price and shorter development time add to its attractiveness. While native is set to keep its prime position for a while longer, more and more aspects of React Native are painting a picture of an emerging underdog that may surprise in the coming years with catching up with the leaders. The table below offers a checklist to see if a RN deployment might be applicable to your use case.

Native iOS and Android are here to stay, and they will remain with us in the foreseeable future. However, the future of React Native is a little uncertain. It is true that React Native community is growing and expanding very quickly, but with the current React Native version still not being 1.0 (the most recent version at the time of writing this article is 0.62.2), we have yet to see the best from React Native.

Another thing worth noting is that Facebook does regularly update React Native, and they are not very interested in fixing bugs that don’t directly involve the Facebook app. The way react-native compiles XML to native code is a black box process. So, if there is some kind of an error in a React Native component, you will either have to wait for Facebook to fix it, or fix it yourself, which requires going into native code.

In the end, is React Native worth it? The answer is: It depends on your project.

References:

https://appinventiv.com/blog/react-native-vs-native-apps/#:~:text=A%20Native%20mobile%20application%20can,the%20level%20of%20data%20access.

https://itcraftapps.com/blog/pros-and-cons-of-react-native-and-native-development/

Native vs Cross Platform was originally published in Walmart Global Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Article Link: https://medium.com/walmartglobaltech/native-vs-cross-platform-322e9896e745?source=rss----905ea2b3d4d1---4