React Native is an excellent framework for building cross-platform native mobile apps. However, there is one major issue at its core that is often either not talked about or simply misunderstood.
What is the problem?
Imagine an example where in order to finish a project, we need a specific resource that we can only get from someone who happens to be Japanese.
There is no Google Translate for us to use so. Therefore, the only way we can communicate with this person is to either learn Japanese or bring in someone who can do the communication for us. What you just read above perfectly illustrates an inherent flaw in React Native and the given name for this scenario is the creation of a “Bridge”, also known as “Bridging”.
Any time we need to access a platform API such as, for example, the microphone, camera, Bluetooth, or something as specific as Apple Music on an iPhone app, a bridge has to create.
If the process of creating bridges wasn’t bad enough to hear already, the bigger problem is that these bridges must be written in the platform’s language. Therefore, we’d likely still need to keep some developers nearby in case we have to build a bridge for some specific feature in iOS or Android, which will then finally be used by the React developer.
How can this be true, and why are developers not angry?
The answer to this question is expo.io, a tool built by the community to overcome the problems we’ve discussed with React Native.
In a nutshell, Expo comes with a bunch of bridges that developers can use along with other useful features as well, which are excellent.
Problem solved then, right?
Not exactly, Expo remedies the problem by not needing us to spend countless hours building bridges, but in return, it locks us into the Expo environment.
One of the many features we lose by using Expo is the ability to actually create a bridge ourselves if the need arises. This means that even if Expo helps us build 80% of our project if the remaining 20% can’t also be remedied with Expo, then we are screwed with two options:
- Sacrifice 20% of the project.
- Sacrifice using Expo, which then means building all the bridges manually ourselves, requiring iOS and Android developers on top of the React Native developers.
In summary, you’re either in or you’re out, there’s no in-between.
That’s pretty bad, is there anything else?
There’s one more aspect very important to this project, and that is the desktop app for Mac and Windows.
Expo does not support React Native desktop apps, so even if we could use Expo in our iOS and Android app, we’d have to build an entirely separate React Native project to handle the desktop app.
Even more troubling news, since we are using the base React Native solution without Expo, we’ll likely need C# and Swift developers to create the bridges for Windows and Mac.
Real-world enterprise problems
In Dev Centre House, we are developing native IOS & Android apps, in addition to using Nativescript, and also used to React Native. So as a software development company, we use and understand the different routes on hand for building IOS and Android apps. However, it often depends on the problem on hand, which we often get back to Native IOS & Android development.
Enterprises are often requesting to build apps using one unified platform like React Native or Nativescript to save cost, time, and development maintenance going forward. However, it is not always possible for all cases, and in some cases, we are still much better off going the fully native route to our experience working on all three.
Conclusion
We’re fully aware that this document puts the spotlight on React Native in a negative manner. However, it is vital to understand these flaws before resources are invested. Furthermore, everything can be crosschecked and verified using the references provided below, all of which are from official sources only. Above are some of the few issues you might face when needing to use React Native.
For this matter, what are the issues or challenges you are facing in your organization using React Native?
