A Client-Side Overhaul Behind Spotify's New Like Limit

When Spotify announced it was lifting the 10,000-song cap on Liked Songs, the obvious technical reading was simple: delete a few lines of code and ship it. In practice, the change exposed a deeper architectural problem that required rethinking how the client apps load, store, and sort music metadata across a wide spectrum of devices.

The legacy client design dates back to an era when laptops dominated listening. On app startup, Spotify loaded all metadata for Liked Songs from disk into RAM, then sorted it in memory. That model works well on a modern laptop or flagship phone with ample memory and stable connectivity. But Spotify's audience has shifted toward mobile, and the hardware in use spans thousands of device models with vastly different processing power and network quality. For users near the 10,000 limit on older phones or slow connections, startup suffered noticeably—even though most listeners with large libraries only actually played a few hundred of those tracks.

Moving from Load-Everything to Batch-and-Store

The engineering response treated the Like limit as a symptom, not the root cause. Instead of patching the cap, the team rebuilt the client-side data handling for Liked Songs. The new architecture, tested on iOS first in April and then on Android, takes a fundamentally different approach to metadata.

On first launch, Liked Songs metadata downloads in batches and is written directly to device storage—either the internal drive or an SD card. Critically, all sort orders (title, artist, album, and recently added) are pre-computed and stored on disk as well. When a user opens any view, the app reads the relevant pre-sorted table and streams results straight from storage, replacing the old pattern of loading and sorting everything in RAM. On subsequent launches, the metadata is already present locally, and the app only checks Spotify's servers for newly liked tracks to add incrementally.

The shift produced measurable gains in startup and view-load times, particularly on lower-end smartphones. Users who never approached the Like limit also benefit, since the performance improvements apply to the client generally.

Rebuilding Mid-Flight

The project took roughly a year from research to release, in part because the team had to replicate existing behavior exactly while swapping out the underlying mechanism. The shared client codebase lost or changed about 100,000 lines, with some modifications requiring substantial new additions. Both the Android and iOS apps were adjusted in parallel.

A major share of the work was simply cataloging every possible way a listener can "like" a song—there are dozens of entry points across the library and playback surfaces—and mapping each one onto the new data flow. Meanwhile, the team tracked ongoing changes to the operational client and the user interface teams' work, such as the introduction of Shortcuts, to ensure feature parity at switchover.

Testing scaled in stages. Around seven months before launch, 30 employees were testing the build. That grew to 1,000 four months later, then to 1% of all users, and eventually 50%, a gradual ramp designed to surface rare "one-in-a-million bugs" before full rollout.

Deciding Where the Investment Goes

Prioritizing an architectural overhaul over a simple limit adjustment was not a foregone conclusion. The engineer leading the work had monitored the impact of the 10,000-track threshold for about three years before committing to the larger solution. The decision hinged on observing shifts in user behavior: as listening moved increasingly to mobile home screens and away from library views, the cost of the old startup pattern grew. A segmented analysis—rather than averages across the entire user base—made it clear that a significant number of listeners were using older hardware and slower networks, and that serving them well meant modernizing the stack rather than incrementally adjusting it.