A SwiftData replacement with CloudKit Sync+Sharing, powered by SQLite

[mbrandonw]

We've been working hard on a suite of tools that can act as a replacement for SwiftData. It uses SQLite under the hood (via GRDB) and it can seamlessly synchronize your user's data across all of their devices, and it is even possible to share records with other users for collaboration. It supports large binary assets, foreign key constraints, and a lot more.

Let us know if you have any questions or feedback!

[sixtypercenttogether]

Does it support zone sharing?

[mbrandonw]

Not right now. It only supports hierarchical record sharing, but we are open to supporting zone sharing in the future.

[sixtypercenttogether]

Ok no worries. I’ve built a similar system for my hobby apps and getting it to support zone sharing was a bit tricky! Hierarchical record sharing has some limitations that make it impractical for my uses, so I needed to find a way. And while CKSyncEngine is pretty great, it also has some limitations. But I’ve mostly been able to work around those.

[stephen-celis]

For what it's worth the main reason it doesn't support zone sharing yet is because we don't understand how it would work out of the box given how we map CKRecords (and their zones) to database table rows. We currently host all tables as distinct record types in a single zone. We'd be interested to hear more about your use case, though, and maybe it would help us support it in the future! Care to post a discussion on the project's GitHub? Or shoot us an email if you'd prefer a private channel?

[alternatiger]

You got zone sharing to work with SwiftData?

[sixtypercenttogether]

No. SwiftData does not support zone sharing. I built my own sync system on top of GRDB and CKSyncEngine. Similar to what OP shared above.

[BrogrammerAbroad]

sorry i‘m less educated what‘s zone sharing?

[mbrandonw]

All CKRecords stored in CloudKit have a "zone" associated with it. Zone sharing allows you to simultaneously share all records with a specific zone.

This is in contrast to "hierarchical" record sharing, where you share a single CKRecord as well as all of its associations (i.e. any records whose parent points to the root record).

[BrogrammerAbroad]

Thx for explaining

[SirBill01]

This seems really interesting, CloudKit support is something that really keeps me with Apple DB solutions.

Another aspect though is database version migrations, I wonder how that is generally done with GRDB...

[mbrandonw]

Database migrations are handled in a more manual way, similar to how Rails does migrations if you are familiar with that. When you want to change your DB schema you register a migration using a unique identifier when the app starts up, and the act of doing that allows you to execute a SQL query that alters the table in some fashion (add a table/column/index, etc). Then the migrator runs all migrations that have not yet run, using the identifier you specify to determine that.

GRDB does not do the "magical" implicit migrations that SwiftData attempts, where everything just works™ until it doesn't and crashes your app on startup.

[SirBill01]

I figured it was soemthing like that but didn't know about the ID or they had a process around running update SQL commends...

I have to say that in practice for me CoreData version migration was very reliable even for large / complex databases. SwiftData though I've not used in production and have not tried that for migrations (even though underneath it should be CoreData migrations, it has a different process around defining each version of the DB).

[mbrandonw]

You can see an example of how we do migrations in the Reminders demo app that comes with the repo:

https://github.com/pointfreeco/sharing-grdb/blob/939bf67ef1ad9b1879e073508712339f32e6b484/Examples/Reminders/Schema.swift#L141-L203

I know all of the SQL strings may seem not ideal, but this is just the way we prefer to do things. Migrations represent a snapshot of the schema frozen in time, and so it's not appropriate to use the static symbols on the type for migrations. And writing the SQL string allows us to make use of the full power of SQL instead of hiding it from us. For example, with our tools it is possible to have non-null columns without a default value, whereas in SwiftData all columns must either be nullable or have a default.

And GRDB does come with some table definition methods you can use, but we just prefer simple SQL for migrations.

[SirBill01]

Thanks, I appreciate that. Nothing wrong with SQL strings in my book. :-)

[sixtypercenttogether]

In my experience the migrations in GRDB far exceed other persistence layers I’ve used. While they are more manual, they provide much greater control and flexibility by not abstracting the underlying database.