Strava for Apple Watch: Planning and Project Overview
with contributions from Jason Cheng, Matt Robinson and Ben Wolak
Strava released its original Apple Watch app shortly after the device’s launch in 2015. In the two year period following the release of our original Apple Watch app we made some incremental improvements, but the overall software architecture never changed drastically. The engineering approach of the original app was heavily guided by the hardware and software limitations of the time, and the result was an Apple Watch app that acted as a remote control and second screen for the Strava iPhone app. This was great for development: all we had to do was keep our Apple Watch app in sync with the state of the iPhone app and the watch would get all the phone’s recording features (Live Segments and audio announcements, for example) for free.
In September of 2016, Apple announced the Apple Watch Series 2. Along with a generous boost to performance and battery life, the new watch came equipped with built-in GPS. The original Apple Watch relied on the iPhone for GPS data, which meant that Strava athletes had to carry their phones with them if they wanted to record an activity using their Apple Watch. The improvements to the Apple Watch’s hardware and software made it a legitimate competitor to dedicated GPS fitness devices. The ability to record activities without the phone was a natural next step for the Strava app.
Because our original app was so dependent on the iPhone, converting the existing app into a standalone experience was a non-starter. This left us with two options: port the recording logic from the phone over to the watch, or start from scratch. Over the past seven years and several hundred million activities, the recording logic on the phone has evolved and grown organically. It consists of a number of monolithic classes that have strong dependencies throughout app. After a brief investigation we decided that starting from scratch would be faster than extracting the record logic from the surrounding iPhone app. Rewriting some of Strava’s most important code felt like a large and uncertain undertaking, but it offered some exciting opportunities as well. In addition to creating an updated Strava experience on the Apple Watch, we now had the opportunity to architect a modern activity recording framework that was well documented, easy to test and easy to use. If successful, this framework could later be pulled back into the phone, improving its usability and testability.
Team, Timeline and Scope
The small engineering team responsible for modernizing the Apple Watch app consisted of two individual contributors that worked on the project full-time, an engineering manager who contributed part-time and a QA engineer.
There was already an overwhelming amount of excitement in our support forums and App Store reviews for Apple Watch Series 2 support by the time we kicked off the project. We wanted to get something in our athletes’ hands as soon as possible. Through a rigorous planning exercise we estimated that we could deliver a rewritten app in about four months. We were forced to cut some features initially in order to meet the deadline. It wasn’t feasible to ship a standalone version of Strava for the Apple Watch that replicated all of the recording functionality from the phone app in the allotted time.
Planning
Even though we decided against using the recording logic from the phone as-is, it still served as reference for what to build for the watch. We audited the phone’s record infrastructure to identify the core functionality.
- Activity State Management — A state machine that manages transitions between recording states. This is used by components throughout the record framework.
- Activity Writer — Logic related to writing activity data to the file system.
- Activity Reader — Capabilities required to read activity data from the file system. This is used to recovery incomplete recordings after a crash, user termination, running out of battery, etc crash recovery.
- Upload Management — Functionality for transferring the activity data from the watch to the phone and then from the phone to the Strava API.
- Filter Chain Management — Our record framework is composed of a number of discrete modules. When a set of modules is assembled in a manner that provides a specific piece of functionality, like calculating a split, we call that a Filter Chain. The complete record experience consists of multiple filter chains which can differ based on athlete preferences and activity type.
- Heart Rate Management — A wrapper for HealthKit that listens for heart rate samples from the Apple Watch heart rate sensor and informs interested parties when new samples are available.
- UI — A user interface that provides basic settings and core stats for an athlete’s current activity.
When possible we broke these components down further in order to identify common code that could be shared between multiple components. From there we estimated how long each atomic unit of work would take and plugged this data into OmniPlan, a project management software tool. This was the first time that we had used OmniPlan for a project and we were happy with the results. It helped us visualize dependencies and provided what turned out to be an accurate estimate of the project timeline.
Development
With a plan in place, development rolled along smoothly. The three engineers on the project worked in a divide and conquer manner. We broke development up into three rough groups:
- Core framework — filters that power the recording logic.
- Basic record — ride activities only, no crash recovery, no auto-pause and basic stats.
- Activity upload — transfer the activity file from the watch to the phone so that it can be uploaded to our servers.
We used test driven development practices to validate the interfaces we had established for our respective components. Once complete, all the independently-build components worked together as expected.
In about four weeks we had a basic working prototype. The prototype displayed a few simple stats, wrote activity data to the file system and transferred the file to the phone for upload once the activity was complete. The prototype helped us identify and resolve major location data issues early in the development process by testing in the real world. With our design validated we continued development, adding functionality like improved UI, auto-pause and crash recovery.
Beta/Silent Roll Out
Beta testing our changes to the Apple Watch app was not straightforward. Typically we hide new features behind feature switches that we can roll out to a select group of users, but due to the scope of the changes to the Apple Watch app this option wasn’t available. This left us with a single beta cycle of two weeks to test our work before we rolled the work out to all of our athletes. Check out this blog post to learn more about our release process. Fortunately we have a devoted group of TestFlight beta testers that were excited to test the new Apple Watch app and provide us with feedback. Our testers helped us identify data issues around using location data to calculate foot sport activities, crashes due to over utilizing the CPU on the main thread and failed file transfers from the watch to the phone.
Release
After release, development of new features halted temporarily while we addressed issues that surfaced during the beta period. After a few release cycles all major issues had been resolved and we moved back to feature work. Since then we’ve added a number of features to our Apple Watch app: run average pace/split pace toggle, first time user onboarding, run split notifications, watch face complication support, activity history, file transfer improvements and watch-based analytics. Apple Watch usage has been impressive so far and we are seeing adoption numbers comparable to dedicated GPS fitness devices.
Conclusion
The Apple Watch project was a fun and unique experience — the opportunity to build an app from the ground up on a new hardware platform doesn’t present itself every day. We had a lean team and an aggressive deadline but were able to deliver an experience that we’re proud of without compromising on the release date. This was possible due to solid upfront planning that gave us a realistic schedule with built-in time to deal with the unexpected and the ability to parallelize as much of the work as possible.
