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