Over the past 6 months I’ve been working together with the team at The Times to lead the adoption of React Native in their Android app. It’s been an interesting journey, so I wanted to share our experience, including our successes, challenges and learnings.

The Times is a large publishing company with many business requirements. They face challenges with keeping all of these requirements in sync across their codebases. The goal of the project was to unify their business rules and requirements into a single codebase. After considering some alternatives, they chose React Native, partly due to their very strong web background, and due to it being the most mature option at the time.

The native mobile teams didn’t have previous experience in React Native or JavaScript. As part of the transition to React Native, the team organised workshops to bring everyone up to speed with the new technologies.

In this project, there was a strong open source component: the various widgets were developed in a separate, public repository. These widgets are meant to be used both in Native and Web, thanks to the use of React Native Web.

The navigation in the app is kept in native code, and React Native widgets are exposed to the app via a native module. This was done because we decided to maintain the same user experience quality as the current implementation, and the current solutions for React Native didn’t meet our requirements. What React Native offers is a minimum common multiple between the two platforms, and didn’t fit with the rest of the application, nor did it work well for us.

The teams at The Times are structured per feature, created as required. Usually every team is composed of an Android, iOS, Web, and backend engineers, plus a QA engineer and a product owner.

What went well

React introduced a very fresh and effective way of describing views in an application; the declarative approach lowers the mental strain required to understand the intended behaviour, and the state travels only in one direction, which makes it easy to control.

Some problems were extremely easy to describe and solve with RN. For example, working on a modal image component in React Native made many things much easier than it would be in native Android and iOS code: in less than a day we managed to have a cross platform image component with pinch to zoom and rotation gestures, working well and fully tested.

iOS Android
iOS modal view Android modal view

Flexbox — the layout algorithm used in React Native — is a well established standard which has been around for over 3 years in the web world, is extremely expressive and battle tested. As a bonus, using Flexbox makes it easy to port similar layouts to web and vice versa.


Not everyone is comfortable with working in multiple level of abstractions and different technologies to the ones they’re used to. Some team members weren’t initially happy about the transition, and it took time to bring everyone up to speed.

To work efficiently in React Native, the team needs to possess expertise in both mobile platforms, and React and JavaScript. All this knowledge is usually not held by a single person, but needs to be expressed in the team composition and, unless properly addressed, it can create knowledge silos. Encouraging pairing between JS and native engineers can help avoiding this siloing.

Integration testing on emulators/devices is tricky due to the way that React Native works. On Android, for example, the most used instrumentation testing framework, Espresso, will not be able to run on a React Native app due to the React Native’s threading model. We partially addressed this by creating an idling resource that waits for React Native to begin displaying content, but we couldn’t completely remove all the flakiness in these tests.

The developer community around React Native is still very young, and when facing problems we found that not all the solutions out there worked for us. We ended up having to reimplement some 3rd party libraries from scratch. For example, we had to create a brand new SVG rendering solution using an undocumented set of React Native features.


When thinking about React Native, or any other cross-platform framework, you need to ask yourself some questions. Does it work for you? Where does it work? Are its strengths and weaknesses matching your product’s? Will it be an impediment or a boost to your product?

It’s also very important to consider the team composition and company culture. Do your mobile developers want to work with it? Do you have the time to invest into forming the team? Forcing React Native on developers can make them rather unhappy, and not investing in their formation can result in an unproductive team.

Due to it being very young, the risk of adopting React Native is way higher than developing a native solution with well established technologies. Sometimes the solution to a problem can be trivial, possibly easier than native, but other times one small issue might take days to solve

Recently, there have been some really insightful posts about companies using React Native. Airbnb published a 5 parts article on their experience with it over the course of 2 years, and Udacity posted a retrospective about their experience with it. Interestingly, both companies are moving away from React Native after years of usage and heavy investment — not (just) for technical reasons, but because it was not a good fit with their teams and companies. It doesn’t seem like they regretted it, but after experimenting for quite some time they decided that the benefits didn’t outweigh the costs.