Should Your Mobile App Development Team Choose React Native over Native Development?
So, let the battle begin!
What the fuss is all about
For a long time, Native apps (written in platform-specific languages and using the proprietary tools) were considered the gold standard when it comes to mobile development.
They offer the best performance, trademark look-and-feel, and full access to hardware related features (like support for multi-touch gestures, access to a camera, GPS, calendar, accelerometer and much more).
At the same time, a lot of developers find the promise of cross-platform apps to “write once – deploy everywhere” pretty attractive.
Traditionally HTML5 and Hybrid mobile apps have lagged behind their native counterparts in UI/UX, performance, and features, but the emergence of cross-platform development tech has made it possible for web developers to create fully native apps.
In theory, React Native apps should combine the best of two words with the support of rich native features, signature UI, great performance and the ability to reuse both code and web-development skills to make the development faster (and also cheaper for the clients). But does the tech live up to its promises?
Our R&D team has set out to compare React Native with the best practices of the Native development.
Despite being younger and less widespread, React Native has its own blog and a growing community on GitHub, StackOverflow, Facebook and Twitter. You can also meet other React Native developers in various chats and forums like Reactiflux, React Discuss, Reddit, IRC channels, etc. Also there are more than 270 React Native meetups all over the world.
Despite the advent of cross-platform tech the majority of companies still favor Native apps. In addition to the great library of products made by Apple and Google, such notable apps as Twitter and Telegram are developed natively.
Truth be told, some of them are adopting React Native already, though the Skype app was developed natively, it’s new version is written with React Native.
A growing number of companies is using React Native to develop their apps with the likes of Facebook, Instagram, Tesla, Airbnb and Walmart paving the way.
Development process under the magnifying glass
Differences in structure
React Native is based on the ReactJS library. In React you build your UI with components. Each component controls its own state. The arrangement/composition of these components eventually becomes your UI.
The UI elements in the code are generic/platform-agnostic as well as their styling but they are rendered as native views. This enables you to reuse a great portion of your code and at the same time create a UI that meets Android/iOS guidelines for style and follows the best practices for each platform.
Unlike React Native, most other technologies for cross-platform mobile development render their own UI that have non-native looks and cause a significant overhead.
As the result the user experience in React Native apps is close to that of native apps and performance is better than in most HTML5 and Hybrid mobile apps.
In Android, the layout is realized in XML-format, where you can declare all the UI elements, their properties, and position in relation to each other. Additionally, there is a graphics builder in Android Studio. It allows you to view the ready layout on/in various screen resolutions as well as add new UI elements and change their properties.
It is more common to edit the layout in XML because you can simultaneously set up the relations between the elements and be sure that all of them will be correctly displayed on all the screens. At the same time, the graphics editor is useful for previewing the layout on various screen sizes.
In iOS, it is preferable to use Interface Builder. It conveniently allows you to align the UI elements and set up the constraints between them. When you add new elements they are given a unique ID. That’s why it is both impossible and inconvenient to only edit XML-files (as you can do in Android).
You can also use Interface Builder to set up the constraints between the UI elements and variables in the code.
You will find neither pixels nor classes in React Native. The layout is implemented via absolute values based on Flexbox. You can use CSS-esque stylesheets/stylesheets a la CSS to define border widths and margins as well as fonts and colors. The usage of flex-like markup is a significant benefit of the tech as it allows you to change the components size depending on the size of the container.
With “flex: 1” style the component will take up all the available space. If there are more than one component they will spread evenly across the available space. This minimizes the time spent on styling as this approach allows you to display the elements proportionally to the screen resolution. The result is always the same on phones and tablets alike.
The creation of styles in React Native is slightly different from what is usual for a frontend developer. In React Native, you use a CSS-like syntax written as a JS object. Then the object with ‘styles’ is transformed into platform-specific instructions on the position and color of elements.
In React Native apps the styles are almost always valid for both platforms. In some cases, you can use platform selectors to define the styles.
Due to React Native’s ability to detect the platform in your code, you can create various components that have alike functionality but at the same time are adapted to a particular OS. Therefore, you can reuse your JS files for versions targeting both platforms while adding conditionals from time to time. For instance, only iOS supports the ‘overflow’ style property. Likewise, the properties of components can be specific to either platform.
React Native Components
Both iOS and Android have huge SDK containing thousands of modules. The React Native development team made a rational choice not to export all of them into JS environment.
React Native manages native views with JS code. At runtime, its “View” is a native “View” in Android and “UIView” in iOS.
The people behind React Native strive to introduce native widgets to the framework. Some elements aren’t available to Android. Among the examples are UIPicker (which became PickerIOS) or Android’s drawer (which became DrawerLayoutAndroid).
Sometimes the desired functionality is absent from React Native, can’t be created with the components you have at hand or calls for the usage of a library created exclusively for native development.
This is where native modules come into play.
They provide a means for bridging native and React Native code. With their help, you can integrate a native code component with the typical React Native layout.
In the native app, React Native appears as a plain view controller, so if you need to use another view controller provided by a library just push it over React Native and afterward pop back from it.
Debug in Android Studio is familiar and convenient. You can place a breakpoint anywhere in the code. While running the app you can view the current call stacks and values of variables and fields (including the private fields).
The same is available in XCode. You can also pause the app at any moment and view the current hierarchy of elements on the screen. This allows you to track the errors related to incorrect displaying of elements.
To debug an React Native app you can use Chrome Developer Tool or Safari web inspector for iOS device/simulator.
To inspect the view elements you can select the “Show inspector” option in the Developer Menu of the device/simulator. You’ll only be able to inspect the styles of elements but not change them.
Also in Developer Menu, there is the Network tab which allows you to track HTTP requests and inspect the request’s type, method, URL, etc.
Another option is React Developer Tools, which allows you to both inspect and alter the hierarchy of React components along with component props and state.
You can also use a platform’s IDE (Android Studio/XCode) for debugging. They allow you to examine in depth all the logs and gauge the app’s performance (resource intensity, speed, etc.).
A great deal of “quality of life” features from web development are also available in React Native. For example, you can reload your app on the run by using LiveReload or HotReload (analogous to Android’s Instant Run) and see the changes to the code right away.
Compare that to the usual practice of native development where you lose your precious time waiting while your app is rebuilt. Although in case of global changes to the code (config changes, new package installation, etc.), it’s still advisable to re-build the project.
To publish a Native app you have to build an application file (apk for Android and ipa for iOS) in IDE and add to Google Play/iTunes. You can also use Gradle plugins to automatically publish the app updates.
Deployment of React Native apps is very familiar for people used to developing native apps.
We have proven in our research that there are no major differences in React Native and native development. Cross-platform has its advantages over native and vice versa.
As a pretty young technology, React Native has some of the issues associated with immature libraries like missing features or best practices that aren’t defined sufficiently.
A lot of developers point out that the stability of React Native is not up to par with the standards of native development. The library has a rapid release cycle with breaking changes happening from time to time. Yet others consider React Native mature enough so that its pros easily outshine its cons.
Dismissing all concerns, React Native offers one advantage that is hard to argue against: it significantly decreases the development time when you want to scale for multiple platforms and as a result, saves you a lot of money.
The React Native UI is fully native and for the most part, React Native apps provide performance, look, and feel that are equivalent to that of Native apps. Oftentimes, you still need to use native components and you can’t share more than 30% of the code in the case of more complex apps with platform specific UIs, but it is still a huge saving.
QA is also cheaper for React Native. Although the UI elements in React Native are different for iOS/Android, the underlying business logic (and the bugs related to it) are the same for both platforms.
This means that despite having a comparable number of UI-related bugs, your average React Native app would be quicker to test than its Native alternatives. You can also save on unit tests for the shared code.
Of course, each project has its own peculiarities that have to be taken into account when choosing a tech stack.
In case you want to develop your next app for both iOS and Android, and potentially other future platforms, don’t forget to consider React Native – it can help you save time and money.
And a native app is great when you consider using all the features that a platform offers, including such modules as video/audio processing or multithreading. Since React Native focuses on the User Interface only, it can be less efficient for applications with many native features.
So, what is your take on this debate? Did you join the ranks of React Native squad or prefer to stick with tried and true Native development?
Share your insights in the comment section and don’t forget to subscribe to get all our articles fresh off the press!