> 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.

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.