The 4 week journey to a React Native Android app.
When Beek wanted to expand their healthy community of book loving users by offering native mobile apps on Android and iOS, they chose the dynamic and rapidly growing React Native platform at a time when the Android tooling was just beginning to mature. Beek’s production web application was built on Ruby on Rails, but they were already beginning to migrate parts of their application to Relay and GraphQL. As G2i joined the project to build out the initial Android client, Beek continued to expand the GraphQL API to expose more functionality.
For authentication, Beek incorporated sign-in with Twitter and Facebook. Username and password authentication was later added to facilitate submission to the iOS App Store. Appropriate SDKs were included for each platform, and Beek’s Rails backend handled the server-side coordination.
G2i leveraged HockeyApp and TestFlight to distribute test builds of Android and iOS builds. The Android and iOS builds share the same codebase, with alternate implementations of some components to account for compatibility differences.
Problems We Solved
Beek had an aggressive timeline of four weeks for the initial Android client. In order to meet this deadline, G2i provided daily access to 3 experienced developers full time and 2 React Native Core Contributors on an as needed basis. Each day G2i developers were able to collectively work in 12 hour windows across three time zones, giving Beek maximum availability and productivity. At any time during each 12 hour window our developers could interact with the Beek team on Slack, exchanging assets and app builds for testing.
G2i also shared Beek’s internal development workflow, including apps like InVision, Trello, and Zeplin. Our developers quickly adapted to Beek’s tools and techniques, and used them to collaborate with Beek even though some of the tools — like Zeplin — were new to the team.
No matter how many conference talks are delivered on React Native, it is still a very young technology and a risk to adopt. High risk comes with high reward, however. With a combination of React and native development experts, our team was able to develop a fluent experience in React Native for Beek.
An especially interesting challenge we solved was the Beek two-column home scene layout. Beek presented an engaging design that incorporated two columns with items of fluid heights. When the team started development on Beek, there was no good way to maintain this layout while still maintaining smooth 60-fps scroll performance.
Before giving up on the layout, we had one of our React Native core contributors look at the problem. They were able to deliver a custom solution involving a slightly modified version of a React Native internal component. With this solution we were able to keep the design and meet our goal of 60-fps. Once the project was completed, we looked at ways to contribute back to the core React Native codebase with a pull request so that we could make Beek’s custom solution available to the open source community. The patch to `ListView` looks like:
Normally we recommend GraphQL for people who do not yet have an API, but Beek was exciting in this case because they came to us with a GraphQL API! After one day of setting up the GraphQL Relay app and being able to rapidly add new features, we knew this project would go well.
Throughout the app’s development, Beek was building out their API alongside our client. As they added features to the API, we were able to take those changes and add a new feature to the app. Because of our domain expertise in GraphQL, G2i developers would often make feature requests for fields and types to be added to the API. This way, we were able to merge client consumption patterns with knowledge of how the app should retrieve it’s data to produce an effective API for all consumers, not just the app we built.
One specific area of both the API and UI went through at least three iterations as requirements evolved through the project’s life.
At a lower level, the React components written for this app were all (except one) stateless functional components. We used the idea of higher order components from Relay and Recompose to provide a functional and more modern approach to component authoring and maintenance. Beek has been able to take this style and expand on it quickly, building even greater features on top of the codebase G2i built for them.
By the end of the month G2i had put a total of 160 hours into the app, which was equipped with internationalization and analytics by the final build. Throughout the initial Android process G2i developers would hand off iterations of the Android app to the client for testing (about 30 builds in total). By the end the app was published in the store and even after G2i’s involvement, Beek employees were able to take the codebase and extend it with new features which have since been published to the Google Play store.
Even with the initial MVP, Beek saw 60% of its traffic coming from the new app. A week after release the app had a solid 4.6 star rating. Beek was happy with the final timeframe, budget, and development process in the midst of constraints.