Spotify discussed “Scaling Mobile at Spotify,” at their New York City office with three speakers, all of whom work on Spotify’s mobile team. They covered how the massive growth of mobile has resulted in a need to make it their top priority. The company has undergone many changes, and the engineering team has been faced with a multitude of new challenges ever since.
The first speaker was Bryan Bonczek, the Mobile Team Lead. Bryan presented a brief history of mobile at Spotify, and the company’s plans for the future.
The Past and the Future
Spotify is a music streaming and sharing service available for all iOS and Android devices, and desktop computers. Founded in 2006, Spotify was launched in 2008 as a desktop client. Today, Spotify has over 24 million users, over six million subscribers and over 30 product teams worldwide.
But the continuing success of Spotify goes hand in hand with its ability to keep up with present day technological trends. As smartphones and the mobile platform continue to increase in popularity and become more and more mainstream, mobile must become the #1 priority for a company such as Spotify. “We knew we needed to make mobile a priority, and so we did,” said Bonczek. This meant hiring many more employees, cross-training mobile developers and ramping up design and QA. They formed what they would call squads, which are autonomous teams that handle the development for a specific feature. They would distribute all mobile development amongst these squads. The idea was that everyone needed to know what it’s like to build mobile software. The idea of “platformization” would from then on be adhered to, requiring that everyone become a mobile developer. “A good platform is required for large scale,” Bonczek explained. They would have to move fast for such a large-scale mobile effort, but still maintain very high quality.
Brian Christensen, an Android engineer, next shed some more light on Spotify’s mobile movement. He spoke about testing methods and the testing tools used on a regular basis.
Testing
Spotify engineers use a variety of different testing tools in order to ensure that their code is running smoothly and their product is free of any bugs or glitches. They need to move fast while simultaneously maintaining a high quality product. Christensen started with the process of unit testing. This consists of the testing of the smallest testable parts of the app. The objective here is to root out complex, confusing and poorly designed code. This protects the code, which is a part of a large, shared and evolving code base. “Everybody’s code is effecting everybody else’s code,” says Christensen. Unit testing works to safeguard your code when another developer can unknowingly break your code, as he/she is unaware that it is having any kind of effect on yours.
Another testing tool used is automated system testing. This is end-to-end testing of the entire system. It tests areas such as navigation, playability and screen state. All the different devices on all the different operating systems run through the test together. It will test the app experience for a free user, premium user, Facebook connected user, a user who is not connected to Facebook, etc. The test will randomly follow all of the possible paths on a continuous loop, showing where exactly the test passes or fails, upon completion. “We want to test the full functionality of the app,” Christensen explained. This process saves a lot of time, as it doesn’t have to be done manually.
Feature flags are also very beneficial to the testing process. A feature flag is a switch in code that enables or disables a feature. This allows for continuous integration, as specific features that are not needed for a certain test can be temporarily turned off. This keeps developers from having to continuously write and rewrite lines and lines of code. This feature plays a pivotal role in enabling the next type of testing, A/B testing.
A/B testing is the process of quickly proving or disproving a hypothesis by measuring the impact of a change against a control. This strategy can provide you with hard numbers and real consumer behaviors, rather than just thoughts and predictions. It can give results such as the number of plays, number of purchases and duration (minutes played). Christensen states that, “you are able to evaluate the effect of a single change amongst many happening at once.” You can make more educated decisions when given the exact number of clicks after a specific change, in contrast to the number of clicks beforehand, the way that feature had previously operated.
The final speaker ] was Adam Price, an iOS engineer, who went on to describe one of Spotify’s most recent projects.
CatKit: The Design and Development Process
Price described the design, development and implementation of the recent project, CatKit. The CatKit iOS library is a collection of components used to implement views in a consistent way. It is a self-contained library, and the idea is to be able to implement it once, and then reuse it everywhere. The first draft of CatKit was implemented in just a week by two developers in the Stockholm office. A strict deadline was issued for the project, but having to meet such a deadline keeps the developers from over-thinking or over-engineering the project.
CatKit was created with two underlying principles. The first is that the only dependencies that were allowed were UIKit and Foundation, which are the two basic Apple frameworks. This principle was implemented by creating a stand-alone app that allows you in order to try out the different classes of Catkit in isolation. Also, because of the fact that the library had to compile on its own, it helped keep the developers honest and not include different dependencies for the rest of the app that would cloud the library.
The second principle states that CatKit components were intended to work on their own, without any custom sub-classes. The reasoning is that the creation of sub-classes results in the fragile base class problem. This means that a super-class can’t be changed without potentially breaking one of its sub-classes. “Going through the refactoring process on every feature allowed us to delete thousands of lines of code and a lot of complexity that was making it hard to maintain the app,” Price explained. Because many components were being shared, it became easier for them to understand other features that were harder to understand before, as a result of them not all being written the same way.
The sharing of components and sharing of strategies and methods made it easier for developers to work on features that others were working on. This helped to fix a lot of bugs and glitches in CatKit that could have potentially presented bigger issues. “Everybody pretty much contributed to CatKit,” said Price. This teamwork and strong team mentality has allowed Spotify to find a great deal of success with every aspect of its product, including CatKit.
Mobile technology is constantly being upgraded, and everyone today wants everything mobile. In order to see sustained success, a company like Spotify must adapt to the mobile platform and reach out to a mobile consumer base. After hearing what these three developers had to say about their work on the mobile side of their product, it’s clear that at Spotify they work on staying ahead of whatever curve is thrown their way.
