How We Used React Native in the Carsharing App HoppyGo

Also available in Czech: https://medium.com/@jvaclavik/jak-jsme-pou%C5%BEili-react-native-v-hoppygo-e8f5cd3a3ca5

I have been using React Native actively for almost two years and was following it for a long time before that. I have to admit that I was skeptical at first because the similar Native Script was not able to get on the market. But what really interested me about React Native was that Facebook started using it, and their influence is enough to alter the entire industry, as in the case of React.

I have developed mobile applications based on Ionic 2, but have encountered significant limitations that React Native managed to solve (especially issues with performance and working with native maps).

Does it make sense to write an Airbnb-sized application in React Native?

Yes, it surprisingly does. Sometime in October 2016, I witnessed the birth of a car-sharing app I worked on called HoppyGo (http://hoppygo.com), which was started by Škoda Digilab and which still exists today. We had a relatively free hand in choosing technologies, and we boldly chose React Native. This was a very good decision, even though making an Airbnb-type mobile application with React Native technology was not exactly common at the time.

In retrospect I can say that HoppyGo’s development on React Native did not cause any insurmountable problems, and even after a year and a half of application development, I would not do it differently given the choice.

Screenflow of HoppyGo on our wall (but not the newest one)

When developing the application, we tried to release the Minimum Viable Product (MVP) as soon as possible so that we could try out the service for real when we showed investors our work. We managed to create the MVP after about 3–4 months of development, which is really good time for this kind of app running on two platforms (iOS, Android). Of course, a lot of flaws emerged in the production, but the application has evolved a lot and is currently stable and usable. Unfortunately, bad MVP reviews on app stores will stay there forever. I believe that some users gave the app low ratings on the App Store and Google Play for three reasons:

• In-app bugs — There were quite a lot in the MVP, and the application would crash relatively often, or certain features wouldn’t work.
• Bad UX — Originally, our design for the whole rent-approval process was too complex (it was necessary to send a request for one car, then the car owner had to approve the rental, and eventually had to confirm the driver again). It was also difficult to register before searching for a car because of various bureaucratic issues. I think there is still a lot to improve, even though the process of approving a car is still too complicated, and I would not be willing to do it myself if I was just lending my car to someone for one day.
• My car is an extension of myself — Thus not lendable. We read such sentiment in the reviews quite often. It’s interesting that people who did not want to rent a car still downloaded our app and bothered to rate it for us. But maybe we just chose the wrong target groups.

Competitors

The comparison of HoppyGo to Airbnb may not be quite accurate, since Airbnb is still a significantly larger and longer-term project than HoppyGo. But in terms of size, if you browse the HoppyGo application, it detects that it contains about 80 screens and offers quite extensive options. In the area of ​​filtering cars, we offer much better options than Airbnb (where, by the way, it is not possible to filter for a sauna house, which drives me nuts!) or a competitive application for car rental.

During the development of HoppyGo, I watched closely (of course) our competition from SmileCar. Also interesting were foreign car-sharing startups like Drivy, Turo, and Getaround.

The iOS SmileCar app looked good from the beginning, but after testing the Android version, it was evident that big differences can exist between the same app on different platforms.The Android version of SmileCar was created only as a wrapper over the web version. Although it works on paper, in practice the application is very slow to use. The possibility of using native elements can be forgotten. The iOS version of SmileCar is much better, but I think UX and filtration options leave much to be desired.

With SmileCar it is easy to see the disadvantages of native development. While one platform (iOS) is relatively user-friendly, the other (Android) is virtually unusable. I suppose that there was no money or time to fine-tune the second platform, because doing an app twice is much harder than just once. But it really means that some 70% of users (people using Android platforms) are disadvantaged, and the company is losing potential customers. On the other hand, the web version of SmileCar, which is used on two platforms, worked well. However, with multiplatform development, applications should be well-functioning on all supported systems. I personally prefer the more ideal solution for combining mobile and web applications with React Native, which uses shared business logic for web and separate templates.

We never encountered a situation when we needed to implement something natively. Everything we needed was created by someone before us and made with a bridge to RN (I recommend https://js.coach/react-native to search for modules). With new SDKs, of course, it can be a problem, but the community usually fixes these issues very quickly.

When developing React Native applications, it’s important to be familiar with Javascript in XCode and have basic development skills for iOS/Android and know their guidelines, etc. It is said that with RN it is possible to share about 60% of the code across iOS and Android platforms. I would personally assume that without external libraries it can be up to 95% if the application does not have to be fundamentally different in graphics and UX. Things like animations between screens or headers are relatively easy, not counting the new iOS and its headers, which have their own libraries. Of course, the more platform-specific the application is, the better, but we have to consider that financial resources are generally limited.

Why is React Native cool?

In short, making an app for two platforms separately is a waste of time and money when you can use React Native. No customer would voluntarily pay for development twice unless the developer house pushes for it — either to make more money or because they have native developers for iOS and Android. They automatically tell their customers that doing a multiplatform application tailored to the guidelines of individual platforms is not possible. And that’s not true.

Would you prefer, a) spending most of your money on one product twice, or b) spending about half your budget creating the product and the rest of the money on new features and UX improvements?

Some particularly useful benefits of React Native:

• Only one codebase and one team of programmers with knowledge of the same technology is needed to develop an application for Android and iOS platforms. You can even go so far as to share business logic with your web application.
• You only need to implement the new functionality once. With native development you have to do it as many times as you need it in different platforms.
• The development of two applications takes half the time and costs half the money (of course approximately). I personally would prefer investing money in product improvements rather than doubling the implementation of the same thing.
• You write in React. React is super (those who haven’t tried it won’t understand). Goodbye, dear Angular and ugly Objective-C!
• When you have one application, you do not need to test two applications. This may sound too good to be true, but it’s really true.
• React Native also works for big companies — Facebook, Instagram, Airbnb, Vogue, Microsoft… or HoppyGo :-)

Since application development is very expensive, I often wonder if companies whose core business isn’t mobile apps can afford to do it.

Generally speaking, the concept of mobile apps is a little unique. For example, I have to download the app from specialized stores and take up space on my phone. In the future, it makes much more sense to unify mobile and web applications (similar to Progressive Web Apps). But the world is probably not ready for this yet.

How about native application development?

There are quite a few reasons for native applications, but of course it’s not black and white, and I realize that native applications also have a lot of benefits — support from OS manufacturers themselves, the ability to use the latest SDK, still high demand for this way of development, more efficient use of computing power, etc. are all strong arguments for not neglecting native developments.

When choosing to use RN or native development, it’s important to think about what you actually want to use. If it’s a challenge to do a game, neither React Native nor any other native development might be a good choice, as there are better specialized and multiplatform game platforms (for example Unity). If I want to create an application for only one platform, it makes sense to use native development. This is the case, for example, if I want to make an application with advanced animations, or work with pictures or videos. One day, for example, I made a more complex Parallax in React Native, and I have to admit that the difference in flow between the native app and RN was quite big (in RN it is used in native driver animations, where animations do not crash, but when dynamic altitude changes, it can be a problem). However, I think these things are going to be optimized since it takes more time than doing natively.

What do I dislike in React Native?

React Native has its flaws. Sometimes I came across situations where using RN limited me. Probably the most serious problems were:

• When I have a forced portrait orientation in the application and turn on a camera that has my own UI implemented, when taking pictures of landscape, the orientation sometimes won’t rewind. I have been attempting to solve this problem for quite a while, unsatisfactorily. Fortunately, this did not happen so often, or there was at most a long delay in returning orientation. I believe that a programmer who knows native languages ​​can help.
• Animation of the modal window in the React router is still not properly solved.
• The above-mentioned parallax was jerky when I did something similar to Airbnb earlier in the header bar: https://medium.com/@moses.gunesch/conductor-orchestrate-animation-in-react-native-edd22b59ad17
• The iOS in React Native maps was a problem if I had a lot of markers on the map and started zooming with two fingers on one of the markers.
• The vertical swiper on Android was hard to create; the horizontal was no problem.
• You need to update React Native once in a while. React Native is too fast, so you have to realistically update and edit breaking changes.

Most of these are quite minor things that can be fixed by another UX design or any native code solution.

And in a final twist of fate, HoppyGo recently merged with Smilecar.

More recommended resources:

https://hackernoon.com/the-cost-of-native-mobile-app-development-is-to-damn-high-4d258025033a

http://janvaclavik.cz/jak-vyvijet-mobilni-aplikace/ (in Czech)

Thanks for reading. I will be happy if you write me your comments on your React Native experience.