Moving to React Native and a Single Codebase: the Great, the Good and the Bad
In this article you’ll find how a single codebase can massively improve development productivity, why we’re big fans of React Native, and why it still might not be the right choice for your product.
With a range of benefits that drive improved developer productivity, moving to a single codebase can help with demanding feature release cycles, whilst offering a seamless user experience to the widest possible audience. As recently demonstrated by some major players, a robust and reliable single codebase is increasingly key in the evolving world of App development.
In this article you’ll discover how a single codebase can bring multiple benefits, why we’re big fans of React Native here, and why, despite all that, it still might not be the right choice for your product.
In this article we cover:
Why choose React Native now?
React Native has matured a lot over the years, so it’s not just the new hyped framework.
The project's maintainers (alongside its active communities) have consistently made the experience of building React Native applications both seamless and smooth. We have seen significant improvements over the last three years in terms of prototyping, tooling, and testing.
That’s the reason why companies like Airbnb, Discord, Instagram, and Walmart have put their eggs into the React Native basket, as it offers not only a faster and simplified way to get applications running on multiple platforms but also a robust and reliable chain of tools that allows developers to achieve the same results requiring way fewer resources when compared to their native counterparts.
From a developer's perspective, the first area where React Native shines is in the possibility of using Javascript, since it’s a dynamically typed language that’s widely known and easy to learn.
That makes it faster for new developers to grasp how React Native works since they can bring the Javascript experience they already have from building web applications into their new React Native project.
This is not the case for other frameworks like Flutter.
If a dynamically typed language doesn’t cut it for you, or if you’re working on medium-sized/enterprise projects, React Native also has support for using Typescript, which greatly improves the developer experience, especially when you have multiple team members working in the same codebase.
How React Native can improve Developer Productivity
In essence, React Native provides the ability to have a single codebase being used for an Android and iOS app at the same time. In practice that means no more:
- Delayed features in one platform over the other
- Replicating bug fixes for each of your apps
- Technical debt between teams that are working on different projects that do the same thing
And yes, in case you decide to work with other hybrid frameworks like Flutter, Ionic, or Xamarin, you can still essentially get the same benefits in terms of having a single codebase, but React Native can enhance your experience as a developer in many more ways.
So let’s dig further into the great aspects to consider how this represents a huge increase in productivity:
Componentization
Another great thing about React Native is that by its very nature it focuses on code composition and componentization, so every piece of a React Native application can be reused in many places throughout the app.
That on its own can have a great impact on the productivity of your team depending on how your application is structured since components are written once and used in several places.
On this note, the React Native community has already created thousands of different components (buttons, text inputs, checkboxes, carousels, modals) that can simply be imported into your project when you want to quickly prototype and launch your idea.
On the other hand, if you don’t want to or can’t rely on external libraries, React Native also offers the flexibility to start creating your own custom components to make sure the look and feel of your app is just as you want it to be.
Available integrations
It’s also important to note that many enterprise-level third-party libraries you’re probably currently using on your native app that has SDKs that are specific to Android and iOS like Firebase, Sentry, and OneSignal already have wrappers for React Native, so you can easily integrate these tools into your application with no need for actually digging deep into native code for either platform.
Community support
Last but definitely not least, community support is something that us as developers cannot live without.
Nothing can slow the development of a new feature more than being stuck in a problem that looks like no one has ever gone through. React Native together with Javascript has over 2.3M questions answered on Stack Overflow, so you can rest assured that pretty much any issue you’re going to run into already has an answer waiting for you.
And just as importantly, if you run into something new, there are thousands of people using this technology on a daily basis in real-world scenarios that are willing to help, so you can focus on what really matters: building your amazing app.
Tech considerations before moving to React Native
With all that said you probably already got the idea that React Native is plenty powerful and that it can be used in a variety of situations right?
Cool, but don’t get too excited yet because React Native may not be the right technology for you and your project.
There are certain drawbacks of using hybrid tools like React Native that you need to be aware of before making the final decision.
Performance
The first thing you need to understand is that React Native’s performance is close to native, but it’s just not the same.
What that means is that if you put a React Native and an Android/iOS app side by side most people will probably not be able to tell the difference, but if you’re the type of developer who cares about every single frame that’s being rendered in the screen, and/or if your application has a really CPU intensive data flow, then it’s probably best if you consider building a native Android/iOS application.
A very simplistic way of explaining why React Native wouldn’t be ideal for those situations is because React Native uses a bridge to communicate with the Native layer of the device, so every time you run a task, there’s a (small) delay from the time you send the request to when you get the response, since the React Native bridge has to pass the data to the Native layer and then send it back to the JS layer of your application.
App-hardware integrations
Another scenario where React Native is probably not a good fit is when your app does too many low level interactions with the device.
When you’re building an application that has this kind of need it’s best if you go native since you’re going to constantly find yourself having to write the native Android/iOS code for the feature and then having to create React Native modules to wrap that code so it can be used on the Javascript layer.
Even worse, since each platform has different SDKs to manipulate the hardware it’s running on, there will be lots of limitations in terms of what can be done exactly the same on all platforms.
So if you can’t take advantage of React Native’s ability to share code between multiple platforms, it’s most likely a better idea to build native applications for each of the platforms you plan on launching, it’ll be faster, more organized and guaranteed that you’ll be able to achieve your desired results as the project grows.
Native knowledge
With that in mind, it’s also important to consider that contrary to what most people believe, it’s not enough to know only Javascript/Typescript when you’re building a React Native app since most applications with actually advanced features will require the development team to at some point have to deal with native Java/Kotlin (Android) and/or Swift/Objective-C (iOS) code.
Therefore, at least some of your team members should have experience with building native applications for the platforms you’re going to be launching.
Having experience with native platforms helps with debugging/profiling unusual issues that the app may run into, as well as identifying possible flaws in terms of how the application will run on a specific platform.
After all, even though it’s being written in Javascript/Typescript, the application will run on the Android/iOS operating system, so it must obey the rules defined by that system.
That experience will also prevent you from getting stuck in the future when wanting to integrate a library that doesn’t offer React Native bindings on its own, or when having to add any kind of communication to the native layer of the application.
Storage
Last but not least, it’s also important to consider that usually, a React Native application has a bigger footprint in the device’s storage when compared to a native application.
That may seem like an edge case since nowadays devices come with up to 1TB of storage, but it may be a deal breaker if you’re planning to release an application that’s going to run on really old devices where storage can be as low as 16GB and users are really concerned about how much space each app is consuming on the device.
Conclusion
We believe that when appropriate a single codebase approach should be favored, but each project and team is different, so now with an understanding of the great, the good, and the bad of React Native, you make your own analysis and make the best decision for your needs—hopefully, it will be an easier task for you with the information shared in this article.