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.
- 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.
- 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 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 “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.