Thank you (GRDB author here).

It is not mentioned in the README of the repository, but SQLiteData wraps GRDB to access the database and get notified of database changes (the meat and butter).

GRDB is by itself a solid "toolkit for SQLite databases, with a focus on application development", with both high levels APIs for everyday coding, and expert SQLite features for the demanding developers. Many apps rely on GRDB alone.

> though it doesn't have CloudKit support out of the box

There is no CloudKit support for GRDB available anywhere except for via this SQLiteData package

"Harmony" was an experiment in adding it to GRDB on iOS 17+ but reports claim that it's broken. SQLiteChangesetSync is another earlier experiment that is unmaintained

Are you suggesting SQLiteData is an ORM, or SwiftData? SwiftData (and CoreData) are certainly ORMs, but SQLiteData is not. It's simply a collection of tools on top of SQLite that provide similar functionality to SwiftData, but you always have direct access to SQLite.

The things you say that SQLite doesn't do is exactly what SQLiteData provides (Swift-friendly bindings for encoding and decoding data from SQLite), and more. There's a footprint, as there is with any library, but there is no ORM level of abstraction here.

How else will you support CloudKit with SQLite? Personally CloudKit is a requirement as my customers value having their personal data inside their own Apple account rather than storing it on my servers. I also rely on CloudKit to avoid the cost and on-call burden of operating a realtime sync service.

Re: ORM, the SwiftData-like ORM part of SQLiteData is actually completely optional. You can write SQL statements directly via #sql: https://swiftpackageindex.com/pointfreeco/swift-structured-q... You can wrap usage of this in your own method so that you can swap out SQLiteData in the future without lock-in.

Re: Swift types, you may roll your own mapping, but performance is not trivial. Here is a benchmark from SQLiteData:

Orders.fetchAll setup rampup duration

   SQLite (generated by Enlighter 1.4.10) 0        0.144    7.183

   Lighter (1.4.10)                       0        0.164    8.059

   SQLiteData (1.0.0)                     0        0.172    8.511

   GRDB (7.4.1, manual decoding)          0        0.376    18.819

   SQLite.swift (0.15.3, manual decoding) 0        0.564    27.994

   SQLite.swift (0.15.3, Codable)         0        0.863    43.261

   GRDB (7.4.1, Codable)                  0.002    1.07     53.326

> I want to be able to write raw SQL and have the compiler check that SQL for correctness and generate the proper bindings and types for using it.

Our library does allow this a little bit, in addition to a Swift API for building queries. You can write SQL as a string while still using the schema information exposed from the @Table macro. For example, a query to select all reminders lists along with a count of the reminders in each list:

    @Table struct RemindersList {
      let id: UUID
      var title = ""
    }
    @Table struct Reminder {
      let id: UUID
      var title = ""
      var remindersListID: RemindersList.ID
    }

    #sql("""
      SELECT \(RemindersList.title), \(Reminder.id.count())
      FROM \(RemindersList.self)
      LEFT JOIN \(Reminder.self) ON \(RemindersList.id) = \(Reminder.remindersListID)
      GROUP BY \(RemindersList.id)
      """,
      as: (String, Int).self
    )

I'm half of Point-Free and can answer your questions.

The fact that our library deploys back to iOS 13 is just our way of showing we care deeply about back deploying these tools so that anyone can use them. Certainly no one is deploying iOS 13 apps these days, but people definitely are deploying iOS 16 apps (and may be for another year or two), which has no access to SwiftData.

And investing time into learning a third party library is just the name of the game when one feels that the tools Apple provides do not suit their needs. Luckily our library mimics many of the patterns that one is used to with SwiftUI and SwiftData, but has the benefits of being based on SQLite, is open source, and not a proprietary technology.

And I'm not sure what wheel we are reinventing here. We feel most of our libraries are specifically filling holes that Apple has left open. We also don't do a ton of paid support with companies, but we certainly do answer dozens of questions on Slack, Twitter, GitHub discussion, etc, every day. All for free.

I think you're missing the point. iOS 13 is not the value proposition of the library, it's simply one small feature of comparison of many and isn't highlighted beyond a simple mention. The library provides just as much value if you are starting a new app today and choose to target iOS 26+.

> And with Apple's history of source-breaking changes over major platform updates, plus given how even huge libraries/tools like Alamofire, Realm, RxSwift, Cocoapods eventually succumbed to oblivion, I can't think of why an Apple developer with any modicum of discernment would choose PointFree's tools over Apple's own--unless they are themselves caught by the allure of reinventing the wheel.

Isn't this just a blackpilled take in general? You're complaining that Apple software breaks, that other third party software is discontinued, and this somehow leads to the conclusion to avoid this library?

The purpose is not iOS 13 (they perhaps should not place that in the lede). But even iOS 17 is hard to use swiftdata on, given indexes were not even added until 18. And many deploy still to iOS 17 or even 16. I don’t know why you see support for that as a suspicious negative.

But for me the draw is:

- Can use this outside SwiftUI views, unlike SwiftData

- Can adopt future improvements without waiting on annual release cycle + several more years until I can sunset older OS compatibility

- Performance: SwiftData has severe performance issues that are manageable with SQLite

- Cross-platform: SQLiteData depends on GRDB which is perhaps close to merging support for Android (and already supports Linux), at least as an experimental trait: https://github.com/groue/GRDB.swift/pull/1708 By using it with https://skip.tools I can deploy the same SwiftUI codebase to both iOS and Android. And with SwiftCrossUI I can target Windows, Linux too while reusing the same model/persistence layer code. Perhaps this will work in WASM too.

And lastly, many apps already choose to use SQLite. You can see several commenters here who use GRDB in their projects. This library adds CloudKit sync to that which has previously not existed outside of broken experiments or proprietary in-house solutions. The CloudKit capability is more relevant than a decision for whether to use declarative syntax.

Now that RealmSwift is dead, there are to my knowledge zero other alternatives to this new library and SwiftData/CoreData for a CloudKit-synced DB.

Re: pointfreeco I’m unfamiliar with their other work and have no interest in TCA. This library has no dependency on TCA and no lock in on the esoteric or paid parts of their ecosystem that I can see. Most of what it does is provided by GRDB, which has some level of community support and production adoption even from within Apple’s own frameworks (Apple ships GRDB inside of iOS & macOS!). Your comments there seem like fear-mongering and irrelevant to this project. I suggest evaluating this independent of any perceived baggage from their brand’s other work.

You’d be surprised; it depends on the scope of the last write wins register. If you do it granularly attribute by attribute, last write wins is fine for mostly-online mostly-realtime collaborative apps. The exception is (rich) text where you really want CRDT/OT/similar intention preserving merges of concurrent edits.

Heh, let’s see how you like Android and React