React Native FAQ 2020
We answer some of your most frequently asked questions about React Native in 2020!
Wait … we’ve done this before. Why are we doing it again?
The reason…we have more experience now, the technologies have evolved, and you have more questions! Without further ado, let’s dive into it.
Q. Should I use React Native, native, or something else?
Ah yes, let’s start with the million dollar question. 😅
We at Infinite Red built native apps for several years before switching to React Native, so we’re very familiar with the pros and cons of native development.
With that said, there’s one glaring reason to consider React Native over native development: its cross-platform story. The reality is that you can deploy the same code base, with minimal tweaking, to multiple platforms, where native code can only run on its native platform. This saves money, time, and maintenance headache down the road.
And we don’t just mean iOS and Android, although those are clearly the biggest platforms that React Native targets. We also mean web and desktop apps. This is something that Flutter and other alternatives can’t match.
Q. How does Flutter compare to React Native?
Flutter is a really well-designed framework from Google that compiles to native code rather than using a JavaScript engine to control native widgets. It’s a good alternative to React Native. However, these are some reasons to continue considering React Native over Flutter:
- React.js web: You can transfer your web skills to React Native easily. We found that React developers can be productive in React Native in about a week, whereas Flutter has a much larger learning curve. We also share a lot of code between our React web projects and React Native mobile projects!
- Dart vs JavaScript: While Dart is a fine language, it isn’t anywhere near as popular as JS. It’ll be harder to find developers who want to work on Dart projects than JS projects.
- CodePush: Flutter doesn’t support CodePush and never will.
- Flutter has Google, primarily: React Native has Facebook, Microsoft, Amazon, Shopify, and many other large companies developing extensively in it. This leads to a more thriving open source community and decreased risk that it’ll be killed off.
With that said, there are technical and business reasons to choose Flutter in some cases. For example, if you will never need web, Flutter becomes more compelling due to its excellent developer experience and solid performance. However, the two frameworks are close enough that you should weigh all aspects, not just DX and performance.
Q. How is React Native’s performance compared to native?
If you’re shooting for 60fps user interface performance, React Native and native apps are usually the same.
In raw number-crunching performance, native (and Flutter) apps will generally outperform React Native.
However, very few apps are used for just straight-line number crunching. What is far more important is common app workloads.
Additionally, there’s a point of diminishing returns with regard to performance. The app needs to be good enough to deliver a great user experience, for sure, but beyond that other aspects start to become more important (such as developer speed, ROI on adding new features, and maintainability).
Ultimately, React Native’s reliance on the JavaScript bridge is the primary bottleneck for performance. There are ways to reduce the amount that you use the bridge (for example, lottie-react-native uses native animations).
For the vast majority of apps, React Native’s performance is more than “good enough”. For apps that need more fine-tuned performance than that, you can always drop down into native code to implement those portions of the app.
Additionally, Facebook engineering has been working on a specifically tuned JavaScript engine for Android called Hermes that dramatically improves performance. Check out their announcement at Chain React 2019. They’re also working on some other changes that will reduce or even eliminate reliance on the JavaScript bridge by using JSI (JavaScript Interface) direct calls instead.
Q. How much code re-use can you get with React Native?
We’ve found that it’s not uncommon to have 100% code re-use between iOS and Android, and about 60–85% code re-use between mobile and web. In a recent client project, we were able to share almost all components, MobX-State-Tree models, utility functions, and services between all three platforms. Where we had divergences, we came up with a clever way to share the maximum amount of code. We’ll create a blog article about that when we are ready!
Q. What’s the best way to upgrade to newer versions of React Native?
Our workflow for upgrading goes like this:
- Create a new branch for the upgrade
- Open up https://react-native-community.github.io/upgrade-helper/ and choose the version your app is at and what version you want to upgrade to
- Manually, and carefully, apply the changes from the diff. Click the checkmark on each file as you complete them. Commit when done
- Go through all the major dependencies that aren’t included in bare React Native (like React Navigation, MobX-State-Tree, etc) and try to update them to the latest version if possible, one at a time. Usually the docs for each library will talk about React Native version compatibility. Commit after each successful upgrade
Very rarely, such as in the case of 0.60.0, it’s easier to generate a brand-new React Native app and copy over all your application code. This is not generally recommended but is another tool to use if you’re struggling with upgrading manually.
You can also use the built-in upgrade tool in the React Native CLI. This will walk you through upgrading. Our software engineers tend to want more control over their upgrades, but it’s a viable path especially on simpler apps.
Q. What is Expo, and is it worth using?
We love Expo at Infinite Red! When we can use it for an app, we do use it.
Expo is both a service (“Expo managed workflow”) that handles building and deploying your React Native app for you and also a set of APIs and frameworks that make building React Native apps easier.
As a service, Expo helps a ton by offloading the difficult building / compiling steps to a remote server. And as a framework, Expo’s consistent, reliable, and well-tested set of libraries (“unimodules”) helps avoid painful problems. And many of them are available even if you don’t use Expo’s managed service.
Expo’s managed workflow can’t be used for every app. When you have to integrate custom SDKs or your own push notifications or a few other limitations, you either need to use Expo’s “bare workflow” or vanilla React Native.
In conclusion: if you can use Expo, use Expo — it’s the nicest React Native development experience. Otherwise use vanilla React Native or the Expo “bare workflow”, and use Expo “unimodules”.
Q. How quickly can you implement the latest iOS / Android features when they’re released?
The answer is — immediately! Since React Native allows you to drop down into native code at any point, those latest features are available the moment you download the latest Xcode and Android SDKs.
If you’d prefer to stay in JavaScript, the fastest way to get access to new APIs is to keep an eye out for new community third-party modules that support them. You can sign up for the React Native Newsletter to know when those are released!
Q. Can you easily build for iPhone/iPad?
Yes! React Native ships with a flexbox implementation that allows you to lay out screens for the iPad form factor along with iPhone. It’s relatively straightforward and a first-class citizen in terms of support.
Q. What common React libraries work/don’t work with React Native?
Almost all React libraries work either out-of-the-box or have a React Native port to use with React Native. Even in situations where they don’t, there are usually good alternatives available. React Native is so widely used it’s hard to find gaps in third party support these days.
Q. Do you need to know Swift or Kotlin to build a React Native app?
You don’t! (Especially if you’re using Expo, but even if you’re not.) Many apps are built 100% in JavaScript/TypeScript.
However, we have found that having native language knowledge — Objective-C, Java, Swift, and Kotlin — increases the number of things you can do with React Native, and your opportunities for optimizations. For example, implementing a custom SDK requires some knowledge of Objective-C and Java, generally. But then again, we can help you with that.
Q. How much does a React Native app cost?
For one platform, you can expect it to cost about as much as a native app. However, when you deploy to the second platform, it usually only costs another 10% or less. That’s where you get the major cost-savings.
In terms of actual dollars — we can give you a range if you can talk more about your scope with us.
Q. Do you like React Native?
No. I love working with React Native. It’s a great framework and an even better community. Thanks for asking!
Acknowledgements
Thanks to Robin Heinze for her help with this article. Also Bryan Stearns, Ryan Linton, and Derek Greenberg for their insight, and of course Gant Laborde for writing the original FAQ and sparking the idea for this update! And lastly, thanks to those who answered my tweet with great questions to include.
Want to learn more?
If you have more questions about React Native, feel free to reach out to us! You can email me at jamon@infinite.red or tweet at me: https://twitter.com/jamonholmgren.
Jamon Holmgren is co-founder and CTO of Infinite Red, a mobile app/web design and dev company based in the Portland area & distributed across the USA. He lives in southwest Washington State with his wife and four kids. Follow him on Twitter for more React and React Native discussions, dad jokes, and random pictures of him in goalie gear.
