Building the BBC Sounds Mobile App
One Star!
“Catastrophic”. “Disappointing”. “Pointless”. “Awful”. “Baffling and lacking”. “Useless compared to iPlayer Radio”.
Those are just some of the things users have been saying in reviews of the new BBC Sounds mobile app.
Reading one star reviews about something you work on requires an ability to avoid taking things personally — even when they can become seemingly quite personal.
I’m the Software Engineering Team Lead on the BBC Sounds App team. It might sound strange, but I have a personal favourite one-star review. The wording is always different but the message is the same. It’s the review which says “this app was released too soon — it’s not ready yet”.
Why is this my favourite? Because it manages to be entirely right while also being entirely wrong, and succinctly describes exactly what we’re trying to do.
Release Early, Release Often
An app is a culmination of thousands of decisions, big and small. Our first major decision was to make a new app for BBC Sounds instead of converting iPlayer Radio, which this team also built and is responsible for maintaining. We’d been tasked with making a new product to combine the best of the BBC Music and iPlayer Radio apps. Converting would have meant reworking nearly every part of iPlayer Radio’s codebase, fitting a round peg into a square hole. On top of that, when we released Sounds, iPlayer Radio users would have had to move immediately instead of having a transition period.
Another early decision was to get all the data the app needed from a single source — the new ‘Experience API’ built by the Radio & Music Services (RMS) team, which Patrick recently wrote about — instead of the variety of different back-end services iPlayer Radio fetched information from.
Decisions like these freed us from assumptions made long in the past, as well as reducing the size of the problems we would need to solve and allowing us to focus on exactly what a mobile team should be focusing on: building the best, most reliable, most usable and most beautiful app we could build.
For our fresh start, we began with one simple aim: connect to a server and show either a green or a red box, depending on what response we got. It’s a simple concept, but immediately we had even more decisions to make.
We decided to write our new app entirely in Swift on iOS and in Kotlin on Android . These are modern programming languages which had only recently taken over from Objective-C and Java (as used in iPlayer Radio) as the standards for mobile development. We decided on an N-tier architecture for the app and MVVM(ish) for the UI layer. We made decisions about what frameworks we should use for making network requests, dependency injection techniques, a ‘bootstrapping’ system for the app so we could manage app startup logic in a single place. We created Services and Coordinators and Factories and Repositories and View Models.
Crucially, we made these early decisions together as a team, because we decided to ‘Mob Program’ through the initial stages of development. This meant all the engineers, Android and iOS, gathered around a single screen and worked together across both platforms for the first few weeks. We all learned together how our new app would work, we all agreed on how we should be writing code, and we could all help each other when problems arose. Even now, though mob programming across platforms is not as common, we are still able to collaborate as a whole team and help each other solve problems.
When we’d finished with our red and green boxes, we decided to make a release. We acted as if this would be the version that was going out to the public and we tested it thoroughly. That was Version 0.1. Version 0.2 brought the ability to sign in to a BBC account before you saw the green box. Version 0.3 added the first version of the Listen page, and in Version 0.4 we added the audio player. In a handful of weeks we’d gone from green and red boxes to a workable audio app. From there we just kept on iterating.
An app is never late. Nor is it early. It arrives precisely when it means to.
In June 2018, we released an app which did the most important things — allowing you to discover, bookmark and listen to all sorts of BBC content — but with some glaring and important omissions. Releasing to the public is a huge moment for an app, but thanks to the months we’d spent practicing making releases it didn’t feel like such a big deal. Rather than having to switch gear from ‘pre-release’ to ‘live maintenance’, we were ready to iterate again and release again.
In the four months since our initial version came out, we’ve released 10 new updates to the BBC Sounds app on each platform, an average of one update every two weeks. These were not small releases, either — we’ve added big important features like downloads, station schedules and episode track listings, as well as fixing major issues such as remembering and displaying your progress through an episode throughout the entire app, not just in the Continue Listening section.
It’s not something everyone wants to admit, but some of the decisions we make turn out to be mistakes. Some of these mistakes are obvious from the moment we try prototyping them, some come out when we do usability testing, some take a while to shake out and mean revisiting things we thought were done. There’s mistakes in our codebase, mistakes in our UI, mistakes in our decisions about which features are most important. We can never really be sure until we hear from real users in the real world.
We’ve had lots of feedback from users about Sounds, some from users who really love the app, some from those that don’t. We use that feedback, especially the critical comments, to help prioritise and decide on what we should do next. It’s a balancing act, where we want to make sure the app works well for users moving over from iPlayer Radio, but works just as well for users who are new to radio entirely, and for younger audiences who we know were under-served by iPlayer Radio.
What we’ve done so far is just the beginning. We’re a team of radio, podcast and music enthusiasts who want to build the best audio app in the world. To do that, the important thing is not avoiding mistakes; it’s continually finding them, fixing them and learning from them.
So if we hadn’t released this app ‘too soon’, how would we know what to do next?
Five Star
Just to finish off, indulge me the opportunity to say a big thank you to the small team of hugely talented engineers, designers, testers and all the others involved in building this app. Everyone works exceptionally hard and deserves to feel incredibly proud of what we’ve built — and what we’re going to build in the next update, and the next one, and the one after that. It’s a privilege to work with such a talented group of folks.
“Brilliant”. “Incredible”. “Cleverly designed and intuitive”. “More modern and usable than the app it’s replacing”. “Everything is so accessible”. “Sleek and simple”. “Top work from the BBC”.
Those are just some of the things users have been saying in reviews of the new BBC Sounds mobile app.
