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 · 10m 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. And many deploy still to iOS 17 or 16. I don’t know why you see support going further back than that as a negative.
But for me the draw is:
- Can use this outside 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 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. This library adds CloudKit sync to that which has previously not existed outside of broken experiments or proprietary in-house solutions.
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. 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 · 38m 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 · 8m 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.
asdev · 38m 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 · 20m ago
Heh, let’s see how you like Android and React
asdev · 18m 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
scary-size · 45m 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 · 38m 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.
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 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 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. This library adds CloudKit sync to that which has previously not existed outside of broken experiments or proprietary in-house solutions.
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. 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.
It employs a „last edit wins“ strategy for conflict resolution, which is fine in my case. Obviously could be too basic for collaborative apps.