A few months ago we wrote a blog post about the native vs. React Native debate. My key takeaway was there’s a tool for every job and there’s a context that tool was designed to work in. Choose the wrong tool, given a context, and your tools will fight you every inch of the way.
I think for a lot of use cases React Native is the right tool for the job and I’d like to cover some of the benefits as I see them. In my opinion, it significantly reduces your time to value, lowers cost, and increases organizational agility.
Minimizing Time to Value
Let's say we need to add a new screen to our app. In the native world, I’d need to implement the screen and recompile the app to see it in my simulator. In React Native I see the changes I make in realtime using fast refresh. I don’t have to wait for the app to recompile and reload on the simulator. Taking compile-time out of the equation is a huge time savings as you iteratively build out features and layout screens.
React Native uses a library from Facebook called Yoga. Under the covers, Yoga allows you to use a CSS paradigm called flexbox to lay out UI components quickly and does most of the heavy lifting to make sure that the layout works across different screen sizes. Most of the time it is also good across platforms so you don't have to duplicate your layout efforts in iOS and Android. I have found this a lot easier than mucking with auto layout and constraints in iOS.
Over the air deployments (aka Codepush)
Declarative Programming and Centralized State Management
The declarative programming model of React Native makes your code more predictable and easier to debug. There's also a rich set of patterns and practices around react. One of those patterns is to centralize your application state. Having a single source of truth makes your application easier to debug and reason about.
In my experience, one of the cool things about dynamic languages is that they are easier to write tests for. I can write tests at higher levels in my application without having to worry about incorporating intricate dependency injection strategies. Yes, you’re right there’s no type safety, but there are solutions if you feel like you need it like typescript.
React Native allows you to get a tremendous amount of code reuse between your iOS and Android apps. For example, in the project I am currently working on we’re seeing code reuse well over 90%, which echoes similar experience other projects at Rocket are seeing. It also echoes what other companies in the software industry are seeing. For example, Shopify is seeing over 95% reuse in their React Native projects. This means you can use one code base between iOS and Android. Think about the things this enables:
A Smaller Team
You don’t need separate teams for your iOS and Android Apps which means a smaller overall team size and fewer people supporting that consolidated team. Planning also becomes easier because you don’t need to coordinate new features between two teams’ release schedules which means fewer meetings. This helps keep costs down.
With one code base, you don’t need to duplicate business logic or tests of that logic in your iOS and Android Apps. Less code means lower maintenance costs, fewer tests, fewer bugs, and easier deployments.
React Native allows your organization to be more nimble by allowing you to redeploy resources from web to mobile or vice versa as organizational priorities shift. One of our clients needed a web admin portal to support the React Native mobile app that we were building. They were able to reallocate two of the React Native devs to go work on the portal and the devs were productive and contributing on day 1.
Should you be using React Native?
In the right situations, I’d respond with why aren’t you? As you have seen it allows you to put features in the hands of your users faster with tooling that allows you to iterate more quickly than pure mobile development, and allows you to run with a smaller, more nimble team with a shared skillset that can be leveraged across technical problems your org faces.