By Corey Hanson, Sr Software Engineer, Tech lead on Growth Tools
Just over a year ago, the Subscriber Experience team started a project to revitalize the BARK mobile experience, which primarily consists of box tracking, rating, add-ons and updates. Over the years, there have been various iterations of the BarkBox mobile app. Unfortunately, due to time, a changing landscape of skill sets on the team, and various shifts in priorities, our “BarkBox” app had fallen into disrepair, and had not kept pace with the development of our latest offerings. As a result, we decided to remove the app from the Apple App store and Google Play store.
However, even after removing it, we still had a loyal base of users using our app regularly. Knowing there were customers out there using an app, we knew could deliver a better experience and decided it was time to make some drastic improvements. In this post, I’ll dive into the process and decisions we went through to revamp the barkbox app, from MVP to where we are today.
Choosing a Framework
We started out by exploring the various mobile technologies available to us at the time. We wanted to find something that could be easily picked up by the engineers on our team, be iterated upon quickly, and that supported a core set of features including push notifications, deep linking, and integration with existing analytics platforms (among other things!)
After a bit of research, we landed on four potential options:
- Traditional native development
- React Native
- Ionic
- Flutter
It didn’t take long for React Native to become our favorite of the bunch. While native development could offer the most authentic and performant experience, it would require our team to pick up Swift and Java if we wanted to give our users both an iOS and Android experience. We had performance concerns about using Ionic based on benchmarking data found in our research, and while Flutter sounded like an exciting idea, it again would require a new skill set (learning Dart) and with it being so new on the scene the ecosystem of libraries and knowledge sharing still had some growing to do.
React Native stood out for it’s accessibility to our team, maturity within the mobile development community, and wide support of features. While we didn’t have much React development experience at the time, we were all familiar with Javascript and several of the various frameworks popular today, including Vue and Angular. As a solution, React Native has been around for several years and is continually developing both it’s core libraries and community. It seemed like we could dive in quickly and hit the ground running to get an MVP out to our customers.
Building the MVP
To kick things off we decided to focus exclusively on iOS. Looking at our Amplitude analytics, we found that almost 70% of our customers who visited barkbox.com from a mobile device, more than twice as many were doing so from an Apple device. In an effort to get an MVP out as fast as possible we decided to delay Android development for the time being.
One of the parts of React Native that appealed to us was Expo — an open-source tool for developing apps without requiring you to interact with native code. It gives you access to several native libraries that have been integrated with the framework to allow for a quick and quirkless implementation. It also blackboxes the build process, which initially removes one item from the list of new things to learn, while also streamlining the steps needed to create a new build. Once you set up the required Apple certificates it’s smooth sailing.
For an MVP, we decided to prioritize the following:
- An authentication system for users to sign in with
- A tab-based experience for logged in users (using the React Navigation library)
- Implementation of webviews as the source for our tabs to speed up both present and future development
Note: I was personally skeptical webviews could deliver acceptable performance to our users when compared to an entirely native experience, but we decided the risk was worth the benefits gained by being able to rapidly iterate on all of our platforms. We’ll see how it turned on later in this post. - Various user-pages from our mobile experience, such as the dashboard and account settings pages
- A few vital app-specific features, such as “magic-link sign-in”
- A redesign of our pages with the new app experience in mind
Throughout the rest of the year we would go on to release our iOS app to the public and add more features. Users can now receive push notification updates on when their box has shipped, as well check out a recently updated dashboard to find more detailed information about exactly when they can expect their package. We’ve added new ways for users to interact with their boxes from the past, present, and future, and have overall been very pleased with the reception:
- Returning customers/usage is much higher in our iOS app vs. non-app. About 55% of app users come back to the app the next month (compared to 32% for non-app users).
- We promote our app in 3 key locations that communicate core value, which is receiving real-time updates for box tracking via push notifications.
In June 2020 we recorded 95k monthly active users (MAU) for the app, which is an all-time high. We strategically promote our app on the purchase confirmation page which has allowed us to onboard new customers and let them know what communication channels and features are available to them! So as our customer base grows, so do our downloads. - Roughly 42% of customers that click our “get notifications” CTA on the customer dashboard opt-in to receive push notification updates for tracking their box. We have had roughly 72k customers sign up for push notifications since it launched in December 2019.
What Went Well
1. React Native
First and foremost, the decision to use React Native was well received across the board. While there are always challenges, React Native has come a long way over the years. Most questions could be answered quickly through the documentation or on Stack Overflow. The familiarity of Javascript meant that the barrier to entry for new engineers on the project was very low. We were able to build what we needed, integrate with existing monitoring and analytics tools such as Sentry and Amplitude, and ultimately deliver the product our customers deserve.
2. Expo
Part of that ease of delivery came from Expo. It took away so much of the initial learning curve that we were able to iterate quickly and get a prototype in the hands of internal testers. Expo made it so easy to build and run a development build of the app locally that we were even able to share the app with non-engineering team members before we were set up on TestFlight. Using Expo also meant that we didn’t have to hunt down tons of libraries right off the bat.
3. Webviews
I admit that while I was initially skeptical of using webviews as the primary way to deliver the experience to our users, it turned out to be a great decision. I was worried about whether the webview would be performant enough, and selfishly I wanted the freedom that comes with building an entire application from the ground up. In reality, the webview was more than sufficient for the content we were trying to display. While we did run into performance issues, they were more of a result of how our site was structured, and resulted in some much needed refactoring that delivered benefits to users on all platforms.
As much fun as an entirely clean slate would have been, using webviews meant we were able to create more new features faster, and give them to users on all devices. It simplified development and testing, and introduced its own exciting set of challenges that made developing with them interesting. We ended up with some creative ways to communicate back and forth between the website and the app, and ultimately wound up with a solid product.
What Didn’t
1. Expo Limitations
While Expo was extremely helpful in getting things up and running, it also created some of the biggest challenges. As great as Expo was, it limits some of what you can build in your app. We wanted to use a specific platform for push notifications, so when it came time for that we needed to “eject” from Expo. That opened up its own set of challenges. Purely by coincidence, we were starting this process around when React Native version 0.60 was released, which included an entirely new way of using native dependencies. We needed to learn the old way of dealing with native libraries, and also the new way as not every one was up to date. We had to quickly learn how to upgrade the React Native version on our own, and also how best to create TestFlight builds. Suddenly we were writing Objective-C and struggling to just build an array. We likely would have hit the pain point regardless, but at more of a time that we would be expecting it.
2. iOS Only
Along those lines, the decision to focus exclusively on iOS at the start has proved to be a painful one. While the plan of launch only on the Apple App Store at the start was fine, it would have been incredibly beneficial to at least keep the Android version of the app up to date. One of the core ideas behind React Native is “Many platforms, one React.” That philosophy is great, as long as you keep up with it. Each platform has its own requirements for native dependencies. Had we been at least testing Android from the start, it would have been easy to eject it from Expo. We ultimately started looking at Android several months after ejecting from Expo, which meant not only did we need to rectify the ejection headaches, we also needed to learn all about Android development. It took lots of backtracking and re-ejecting from Expo using an old build of the app to just get Android running, and that still left us far from a finished product.
3. Difficulties with the App Store
Our last big issue had nothing to do with React Native. After several months of being in the App Store, Apple decided to reject our current build because of not having a streamlined signup process in the app itself. Since our core products are subscription boxes, we opted to send new users to our mobile web checkout flow, rather than pulling it into the app. This was based on an assumption that the vast majority of people downloading the app would be existing customers. Despite approving it several times, Apple changed their tune and instructed us to change the flow to something that would keep people within the app. This could be to host the experience in a webview, or to recreate it in the app. Needless to say, this was an unexpected hurdle we hadn’t planned on needing to prioritize.
Looking Ahead
The BARK app will continue to evolve in the coming months. We still need to unblock our Apple submissions and finish our version of the Android app. We’d like to automate builds and deploys to all platforms, and implement more push notifications to keep our users engaged with our aspects of the platform. Overall, React Native was a great choice for the project. There were hiccups for sure, but ultimately we have an app that is easy to both develop and maintain, and is getting used by more and more customers each month!
