React Native: The Good, The Bad, and The Ugly

June 15, 2018 Eric Nograles

Editor’s Note: This blog was originally written for and published to Quora by our fellow Appirian Eric Nograles. Enjoy this crossover hit!

We used React Native (RN) to build an iOS and Android app for a retail client who expected upwards of 500k users as their ultimate install base. I believe the best way to summarize our experience with RN is through three categories: The Good, The Bad, and The Ugly.

The Good

  • Batteries included option. If you’re not keen to set out on your own with only “vanilla” React Native and the ecosystem, Expo is the ticket. Their claim to be the fastest way to build an app is more reality than marketing. It is indeed one of the lowest friction, easiest to use platforms we’ve ever seen and highly recommend starting with them.
    • Check out Snack to quite literally get going in five minutes or less, with no dependencies on Xcode or Android Studio.
  • Excellent code reuse. You can expect, at a minimum, roughly 75 percent code reuse between platforms. In our app example, the designs didn’t diverge much between iOS and Android, so our code reuse was closer to the 90 percent mark.
  • Superior developer experience. I’ve built apps on both Xamarin and Cordova/PhoneGap. The React Native developer experience is vastly superior. Out of the box, you get such things as Hot Reloading (code and see the effect in realtime), Inspector, debugging in Chrome Dev Tools, etc.
  • Flexbox translated to native mobile UI’s. This almost gets mentioned as an afterthought, but because React Native implements a subset of Flexbox (see A Complete Guide to Flexbox | CSS-Tricks), layouts really are a cinch for all form factors. It takes a little getting used to, especially if you’re not a web developer, but once you understand how it works, you can see the nearly unlimited creative freedom you have with mobile screens.
  • Yes, it’s really native and provides a superior user experience to traditional hybrid. While you are coding in JavaScript, the screens translate to native views, and therefore are performant by default. These aren’t WebViews that hybrid devs are used to with PhoneGap or Cordova.
  • Unique capabilities to a JavaScript-based platform. Over-the-Air (OTA) updates via the Expo platform or a library such as CodePush means your users get features and iterations much faster than traditional native development. Take advantage of amazing things in the React ecosystem such as Apollo GraphQL. The possibilities are limitless.
  • “Learn once, write anywhere” = believe the hype. Your experience in React Native will translate to just plain React on the web. There’s a lot of cross-pollination in libraries between RN and React. Anecdotally, the teams I’ve led using both can jump back and forth between mobile and web (and also backend with Node.js) with minimal friction and loss of velocity. “Universal JavaScript” is a very real and very powerful capability.
  • A superior philosophy. Native modules are first-class citizens, and there is great documentation on how to bridge native iOS and Android code. RN is the first “hybrid” platform I have seen where the focus is to expose the unique capabilities of each platform vs. trying to get each platform to adhere to an API that may or may not be conducive to using said platform.
    • This isn’t to say that there aren’t commonalities between platforms that can be addressed via simplified API’s. React Native adopts this as well, but not as its first prerogative.
  • A strong, vibrant community. There’s libraries for the majority of use cases you can think of. As an example, check out what’s built-in with Expo. Most of the libraries included were created by the community!

The Bad

  • The release cycle is brace-yourself fast, especially if you didn’t opt into Expo. Literally, a new version of React Native gets cut every month. While most releases don’t bring wholesale changes, there are some that end up breaking a good portion of the ecosystem and you have to wait for library maintainers to catch up. There’s really no concept of an “LTS” like you see with Node.
    • I’d highly recommend using Yarn to manage your dependencies — to lock down your versions and willfully upgrade libraries as RN drops new releases.
    • Expo has been very good about upgrade paths and documenting what breaks between versions of their SDK. They’re usually a version behind of the “main” React Native branch, so that gives you a little breathing room.
  • If setting off on your own without Expo, a bit of mental equity you need to pay up front with regards to choosing libraries. Because much of React Native is built by the community, you need to be aware of what types of complexity you’re opting into. This can be also construed as a good thing, because, as an architect, you should know the complexities you opt into in general.
    • You still need to be familiar with how native projects are structured, as you will be diving in there to “link” libraries and set configurations for native-based libraries (e.g. Google Analytics).

The Ugly

  • The “vanilla” React Native upgrade process, with respect to actually upgrading your native projects, needs major improvement. They started to address this in the 0.40 versions using Git patches, but this is the biggest pain point of the entire platform.
    • In short, every new version of React Native includes updates to the code on the native projects themselves. Unfortunately, as you develop, you’re going to be touching a good majority of those files. For example, the AppDelegate.m in iOS or the MainApplication.java in Android. This leads to “merge conflict resolution hell” with every upgrade.
    • The upgrade process with Expo has been far smoother and more deliberate.

In conclusion, we at Appirio have been very happy with our React Native experience and highly recommend it for building apps. You’ll see some eye-popping velocity when you use React Native in conjunction with Node.js in the backend. “Universal JavaScript” is an undeniable operational advantage that every organization should consider. If you want to learn more Tech Tips & Tricks and gain access to countless cloud resources, visit the Appirio Hub.

Previous Article
3 Things You Should Know Before Starting Automated Testing
3 Things You Should Know Before Starting Automated Testing

Find out what you need to know about the automated testing framework before you start automating your testi...

Next Article
Why We’re Right, Even When We’re Wrong: The Struggle with Confirmation Bias
Why We’re Right, Even When We’re Wrong: The Struggle with Confirmation Bias

How can we become more aware of our own biases? Confirmation bias is an everyday phenomena, where we active...