Reinventing Core Data Development with SwiftData Principles | Hacker News Reader

Reinventing Core Data Development with SwiftData Principles

fatbobman.com

37 pointsfatbobman27 comments

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

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.

I don't know about SwiftData, but my experience with SwiftUI is great. I've put a EU-sized project into production and it wasn't a problem at all.

In my experience, the trick is making small tested and working views, and combine these into fullly-fledged screens.

What is an EU-sized project?

SwiftUI’s problems are due to Swift in one respect. The way Swift’s type inference works plays very badly with SwiftUI view builders leading to very long compile times and many cases in which the compiler will just give up entirely and you’re left randomly commenting out bits of code.

That this is the best the richest company in the world can do with the API to their most valuable product is quite astonishing.

Sometimes I lament the fact that in Jetpack Compose, @Components don't return anything. They are all side-effecting functions, even though the view is supposed to be a function of the arguments.

But then I hit a "Unable to infer complex types" error in SwiftUI, and think maybe the Google folks got it right after all.

I much prefer the Flutter approach. Everything is a widget. It can lead to more nesting but the tooling, compilation times, and performance are great.

Given the amount of performance rants bashing Compose, probably not quite.

Are they even doing a release build?

Unfortunately debugging challenges aren't unique to SwiftUI. Having having your application code get buried underneath miles of framework magic in stack traces can also be experienced with Jetpack Compose.

Jetpack Compose has the benefit of being mostly open source. I can always crack open a misbehaving TextField to see what's going on underneath.

SwiftUI has the unfortunate combo of being closed-source, being platform-dependent, and being buggy in the most unusual ways. Which is a shame, because SwiftUI has a lot of good things going for it.

That's a great point and I agree, but it'd be nice if it weren't necessary to pop the hood to debug garden variety issues. The simplicity of UIKit in that regard is hard to beat.

What's incredibly annoying is that a lot of the SwiftUI components are just wrappers around the equivalent UIKit components (eg. ScrollView/UIScrollView), but are missing a lot of the functionality of the underlying components.

These should really be open source: it's such a waste of time to have to experimentally poke around to see how the SwiftUI components interact with their UIKit counterparts, when these should really just be straightforward wrappers.

In many cases, the declarative APIs are just poorly thought out and/or clearly not "battle tested", and there is a lot of API churn in really crucial components which are also often not backported to older OS versions.

> These should really be open source:

It's funny, when SwiftUI and Compose were coming out we waited a bit but jumped in as soon as we could. With Compose, our early versions required us to make builds of Android Studio on our own machines that supported it. But even then Compose felt more polished in a lot of ways - and if we ran into issues we could _see the code_ and make our own components with the changes we needed if necessary.

SwiftUI is great, really, but has so many rough edges, gotchas, and bugs. They do get fixed, but you're still supporting 4 year old versions of iOS without those fixes, so you're screwed.

Just completely boneheaded not to open source SwiftUI from the start, especially with how great the open source Swift community is.

Since it’s trivially easy to bridge a UI/NSView into SwiftUI, why don’t you do that? If you think of SwiftUI as a dumbed-down children’s toy box version of the grown-up’s tools, there’s nothing to complain about. It’s really better that way since UI/NSKit has so many footguns.

This is only true for the very simple cases you might see in an example snippet. If you need a UIView because you need access to some kind of imperative action (which is usually why you need a UIView), there is no channel for that. Declarative vs imperative are fundamentally incompatible when in the same abstraction layer. You have to use the kind of hacks you used to only see in "bad" codebases, like notification broadcast instead of delegated function calling.

Not sure I follow. Have you seen UIViewRepresentable? You can turn a UIView into a SwiftUI view in 5 lines of code. If you need to move state there is a two way bridge you can choose to implement called a Coordinator. It is a blank protocol with zero obligations to fulfill and only exists as convenient a reference type simultaneously accessible by both the UIView and the SwiftUI parent.

I can’t imagine how it could be implemented more simply.

Even if you are rendering a complex chain of compute shaders with multistage heap fences onto a process shared IOSurfaceRef with several concurrent threads greedily realiasing your scratch buffer to queue up more work, it doesn’t matter. Eventually you’ll up with a UIView or CALayer and it’s still just one function call to bring it into SwiftUI.

I don't see SwiftUI as a "dumbed-down children's toy box" at all -- SwiftUI is excellent conceptually. I am just frustrated that the "SwiftUI standard library" that Apple ships with it is so rudimentary, as if we didn't already have over a decade of prior art of how to implement declarative APIs for basic components.

The worst offenders by far are the scroll & list views, which are basically useless. As a starting point, there is no way to get the current scroll position from a scroll view in iOS <18.

So yes, I often have to wrap the UIKit components myself, and deal with all the joys of UIKit I was hoping to finally avoid...

Apple did exactly the right thing with Swift itself: the Swift forums are excellent, and it's clear that Apple employees use these to prioritize the (very real) Swift bugs and limitations. Why does this not exist for SwiftUI?

I agree with you, but I actually like UI/AppKit so I’m biased. The only “pure” SwiftUI components I trust are Button, Image, and Text. Everything else gets built out “old-school” and wrapped in a UIViewRep. It’s just so much easier that way. SwiftUI Lists are half baked. Sheets and popovers feel like they were implemented by a stoned intern that thought it would be funny to troll everyone.

In the not-distant past, Apple had beautiful software (OS/lang/frameworks) and sucky hardware.

In the present, Apple has beautiful hardware and sucky hardware.

No idea when they will get both beautiful hardware AND software.

(Frankly, I preferred good old, stable Objective-C - Apple ditched the KISS principle, when they adopted Swift).

I wrote an app tracking my location using the latest SwiftUI and SwiftData and the performance is so bad to the point it starts to stall the UI after just a few hundred data points. Apparently the magic of SwiftData + SwiftUI is only useful for making demos and anything beyond a few hundred data points wouldn't work out of the box. Everything is done on the main thread and offloading to non-main thread creates huge headaches and breaks the UI updates. It's almost as if the dev guys at Apple were just trying to hit their WWDC OKRs by releasing something so immature and useless for production. Even just reading/writing data to local, CoreData is two to three orders of magnitude faster than SwiftData in some cases. Their newly released core location APIs for getting location updates are also full of caveats and not useful for production at all. It seems that the teams are just focused on making good-looking Swift code using fancy new language syntax sugars.

Core Data is tricky to use properly to the point that I avoid it in all new projects and opt for GRDB, sqlite or json files instead. Core Data is one of the few technologies that once I learned it well, I disliked it even more. Putting a half-baked, leaky abstraction on top of it really doesn’t appeal to me. It’s also best to avoid any new developer tech from Apple for about 2-3 versions.

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!

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

GRDB is a nice Swift API for SQLite that doesn’t try to do too much.

https://github.com/groue/GRDB.swift

+1 for GRDB. One of the best open source iOS SDKs I've used. The one downside I've run into vs. Core Data is that sharing a database between multiple processes (e.g., your main app and a widget) is not as well supported (to be fair, the quirks around this are documented extensively and quite well).

That's OK, but there's still a lot of unnecessary/undesirable wrapping.

Reply on news.ycombinator.com