The abstractions you build your code on top of can be very costly, and a lot of that cost is due later.
You need to carefully weight the costs of abstractions you adopt. That goes double (or triple or quadruple) for data access, which is typically the central point of an app.
When sqlite is involved, I'm really doubting an ORM is worth it in the great majority of cases.
That's because sqlite is robust, mature, full-featured, very well documented, has demonstrated long-term viability, has a commitment to backwards compatibility and support, etc. I think it makes the most sense to implement an application-level data-access layer and have it use sqlite as directly as possible.
What sqlite doesn't do that an app needs is dealing with Swift types. I.e., the grunt work of the sqlite3_bind_* and sqlite3_column_* calls to transform Swift values to and from sqlite3 values. (And to a lesser extent, various Swift-isms for quality of life.) But you can have that without the rather more intrusive footprint -- and therefore much higher cost -- of an ORM.
rTX5CMRXIfFG · 1h ago
I find "Fast lightweight replacement for SwiftData that can target all the way back to iOS 13" (when SwiftUI came out I think) to be such a hard sell. How many businesses are there that must absolutely (1) run their apps on iOS 13; (2) use declarative syntax for data persistence; and (3) are profitable enough to invest time and effort on learning a third-party library for a really old OS? It sounds like an overly specific use case.
In general though, I'm not sure who finds PointFree's work a net positive investment of resources, but the company seems to be in the business of reinventing the wheel and locking you in so that you'll pay for support. Meanwhile, Apple's own SDKs are free. 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.
wahnfrieden · 51m ago
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.
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.
mikeocool · 1h ago
GRDB/GRDB-Query (https://github.com/groue/GRDB.swift) is another solid library worth looking at if you're looking for libraries in this space, though it doesn't have CloudKit support out of the box.
The more SwiftData alternatives the better -- as it has a lot of rough edges, and Apple hasn't invested much in it since it's initial launch.
groue · 49m ago
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.
mikeocool · 35m ago
Oh hi -- Thanks for your work! Just finished replacing SwiftData in an app with GRDB and it was a pleasure to use.
After struggling with some issues in SwiftData, GRDB really hits the nail on the head in terms of providing a solid dev experience for the common cases, but allowing you to drop into the more advanced features when you need them.
groue · 17m ago
You're welcome :)
jparishy · 8m ago
Used GRDB many times in a previous life, thank you very much for your work
wahnfrieden · 4m ago
> 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
asdev · 1h ago
Unrelated, but as a backend dev who recently worked in Swift/SwiftUI to build an app, the iOS developer experience is absolutely horrendous
rTX5CMRXIfFG · 1h ago
Heh, let’s see how you like Android and React
asdev · 59m ago
React Native is actually quite good at this point, I've worked with it pretty extensively before doing a native app. I prefer it so I don't have to deal with iOS stuff directly
wahnfrieden · 17m ago
What would you use from RN to achieve CloudKit sync? I haven't seen anything notable.
Many users value iCloud sync because it keeps their data private to their own Apple account, without having to share access to their data with the app developer's servers.
scary-size · 1h ago
Love it! Not an iOS dev, but have built a personal app that I want to publish for macOS too. I built on top of SQLite, but didn’t want to tackle the synchronisation yet. That should solve it.
It employs a „last edit wins“ strategy for conflict resolution, which is fine in my case. Obviously could be too basic for collaborative apps.
jitl · 1h ago
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.
You need to carefully weight the costs of abstractions you adopt. That goes double (or triple or quadruple) for data access, which is typically the central point of an app.
When sqlite is involved, I'm really doubting an ORM is worth it in the great majority of cases.
That's because sqlite is robust, mature, full-featured, very well documented, has demonstrated long-term viability, has a commitment to backwards compatibility and support, etc. I think it makes the most sense to implement an application-level data-access layer and have it use sqlite as directly as possible.
What sqlite doesn't do that an app needs is dealing with Swift types. I.e., the grunt work of the sqlite3_bind_* and sqlite3_column_* calls to transform Swift values to and from sqlite3 values. (And to a lesser extent, various Swift-isms for quality of life.) But you can have that without the rather more intrusive footprint -- and therefore much higher cost -- of an ORM.
In general though, I'm not sure who finds PointFree's work a net positive investment of resources, but the company seems to be in the business of reinventing the wheel and locking you in so that you'll pay for support. Meanwhile, Apple's own SDKs are free. 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.
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.
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.
The more SwiftData alternatives the better -- as it has a lot of rough edges, and Apple hasn't invested much in it since it's initial launch.
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.
After struggling with some issues in SwiftData, GRDB really hits the nail on the head in terms of providing a solid dev experience for the common cases, but allowing you to drop into the more advanced features when you need them.
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
Many users value iCloud sync because it keeps their data private to their own Apple account, without having to share access to their data with the app developer's servers.
It employs a „last edit wins“ strategy for conflict resolution, which is fine in my case. Obviously could be too basic for collaborative apps.