Month: May 2017

An Introduction to React-Native, through the eyes of a Native Mobile Developer

Posted by on May 24, 2017


Recently there has been a push for React-Native development here at Rivet Logic. As a purely native Android developer for just over seven years, I was a little skeptical when asked to dive in to React-Native. There have been many cross-platform frameworks over the years, and all have been consistently short of what they claim to provide. I remember way back in 2009 when first asked to dive into the Android SDK I was told by many it would be a waste of time as HTML5 would be the standard for writing mobile apps any day now. That was seven years ago remember, and in the tech world years are like dog years, so theoretically that was 49 years ago. Since then demand for native app development has grown exponentially every year.

There is however, a different vibe about React-Native that allowed me to walk into this more open minded (or less close-minded depending on your perspective). React-Native is growing fast and growing organically. There is already a strong community of developers contributing more and more each day. I also got the impression early on that React-Native was not trying to pretend to be something more than it was, I will try to elaborate more on this later. I needed to get a feel for what development was like first. Next I will explain my approach to this and eventually (hopefully) convey what makes React-Native different. and how it can build some bridges between Android, iOS, and the web.

Getting Started

It’s important to jump into something like this without too much outside influence. I tried to stick to the official documentation to begin with and not spend time reading up on other’s thoughts and opinions. To begin we followed the official intro steps you can find here: installing Node, Watchman, and the React-Native CLI, I initialized a new project with react-native init TestProject and opened it in android studio. Next I started up an AVD and used react-native run-android  right from Studio’s terminal. It worked on the first try!  Sure it was a simple ‘hello world’ but I fully expected a few of the usual obstacles to get things started, there were none. Nice way to score some points right out of the gate!

As a model, I used a demo application built previously for a different topic. It is a simple Twitter app that allows the user to enter a username and the max number of desired results. The search parameters are entered into a DialogFragment and the results are then displayed in a RecyclerView of CardViews. The app is simple, uses a few native Android components, data models, and a transport layer. I wanted to see how far we could get with a few of the UI components starting from scratch using React-Native.

Here are a couple screenshots of the original:


Starting at the top we needed a Toolbar. It only took a couple minutes of searching to find multiple examples of how to do this with existing React-Native components. I had to brush up on my JavaScript as that is not something I commonly use, however that is one advantage of React-Native, JavaScript is somewhat universal. Everyone has used it at some point, even if minimally, and it is easy to pick up and follow. ToolbarAndroid was included as an import, then added as a tag, and a style was added as well, sImple enough. I am actually looking forward to discovering more of the styling features such as the drop shadow or including the ‘fitsSystemWindows‘ attribute.

Here is everything it took to add an Android Toolbar using React-Native

import {
} from 'react-native';
<ToolbarAndroid title='Twitter Exercise'
	titleColor='white' />

toolbar: {
	height: 56,
	backgroundColor: '#1DA1F2',

After testing I moved on to the FloatingActionButton. I was not able to find a native component for the FAB, however there were already plenty of examples using a TouchableHighlight and some custom styles. Again with minimal effort I was able to create a UI element pretty close to the native FAB. There is some work to do with the shadow, image, and ripple effect, but we can save that for a follow up later. I stopped after getting a few of these UI components up and running. I did not want to get too complex for the purposes of this article, as an introduction we just need a feel for things right now. I was impressed to see that many of these components already had support, and better yet they are tied to actual native components, rather than a web view ‘that sort of looks like’ the components they were modeled after. I am curious to see how far we can get with some more complex views such as a RecyclerView with multiple clickable areas as well as item types, but again, that can be for another day.

Here is my Toolbar and FAB using React-Native.


  1. Hey, that wasn’t so bad. With minimal effort we were able to get our app running on a device and display a couple of key UI components. Again, we only needed an introduction to the platform so some of the more complex pieces can be left for a more technical follow up to this.
  2. React-Native is different from the hybrid and cross-platform technologies we have seen in the past. Here is the thing; none of them, including React-Native, can cover all the bases when it comes to mobile development. The difference is that React is not pretending to, or claiming that it can. There are more and more features supported all the time and for those that are not, the tools are there to write your own. React allows you to create your own modules to use any native feature or native code that you need.

  3. The UI guidelines between iOS and Android are and always will be very different. Take for example a navigation drawer vs a bottom menu. Implementing these will take very different layouts (Android is now warming up to the bottom menu concept). React-Native encourages you to go ahead and do just that for each platform rather than try to force something that doesn’t look quite right on either device. Users are accustomed to the look and feel of their respective devices and that needs to be accommodated in app design.

  4. Native developers can think of this as another tool in the toolbox, and React-Native will need native Android and native iOS developers to work. Custom modules will have to be created all the time to keep up with platform changes and someone needs to have a deep understanding of their platforms design standards, workflows, and architecture. Take for example the changes in Android 6.0 that gave us line item permissions. The API for handling this can be somewhat complex. Are there some apps that could be written in React-native with no Native platform experience whatsoever? Sure, but in my experience those apps do not exist outside of a demo or sample. When you start working out the details of an enterprise level app for a client there will be roadblocks every step of the way. I get the feeling that React-native understands this.


After spending a few days getting to know React-Native I think I am starting to see where this can help the team as a whole. Again, keep mind that my perspective may be a little different than most being a native mobile developer first and web developer second (and by second I mean a far second). React-Native is not going provide a ‘write once run anywhere’ environment, nor will it allow a developer with no native mobile experience to turn out a complete enterprise level native app. It will however, build some bridges between the members of your team. You may still end up with a designated iOS team, Android team, and web team, but they will now better understand what the other is doing, and even contribute.

If a client came to me with a clearly defined Android application to build, and there were no concerns about other platforms or web elements of the project as a whole, a purely Android project from start to finish, then I see no reason to use React-Native. Here is the thing though; that has happened once throughout my entire professional career (the more I think about it I’m surprised it happened once at all).  No doubt we will always be working with multiple teams of developers from different platforms in the same development lifecycle. React-Native has the potential to make that process easier and more transparent for everyone involved.