Back to main page
Native vs. React Native: which is right for you?
There are two ways to approach developing a mobile app for iOS and Android. You can use the native technology provided by Apple and Google to build a version for each platform, or you can find a solution to build for both at the same time. One of these solutions is a Javascript-based framework called React Native.
When thinking about native vs. React Native, one major concern companies have is cost. The challenge with native is that you want a single app but end up having to build it twice. This is especially tough if your business is just starting out and you don’t have a large team or budget to allocate to development.
That’s where React Native comes in. In theory, it could cut your development time and costs in half. Since it’s based on React, which is used for building websites, it’s easy for web developers to learn. Plus, web developers are easier to come by than mobile developers. All of these potential benefits make React Native seem like a great way to save money and quickly jump into building your product.
But is React Native really a perfect solution for fast, inexpensive, and high-quality mobile app development? Let’s break down some of the main issues you’ll need to consider and see how it stacks up against doing things natively.
The short answer
The short answer to the native vs. React Native question is that it depends on how important mobile is for your product. If you’re only looking to give your content a presence on mobile platforms, React Native can do the job quite well.
But if you need to create smooth animations, have pixel-perfect design, or you want your app to accomplish complex tasks like editing photos and videos, go for a native solution. At the moment, React Native just isn’t as good at making the best use of what mobiles have to offer.
Cross-platform compatibility
One major benefit of using React Native is that your code will run on both Android and iOS. You may have read AirBnB’s recap of their experience with React Native over the course of two years of development. Their takeaway? Most features built using React Native achieved between 95% and 100% shared code, with only 0.2% of their files being platform-specific.
In our experience, we reached even lower numbers than AirBnB. For smaller projects, React Native’s cross-platform compatibility is very high, which has the potential to save you plenty of time and money.
React Native can also facilitate collaboration with web development. We found that this generally worked quite well. You can use git submodules to share various types of code across platforms, including, hooks, helpers for components, and assets.
However, shared codebase percentages drop significantly once you add a third platform like web to your development process. Plus, certain tasks won’t show up in this metric. One thing to keep in mind when using React Native is that you still have to set up CI/CD and analytics twice, once for Android and once for iOS. This requires lots of effort and means that using tools like Nevercode, Fabric, and Firebase analytics can take more time than it would on native platforms.
Cross-platform debugging
Debugging also takes longer with React Native. This is because debugging usually needs to be done natively, and very few developers have an extensive knowledge of Android, iOS, and web. If an Android developer using React Native has to figure out how to debug iOS-specific bugs related to platform-specific tooling and libraries, they’ll be much less efficient than if a dedicated iOS developer had done so in the first place. Not to mention that React Native uses Javascript, which adds a whole other layer to your system and makes debugging more complex than it would be in native.
Development experience
React Native’s iteration speed is lightning fast. Using a feature called Hot Reloading, new builds can be tested in just a couple of seconds. The new version, Fast Refresh, promises to be even faster.
That said, the tradeoff for this kind of speed is instability. It’s not uncommon for developers to have to restart their toolchain when switching between feature branches, for example. Still, build time in React Native is much faster than native, whose compilation times don’t drop below fifteen seconds and can stretch out to twenty minutes for full builds.
Another thing to keep in mind when comparing native to React Native is the latter’s lack of maturity as a development framework. It took a lot of trial and error for our VabaSaba developers to get basic design elements like rounded corners and consistent shadows working on both iOS and Android. Getting onscreen keyboards to work well with the content was an issue, too.
This will hopefully change as React Native matures, but for the time being it’s frustrating to have to spend hours figuring out how to get consistent results building simple features like these. Facebook does seem committed to pushing things forward, however, and has rolled out regular updates to React Native over the past year. So there’s hope that this will improve in the near future.
Performance and initialization time
Though native development may take more time overall, it provides better performance, especially for hardware-intensive apps. Newer phones can handle React Native as long as your app’s user interface isn’t crammed with features, but performance will quickly drop on older models like the Samsung S8 or iPhone 7. The same is true for initialization times.
When building VabaSaba, our Tinder for cats, we spent a lot of effort getting transitions and animations running smoothly with React Native. These features required specialized React Native knowledge to build and involved a fairly steep learning curve, making it harder to optimize performance than if we had worked with native iOS and Android solutions.
Open Source Libraries
React Native taps into the very large Javascript ecosystem, which can provide developers with tons of libraries to work with. In practice, however, it often takes time to search through these libraries, try things out, and make compromises based on what they have to offer. Libraries don’t always have an active maintainer, either, so you have to take into account the time it takes to maintain them on your own when considering React Native.
Plus, open source libraries are often written from the perspective of a single platform. We couldn’t use the Lottie animation library for Android in a recent project because the React Native version for Android was much older than the iOS version. That’s the tradeoff for React Native’s extensive reach: it can’t be great at everything all at once.
Native vs. React Native: the takeaway
Building hybrid apps isn’t easy. If your team starts developing something with React Native then encounters an issue that can only be resolved natively, you’ll end up spending much more time and effort figuring things out than if you had gone with a native solution from the start.
Overall, our developers like the idea behind React Native but find that using it often involves more problem-solving than it does actual development. This is particularly true for apps that have complex UX/UI or require intensive uses of mobile hardware, but also true for certain basic design elements that aren’t as easy to build as expected.
We’d recommend React Native for lighter projects that don’t need to do much more than display information about a product. But if the app you’re building is a central part of your business, if it needs to use system resources efficiently, or if it has to focus on security, it’s best to turn to native Android and iOS development tools.
Still, Facebook has been very active developing React Native recently, with a focus on fixing its pain points in an open source way. If they keep this pace up, React Native promises to become a very powerful tool for helping companies save time and money on development without sacrificing quality. Only time will tell whether that promise is met or not.
Looking for a software development partner?
We can help you to decide which technological framework to use, put together a development roadmap and build your product with lightning speed. Want to find out more? Drop us an email.
Although the author of this article is Siim Pruulman, the author wishes to thank the following team members for their valuable input and critical mind: Jakob Hoyer, Priit Tiidla, Nick Walker and Artur Pata.
