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.

▲

mbw234 3 days ago | parent | next [-]

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.

▲

daveidol 3 days ago | parent | next [-]

I just want to say thank you for the great work you guys do! I honestly have no idea why people feel the need to tear you guys down.

Using TCA has been a great tool for me in my toolbox and it’s very clear how much time and effort goes into making these libraries, documentation, videos, online support, etc.

▲

rTX5CMRXIfFG 3 days ago | parent | prev [-]

This library is basically Swift/Core Data, just portable farther back in time. It’s not hard to point out where the reinventing the wheel is.

> 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

Or you can just wait a couple more platform updates instead of always being on the bleeding edge. Apple’s frameworks might not be perfect, but they’re quite exhaustive, and libraries that aim to fill in those gaps are offering diminishing marginal returns that would be unnecessary in 1-2 WWDCs.

I’m sure there are apps small enough to plan for short time horizons, but for companies who plan for their apps to run for half a decade or more, this is the sort of library that you’ll soon mark as tech debt and then refactor for removal when its approaches eventually make it to Apple’s own SDKs. The historical precedent is there.

> open source, and not a proprietary technology

Yea those are great virtues elsewhere but they stop becoming priorities the moment you pay for the license to develop for a walled garden and agree to its T&Cs

▲

wahnfrieden 3 days ago | parent | next [-]

> Or you can just wait a couple more platform updates instead of always being on the bleeding edge.

So your advice is to use CoreData until 2028 or so until we can terminate iOS 17 users and start using WWDC24 SwiftData.

And then maybe a few years from now (meaning usable by 2032) Apple fills SwiftData's gaps that SQLiteData meets today (ability to use it in background fetch tasks, scalable performance, usage outside of SwiftUI views, fast JSONB storage & querying, FTS) or has the capability to meet in the near future (sharing, public database etc.).

That's neither compelling nor industry standard, and is why so many businesses haven't adopted SwiftData and have moved on from CoreData.

It's the same reason PSPDFKit built up to a 9 figures business - no one wants to wait around for years and years for Apple to maybe incrementally improve PDFKit and also not provide any support, developer relations, or ability to fix a bug yourself.

▲

rTX5CMRXIfFG 3 days ago | parent [-]

What industry standard are you talking about? We literally have large financial institutions making more money than you running their systems on freaking COBOL. It _is_ common in the industry for organizations to hold off on newer technology because refactoring to the coolest new tech is too costly. Even Cocoa frameworks aren’t obsolete just yet, and it’s unlikely to be so for a long time.

Everything you just said is a dishonest excuse so that you can play with a new library using your company’s money and while letting them incur the additional risk of breakage or tech debt. Nothing is stopping you today from using Core Data to build an observable model or to partially adopt SwiftData just in the functionality that it can sufficiently cover.

	▲	wahnfrieden 2 days ago \| parent [-]
		No need for personal attacks. I don’t work for anyone. And you don’t know or understand my requirements to make such false claims.

▲

helge5 3 days ago | parent | prev [-]

If you think that this library is "basically Swift/Core Data", you have to learn more about "Swift/Core Data" and what it does, and why and how.

	▲	mbw234 2 days ago \| parent \| next [-]
		It persists data to disk in a manner that is easy to query. It allows observing changes to the data so that features update when necessary. It handles graphs of objects just fine thanks to recursive CTE's in SQLite. With a little bit of work it can handle historical edits with undo/redo. It seems to quack like Swift/Core Data to me, but bringing SQLite to the forefront instead of putting needless abstraction layers on top of it.
	▲	rTX5CMRXIfFG 3 days ago \| parent \| prev [-]
		There’s the cheap personal attack

▲

stephencelis 3 days ago | parent | prev | next [-]

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?

▲

rTX5CMRXIfFG 3 days ago | parent [-]

If you think that through, the answer is: of course! Take for example the move from Swift 1 to 2 (an extreme example but illustrates the point).

If you used a third-party lib written in Swift 1 and you had to move to Swift 2 because the next version of iOS requires the latter. Then you’ll have to wait for the lib developer to publish a version of their third-party lib for Swift 2 before you can publish your app. That’s the same kind of risk that you’re exposed to with source-breaking changes.

Admittedly, source-breaking changes have gotten less frequent in Apple’s major tooling updates, but the right mindset when developing for walled gardens like Apple is that it will happen again.

	▲	jen20 3 days ago \| parent [-]
		You appear to have unwittingly made an argument for why to use this library over SwiftData - here you can control your own destiny instead of waiting for bugs to be fixed in the OS frameworks and customers to update.

▲

wahnfrieden 3 days ago | parent | prev [-]

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.