18 Months of Experience with React Native at Netguru: Lessons Learned, Mistakes Made and a Look into the Future

In 2016, React Native was one of the rising technologies giving a great promise to save on development time but also carrying some risks. No one really knew in which direction it would go, whether it would last or become forgotten.

We decided to take a bet and invest in the research on React Native. Today, we know it paid off, and React Native is here to stay. Facebook’s framework has been leveraged by big players such as Tesla, Instagram, and Airbnb. Airbnb has recently shared their experience with RN on their blog. After having delivered 20 projects and with 15 React Native developers on board, we want to share what happened over the past 18 months of our journey with this technology.

How it started

Everything started with 4 passionate developers, building an internal app. Front-end and back-end devs kept working together, testing various aspects of RN. It was the time when the latest React Native version was 0.39, and most of the crucial features in React Native were experimental. It was also the time when nobody was quite sure in which direction things would go. Some people were deeply sceptical: why would anyone need an RN app if we had native developers and the native version was more performant? Some people thought that Progressive Web Apps would quickly substitute the alternative ones. Nevertheless, we decided to give RN a try and see for ourselves.

Our team

In the very beginning, we were quite sure that RN belonged to the “frontend family”. With the passage of time, we became more and more convinced that it is a mobile technology. That is why we joined Android and iOS developers. We started with 3 people on the team. Right now, there are 3 React Native teams with 15 members altogether.

Interestingly, people have different backgrounds. Some developers used to be back-end programmers, others used to create front-end interfaces, yet others know mobile technologies well, and we even have a blockchain developer and a designer onboard! With so many different specialists on the team, we can look at our projects from different perspectives and, as a result, find unique solutions to problems that crop up on the way.

First project(s)

We started developing two projects simultaneously: Whym and Ghinwa. One of them was a single-dev endeavour based purely in JS. The other one was a combination of JS and native code (by native, we mean Java and Objective-C). Both of them were challenging. Single-dev projects, when technology is really fresh, are hard, and so are the native-based ones, even with several people on one team. They were a good lesson on how to deal with RN limitations and what skills are needed to overcome typical errors and obstacles.

It was also a true lesson of humility and great opportunity to become the mythical “full-stack” developer. Understanding some of the basic concepts was not an easy task. People with mobile background had to deal with hard front-end-issues (just imagine how difficult it was to create a pixel-perfect app with RN not being able to support absolute positioning on Android), while people with browser-based experience had to become friendly with either Xcode or Android Studio.

Internal insights

Starting RN development at Netguru was a great chance to meet other mobile/frontend team members and collaborate more closely. Without the mobile experience, it is hard to deploy the app, set up the correct certificates or simply debug the code. It is also hard to determine whether an issue was related to your changes in the code or changes in the library you were using. Countless hours spent on pair-programming sessions were beneficial in terms of productivity and became fruitful after long months of investment in knowledge-sharing processes. To support knowledge-sharing that, we developed a huge internal database of difficult cases and processes, which always becomes helpful when dealing with severe bugs or setting up new apps.

We also asked RN devs about their feelings after working with RN for more than 10 months. Everyone described their experience as positive and nearly every team member would choose RN for their next project. Also, Airbnb summarized their findings in their article. Most of Airbnb engineers would also choose RN given the chance.

First fuck-up(s)

In the very beginning, we underestimated many tasks. We thought some of the features could be delivered faster. It was because we were estimating the projects together with native devs, having as the basis the estimates we used in former projects. We often transferred those estimates 1-to-1.

After developing several RN projects, we know that they cannot be of the same size as the native estimates for one platform, but are still significantly lower that the joint estimates for both platforms (at least in most cases). Furthermore, with more experience comes more accuracy in estimations.

React Native academy

Education at Netguru is of primary importance. That is why we decided to organize two editions of RN academy. Having in mind that our RN team consists of members with different technical backgrounds, we decided to encourage other unconvinced devs to try RN development. The workshops were successful – both for us and for the participants. Some of them have already joined us!

Projects

Over the past 18 months, we’ve started 20 projects in React Native. Most of them are pure RN (that means that no native developers were needed), some of them use native libraries written in mobile native languages (both in old ones - Objective C and Java and new ones - Swift and Kotlin), and one project was a module within larger native app (written in Swift and Java).

We used all types of backends in those apps: the good old REST backend (e.g. in Rails or Node) and firebase real-time database and GraphQL.

We did all kinds of projects: real-time chats, apps using geolocation and maps, etc. Some apps were simple, others not so much. One project built by our team, Shine, became “App Of The Day” in Apple’s App Store.

It turned out that if something was missing in the RN libraries we were able to write our own native modules or bridge the native libraries with RN. There are articles demonstrating how to achieve it and it’s not very difficult for native developers.

Lessons learned

Over those 18 months, we’ve built many great apps. Not everything was easy and straightforward. Sometimes, we had to use hacks to achieve a satisfying result, other times, we had to write native modules, but eventually, we always did what we had to do. Since then, both React Native and our team have matured. More and more libraries are being launched, many native libraries have React Native bridges, and React Native itself is getting better and faster.
The React and React Native communities are very active. The React Native repository has over 13k commits and over 65k stars. React, in comparison, has 10k commits and about 100k stars. There are hundreds of React-native libraries (some of the more popular ones can be found here).

• React Native is much more mature than it was 18 months ago.

• More and more libraries are available, and in most cases, we don’t need to write our own bridges.

• Tracking errors is easier – we can track errors in the native code and in JavaScript.

• We did many different kinds of things in React Native: push notifications, real-time chats, maps with geolocation, animations, playing videos, logging with different socials, uploading photos, videos, etc.

• We used all kinds of databases.

The future of RN in Netguru

Our team consists of 15 members and is still growing fast. React Native is maturing, and so is our team and our approach to RN development. We try to use latest technologies such as storybook, different state management libraries, etc. We believe that RN is the future of mobile apps. Facebook, the company that created React Native, also believes in this framework and keeps improving it.

We know that Airbnb dropped React Native, but a company with $2.6bn in revenue can afford to hire enough engineers to work on two platforms and make a perfect app. For startups and smaller companies, however, React Native is a great option because building an app is much faster.

React Native is good especially when it comes to rapid prototyping or developing simple apps. Right now, mobile apps are becoming more and more similar in terms of the design – maybe it is the high time to share the code?

Looking for an experienced team of React Native developers? Contact us and let's do something together 🚀