React Native is a mature and robust tool for cross-platform mobile development. The prospect of maintaining a single codebase for both Android and iOS is extremely compelling, and for many projects it's an excellent choice. However, like any technology decision, choosing React Native involves important trade-offs that aren't always obvious until you're deep into development. We've built successful apps with both React Native and native tools, and we've learned some things about when each approach shines and when it struggles. In this article, I'll share what we've learned about the real-world pros and cons of React Native, so you can make an informed decision for your specific situation.

Let's run through an imaginary scenario, inspired by true events. Suppose you want to build an app that lets users schedule events and upload images and videos for these events. You decide to use React Native because you want to save time and effort and you believe that having a single codebase will facilitate that. You fire up a React Native project and start writing components, composing them in screens. Everything is going great. You were able to quickly implement all the features for this version of the app using only freely available JavaScript libraries that were easy to install. The development experience was phenomenal. The app seems to work well, and stakeholders are happy. But this is still just the initial version of the app. You have big plans for adding many more features.

You learn that a new version of React Native comes out, and you smartly decide to keep things up to date. After all, how hard can it be? You expect it to take no more than an hour. But as you update dependencies, you are faced with a litany of mysterious errors. You patiently dig through the source code and GitHub issues for all the libraries you’re using, and by this painstaking and time-consuming effort you finally get the app running again. Instead of 1 hour, it took 2 full days. Yikes. You hope that was just a fluke as you finally get on with adding new features to your app.

Uh-oh. You discover that even though the app is running again, the feature that displays event details - including dates and times for events - isn’t working correctly. The timestamps are off by several hours. Good thing you noticed - that could have been really bad! As you try to understand why this is happening, you discover that the new version of React Native comes with a new JavaScript engine, and that new JavaScript engine does not include something called the “Intl” API. Apparently the Intl API was included in the old JavaScript engine, and it is what ultimately powered the date/time calculations. You learn that the React Native team decided not to include Intl in the new JavaScript engine because it is too big and slow, but they didn’t replace it with something equivalent because Meta doesn’t use Intl anyway.

After another day or two of trying to find some way around this issue, you decide that the only real solution for your app is to build a custom “native module” to handle the date calculations. That means you need to write some Kotlin/Java code for Android, and some Swift/Objective-C code for iOS, along with some JavaScript “glue” code to make that platform-specific code available to the JavaScript layer. After a couple of days of development, you finally get things working again. You chose React Native because you wanted to have a single JavaScript codebase, but now you have essentially 3 codebases in 3 different languages to maintain!

Finally, you can start adding the new features such as giving users the ability to upload image and video files to your server. You find a popular open-source library to help facilitate that. Everything seems to work great, and you finally release the newly updated app. Users love the new feature and they start uploading files. But some users report that the feature isn’t working for them. They start uploading a file, it spins for a while, and then just stops. The file never gets uploaded and they never see an error message. As you investigate, you discover that uploads are timing out for iOS users with large files or slow connections, and the library you're using doesn't provide good error handling or configuration options for this scenario. You look for alternative libraries, but find that there are no other React Native libraries available that can do what you need. So you decide that your only option is to create another custom native module to handle file uploads. So much for having a single codebase.

As the months go by and you try to add new features and fix bugs, variations of the above scenario keep happening over and over. It wears you down. You start making compromises. Your app’s user experience suffers. The React Native honeymoon phase is over. The goal of having a single codebase is dashed. You are not realizing the time savings you hoped to gain by using React Native, and you're starting to wish that you'd never heard the term "cross-platform".

The truth is that it’s not React Native’s fault. It’s just that it wasn’t the right tool for this app.

Your friend Alice also wants to make an app for her health insurance company. The app is complimentary to her company’s services. It is intended to provide customers a convenient way to view basic information about their policy, find in-network providers, and provide a digital copy of their health insurance card. Alice put together detailed designs of the app. After analyzing the designs and listing the app’s requirements, she chooses to build the app with React Native. She was able to implement the app with only a single JavaScript codebase - no custom native modules were needed. Aside from the difficulties that are typical when upgrading React Native and other dependencies, the app has been very easy to maintain and has been a huge success.

So what made Alice's project succeed while the first scenario struggled? The difference comes down to understanding your app's requirements upfront, and then using the right tool for the job.

The stories above are based on real-world experiences with building & maintaining React Native apps. Some apps are more prone than others to these problems. React Native is an excellent choice for many types of apps, but it is not the best tool for every app. So how can you decide whether React Native is a good choice for your app?

The first step is having a really good understanding of your app’s requirements. Take the time to put together detailed, high-fidelity designs or semi-functional prototypes. Don’t just think about the initial MVP version.

Once you have a detailed understanding of your app’s requirements, you’re ready to make an intelligent decision about whether to build it with React Native or standard native SDKs. If your app meets all or most of the following criteria, then it is probably a good candidate for React Native:

• The app is simple, meaning it is mostly a read-only display of data that changes infrequently (as opposed to real-time updates like live scores, financial market quotations, or online multiplayer games).
• It deals with mostly textual data, with only incidental use small images, graphics, or videos. In other words - it is not a media-focused app that lets users upload or edit images or video, for example.
• It does not require the use of hardware features such as the camera, microphone, accelerometers, GPS-based location tracking, etc, or other advanced device features such as AR/VR.
• The app is not the primary way your customers interact with your business.

Just to be clear - an app built with React Native can do all of those things. A React Native app can do pretty much anything that a pure native app can do. The point is that doing certain things can be much more difficult to do well with a React Native app versus a native app.

Conversely, stick with standard platform SDKs if your app requires any of the following:

• Support for more than just phones. For example, if you need the app to also run on Apple CarPlay or Android Auto widgets, smart watches, or tablets
• Highly interactive screen such as graphics-intensive games, or custom diagramming/drawing features
• Lots of image, video, or audio assets, for either viewing, editing, or uploading
• Real-time data streaming
• Lots of background processing
• Access to device hardware such as the camera, sensors, GPS location tracking, bluetooth, NFC, LiDAR, etc.
• Advanced frameworks such as Augmented Reality, Machine Learning, speech recognition, Natural Language Processing, etc.
• Apple Pay or Google Wallet

Generally, React Native is a fantastic choice for fairly simple apps. By “simple”, I mean an app that mostly deals with text-based data and is mostly read-only. But a simple React Native app can still deal with huge amounts of data efficiently. Shopify’s Shop app is a great example. This is an app that displays a lot of data - mostly basic images and text-driven content that you’d expect in a typical e-commerce app.

Another example of a well-known React Native app is Coinbase. In my opinion, Coinbase would probably be better off without React Native because the app is the primary way that customers interact with Coinbase, and it has to display real-time financial data. Coinbase did a great job of making it work, but I suspect it’d be a lot easier on them if they had just stuck to the standard platform SDKs. Based on their engineering blog it sounds like they had to create a lot of custom native modules.

React Native is a phenomenal tool for making apps, but it is not the best tool for all apps. By putting together detailed designs and fully understanding the requirements for your app, and by using the guidelines provided in this article, you can make an intelligent choice about whether to implement your app with a cross-platform tool like React Native or to stick with the standard native SDKs.

Not sure which approach is right for your project? We'd be happy to review your requirements and help you make an informed decision. Contact us at hello@alienmethod.com.