How using React Native to create the first Refinery29 native app influenced our team and product strategy in some cool ways.

In 2015 Product & Engineering at R29 decided to make our first native app. When other media companies were abandoning apps, we decided we wanted to be creative about how we approached the decision to make an app and explore what it could do for us as a team and a company. This post is concerned with the technology and engineering planning that went into the app, for a more in-depth look at the product and design side check out this post from James Cabrera here.

As we parsed through ideas for what the app’s mission would be, on the technical side we knew that we wanted to take a risk on how to build it. I had a positive experience building several prototypes with React Native in April and May of 2015 and we decided that this was the right time for us to start exploring it as a viable option for “real development work.”

A Little Background on React Native

For the uninitiated, Facebook released React Native to the open source community in March of last year. It’s billed as “A framework for building world-class native apps using a consistent developer experience based on javascript and React.” Exciting stuff for a team comprised of javascript developers! The possibility of being able to create a native app utilizing the same developer tools, skills and language we’ve used over the years to create our websites, content management system etc. was intriguing. Another advantage was the ability to port over our process for unit and feature testing, coverage/linter tools and even our deployment environment.

Thus began the work for This AM (now available on iOS with our launch partner belVita.)

What is This AM

This AM delivers 8 pieces of curated daily news, thoughtfully summarized by our editors, refreshed at 6 am EST. The app highlights beautiful visual design and seamless user experience. Download the app here and tell us if you agree.

Challenges with React Native

Building an app with RN presented some real technical challenges (for a more detailed look at tools & process, please check out my colleagues’ post.)

The biggest challenge for React Native is that much is still to be done in maturing the framework and setting standards and best practices. Developers rely heavily on the work of others in the community to move quickly and reduce boilerplate. But with React Native being so new, we had to spend more time bridging the modules and components that are otherwise readily available in Objective-C. To illustrate this problem at it’s worst, on a few occasions we would complete our own implementation for something the same week that it landed within the framework.

Feature testing was another area where the path wasn’t completely cleared. But a key component in ensuring that developers don’t introduce regressions as they commit new code. After some looking around we found Calabash to be the best solution. We’re able to run our feature tests both on iOS and Android without having to change the way they’re written or the implementation and it plays nice with Travis (our continuous integration tool.)

New versions of React Native keep coming fast and with major and sometimes breaking changes. It’s really great how fast Facebook and the community are addressing the concerns that interested developers are raising, but it also means that we have to frequently update in order to gain the new features while also having to deal with those breaking changes.

That said, I firmly believe it is still leagues faster than developing in Objective-C or Android if you don’t have native developers already on staff.

The Benefits

The intriguing part of this whole process has been how this decision — what language and framework to utilize when developing our apps — has impacted the team as a whole.

As mentioned, javascript is the primary language of our front end team. And an import goal of engineering management is to consolidate the number of frameworks, tools and knowledge to concentrate expertise and maximize our ability to ship products. We are starting to use React/Redux on our Web and CMS teams, so building this native app in React Native with Redux in a sense democratizes the native app process. Instead of having to play a game of matchmaker to assign a particular project to a particular engineer who has the necessary exposure/experience, we can focus on the product needs that will best support our audience.

Having one front end language to rule them all is a huge step forward in more effective and faster development across all of our platforms. And as a tech lead, I’m supposed to make decisions not only in terms of performance and architecture, but also how to manage and mentor my team. I am hoping that by building products in this way that we enable all of our front end developers to become native app developers too.

Thanks for reading, for more details, contact me at ben.wilson@refinery29.com.