I wonder if Apple intends to add sharing to SwiftData? That would be neat, and helpful.

I started to migrate a personal project to SQLiteData, but the ergonomics are quite different, and my gut says that a first-party dependency is always a safer bet than a third-party dependency.

This situation says "intentional design decision" on the tin, but comes out feeling like "compromises" no matter what I choose.

@tonyarnold What do you mean by “sharing” in the context, CloudKit shared databases?
@helge aye.
@tonyarnold Quite likely to be added to SwiftData I assume. No particular reason why it couldn’t do that I think.
@helge no, I can't see why, either - it's just taking half a decade to build up the features from what we had in the past. Fairly typical for Apple, IMO.
@tonyarnold I was very surprised that SwiftData wasn’t a clean room implementation. Maybe they overvalued the need to interoperate with CoreData … or just politics 🙈

@helge I was surprised too! My assumption was politics, but we’ll probably never know.

It’s not ideal. So many sharp edges brought over from Core Data.

@tonyarnold "quite different" is polite. There are some overloads there that basically kill type inference for me.
@bok you're GRDB all the way, right? Even for small personal projects?
@tonyarnold all the ones where I started with SwiftData or SQLiteData I've hated it and come back to GRDB in the end. Well except one where I need CloudKit syncing.
@bok @tonyarnold Cries in Realm.
@timoliver @bok too soon, Tim, too soon
@tonyarnold show us on the doll where Realm hurt you, @timoliver
@bok LOL realm is trapped in here with @timoliver

@bok @tonyarnold Do you have any examples you can share of where type inference was impacted? Also worth noting that you can always write SQL strings still in a schema safe manner: https://github.com/pointfreeco/swift-structured-queries/blob/20db4a2a446f51e67e1207d54a23ad0a03471a7b/Tests/StructuredQueriesTests/SQLMacroTests.swift#L10-L18

That still leverages the static symbols of your schema but in a safe SQL string.

The type-safety and schema-safety in our query library has its tradeoffs. We want people to be able to write safe SQL queries, but it often seems like Swift's variadic generics are not up for the job.

Also worth noting that SwiftData's #Predicate breaks down even sooner and more spectacularly from our experience. It's just a hard problem to solve, and that's why we expose an API for safe SQL strings.

swift-structured-queries/Tests/StructuredQueriesTests/SQLMacroTests.swift at 20db4a2a446f51e67e1207d54a23ad0a03471a7b · pointfreeco/swift-structured-queries

Truly type-safe SQL. Contribute to pointfreeco/swift-structured-queries development by creating an account on GitHub.

GitHub
@tonyarnold My experience is that opting for GRDB early on leaves one mental space to “solve sync” on the server and room to spare for features like “let users export their own stuff and do whatever they want” 😅. SwiftData is a good choice as in-memory model for use cases where persistence is not really needed (e.g. you’re downloading everything or it’s just runtime user created data)
@tonyarnold The 1st party over 3rd party refrain is common in our community, but over time it just doesn't seem to hold water. Apple's frameworks have all the same problems that 3rd party frameworks have, but even moreso. They've been abandoned and deprecated over time with no warning, and they are updated on a once-per-year schedule. Heck, the only update SwiftData has had in 1.5 years is adding inheritance for models, so I won’t be holding my breath for iCloud sharing to be added anytime soon 😅