Building the Future of Our Desktop Apps

A Shared UI for Spotify’s Desktop and Web Clients

For the past two years, Spotify’s client engineering team has been working toward a single goal: one unified user interface for both the Desktop application and the Web Player. Previously, the two clients were built and maintained separately, which meant duplicated work, divergent feature sets, and a growing technical burden.

The old Desktop client was the company’s full-featured experience, but it had become difficult to develop. Built on a patchwork of web technologies—a result of multiple teams contributing over time—it was hard for new engineers to onboard to and harder still to extend. The Web Player, by contrast, was a lighter, modern React application with a clean architecture and continuous deployment. Its codebase was easier to work with, but it lacked the capabilities that Desktop users had come to expect.

Accessibility was another deciding factor. In assessing both clients, the team found that making the Web Player accessible would be difficult but possible; making Desktop accessible was nearly impossible under its existing architecture.

Converging on one codebase

After evaluating options such as sharing components or features, the team landed on a more ambitious plan: gradually bring the Web Player’s feature set up to Desktop-level parity and make it the foundation for both clients. This approach allowed for continuous deployment and incremental testing with real users, avoiding the risks of a big-bang rewrite.

The Desktop client remains a native Windows and Mac application that uses the Chromium Embedded Framework (CEF) to render a web-based UI. In the old Desktop architecture, every page was a standalone app running in its own iframe—a design intended to let multiple teams own different features. Eventually, however, one team ended up responsible for the entire UI, and the iframe-based structure became more hindrance than help.

The challenge was that the Web Player was deeply tied to web servers for data and authentication, used a playback stack that didn’t match Desktop, and lacked offline capabilities. To run the same UI in both environments, Spotify built a layer of TypeScript Platform APIs to abstract data sources, playback stacks, and feature availability. The team also rewrote the client in TypeScript as they migrated features over.

The result is a React-based UI that communicates with Platform APIs through React Hooks. The interface runs identically on the web and inside the Desktop container, without needing to know whether data comes from Spotify’s C++ stack or from its web infrastructure. This architecture let the team move quickly, adding downloading, offline mode, local files, lyrics, a “Now Playing” queue, and advanced sorting and filtering features. In just over a year, the shared UI matched the original Desktop client’s feature set and, in some areas, surpassed it.

Managing the organizational side

Beyond the technical work, the project required solving an organizational puzzle: how to build a new client without stalling day-to-day work. Design and product teams started by researching how users interact with the existing apps, defining what features were essential and what the new client should look like.

Engineers from multiple teams formed a small virtual team to run initial experiments. Their assignment was to prove the concept—getting the Web Player running inside the Desktop container, tackling playback and authentication, and mapping out the engineering approach. Because both codebases were already co-located in the same monorepo, the task was easier than it might have been otherwise.

After three months, the exploration phase concluded with a roadmap and clear priorities. The project then required full commitment from the wider team, with constant testing and analysis to validate the direction. The pace of implementation once the shared UI was in place gave the team confidence that they had chosen correctly.

Measuring the outcome

The project had four primary goals: code reusability, unified user experience, faster development, and meeting the needs of both Desktop and Web Player users.

Code reusability

Writing UI code once and using it in multiple clients means design changes propagate everywhere at once. Spotify plans to expand this reusability, sharing Platform APIs with even more clients in the future.

Unified experience

One set of components across clients allows for more thorough implementation of design systems. The work also moved clients closer to Spotify’s shared design language, making cross-platform transitions smoother and the overall experience more modern and accessible.

Development speed

While it’s still early to prove long-term velocity gains, the number of features shipped since the project began is a strong indicator. The cleaner architecture has also made UI coding simpler and easier to understand for developers—an unexpected benefit that points to a solid foundation for future work.

User satisfaction

Throughout the process, the team ran user research and continuous tests to ensure the new experience served both existing power users and newcomers from mobile. The result is a more accessible application shaped by direct feedback, with an architecture that will allow the client to evolve more quickly going forward.

What users can expect

For music listeners, the new Desktop client and Web Player should feel familiar yet refreshed—carrying over the features they rely on while introducing some that were previously mobile-only. Over time, users should see new features appear more frequently as the team leverages the unified architecture to iterate faster. For Spotify, this launch isn’t the finish line; it’s a new starting point for the application that began the company’s journey.

Rethinking the Desktop Client Architecture

Spotify's desktop application has evolved from a simple music player into the central hub for how many users experience the platform. But with that growth comes complexity. The legacy architecture, built on a single web-based front-end running inside a Chromium shell, started showing its limits: slow startup times, heavy memory usage, and a codebase that was increasingly difficult to scale across different teams working on distinct features.

The engineering team took a step back to reconsider what the desktop app should be. The result is a new, modular architecture that separates the application into distinct components, each responsible for a specific domain like the player, the library, or the search experience. This shift allows teams to develop, test, and deploy features independently without risking stability across the entire client.

Moving to a Service-Oriented Frontend

The core of the redesign is moving away from a monolithic front-end. Instead, Spotify now structures the desktop app around a set of internally developed services. Each service handles a specific business capability and exposes a set of well-defined APIs. These services run on a lightweight runtime native to the desktop, rather than relying on the heavy web view for everything.

For user-facing contexts, the team still leverages web technologies where it makes sense. The key change is that rendering is now the only job of the web layer. Complex features like playlist management or the radio algorithm are no longer tangled up in the DOM and browser event loops. They are managed by dedicated services that communicate with the UI layer through typed contracts, improving performance isolation and reducing the risk of cross-feature regressions.

Why Not Just Fix the Web Shell?

The previous approach centralizes all logic in a single web view known internally as the "Dominion." Retrofitting it with performance fixes was possible, but every optimization was a one-off that still left the underlying structural problem intact. A memory leak in the search feature would still cause the entire client to slow down. Conversely, decoupling into services allows the engine behind the user interface to be swapped or updated without rewriting the logic of the player or the offline library.

Importantly, this architecture also aligns with modern web standards. The services are not a proprietary framework—they are built on existing patterns for inter-process communication. This enables Spotify to migrate gradually, feature by feature, without the risky "big bang" rewrite that often sinks such projects.

The Payoff: Performance and Autonomy

Early results from the modular rollout show tangible improvements. Startup time in internal testing has dropped significantly compared to the legacy build. Memory usage is more predictable, and when a particular service encounters an issue— say, a third-party integration that the podcasts panel relies on—the rest of the application remains responsive.

From a developer experience perspective, teams now own their slice of the desktop truth. The UI teams can ship changes daily if they want, while the underlying service teams maintain strict API contracts. This autonomy pushes decision-making closer to those who know the feature best, shortening feedback loops considerably.

Working From Anywhere

Interested in contributing to this kind of work? Spotify’s recently announced Working From Anywhere policy lets employees choose between full-time remote, full-time office, or a hybrid of the two, opening these roles to a broader spectrum of candidates. Current postings are available on the job board.

The project was a collaborative effort across several squads. Credit goes to Felix Bruns, Peter Johansson, Alberto Núñez Acosta, Guido Kessels, Tryggvi Gylfason, Craig Spence, Lucas Lencinas, and Emma Bostian for driving this architecture forward.