Offline Support

[g3rd]

Feature request

I am building an application for a user group that spends a majority of their time ouside of a network connection. Having an offline sync or cache would simplify development.

Is your feature request related to a problem? Please describe.

No

Describe the solution you'd like

Either a recommened approach to caching or storing data offline or providing some magic behind the scenes to sync offline data.

Describe alternatives you've considered

Manually creating a local database copy with Core Data, Swift Data, or Realm Swift.

Additional context

[MadeByDouglas]

I'm not really sure this library should handle this. (A recommended approach and/or more documentation would be great though.) There could be so many ways to implement a local state, as you mentioned SwiftData, Realm, or others. I am currently building an app that uses SwiftData and Supabase, and while it might be nice to have these wrapped up together, its probably better for the choice to be up to the individual app or team since each team may have different priorities.

I'm curious to discuss it further though, this feels like it would be way down the list on things to tackle and require a lot of thought beforehand to do it right.

[DamilolaDami]

Firebase has a feature which you can disable cache on initialization of the sdk. This way if the developer is not interested they can easily turn it off

[dshukertjr]

PowerSync is one option.
https://docs.powersync.com/client-sdk-references/swift

[262hz]

For my app at least, managing the local state while the user is not connected to a network, then eventually syncing with the server — this isn't something I want the Supabase SDK to handle "automatically". It's not easy to assume exactly how each apps needs to handle this scenario.

[theolampert]

I've written a few offline sync engines on various projects and I recently wrote an offline-first, two-way sync system with this library and GRDB, leveraging the observation tools of each library to also maintain realtime features when a connection is available.

This was all highly specific to the end application's requirements and wouldn't be able to cover every usecase an end user might need from this feature. It would also enforce a certain regitity that supabase currently leaves very fleixble in its data modelling.

If we're instead talking about a simple offline "cache" like what Firebase provides (Firebase doesn't provide offline writes as far as I recall, but I haven't used it in years) then you could argue this library could provide something there but that is a fairly trivial feature to implement.

I'd vote for keeping this out of this library and keeping it laser-focused on what it's currently doing really well.