Maximum acceleration
It all started with the fact that we decided to speed up development by 10 times at the company level. We set an impossible goal to go beyond the usual horizon of events and try new things. All Profi.ru development teams took up the experiments. At that time, the company had 13 native mobile developers, including me and two team leaders. My team worked on two mobile apps. In the first, customers are looking for specialists, in the second - customer experts. For me, this period was incomprehensible and emotionally stressful. According to my feelings, we did so much so that everything worked quickly.
We used a common architecture throughout the project and monitored the purity of the code. Used generators that create all the module files. They tried to take out all the business logic on the backend. We set up CI / CD, and applications covered with E2E tests. Due to all this, some applications were stably released once a week. I had no idea how to speed up development even twice. By far at 10. Therefore, we determined what is important to us.
- Unified code base. I wanted all our mobile developers to write the same code. In one language, without platform differences between iOS and Android. So we could speed up the development by half.
- Easy to learn new tool. So that when expanding the team we do not have problems with retraining or hiring.
- Quick releases. So that we can release not once a week, but every day.
- Instant updates. So that all users receive updates immediately. As it is now happening in web development.
After a short review, three candidates appeared: React Native, Flutter, Kotlin / Native. Neither Flutter nor Kotlin Native can be released quickly. And we considered this perhaps the most important. In addition, these technologies were completely raw at that time. We settled on React Native - it can be released instantly. Plus, most of our developers have already used React.
In general, I was negative about cross-platform tools - like most native mobile developers. Go to any mobile conference and talk about it - you will immediately be stoned. I love this thing myself :-) Therefore, in order to confirm or refute the fears, we conducted our investigation.
Pros, Risks, and Issues
We studied examples of using React Native in different companies - successful and not so good. With Head of Dev, Borey Egorov carefully read more than three dozen articles and other materials. Some discussed each paragraph. At the end of the article - links to the most interesting. We noted the points that can accelerate us, possible risks and questions. After that, we talked with developers from three companies. In each of the guys created a mass product and worked with React Native for at least a year.
With the pros, everything was pretty obvious.
- General code base.
- Over-the-Air, or update by air, bypassing the store.
- From the first two points it follows 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, then he can quickly learn React Native. And if the mobile developer already knows this platform, then it can enter web development relatively quickly.
The list of risks was longer :-)
The first risk . Instead of one platform, in the long run we are forced to support three: Android, iOS and React Native.
Sometimes the developer screen looks something like this:
Reality. One of our interlocutors injected React Native into existing code. Yes, a full-fledged third platform appears, but you do not go anywhere from the native development. His team had to synchronize state between React Native and native code. This entailed a lot of switching between different pieces of code / different paradigms and IDEs. Therefore, they decided to write a new project from scratch, make a framework on React Native, and already insert native pieces in it where they are needed. Got better.
The second risk. React Native Black Box - sometimes there are situations when a developer does not understand why a bug appeared. You have to search everywhere: in React Native code, in the native part of the product or in the React Native platform itself.
Reality. The guys with whom we talked wrapped the application with logs and various tools: Crashlytics, Kibana and so on. Problems remain, but it becomes clear where they arise.
The third risk. It has often been found in articles that React Native is suitable for small projects, but not for large products with platform functionality.
Reality. We looked at whether there are large companies on the market that work with React Native. It turned out - there are dozens, if not hundreds. Including Skype, Tesla, Walmart, Uber Eats, and Kitchen in the Area.
Fourth risk. Each time you upgrade your operating system from Apple or Google, the project may break.
Reality. We decided that the risk was perfectly acceptable. The same risk exists for native development. When the new OS for iOS and Android comes out, you adapt your application to it.
The fifth risk. There is no support for a 64-bit system in Android, and issue has been open since 2015. And since August 2019, Google Play has not accepted builds that only support 32-bit systems.
Reality. We looked at the issue that the React Native team worked on in the summer of 2018. They promised to add support in the next release, although they have not yet fully fixed support for the 64-bit system. This greatly upset. Support was later added, but some Android devices fall after the transition. As we later found out, the percentage is scanty, but still it was the most painful point for me.
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, in principle, will not be able to support.
Reality. There are no guarantees for us or for many other companies. You either realize the risk and do it, or try something else. We decided to do, and to solve all problems as they become available.
Seventh risk. We could not say in advance how fast React Native will be compared to the native application and what performance it will show.
Reality. The literal quote of one of our interlocutors is "lists of elements of variable height when scrolling were slowed down." We decided to check in practice. A little run ahead - at the time of writing the first prototype of the application, we did not see such a problem, but when we developed a full-fledged application, there were many questions about the performance of React Native.
Eighth risk. It is unclear how quickly we can find the developers of React Native. On HeadHunter I found about 300 resumes, despite the fact that there were more than 150 thousand developers for iOS.
Reality. They didn’t go deep here, as they had hired React developers more than once and knew what to pay attention to. We decided that as a last resort we can retrain the React developers in React Native.
There was also a risk that someone would leave the team, as mobile developers do not like this technology. By the way, I was right. Someone left :-(
I'm tired of writing React Native, so what follows is just RN :-)
What we change and what not
We discussed the results of the investigation with the founders of the company, Sergey Kuznetsov and Yegor Rudi, and received the go-ahead for the experiment.
We decided to create a new product from scratch, and not to insert into an existing one. And also - do not touch our client application. It was quite mature, and economically it made no sense to radically change something. In addition, it was important for us that the client application had its own native experience for both iOS and Android.
But we wanted to change the application for specialists radically. Unlike the client, we were not embarrassed that the specialists would have the same interaction experience for iOS and Android applications. Plus, we believe that in a product for specialists we can do without animation and visual effects. But before the whole team switched to a new technology, it was necessary to feel how it works.
Experiment in action
In December 2018, we assembled a team of three people. Two React developers and one native - me. I understand how Android works, and am well versed in iOS development.
As part of the experiment, we wanted to check the following points:
- how instant releases work in RN;
- how is the interaction between the native components and RN;
- can we use our native components;
- how RN works with the camera, push and diplink;
- how navigation and state saving work in RN;
- as far as we can do with RN pixel perfect;
- how automatic testing works in RN;
- how quickly the 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 under RN in just two weeks. For me, the technology was completely uncomplicated. One of our React developers helped me a lot - he famously talked about React / Redux and JS in general. It was necessary to enter the intricacies of React / Redux, but after a while the “neuron began to learn,” as our company says :-)
- I was pleasantly surprised that in some form JS + Flow provide strong typing. For JS, I had much lower expectations. At the same time, I would definitely prefer Swift and Kotlin: for me they are many times more beautiful and more pleasant than JS, but here the main words are “for me”.
- It helped us that the team included developers who can write code for iOS, Android, and React. Each platform has its own specific problems. To solve them, the team must be cross-functional.
- Instant releases work. For me it's like magic. No need to wait for releases and upgrades from Apple. Wanted - took and released.
- Very often the project broke down. This is really not cool. You took the changes from the branch, you try to run it - and never mind. It was very annoying. At some point, we just wrote a script that cleans the project completely. This is not to say that they solved the problem as a whole, but finished off most of it.
- Still, we have to work with three platforms, despite the fact that we mainly write code on RN. All developers had three IDEs: Xcode, Android Studio, WebStorm.
- Pushas, deeplinks, camera, navigation start up. But they are started either with the help of third-party libraries, or libraries in the native code must be written yourself, and then connected to RN.
At the end of the article I want to return to the title. So is the RN a silver bullet for all problems? We decided for ourselves that no. At the same time, they got what they wanted. We have increased several times the speed of delivery of features and now we can release it to all users every day. It is also important that cross-functional teams have appeared in the company, where each developer writes code both on Android / iOS and on the web.
And yes, the applications in the store :-)
Useful articles about React Native
- Why Discord is Sticking with React Native - Fanghao (Robin) Chen
- How I Loved and Hated React Native - Andrey Melikhov
- React Native from the point of view of a mobile developer - Andrey Konstantinov
- React Native at Instagram - Instagram Engineering
- React Native: A retrospective from the mobile-engineering team at Udacity - Nate Ebel
- React Native: one-act fact battles - Samat Galimov
- Sunsetting React Native - Gabriel Peal