React Native - A Silver Bullet for All Problems? How We Choose a Cross-Platform Tool for Profi.ru

Hello, my name is Gevorg. I’m Head of Mobile in Profi.ru. I Want to share with you the story of our experiment with React Native. I will tell you how we evaluated the pros and cons of development in React Native – in theory and in practice. This article will be useful for those who are interested in cross-platform mobile development but have not yet decided whether to go in that direction or not.

Maximum Acceleration

It all started with our decision to speed up development by 10 times at our company. We set an impossible goal to go beyond our familiar surroundings and try new things. All the development teams at Profi.ru took on experiments. At that time, the company had 13 native mobile developers, including two team leaders and me. My team worked on two mobile apps. In the first, clients are looking for specialists; in the second – specialists are looking for clients. For me, this period was incomprehensible and emotionally stressful. I feel like we already did enough to make everything work quickly.

We used a common architecture throughout projects and kept the code clean. We used generators to create all the module files. We tried to move all the business logic to the backend. We set up CI/CD and covered the applications with end-to-end tests. Because of all this, some apps were released steadily once a week. I had no idea how to speed up development even by two times. How can we possibly do 10? And so, we wrote down what is important to us.

A unified codebase. I wanted all our mobile developers to write the same code. In the same language, without platform type differences for iOS and Android. That way we were able to speed up development by two times.
Ease of learning a new tool. So that when we expand the team, we don’t have any problems with hiring or retraining.
Quick releases. So that we can release not once a week, but every day.
Instant updates. So that all users receive updates at the same time. Same as what’s now happening in web development.

After a little research, we settled on three candidates: React Native, Flutter, Kotlin / Native. Neither Flutter nor Kotlin Native can be released quickly. And we thought that was probably the most important thing on our list. Also, those technologies were quite raw at the time. We settled on React Native — we can release instantly on it. Plus, most of our developers have already used React.

In General, I had a negative attitude towards cross-platform tools – like most native Mobile developers. Go to any Mobile conference and talk about it — you will immediately be pelted with stones. I like to do that myself: -) So to confirm or refute our concerns, we conducted our own investigation.

Pros, risks, and issues

We have studied examples of React Native use in various companies -successful and not so much. With our head of development, Boris Egorov, we carefully read more than three dozen articles and other docs. In some, we discussed every paragraph. At the end of the article – we looked at the most interesting links. We noted things that can speed us up, possible risks and issues. After that, we talked to developers from three companies. In each, the guys created a mass product and worked with React Native for at least a year.

The pros were pretty obvious..

A unified codebase.
Over-the-Air – updates over the air, bypassing the app stores.
From the first two points, it followed that the speed of delivery of features to users will increase.
Web developers will be able to write code for mobile applications. If a web developer knows React well, they can quickly learn React Native. And if you are a mobile developer who already knows this framework, you can relatively quickly get into web development.

The list of risks was longer 🙂

The first risk. Instead of one platform, we have to support three in the long run: Android, iOS, and React Native.

Sometimes the developer screen looks something like this:

Reality. One of the developers we talked to was implementing React Native into existing code. Yes, there is a full-fledged third framework, but you don’t get away from native development. His team had to synchronize the state between React Native and native code. This involved a lot of switching between different parts of the code / different paradigms and IDEs. So they decided to write a new project from scratch, create a framework on React Native, and insert already made native pieces where they need them. It got better.

The second risk. React Native Black Box – sometimes there are situations when the developer does not understand what caused a bug. You have to search everywhere: in the React Native code, in the native part of the product, or in the React Native framework itself.

Reality. The guys we talked to were putting logs and different tools on the app: Crashlytics, Kibana, and so on. Problems remain, but it becomes clearer where they occur.

The third risk. In the articles, it was often mentioned that React Native is suitable for small projects, but not for large products with platform functionality.

Reality. We looked at the market to see if any big companies work with React Native. Turns out there are dozens, if not hundreds. Including Skype, Tesla, Walmart, Uber Eats and “Кухня на районе.”

The fourth risk. The project may break with any operating system update from Apple or Google.

Reality. We decided the risk was acceptable. The same risk exists for native development. When a new OS for iOS and Android comes out, you adapt your app to it.

The fifth risk. There is no support for a 64-bit system in Android, and the issue has been open since 2015. And since August 2019, Google Play has not accepted assemblies that support only 32-bit systems.

Reality. We looked at an issue that the React Native team was working on in the summer of 2018. They promised to add support in the next release, although they still haven’t fully fixed 64-bit system support. It was very upsetting. Support was then added, but some Android devices fail after the transition. As we found out later, the percentage is insignificant, but it was still the most painful point for me.

The sixth risk. The likelihood that tomorrow Apple or Google will release a new version of their OS and break React Native. Or a new technology that Profi.ru can’t support.

Reality. There are no guarantees for many other companies or for us. You either realize the risk and work with it, or you try something else. We decided to work with it, and we decided to solve all the problems as they came in.

The seventh risk. We could not tell in advance how fast React Native would be compared to a native application and what performance we could expect.

Reality. A verbatim quote from one of our conversations – “when scrolling, lists of elements of variable height slowed down.” We decided to test it in practice. Moving a little ahead – at the time of writing the first prototype of the application, we did not see that problem, but when developing a full-fledged application, there were many questions about the performance of React Native.

The eighth risk. It’s not clear how quickly we can find React Native developers. On HeadHunter, I saw about 300 resumes, even though there were more than 150 thousand developers for iOS.

Reality. We didn’t go too much into it, as we had already hired React developers many times and knew what to look for. We decided that as a last resort, we can retrain React-developers in React Native.

There was also a risk that someone would leave the team, as mobile developers do not like this technology. I was right, by the way. Someone’s gone 🙁

What we change and what we don’t

We discussed the results of the investigation with the company’s founders Sergey Kuzneсov and Yegor Rudy and got the go-ahead to conduct the experiment.

We decided to create a new product from scratch instead of inserting it into an existing one. Also, we didn’t want to touch our ‘finding client’ app. It was quite finished, and economically it did not make sense to change something radically. Also, it was essential for us that the client application had its own native experience for both iOS and Android.

We wanted to change the app for finding specialists drastically. In contrast to the client app, we did not mind that the specialists will have the same experience of interaction for iOS and Android applications. Plus, we believe that the product for specialists can do without animation and visual effects. But before switching the whole team to the new technology, it was necessary to feel out how it works.

The experiment in action

In December 2018, we assembled a team of three people. Two React-developers and one native developer, me. I understand how Android works and am well versed in iOS development.

As part of the experiment we wanted to check the following items:

How instant releases work in React Native
How the interaction between native components and React Native works
Can we use our native components
How React Native works with the camera, pushes and deep links
How navigation and state saving works in React Native
How much can we do with React Native pixel perfect
How automatic testing works in React Native
How quickly a native or React developer can learn the technology

We got the first results within a month and a half after diving into development.

I started writing code using React Native in two weeks. For me, the technology was quite simple. One of our React developers helped me a lot – he taught me about React/Redux and Javascript in general. It was necessary to get into the subtleties of React/Redux, but after a while “the neural network began to learn”, as they say in our company 🙂
I was pleasantly surprised that Javascript + Flow gives strict typing in some ways. For Javascript, I had much lower expectations. At the same time, I would definitely prefer Swift and Kotlin: they are much more beautiful and pleasant for me than Javascript, but here the main words are “for me.”
It helped that the team had developers who can write code for iOS, Android, and React. Each platform had its own specific problems. To solve them, the team must be cross-functional.
Instant releases work. It’s like magic to me. It is not necessary to wait for releases and approvals from Apple. Want to push a release, just take it and push.
Very frequently the project broke. It’s really not cool. You take changes from the branch, try to run – and nothing happens. It was very annoying. At some point, we just wrote a script that cleans the project completely. We can’t say that we solved the whole problem, but we solved most of it
We still have to work with three platforms, despite the fact that we mostly write code in React Native. All developers had three IDE’s: Xcode, Android Studio, WebStorm.
Pushes, deeplinks, camera, navigation are launching. But they are started either with the help of third-party libraries, or libraries in native code should be written by us, and then connected to React Native.

I want to go back to the title. So is React Native a silver bullet for all problems? We decided for ourselves that no, it isn’t. At the same time, we got what we wanted. We have increased speed of delivery of features several times and now we can release to all users every day. It is also important that the company has cross-functional teams, where each developer writes code, both in Android/iOS and on the web.

And yes, the apps are in stores 🙂

Useful articles about React Native

Written by Gevorg Petrosian, translated from here