In recent years, a lot has changed in the field of app development. Gone are the days when apps had to be developed separately for each operating system to be supported. Hybrid apps are the new trend. For good reason: Hybrid development saves enormous amounts of time, costs, and other resources. The vast majority of apps that leave our app agency are developed in React Native. Many clients ask us: What is it that allows you to implement my app in a fraction of the usual time? We provide you with an overview, including pros and cons.
React Native in a Nutshell
Heads up, this gets a bit technical — but we’ll keep it short for clarity. React Native is a framework (essentially a toolkit) for developing primarily, but not exclusively, smartphone apps. It is based on the UI framework React and extends it, as the name suggests, with the ability to develop native apps for different operating systems. While "true" native apps are developed directly for a specific operating system, React Native apps are developed "universally." The written code is then packaged into a native iOS or Android app. Through a so-called bridge, which is also included in the native app generated by React Native, the packaged code can then communicate directly with the operating system. This makes it possible to use software and hardware functions that pure web apps, for example, do not have access to. UI elements are rendered directly through the native app and don’t need to communicate over the bridge. This gives React Native apps outstanding performance, which doesn’t have to hide from native apps.
Who Uses React Native?
The chance is high that you have at least one app (probably many more) installed on your smartphone that was developed in React Native. React and React Native are primarily developed by the internet giant Meta, but both have an enormously large open-source community. Among others, the apps of Facebook itself, Amazon including Kindle, Microsoft Office, Pinterest, and many more were developed in React Native. You can see an overview of other apps in the Showcase on the React Native website. However, this is only a tiny snippet. You probably use more apps developed with React Native than you think — and you won’t be able to notice the difference from native apps.
The Turbo for Your App Project
The big advantage of React Native (as with other similar frameworks like Flutter) is that an app only needs to be developed once. What sounds trivial has a huge impact on the time and budget required. The universal React Native code can then be exported as a native app for any possible operating system. In most cases, that's iOS and Android. However, it is equally possible to develop web apps, applications for macOS and Windows, and even the Apple TV with React Native. All with a single codebase. Granted: Here and there, device- and operating system-specific adjustments and optimizations must be made. Not everything that works smoothly on iOS runs directly on Android. The effort for this is so marginal compared to developing two separate apps for each operating system that it can be almost completely neglected.
In the end, it is therefore possible to develop an app for iOS, Android, macOS, Windows, and the web for the price and time of one app.
Open-Source and the Ecosystem
Another point that React Native can boast is the community behind it. While React Native provides a solid basis, there are countless libraries from volunteer open-source developers, which enable apps to be implemented even faster and more efficiently without having to reinvent the wheel at every corner. The app needs a navigation with a tab bar at the bottom of the screen? Sure, someone has already solved that. The app needs access to the camera and GPS? There are several handfuls of freely accessible modules just for that.
However, there are two dangerous traps here: On the one hand, one could be tempted to sift through the plethora of open-source libraries and clutter the app with completely irrelevant functions and UI elements for the user. Not only does this affect the app’s performance, but it also adds nothing for the user and makes the app more complex than it needs to be. The much greater danger lies in the choice of modules to use: It must be noted that these are ultimately only developed on a voluntary basis. Nothing prevents a maintainer of an open-source library from discontinuing development from one day to the next. If you want your app to continue to be developed, this usually means that the affected module must be replaced or replaced with your own code. This results in double work in part. It is therefore extremely important to have an experienced and React Native-specialized agency on hand that is familiar with the ecosystem around React Native and knows which modules can be used to what extent without risking shooting yourself in the foot in the long run.
Expo – React Native on Speed
Particularly noteworthy in the React Native ecosystem is Expo. There is virtually no app that leaves our agency without using at least one module from Expo, or being fully integrated into Expo's own ecosystem. Expo is a veteran in the React Native community and has been actively advancing its development for years. A completely new system of frameworks, modules, and tools has now emerged that greatly simplifies working with React Native. Here too: The app needs access to the camera? There’s an Expo module for that. Need access to the user’s location? No problem, Expo has a library for that.
For a long time, however, using Expo modules had the disadvantage of "locking" oneself into the Expo system (vendor lock-in). Their modules could only be used if one also used Expo's toolkits, which in turn meant that React Native’s own toolkits could no longer be used. Moreover, if you used Expo, many libraries from other providers couldn’t be used either, which also meant that some software and hardware functions, such as in-app purchases, couldn’t be implemented at all if you relied on Expo. In rather inexperienced circles of app developers, Expo is still somewhat discredited. However, this is completely unfounded: At the latest since November 2021 and the release of the Expo Application Services (EAS), this vendor lock-in no longer exists. All Expo modules and even Expo’s toolkits can be used without locking oneself in as a result. Using libraries from other providers is also no longer a problem with the simultaneous use of Expo. At the same time, compiling (i.e. packaging the code into a runnable app) and distributing React Native apps has become much easier thanks to Expo EAS. Today, the rule is: Anything that can be done in React Native can also be done in Expo — but faster, more comfortably, and efficiently thanks to the comprehensive toolsets. Those interested in a slightly more technical explanation of EAS will get a good explanation of the difference from the previous workflow in this post by Expo.
How Future-Proof is React Native?
With all these advantages, you might be wondering if this is future-proof. After all, React Native is just another layer of your app that may fall away someday. Here too, React Native shines with the strong support of the open-source community. Even if Meta should ever decide not to continue developing React Native, the chances are extremely high that another developer team will take on this role. Numerous business models have now emerged around React Native, not least the aforementioned Expo Application Services, which means a lot of money is involved in the system. It is therefore almost impossible for React Native to disappear or stop being developed overnight. Even the thought that Meta loses interest in continuing to develop React Native is quite far-fetched: After all, Meta probably has little interest in having to rebuild a large part of its own apps, which itself rely on React Native. With an app developed in React Native, you are opting for a future-proof option that not only makes your app development faster and more efficient but also more cost-effective.
Disadvantages and Limitations
Having raved about React Native in this article so far, it’s only fair to point out disadvantages, and where a native app might be the more sensible option. One thing upfront: If you hire a developer who advises against React Native because feature X or Y cannot be implemented and only a native app would be possible, that developer unfortunately has a fundamental misunderstanding of React Native. As described at the beginning of this article, React Native is not just a nice-looking web app. Even if there isn't a ready-made module for a specific function, it is possible to develop this function natively for the desired operating systems and let the native code communicate with the universal hybrid code through the bridge. So, there still does not have to be a completely separate app developed for each operating system; only the desired function itself needs to be developed separately. The business logic based on this native function is then found in the universal code, which only needs to be developed once. For this to be possible, however, it requires a developer or agency deeply familiar with React Native and specialized in developing with it. A rather inexperienced developer will only be able to rely on open-source modules, unable to develop their own native module if there is no ready-made solution. This will quickly lead them to advise you to simply develop the entire app natively. A costly mistake.
Nevertheless, there are also situations where a native app makes more sense. However, these are so rare that we can count them on two hands in our agency's history. Mainly, these situations involve the required performance of the app. If it relies on peak performance, React Native is out of the question. However, the likelihood is high that you think your app requires more performance than is actually necessary. Speed that React Native can no longer offer is typically only needed by apps that handle complex 3D visualizations, augmented reality, video editing, or the like, as well as by 3D-based video games. We would be happy to advise you on this with regard to your app project in a non-binding initial conversation.