[HN Gopher] Reinventing Core Data Development with SwiftData Pri...
___________________________________________________________________
Reinventing Core Data Development with SwiftData Principles
Author : fatbobman
Score : 23 points
Date : 2024-10-16 12:04 UTC (10 hours ago)
(HTM) web link (fatbobman.com)
(TXT) w3m dump (fatbobman.com)
| happytoexplain wrote:
| >After repeated deliberation, I had to make a tough decision:
| abandon the thousands of lines of SwiftData code I had completed
| and return to Core Data.
|
| The same story many experienced with SwiftUI vs UIKit. Apple has
| flubbed the move to declarative APIs hard. It's a scary
| experience committing to these APIs, because of the wild changes
| they experience, the performance issues, and the fact that they
| are borderline un-debuggable by the average mind compared to
| imperative APIs, so when you run into _real_ trouble, you 're
| often kind of just fucked. And it's not even like normal 1st
| party frameworks where the bug is virtually always in your code.
| With these, sometimes the bug really is Apple's.
|
| I wish these things didn't have "Swift" in the name, since their
| problems have nothing to do with the language as far as I can
| tell, and they make Swift look bad.
| TheJoeMan wrote:
| You hit the nail on the head, but if SwiftUI screws up, I catch
| that pretty easily. I am too scared to try SwiftData because
| schema migration is entirely on Apple's hands, and customer
| data loss is a bigger deal.
| floydnoel wrote:
| This is very helpful content. Since the announcement of SwiftData
| I have been contemplating updating our app from Core Data, as it
| seemed like a streamlined approach.
|
| Luckily, I had too many things to work on, so I didn't get around
| to it. I bookmarked this page for ideas the next time I have to
| deal with Core Data, thank you for the article!
| jmull wrote:
| > It's 2024--Is SwiftData Ready?
|
| No way.
|
| At least right now, SwiftData shouldn't used for anything but
| quick-and-dirty PoC's, demos, or other limited-use, low-stakes
| things.
|
| There are some good ideas in it, especially how it integrates
| with SwiftUI. But it's alpha quality right now.
|
| The article actually oversells SwiftData, IMO. I don't think it
| wasn't usable in iOS 17.
|
| And its concurrency story isn't great. E.g. if you want to do
| queries or other data access in the background, you'll need to
| create and maintain separate, Sendable variants of your models.
| Now, I get that SD is really a memory-based database (typically
| backed by sqlite), so you can probably do a lot right on the main
| thread, but you'll end up wanting to move some things for various
| reasons, and it's awkward and boiler-platey. Not to mention,
| models have a magical connection to containers. You can't see it
| directly, but try to instantiate a model without a container
| (for, you know, _preview_ -- a core feature of SwiftUI).
|
| There are also some creaky design decisions. On one hand, it acts
| like an ORM, that wants to persist an object graph. But it also
| leaks relational concepts all over the place. They probably
| should have picked one approach or the other... as it is, at
| every turn you have to figure out if they went relational or
| object graph, and program accordingly.
|
| Now, CoreData has it's own issues, and, I assume, Apple is no
| longer going to focus on it, so I'm not sure it's a good idea to
| use it either.
|
| Personally, I've just started using sqlite3. With that you've got
| all the speed, power, and reliability, and don't have to hope
| Apple doesn't blow up your project on each release.
|
| (I use some utilities to take the boiler plate out of passing
| Swift values as parameters and receiving Swift values as results.
| Other than that, you can just call the sqlite3 C API directly.)
| cageface wrote:
| GRDB is a nice Swift API for SQLite that doesn't try to do too
| much.
___________________________________________________________________
(page generated 2024-10-16 23:01 UTC)