Well, it has things like @Table and wants you to write SQL using Swift syntax. It's good that it lets you bypass this, but it encourages using the wrappers so I think that's going to be most of the usage. Also, if you're going to mostly bypass, then why incur the costs of adopting? The main bypass I saw was #sql, but while you can write SQL, it's a substantially different API than sqlite's C API to do the same.

One problem with data access wrappers is that what's both above it and below it have strong app concerns. The developer needs to understand and control what's below it, so an intermediate abstraction gets in the way. That is, in addition to understanding the lower-level, they also have to understand the intermediate abstraction, and how it maps to the lower level. So it's really best if the API surface is minimal.

What I would want is an API where the core is something like:

bindParameters(pStmt, anEncodableThing) readRowColumns(pStmt, ADecodableThing.Type) -> ADecodableThing

where pStmt would be as minimal a wrapper around a sqlite statement as is feasible (maybe even a pointer to a sqlite3_stmt directly?). There might be a minimal (non-existent?) wrapper around the sqlite3 connection too. (The sqlite pointer should be a public member of any wrapper, so you can call any sqlite3_ functions you want).

(I'd want some convenience methods too, that combine bindParameters and readRowColumns with preparing a statement and stepping through it, like sqlite's exec.)

Now, I know this doesn't address CloudKit sync at all, but I think a similarity minimal type-focused binding is best there too. It has nowhere near the 5-star API that sqlite has so there's a better argument for wrapping it, but sync tends to quickly accumulate app-level concerns when it comes to the exact details of sync conflicts, so you might as well keep that at app level. I think there maybe a set of composable convenience methods might do it, to handle the pain points without hiding the details you'll need access to.

Anyway, my point is NOT that sqlitedata is bad, it's that people should be really careful about taking on the costs that it has, and consider whether it will ultimately cause more problems than it solves. Meanwhile, sqlite is world-class -- you want to wrap it as little as possible.

World-class doesn’t help me if there is no off the shelf or easily made solution to CloudKit sync. Which hasn’t existed until SQLiteData.

(Previously I rolled my own sync with RealmSwift but that’s now dead.)

Without that, my only alternatives are SwiftData or CoreData, with severe downsides.