Subsonic vs OpenSubsonic
Two specifications coexist in the wild:
- Subsonic — the original API published by Subsonic. Stable, widely implemented, but frozen.
- OpenSubsonic — a community fork that extends the original with new endpoints, richer response shapes, and better metadata.
Most modern servers (Navidrome, Airsonic-Advanced, Gonic) implement both: the original Subsonic surface plus the OpenSubsonic additions.
Where they overlap
Section titled “Where they overlap”The vast majority of read-side endpoints — getting albums, browsing artists, fetching cover art, streaming — are identical. SwiftSonic handles these transparently; you call the same method whether the server speaks Subsonic or OpenSubsonic.
Where they differ
Section titled “Where they differ”OpenSubsonic adds:
- Richer track metadata (multi-artist support, better tags, sort names).
- Server-side capability discovery (
getOpenSubsonicExtensions). - Replay-gain, bookmarks, and richer playback state on response objects.
- New endpoints not in the original spec.
When SwiftSonic talks to a vanilla Subsonic server, OpenSubsonic-only fields show up as nil or empty — they are optional in the response models.
How SwiftSonic handles the split
Section titled “How SwiftSonic handles the split”SwiftSonic does not present “Subsonic mode” and “OpenSubsonic mode” as two separate clients. Instead, response models include both the standard and the extended fields, and unsupported fields decode to nil on a vanilla server.
If you need to know whether a feature is actually supported by the connected server before using it, query the capabilities — see OpenSubsonic extensions.
What SwiftSonic will not do
Section titled “What SwiftSonic will not do”- It will not implement endpoints from a single server’s vendor extensions (e.g. Navidrome-only routes that aren’t in either spec).
- It will not silently fall back to legacy auth or guess at undocumented response shapes.
If a behaviour is not in either specification, it does not belong in SwiftSonic.