Roadmap: SwiftSonic 0.6 — Ergonomic improvements from real-world dogfooding

[MathieuDubart]

Hey everyone,

After publishing SwiftSonic 0.5.0 with security hardening and full Subsonic +
OpenSubsonic spec coverage, I've been heavily dogfooding the library while
building Cassette — a native
iOS/macOS Subsonic client.

Building a real app on top of SwiftSonic surfaced a few friction points that
were too persistent to ignore. They're not bugs and not blocking, but they
forced workarounds in Cassette that don't belong in consumer apps. 0.6 will
focus entirely on ergonomic improvements to make the library more pleasant
to use without changing its scope or introducing breaking changes (mostly).

Here's what's coming.

---

🎯 What's coming in 0.6

1. Hashable conformance on identifiable model types

SwiftUI's value-based navigation pattern (NavigationLink(value:) +
navigationDestination(for:)) requires the navigation target type to conform
to Hashable. Currently, model types like ArtistID3, AlbumID3, Song,
Playlist, and PlaylistWithSongs conform to Codable, Sendable, Identifiable
but not Hashable.

This means consuming apps need to add retroactive conformance via extensions,
which is boilerplate that should live in SwiftSonic itself.

0.6 will add Hashable conformance (keyed on id) to all Identifiable
model types. This is additive and non-breaking.

2. Public memberwise initializer on Playlist

Playlist currently has a synthesized internal memberwise initializer, which
means it can't be constructed from outside the SwiftSonic module. This blocks
legitimate use cases like building fallback or empty playlist values in UI
layers, or constructing playlists in tests without going through the API.

0.6 will expose a public memberwise init on Playlist, with sensible
defaults for optional fields and a static Playlist.empty(id:) factory for
the most common fallback case.

3. Direct image data fetching via coverArtData(id:size:)

SwiftSonicClient.coverArtURL(id:size:) returns a URL? (a signed/parameterized
API endpoint URL), not the image data itself. This is fine for streaming use
cases where you pipe the URL directly into AsyncImage or a similar SwiftUI
helper.

But if you want to download and persist the cover art blob (for example
to support offline playback with cover art display), you need to:

1. Call coverArtURL to get the URL
2. Manually build a URLRequest, including any auth or custom headers
   (Cloudflare-protected hosts require headers that SwiftSonic injects
   internally but that aren't exposed when you receive just a URL)
3. Fetch with URLSession.shared.data(for:)
4. Write to disk

That's four manual steps that re-implement logic already present in SwiftSonic's
transport layer — including the trickiest part, custom header injection.

0.6 will add a coverArtData(id:size:) async throws -> Data method that
performs the full fetch internally with all auth and transport configuration
already applied. The existing coverArtURL method stays for streaming use
cases.

---

🛠️ Patch versions

I'm keeping space for 0.6.1, 0.6.2, etc. for any small ergonomic fixes or
oversights discovered after the 0.6 release. If you hit friction while using
SwiftSonic in a real app, please file an issue — the goal of this minor cycle
is exactly that.

---

🔮 Beyond 0.6

A quick teaser of what's planned next, in rough order:

• 0.7 — Advanced OpenSubsonic extensions (synced lyrics, contributors,
  moods, tokenInfo, ReplayGain). Expanding spec compliance into the more
  recent OpenSubsonic territory.
• 0.8 — Optional multi-server support (Gonic, Ampache) if community
  interest is there. SwiftSonic stays focused on the Subsonic/OpenSubsonic
  spec — anything outside that is community-driven.
• 0.9.x — Pre-1.0 polish, deprecation cycle for any rough edges.
• 1.0 — API frozen.

---

💬 Feedback welcome

If you're building something with SwiftSonic and hitting friction I haven't
listed here, please open an issue or comment on this thread. The whole
0.6 milestone exists because dogfooding surfaced real ergonomic gaps — your
feedback can do the same.

Cheers 🎸

[bocan]

Well, fortune favours the bold... I'll have a go at implementing this into mine over the next few days and report back any issues I find. Perhaps with a PR if it's anything easy to address.

https://github.com/bocan/bocan-music/blob/main/docs/design-spec/phase-19-subsonic.md

[MathieuDubart]

That would be awesome, contributions are very welcome! Feel free to open an issue first if you want to discuss the approach before diving into a PR !

Good luck with your implementation 🙌

[bocan]

Just to update this, as far as I can tell, it's all working perfectly! There's still an amount of work on my side as I'm still not happy with the federated search of sonic + local, but it's totally usable. Many thanks for this project! It was great timing running across it as I would have needed to write the library myself otherwise. 🤜🤛

[MathieuDubart]

Hey !
Thanks for your update, I'm glad it worked well for you !
If you have any issue/improvement or else, feel free to share/open a PR ;)

Good luck with your project 🤝