The challenges behind releasing our Windows 10 Universal app
This summer, we’ve removed our “preview” tag from our Windows 10 Universal app. It’s a huge milestone for the Windows Team at Deezer. Even if the work is not done, we wanted to share a few things we’ve done between our first line of code and today.
Why we’ve decided to go universal ?
Deezer has a full-time Windows Engineering team for four years now. During this time, we’ve shipped several apps, and more than 100 updates for:
- Deezer for Windows 8,
- Deezer for Windows Phone 8,
- Deezer for Windows 8.1 (Non-Universal/Shared),
We’ve skipped the “Windows 8.1 shared” wave for several reasons:
- the background audio architecture was changed, causing us a lot of rework,
- Some XAML controls also have evolved from Windows Phone 8 Silverlight to Windows Phone 8.1. As we have a lot of custom controls and styles, this was also going to cause a lot of rewriting.
As Microsoft “veterans” developers, we knew that more changes were coming to Windows 10, so we postponed our next big release for the Windows 10 Universal platform.
As a company, one of our main objectives is to give you access to your music anywhere you are, with any hardware that outputs sound. Windows 10 promise is to let you deploy your app on phones, laptops, PCs, Xbox, Raspberry Pi and other devices. For a “small” development team like us, that seems to be a perfect fit. We will have only one code base to handle all our apps on Windows Platform.
A subtle equation: which features develop first ?
We already had a Windows 8.1 app, and a Windows Phone 8 app. There was no feature parity between these two apps. Moreover, there was a huge feature gap between our Windows apps and their iOS and Android counterparts. However, we are still a small development team, and we were rewriting the app from scratch. Obviously, we had a choice to make. All our core experience features — like playback and offline sync — are a part of our Windows 10 app. However, some features didn’t make it. As of today, here are our top features on Deezer Music for Windows 10.
On that list, you’ll see few features in bold: these features made their first appearance on the Windows platform ever. Even if we rewrote the app, we’ve taken the time to implement great new features for our Windows users.
A first adaptive experience
One of the challenges behind releasing a Windows universal app is to make it working for any device size. Even if we have apps for desktop, mobile, tablet and TVs, combining most of these requirements within one app is quite challenging.
At the time of designing it, there were no app in the store to take inspiration from. We’ve done a bunch of research and mockups before finalizing our choices.
At the end, we’ve decided to focus only on navigation. We have a Hamburger menu — with items always accessible through their icon — for desktop and a tab menu on phone. This core principle spans across all the app. Then, each page is “responsible” to get an adaptive treatment. Our reasoning behind this choice is to make a usable page, and then see — via telemetry — what pages are used most and on which screens. Then, we will optimize each page according to where they’re used. We will only start this second step now, after our release.
Set the stage: tests, automated builds, etc…
At Deezer Devs, we have standards for any code we produce, including: writing unit tests, build & run tests before each merge, code review any line of code, have automated builds for deployment.
To be honest, this part of the story is a sad one. Even after more than a year from their releases, UWP tooling is not at a maturity level we expect to create great apps.
UWP tooling is not at a maturity level we expect to create great apps.
First, the unit testing landscape is a little bit empty. There are few unit test frameworks that integrate well with Visual Studio and the build pipeline. However, we lack tools around unit testing (like a mocking library/framework), and MS Test runner needs to be run in interactive mode. This come with huge drawbacks: you need a custom and on-premises build agent, and you can’t run your unit test in parallel.
One year after our first line of code, there is still no way to build a package for store submission from our CI pipeline. Every package we submit has to be built on a developer machine. This is not the release process we had on our Windows Phone 8 app, and it’s sad to have a drawback on such basic development workflow step.
Since the writing of this article and it’s publication, Microsoft released a Visual Studio Team Services “Windows Store” extension. We didn’t tested it, as it does not yet support flighted submissions, but we’re looking forward to resolve this issue soon :)
This story is not ended yet! We’re working closely with Microsoft engineering teams on a broad range of UWP development issues — including tooling, testing, deployment, framework, etc… — and they have great features coming soon. All these issues have been discussed with them, we just hoped for a sooner resolution. We keep up the good work, as they do. For example, at the beginning of the year, we had no options to run UI Automation tests for our UWP app. Since Microsoft announced a driver for Selenium-based tests, we can now run some sanity tests automatically.
Going public with our preview
Beta releases are part of our mobile workflow since years. Our new Windows Universal app was no exception. However, we’ve slightly changed things compared to our previous windows beta. We had three beta phases:
- An invite-only beta for our paying subscribers,
- An invite-only beta for our free users,
- A public beta for everyone.
We chose this approach to let our paying subscribers be the first to test the app. When they’ve started using the app, we were able to implement mandatory features for our free users.
The feedback was tremendous: we’ve multiplied by 40 the number of beta registrants compared to our previous beta. We had such a great amount of candidate that we had to work with Microsoft to overcome the Windows Store limits around this feature.
Handling feedback during (and after) preview
When working on a mobile app, you really have unexpected issues like crash the app because of wifi in campings (true story). As we didn’t have a great telemetry in place, we’ve relied on two tools to get feedback from our users: Windows Store ratings and comments, and a custom “send feedback” feature.
Everyday, we read all store comments.
We also use appbot.co, a service that extract store comments and give you powerful tools to review them: grouping, auto-categorization, sentiment analysis, etc… Everyday, we read all store comments. Comments rated with one or two stars get pushed into one of our Slack channels, so we get sure that any weird issue is getting notified by our engineering and product team.
For the beta version, we’ve also created a little page where users can send us a direct feedback — bug or suggestion — via email. Between April and July, we had more than 2000 feedback sent from this feature, far beyond our expectations. It has helped us shape our roadmap for the rest of the year.
What’s next?
Even if we’ve reached a big milestone, the Windows Team at Deezer is still working on our Windows 10 Universal app. We can’t share what’s coming yet, but watch out the store for new updates and new features coming in the next weeks :).
By the way
Are you a C# developer? Do you want to work on these topics? You should send your application and meet our Windows team. If you want to apply, you can also read our post about applying Agile methodologies in our HR department. This will help you understand what’s going on behind pushing the “Apply” button.
