Three reasons to choose React Native

I occasionally get asked how someone might go about building a mobile app. Many product families include an app for iOS/Android, and whilst the gold rush of the early App Store days are over, you do still encounter people who have a great idea for the next big thing, but aren’t sure where to start. The debate around the merit of building a Progressive Web App (PWA) can be looked at another time.

I usually recommend using React Native — and for new apps, Expo in particular. React Native lets you build applications using Javascript (or TypeScript — its well supported), and Expo is a supplemental family of services and libraries that further simplify native app creation. The alternative recommendation would be to build using a more platform-native approach — so Objective C/Swift on iOS or Kotlin for Android. But provided you don’t have a compelling reason to use these (such as in-house talent or an existing app), I believe React Native is the best choice.

In this post I’ll set out three compelling reasons why I think this is the case. “Best choice” for me means an option that grants the developer the most leverage in building an app, whilst enabling them to provide a great user experience.

It’s also important to mention one possible reason that I’ve excluded, which is the idea of “Write Once, Run Anywhere” — the possibility that you can build your application once, and it’ll work on both Android and iOS. This is a promise that I would say is partially met by React Native. You can build screens etc. that work cross-platform, and my experience is that a large percentage of your app doesn’t require any platform specific expertise. But, in an example of the 80:20 rule, there’s still 20% which will be platform specific and its this area where you’ll inevitably spend more time. In particular, things like deployment and releasing your app do require some specific knowledge (the App Store and Play Store are quite different). There’s no such thing as a free lunch.

React Native (often abbreviated to RN) uses React. If you use React on the web you’ll find RN somewhat easier to get started with. But I don’t think thats the big advantage — React is quite learnable, and some of the more “expert-level” web skills are not really transferrable.

The big win for me is that RN is part of the React ecosystem. If you write unit tests in Jest for a React web application, you’ll find writing Jest unit tests for a RN app straightforward. You can continue to use many of your favourite libraries — from state management tools like Redux and Recoil, to styling with Styled Components. And of course you can chose to use familiar JS technologies like TypeScript or Lodash.

You might not be able to literally copy and paste everything from your web app’s codebase to your native app, but you'll be able to transfer knowledge and experience and this counts for a lot more. Typing is not the bottleneck.

React Native’s home page currently has the strap-line “Learn once, write anywhere.” — I couldn’t agree more.

React uses a declarative approach to UI, and the success of this approach (and other frameworks that also take the same direction) has been clear to see. Until recently, with SwiftUI and Jetpack Compose, declarative UI required third-party frameworks on native iOS/Android — my experience of these has been pretty negative.

That you build a declarative UI is one of the most compelling reasons to select React Native. This approach is quicker to build, easier to iterate, easier to test, more beginner friendly — and when you do encounter a bug or some difficulty, far easier to reason about and understand.

Whilst the first-party declarative solutions are still immature (I would not recommend SwiftUI for production yet), the best way to build a declarative UI for a mobile app is via React Native — and this is a compelling enough benefit that it should be part of making your technology choice.

Over the air (OTA) updates are a way of updating a mobile application that has already been downloaded and installed on a user’s device — avoiding the delays of App Store approval.

If you come from a web development background, its quite a shift to realise that once you have released a version of your app, if someone was to discover a bug, the only way to get a fix deployed is to release another version of the app — and hope that your users install it. This is really different to just pushing an update to your CDN or re-deploying some backend code. Its more unforgiving.

Not everyone has a QA team to ensure every release is bug free, and during the early phases of building an app, ensuring that every release is 100% perfect is a noble but time-consuming endeavour — your time would probably be better spent elsewhere.

OTA updates are possible with React Native as a lot of your app is a JS bundle — the “native” part of the app can check for and download a new bundle at launch if needed. This means you can quickly push out small fixes. Expo makes this really straightforward. It’s a huge benefit — it enables you to move quickly and iterate fast on the released version of your app.

Use React Native! If you value quickly building great applications, it’s a fantastic choice.