Why React Native? — Mobile App Development Part 0
This is part 0 in a series of articles about mobile app development with React Native.
This series of blog posts is about developing mobile applications with React Native. But before we get our hands dirty in Part 1, we should justify, why we even consider React Native and what other options there are. If that is not interesting to you, feel free to skip right ahead to Part 1.
Before we get into actually developing a mobile app using React Native, let us look at the competition and evaluate whether React Native is right for you.
The AlterNatives
To decide on whether React Native is right for you, you need to know what other choices you have. The alternative technologies that we will consider here, are native development, Apache Cordova, the Ionic framework, Flutter and Xamarin. Maybe one of these approaches is the right one for you because of your technological background or an existing codebase in your company.
Native
You probably know that you can write your native apps in Java or Kotlin for Android and in Objective-C or Swift for iOS. For both platforms the native APIs and workflows are simply more powerful and flexible than any cross-platform technology can ever be.
They allow you to take advantage of all the platform’s features. With cross-platform solutions you eventually will run into a problem that you cannot solve with the given technology — the power of native is endless. Not only are the technical capabilities of native superior, but the documentation is too. Google and Apple have invested into documentation and community for years and whatever problem you are facing, someone has probably already solved it. This is in particularly stark contrast to the React Native ecosystem, which is relatively young and defined by breaking changes in the library or the tooling around it.
The obvious disadvantage of native development is that you have to develop two apps in parallel: one for iOS and one for Android (unless you decide to only target one of these platforms). This not only adds huge amount of additional coding work, but also introduces an organizational overhead into your development process.
While it might be a natural thing for a seasoned Java developer to start developing Android apps, web developers will likely have a much harder time transitioning into native app development. For them, using a technology like Cordova or React Native will be much easier to pick up.
Cordova
Being around since 2011 as the open-sourced version of Adobe’s Phonegap, Apache Cordova is a classic in the realm of cross-platform mobile development.
Cordova provides you with a web view in which you can run any web application. In order to interact with the platform, Cordova exposes device APIs to the JavaScript inside the web view.
Running a web application in what is basically a chromeless browser on the mobile device comes with some obvious advantages and disadvantages. It offers you a tremendous amount of freedom when it comes to choosing an application architecture. The hurdle of entry on the one hand and the scalability to support larger applications on the other hand are defined by the framework you use, not by Cordova. Existing web applications might be easily ported over to Cordova and if you want to develop an app for mobile and the web, Cordova is your friend, as it also offers web as a target platform.
The flexibility of the web-based platform might be scary for developers coming from other languages, but web developers will feel right at home. Since differences in browser engines have become mostly irrelevant, a Cordova based app will likely look exactly the same across iOS and Android. This can be a good thing, if consistency between the apps is a prime concern. But it can also lead to tedious conditional logic if you want to incorporate OS-specific UI concepts and best-practices.
A downside to rendering a web application instead of using native UI components is, however, that it takes special care to make the UI feel native. There are a lot of details to how native UI looks and feels, that users often only notice unconciously — unless something about UI feels wrong. To avoid irritating users, native behavior has be emulated perfectly. The other option would be, to create a UI that is so radically unique and different from native, that users would not apply their usual expectations for UI to the interaction with your app. If what your app does lends itself well to extremely creative UI concepts, great, but if you mostly rely on traditional ways to display and manipulate data, a web view-based technology such as Cordova might feel clunky.
Since Cordova does not come with a builtin structure for the user application nor with out-of-the-box UI components, it inspired a host of frameworks that build on top of it. Their scope, approach and success vary, but maybe you find exactly what you are looking for among these frameworks: Besides Adobe’s Phonegap, relevant frameworks include Framework7, Onsen UI and Ionic.
Generally speaking, if you are a web developer venturing into mobile for the first time and you are not working with Angular or React already, then Cordova might be right for you, as you can probably take your favorite set of frameworks and libraries that you are using on the web with you.
Ionic
The Ionic framework builds on top of Cordova, but comes with its own complete ecosystem: It uses Angular as the framework to build the app, brings its own CLI for initializing and packaging projects, has its own marketplace of third-party components that you can use, and they offer a service that lets you build application binaries in the cloud and push updates to clients.
As Ionic uses the Cordova technology, some of the same pros and cons apply. Given that Ionic is a more complete overall solution and Angular is a relatively rigid framework, it might be a good solution for non-web developers who are looking for a mature system that provides them with a lot of structure to get started quickly. For seasoned Angular developers, choosing Ionic for their first mobile app is probably a no-brainer.
Web developers who are not fans of opinionated frameworks and like to mix-and-match smaller building blocks to create an architecture to their individual liking might not be too happy about using Angular and I definitely count myself as one of them.
Xamarin
The Microsoft-owned cross-platform development tool Xamarin provides you with C#- and .NET wrappers around native APIs. With Xamarin Native you will still end up with native projects for iOS and Android respectively, but a large part of your code will be written in the form of Portable Class Libraries written in C# that you can reuse across platforms.
Xamarin.Forms is a slightly different solution that has you work on one cross-platform code base. Apart from using C# and .NET for writing application logic, you define your UIs in XAML, a markup language reminiscent of XML that can also be used e.g. in apps for the Universal Windows Platform (UWP). But while you do have one shared codebase for both your iOS and Android, you will nonetheless end up writing a good portion (from what I hear it varies between 5% and 20%) of conditional logic to target each platform specifically.
Microsoft tries to make up for Xamarin’s relatively small online community by giving you a highly integrated development environment in the form of Visual Studio (which you have to use). The tooling and the SDK allow you to get started quickly with a simple app, but your mileage may vary once you start working on more complex features or those that require platform-specific code.
Xamarin Native and Xamarin Forms might be worth a look, if you feel at home in the .NET world or even if you are mainly experienced in Java development, as the conceptual leap is smaller compared to e.g. going from Java to React Native. If your company is already invested into the Microsoft ecosystem and you would like your app development to synergize well with other .NET applications your team is working on, Xamarin might be right for you. For people coming from a web development background, such as myself, I see no real benefit in diving into this unfamiliar and only okay environment for doing cross-platform development.
Flutter
A more recent contender in the realm of cross-platform development, is Google’s Flutter. It’s an interesting technology in that is bears some similarities with React Native, but differs substantially in other aspects.
Flutter uses Google’s Dart programming language. It has been around for a little while but not received much attention from most of the developer community, it seems. It is mainly focused on being used with Flutter to build cross-platform mobile apps, but it can run inside of Chrome and there is a server-side implementation as well. You most likely have not used Dart before and chances are, you are not going to use it for anything in the future — except in Flutter, if that’s your pick.
Flutter takes quite the opposite approach to running code and native bindings than React Native does: The Dart code is compiled to native ARM code, which beats out React Native and any Cordova-based technology performance-wise. For its UI, though, it does not use bindings for native components, but draws its own UI using a fast and battle-tested rendering library.
As a consequence, you get visual consistency across different platforms and OS-version (similar to a WebView-based approach), but you potentially lose consistency between the look-and-feel of your app and the OS its running on. Which of these types of consistency is more relevant to you, of course depends on your project.
In terms of application architecture, Flutter seems to incorporate a paradigm that’s similar to React Native: Data flows down a component hierarchy and state updates have to be manually handled via setState (it even has the same name as in React :) ).
If you don’t mind learning a new language and like the idea of having your UI consistently rendered across devices, Flutter might be worth a look.
My personal feeling is, that Flutter takes what makes working with React difficult (data flow and state management), keeps that, and adds a new language to make things more difficult. I thoroughly enjoy writing JavaScript and I am not sold on the benefits of Dart. But I definitely lack the experience here to come to a final judgement about this.
React Native
While all those technologies have their merits and might be right for your situation, this series is about React Native after all. So let’s dig into what this is all about!
What is it?
If you are like me, you want to keep working in JavaScript when it comes to your mobile application, but at the same time not be limited by the technological compromise that is Cordova. Or maybe you just really, really like React. Fret not, my friend: Behold React Native!
What makes React Native different from Cordova and any derived framework, is that with React Native, your UI is actually a native one. While your general app logic is run by a JavaScript runtime on the mobile device, the UI definitions are mapped to native components. This has the potential to give your app a more native look and feel throughout, not to speak of the better render performance.
Developing a React Native app feels very similar to writing a web app in React: You (usually) have your JSX component definitions, the same lifecycle methods, you can use Redux and styled-components and all that good stuff that React developers are used to. At the same time, you can use APIs to access device capabilities like the camera or storage.
The comparison to React.js is also fitting in the sense that the library itself only comes with a view layer (very, very broadly speaking). Developers from other languages might be surprised by the lack of an MVC architecture: For structurally more complex apps you have to find your own solutions (which of course can include using additional JavaScript libraries to help you with that).
The Community
If you choose to build your app in React Native, you are in good company: Facebook Messenger, Instagram, Pinterest, Skype and Uber all use React Native to some degree. Several posts on large companies’ development blogs reveal how React Native allowed their web developers to create a mobile app and how this app made use of shared components across web and native.
React Native comes with a couple of useful APIs and components, but quite early in your React Native app development endeavor you will notice that you require features, that the base installation of React Native does not offer. Fortunately there is an enthusiastic and productive community of developers that write and publish custom components, UI toolkits and native modules. Native modules expose some native API to JavaScript so that you can access features like the camera or contact list. A great collection of all kinds of React Native ressources can be found at awesome-react-native.com and a large set of UI components is assembled in this GitHub repo.
Kinda Subjective
Why do I think, that React Native is a great choice for mobile app development? It allows me to create native UIs using cross-platform code. How convenient is that?! Neither do I have to write separate applications for each platform, nor do I have to compromise on rendering inside a web view. The power of native is at the fingertips of our JavaScript-proficient hands. And while I personally don’t love writing React, I still like it much better than Angular. React Native allows me to use small libraries and assemble them to my liking using my own glue code and architecture, just like on the web platform. I love JavaScript for its expressive power and with React (Native) I maintain that power to a far higher degree than I would in Angular (or Xamarin for that matter).
Summin’ it up
You came to this blog post to read about React Native and maybe you are a bit disappointed that we didn’t immediately took a deep dive into the topic. But I think the decision of what technology to employ in a new project, has to be an informed one. Which solution is right for you, depends on your situation:
- What are the technologies that you or your team are most experienced with?
- Can you afford to develop two native apps in parallel?
- How much is your app going to rely on native APIs, how performance-critical is it?
- Do you want to leverage code sharing between the app and the server, or between the mobile app and a web app?
- Should your app adhere strictly to the look-and-feel of the native UI or are you going to build a very custom UI anyway?
Think about these questions before committing to a technology — what is right for one project is not necessarily right for the next one. I hope, this article could serve as a starting point to guide you in making that decision and to maybe point you into a direction. If you decide to stick with React Native, stay tuned for part 1 of this series, where we will get started with our initial setup of React Native.
—
PS: Who said, that the technologies mentioned in this article were mutually exclusive? It is possible to combine them to try and utilize each one’s strengths.
