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
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 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.
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 firstname.lastname@example.org.