React Native Dilemma

I want to share my experiences working with React Native, but first let me tell you about the project we are working on.

Monument

Monument is a smart device that allows you to store and manage your photos and videos quickly. With built-in artificial intelligence, it allows you to manage and analyze your photos according to date, location, type of camera, people and what is in the photos. It also allows you to easily group and access the photos you have tagged. Thanks to its ability to use a USB hard drive, you can have the capacity you need and eliminate monthly payment for cloud services. You can find detailed information related to the product from the following link:

Monument Labs, Inc.

First of all…

After the funding from Kickstarter we have started on working on the mobile app and we had to decide between a native or hybrid implementation. Those were the requirements at the time:

• We had a limited time to deliver the application.
• If we made the implementation native, there would be no shared code, which would require us to use separate resources for iOS and Android.
• As user interface, we did not want the application to look like a hybrid application. React Native partly solved this issue by using native components in the user interface.

For these reasons, we decided to continue with React Native which was relatively new at the time.

React Native

React Native is a framework developed by Facebook that allows you to write applications with JavaScript using the native UI components of the mobile platform.

Many successful projects have been made with React Native and it is possible to benefit from most of them. The F8 (Facebook Developer Conference) project is a good example, as it is an open source showcase by Facebook.

fbsamples/f8app

Monument Application

The application allows you to upload your photos and videos to your Monument device and manage all your contents.

We started the application with React Native and after facing various problems, we decided to switch to a native application instead. In short, I want to talk about these problems.

Reduced use of shared code

We based our application on the menu examples given by React Native and, decided to use the TabBar structure on iOS and the side menu structure on Android.
Also, some components are designed specifically for iOS or Android. That results in using different components for different platforms, which is against the whole idea of writing shared code.

Components are few and not enough

As I mentioned, the device analyzes the photos and videos and makes them meaningful for us, in this way, it makes it easier to manage photos and videos. In order to be able to analyze, meta-data such as location and time of photos have to be transferred to the device. However, React Native components providing access to photo library gave us limited information. For this, we had to edit a native component and write interoperable code. In such a case, you also need a resource who knows the native platform.

Besides these, we needed to connect the device with technologies such as Bluetooth and Bonjour, and RN components were not available for them. We had to write separate native code. And you also have to keep in mind, every time you add some functionality in native platform, you will have to have a bridge between them, since the logic on the React Native is implemented by the JavaScript VM, a completely isolated part from the native platform. This bridge introduces some performance penalty as well. If the bridge transfers “just a bit” of data infrequently, you’re perfectly good to go. However, if this bridge passes data for tens of thousands of photos’ metadata, or something similar to the effect of that, you start to see the performance degradation..

Performance Issues

We tried the first tests in the photo collection using a handful of photos.
However, we assume that there will be somewhere between 20 to 30 thousand photographs in user’s collection. We tested with large collections, but the memory usage was increasing and the application kept crashing. React Native offered a variety of optimizations, but even with these, it only helped to show thousands of photos. In fact, the main deciding factor for us was the lack of a solid foundation to render and manage large collections.

Looking at other applications, many photos and video applications offer smooth and high-performance collection structure even on old phones. In this case, it seemed difficult for us to continue our application as a hybrid.

In terms of component and convenience, RN seems to be sufficient for a quick and simple application, however, as the application grows and component needs an increase, we realize that RN is not enough. So, we gave up developing the hybrid application.

Pros

• Through the use of a shared code, the development process is much faster.
• Hot reloading and live reloading are useful; you can instantly see the changes you make in the code while the application is running, without having to go through compile/deploy cycle.
• The components are very useful. You can call component with a single line code. You use JavaScript to manage components. It also allows you to get a small scale application quickly.
• With Flexbox, you can also develop a flexible user interface quite easily.
• There is good community support and you can get your problems resolved quickly.

Cons

• In case of problems with components, you should expect Facebook to solve this problem or fix it with your native knowledge. In this case, you will not be able to make any progress in your project.
• There is always a delay between introduction of native components and them being available on React Native. A shiny new MapView could be in the upcoming iOS version, but you might not be able to use it in your app, unless the React Native component becomes available. Unless you roll up your sleeves and write a component for it.
• You will use a weaker tool for IDE. For example; xCode successfully monitors memory leaks and provides a successful debug.
• When you do component support you will have to transfer it from two platforms via a bridge. In this case, you need resources who have other than JavaScript, native experience.
• Performance for large collections is nowhere comes close to native applications.

Conclusion

I tried to tell you about the good and bad things and our overall experience with React Native. I hope it will be useful for you to decide between hybrid and native apps.