Cost-saving is usually the most apparent benefit, given that — on a typical project — a single engineer is able to work on an iOS and Android app simultaneously. The same goes for an application’s post-launch maintenance and new feature development; at this point, the client normally needs to find two native engineers to get familiar with the codebase and start working on the project. In the case of cross-platform development, the client only needs one.
Nevertheless, due to high demand, finding a really good React Native engineer is definitely not an easy task these days. Therefore, the math is not that simple, and 1 does not always equal 2.
Not all applications are a great fit for React Native and that is why, at STRV, each application proposal is closely reviewed by our Frontend (React Native), iOS and Android departments to determine whether native or cross-platform development is the best fit. It is not uncommon for clients to approach us with a request for a complex React Native application and us suggesting native development instead, to ensure client and project success. On the other side of that, our Android and iOS departments sometimes suggest React Native on less feature-intensive projects to benefit from cross-platform development.
The State of React Native
To follow up on the statements above, it is worth mentioning that React Native is not just for simple applications. The framework is battle-tested by Facebook and Instagram applications, which regularly appear on the AppStore’s Top 10 Most Downloaded Apps in the US. And, recently, Coinbase — the biggest crypto exchange platform and a heavy React Native user — nabbed the #1 spot on the list. There are many other leading companies using React Native; you can learn more on the React Native website.
Among those companies, Microsoft has started investing in the framework, with Skype and Office applications now written in React Native. And not only has Microsoft taken an active part in the new React Native versions’ release process, but it’s also been developing react-native-windows — a library to ease the development of desktop apps for both Windows and macOS. A great example of a successful approach is the rewrite of Facebook’s Messenger desktop app from Electron, the current cross-platform desktop go-to solution, to React Native. This goes hand in hand with React Native’s Many Platform Vision. Some of the main motivations were also described in a recent React Conf 2021 talk.
Trends
Shift to Expo
Looking at the applications currently under development at STRV, we have seen a major shift towards Expo, a React Native framework that tries to abstract out manipulation of native iOS and Android code to allow web engineers with knowledge of React to build mobile apps without major roadblocks. We were quite skeptical about Expo; just a year ago, I suggested that you can’t build a professional application with it. Oh, how things change in frontend development…
The truth is that of our two new React Native projects, both are Expo applications. In both cases, the codebase was already bootstrapped by the client, so it was not exactly our choice — yet we’ve seen major improvements in the Expo ecosystem, which is why we decided to stay open-minded and give it a go. Additionally, keeping what’s best for our clients in mind, ejecting a project from the start would mean adding complexity with which the clients’ internal engineers might struggle in terms of productivity.
To add perspective, we generally had two big problems with Expo projects. The first was that whatever features you needed, once you shipped your application, Expo would bundle all its features with it — meaning that the resulting application size would be a minimum of 50MB, regardless of its simplicity.
The second was that, when integrating a package that was not part of the Expo environment, you would have to start managing everything Expo was doing previously for you — a painful process previously called “ejecting.” Therefore, it always made sense to build pure React Native applications from the start to offer the best customization for our clients and a small application size for their users.
Neither of the arguments above holds true anymore. First, Expo introduced the Expo Application Services (EAS) build system, which bundles only features your application actually uses. Once we migrated a client's app from the previous Expo build system to EAS, the iOS application size dropped by 63%, from 70MB to 26MB.
Secondly, the changes in the build system enabled customization of Expo applications with a new config plugins environment. Now, whenever we need to customize our React Native project the way traditional Expo would not allow us to, we can write an Expo config plugin that will do the customization for us. On my current project, I have five essential config plugins (three of my own, two community-driven) and another two from the community I use for development — proving that without customization, one would have to either eject from Expo or make sacrifices on certain features.
Moreover, EAS tremendously helps with credential management for submitting applications to app stores, which is a common pain point for a React Native engineer who has to learn specificities for both iOS and Android store submissions. Not everyone has the luxury of having colleagues from native departments nearby to offer their expertise (like we do at STRV).
Overall, Expo has made a huge leap forward in 2021 and I believe that slow convergence towards Expo will benefit the previously split community of React Native engineers who would develop only in Expo versus those who would prefer full control and would not give it a chance (which used to be our case). Standardization of React Native applications should also help the clients, making it easier to find and hire the right engineering candidates who will be maintaining the application and its codebase.
Competition
There’s been quite a big hype around Flutter, a cross-platform framework by Google. Its popularity has been growing rapidly, even catching the attention of our Android department. These days, it is quite common to compare React Native to Flutter, with each side elevating its favorite framework. Yet the truth is that competition only benefits everyone.
I believe that both frameworks can thrive and learn from each other. It might be a good thing that React Native is not the only major cross-platform player, should something extreme happen — like Apple considering limiting the presence of cross-platform applications.
For us, React Native is a battle-tested cross-platform solution that provides our clients a familiar codebase to work with. But we have also started actively utilizing Kotlin Multiplatform, an elegant cross-platform solution that allows our Android and iOS departments to share the business logic part of the codebase, offering time-saving and consistency across both applications.
Looking Ahead
We have many things to be excited about in the React Native ecosystem. The major evolution coming in 2022 is most likely a release of a new rendering system called Fabric, which has been in development since 2018 and, by the way, is already powering over 1,000 screens on your Facebook application.
Overall, React Native’s new architecture promises even better performance and application start-up times. A big part of this will also be Hermes, a javascript engine optimized for React Native originally built to speed up Android applications. Recently, it got the support of iOS and is on track to become the new default.
The new architecture release will coincide with React 18 bringing Suspense, a data fetching evolution that has been in the works for a few years. Together with Suspense, the new architecture will allow applications to not only be faster but feel faster.
The React Native community is also very active, and one of the most exciting projects within the space is React Native Skia, an implementation of Skia — Google’s 2D graphics engine powering Flutter applications (proving my point about competition benefits). Hopefully, we may see a stable release this year, allowing engineers to utilize new drawing capabilities and shift some graphics from less performant SVGs to Skia.
Another community project to watch is RePack, a toolkit bringing Webpack — a module bundler — and its powerful ecosystem to React Native. It’s a much-needed competition to Metro, the current default bundler solution that has not seen a significant improvement compared to new web-based bundlers.
Finally, I would like to go back to Expo, which we will definitely see growing further. EAS Updates — an evolution of Expo Updates — has just been released to preview, allowing developers to create workflows in which they can update mobile applications “over-the-air” without the need to go through the Apple or Google store review. It’s a total life-saver to instantly fix little bugs.
There are also Expo Modules in the works, which should allow us to write React Native packages in Swift (iOS) and Kotlin (Android). Those are easier programming languages to learn compared to Objective-C and Java, empowering more engineers in bringing native iOS and Android features to React Native.
Summary
React Native has been evolving and it is encouraging to see both Facebook and Microsoft heavily investing in its future. Given its cost-saving potential and codebase familiarity and maintainability, it is an attractive option for those of our clients who frequently consider it as their solution of choice. Yet years of experience in architecting mobile applications and solutions positions us as a company that understands in which cases React Native can truly thrive, thereby letting us ensure the success of our clients’ applications.
