Why You Should Consider React Native For Your Next Native App

If you're deciding how to build your next mobile application, here's why you should consider using React Native.

As a developer who’s created mobile apps using React Native and Swift, I’ve come across pros and cons for each approach, and the advantages of React Native certainly outweigh its disadvantages. I should also emphasize that this article is not meant to convince you to use React Native for every mobile application, and you shouldn't. React Native is not the de facto solution to building mobile apps. It still has a lot of shortcomings, but given the right use case, it is an effective solution to shipping a cross-platform app without compromising user experience.

Cross Platform Business Logic + Native UI

The biggest selling point of React Native is the fact that it lets you build native apps using the same technologies that web developers are already using. It lets you render truly native view components using the same declarative React API that we all love. This is not the case when writing an app in Swift, where the UI is built imperatively, meaning we have to explicitly handle all UI changes versus declaring our UI and letting React handle the rest of it for us.

What's also great about React Native is that the JavaScript code runs on its own thread apart from the main UI thread, which lets us build apps that can execute complex logic but still maintain the 60 fps experience that we all expect. Should you need any custom native functionality, React Native also makes that possible by providing an excellent bridging API.

JavaScript Ecosystem

The JavaScript ecosystem has grown tremendously in the past few years with no signs of slowing down. The amount of tools and libraries out there is overwhelming, and there is a thriving community constantly contributing to an already abundant pool of native modules. We can simply add modules when needed without having to worry about SDK compatibility or messing around with third party binaries.

We love building and using open source tools, so over the years we've worked on our own open source state management tool for React, Microcosm, to help us conquer the data layer. It's something that our team is very productive with, so we've had no problem using it within a React Native app.

If you've used Core Data before, you know how much of a pain it is to set up and how much boilerplate code it brings to a project just to add some simple data persistence. And I can't count the number of times I've had to write 10 - 20 lines of code to parse a JSON file when I can just do JSON.parse() and be done with it.

Smooth Developer Experience

React Native adheres to Facebook's philosophy of "learn once, write anywhere". It helps web developers build native apps using tools they're already familiar with, and this has massive gains from an economical and technical perspective. Projects like Expo and create-react-native-app make it easy to get started with a React Native project by handling all the initial configuration and scaffolding of the app, so the barrier to entry is pretty low. If you've worked with AutoLayout and Storyboards in Xcode, you know how steep of a learning curve iOS programming can be. With React Native, you can scrap all that and use CSS-in-JS and flexbox for all layout needs. Couple that with the the built in UI inspector and profiler and you're set.

Modern Tooling

Web tooling has made huge leaps in the past few years. Things like live reloading, hot module replacement, remote debugging, wireless compilation, and inspectable UI makes React Native development that much more productive. None of these luxuries are available at the ready when doing native iOS development. Even compiling a basic Swift app takes 5 - 10 seconds. That's a lot of time to wait between incremental changes, and can easily take you out of your flow. Compound that over a few hours of iterating on an app and you've easily lost time that could've been used for something more productive than waiting around for Xcode.

The remote debugger and interactive UI inspector/profiler in action. Not the type of setup you can get in native iOS development.


So far, we've only talked about the benefits of React Native. But I think it's valuable to understand where React Native falls short.

Xcode is a very productive IDE to work in, and Swift is an empowering programming language. Its strong type system and functional features help us write elegant, readable code, and Xcode provides excellent interactive documentation to help navigate the entire iOS API. Other small things like compiler hints and warnings ensure the code that's being written is safe. We used Flow for this project to ensure static typing but it's really a just a superset of JavaScript and not a fully featured statically typed language.

In terms of performance, React Native is executing all the JavaScript on a single thread, meaning you don't get to harness the power of multithreading that is available when using the native APIs. This isn't really a problem for most apps, but if you're trying to make a game, interface with hardware, or do expensive computations, your app will suffer.

React Native comes with a massive dependency chain of its own and we all know that having so many dependencies is not ideal. Just take a look at the dependency graph below, which you can interact with here. That is a lot of nodes.

Debugging React Native modules can sometimes get tough, especially because there is so much abstraction between the JS layer and the native layer. It can feel like you're working inside a black box. If you're writing native iOS code, you're solely depending on the iOS platform itself. It feels secure, transparent, and the foundation doesn't feel shaky because the iOS API has matured so much over the past 10 years. React Native is only a few years old, so it's nearly not as mature.

Something else worth noting is that when you're choosing React Native, you're opting into a platform, not a framework or a library. That means your product is at the mercy of the creators and maintainers of this platform. This might be either good or bad, but the decision is up to you. You're also opting into another layer of abstraction between you and the device's native API, so you have to accept that it will never be the same as native development. And while your users may not notice or care if it's a React Native app or not, as a developer it's hard to overlook the fact that something will always feel slightly off.

Closing Thoughts

With that said, React Native is still a nascent tool (v0.46 at the time of writing this article), and has matured very well so far. The fact that it's being used in production by the likes of Facebook, Instagram and Airbnb speaks volumes about how powerful it really is. There is still a lot of room to grow and I'm excited to see where it goes in the next few years. It's fascinating that we can even build native apps this way and I imagine it's only going to get better from here!

Sign up for The Viget Newsletter

Nobody likes popups, so we waited until now to recommend our newsletter, a curated periodical featuring thoughts, opinions, and tools for building a better digital world. Read the current issue.