The cost of development and maintenance is one of the fundamental concerns when developing a mobile application. This is especially true if we were to develop the mobile app in their respective native language as we have to build two separate apps for both iOS and Android. Once developed and released we will have to go thru the process of updating and maintaining these two separate apps adding up more cost. The mobile app development industry’s answer to this problem was hybrid mobile app development. We already have many well establish hybrid mobile app development platforms like PhoneGap using Ionic Framework, Xamarin, Sencha Touch, Kendo UI etc. But these platforms have their own advantages and limitations.
The Advent of React Native
Limitations and Drawbacks of React Native
In this article, I will try to touch upon the limitation and the grey areas that React Native currently has. Most of these shortcomings are being addressed by Facebook and the React Native community. But there a few concerns that might prevent you from jumping ship to React Native mobile app development. It’s always good to know these concerns well in advance.
- Native app development has its advantages
If your app is not doing any hugely heavy lifting (i.e. in terms of heavy memory or CPU usage) React Native seems like a really good choice. Having worked with both hybrid and native platforms before, if your app is doing a ton of heavy lifting, I would still recommend native development as a way to more closely manage things like CPU usage and memory footprint.
- Constant updates to the platform
React Native is a relatively young and emerging platform. Whereas Native development is quite mature. iOS(ObjC) and Android(Java) have been on the go for close to 10 years and there some really great tools that have developed in that time. This is not really a disadvantage but rather another point that React Native has a lot of catching up to do. Due to its relatively new entrance React Native is heavily in development, and a new version is released every month. Constant updates bring new ported native components, improved custom ones (like the Navigator), bug fixes and performance improvements. This is good in terms of activeness of the platform. But a bad choice if the app is to be maintained for a long-term as each build might require updating the platform which brings dependency checking for existing code base. Incorporating these new releases requires vigilant updates to our own code if the logic of the prebuilt components changes. So developers will have to set aside some effort to incorporate these changes in order to keep up with the platform. Many people take up React Native fully understanding this situation. But if you are consulting for a client make sure that they understand this fact.
- Loosely-typed language
- Native Language Dependency
If a functionality that you require isn’t currently available in React Native we will end up writing native modules. Native modules are a way of bridging native code and React Native code. The native module needs to be written in Java and swift/objective c. Possibly, at some point during your development you have to take help from a native developer or do it yourself in the native language.
- Abstraction Layers Limitations
React Native is an abstraction, which means that there is a pretty large chunk of code sitting between the developer and the native platform you are developing for. One significant issue with abstractions is bugs. If you hit upon an issue with the abstraction layer, you might have to delve into the implementation and fix it yourself. This can be time-consuming, and you might find issues that you are unable to resolve! Another issue with abstraction layers is that you are dependant on a third-party not just for bug fixes, but to keep their framework up-to-date. The iOS world moves very quickly, and other companies such as Xamarin have to work very hard to keep their abstraction layer up to date. Another less obvious abstraction leak is features that you cannot access. Most abstraction layers are incomplete in that there are some features of the underlying system which are not exposed via the abstraction layer.
- Long-term Commitment and Upcoming OS Version Support
A major concern with using React Native is the lack of long-term commitment to the project. React Native is not a plug-and-play like CocoaPod, it’s not a mere SDK, it’s not a mere library, it’s an entire software development platform. If Facebook stops maintaining React Native, my app will stagnate, and there won’t be a “React Native replacement” at our disposal. We have seen this happen with Facebook with Parse
Adaptation to new OS versions will be slow. In other words, you currently don’t have any guarantees it’ll ever be compatible with iOS 11, or 12.
- License and Patent Controversy
Last, but one of the most important concerns with React Native is it’s License and Patent controversy. Alongside its permissive BSD-style license, React Native ships with Facebook’s Additional Grant of Patent Rights, Version 2. Last week, Facebook updated its Open Source Licensing and Patent for React, ReactNative and other open sources projects. According to the update, your right to use Facebook’s open source projects will be terminated if you sue Facebook over a patent issue. In practice, this seems like a deterrent to using Facebook over patents. By implication, it also seems to give Facebook a good deal of breathing room to infringe patents within the app that uses React Native. This particular change has created a lot of panic around the developers that use React, React Native and other open sources project. This change resulted in Automattic, the creator of WordPress to completely abandon their WordPress code rewrite in React (not React Native). That was years’ worth of work! Apache Foundation had earlier announced that they will no longer be using Facebook BSD+Patents licensed code for new projects. These incidents sound pessimistic. But you ought to be pessimistic when evaluating software licenses and patents.Update: Days after this article was published Facebook relicensed their open source projects React, Jest, Flow, and Immutable.js under the MIT license and removing the BSD + Patents style license. This is a very positive move from Facebook as they have acknowledged the concerns of the open source community. I hope they use the same for MIT license for React Native which is still under BSD + Patents style license.
You might feel that some of the limitations mentioned here are also true for hybrid or even Native platform. The intention of this article is to make you aware of the limitation of the platform before you take the big plunge into Reactive Native development. With the current attention that React Native is gathering in the current mobile app development community, I am sure that in future, React Native might outperform PhoneGap and Xamarin.