[artman]

Most certainly, if the data that the mobile app consumes is bounded and the same data is accessed frequently. Uber for example could have benefited from a sync architecture immensely (I tried to implement one back in the day, but was too late to the party as hypergrowth blocked any attempts at switching architectures). Sync architectures are not only great from a user experience point of view, but also for developer productivity and velocity. Sync takes care of a slew of problems that makes feature development slow. I gave a talk on this at last year's Local First conf https://www.youtube.com/watch?v=VLgmjzERT08&t=4s.

[bhl]

Ecosystem for local-first and mobile is pretty immature, at least for Swift.

In comparison to the web where there's so many libraries e.g. Zero, LiveStore, LiveBlocks, I've yet to find a good GRDB (sqlite abstraction) integration / client.

Offline-first is definitely very strong, but now how do I get data into a remote database with conflict resolution support?

[artman]

For inspiration, you might want to look at what we open sourced at Uber, https://github.com/uber-archive/jetstream-ios and https://github.com/uber-archive/jetstream/wiki/Protocol. While pretty immature and quite outdated nowadays, it did power one prototype in production and has a lot of the same concepts that we later used in Linear's sync engine.

[satvikpendem]

I simply eschewed a relational database and instead used a CRDT like Yrs, Loro, Automerge, etc as my main source of truth. The benefit is that they work well on mobile as well as every other platform, given they're all written in Rust.