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