Goodbye, Manual State Notifications. Hello SwiftData

Tyler Hackbart — Mon, 22 Jun 2026 15:09:46 +0000

I've been carrying iCloud sync around in my apps for years, and for most of that time it was the part of the stack I dreaded touching. The setup was Core Data with NSPersistentCloudKitContainer, wired into a fairly traditional Model-View-Controller structure. It worked, eventually, but "worked" did a lot of heavy lifting in that sentence. SwiftData has changed how that part of my apps feels day to day, and I want to be honest about both what got better and what I gave up.

The old way: state was the hard part

The thing nobody tells you about Core Data plus CloudKit in an MVC app is that the persistence wasn't really the problem. The problem was state. My view controllers were responsible for knowing the current truth, but the truth could change underneath them at any moment because a sync had landed from another device. So I was constantly reconciling two ideas of "now": what the controller had loaded, and what the store actually held after CloudKit did its thing in the background.

That meant a lot of plumbing that had nothing to do with my actual app. I was listening for NSPersistentStoreRemoteChange notifications, refetching, diffing, and then telling the UI to reload. Half the time the reload was unnecessary and the whole screen flickered or scrolled itself back to the top for no reason the user could see. The other half it was necessary and I'd missed it, so a record showed up stale until the user backed out and came in again.

It felt like overkill, and that feeling was the tell. Refreshing the entire view every time a change came in was a sledgehammer, but doing anything more surgical meant hand-writing change tracking that I didn't trust and didn't want to maintain. The controller layer became the place where all of this anxiety lived. It knew about the store, the sync, the merge policy, the fetch, and the UI, and any one of those changing could break the other four.

The new way: a fraction of the code

The first thing that struck me moving to SwiftData was how much code simply disappeared. A model that used to be an .xcdatamodeld file, a generated NSManagedObject subclass, a fetch request, a fetched results controller, and the notification handling around it collapses into a single @Model class and a @Query in the view. Honestly it's somewhere around a fifth of what I used to write to get the same behaviour. The container setup that used to be a careful block of options is now a .modelContainer modifier with iCloud configured alongside it.

But the real change isn't the line count, it's that the state problem mostly went away. @Query observes the context and refreshes the UI when the underlying data changes, including changes that arrive from another device. The thing I used to hand-build, that whole remote-change-to-refetch-to-reload loop, is now just how the framework behaves. A record syncs in from my iPad and the list on my iPhone updates, and I didn't write a single line to make that happen. The first time I saw it work I genuinely didn't believe it had synced, because I kept waiting for the manual refresh I no longer had to trigger.

That's the part that feels almost magic compared to the old days. The UI staying in step with the store across devices used to be the hardest thing to get right, and now it's the default.

What I gave up, honestly

It isn't free. With the old setup I had complete control over the merge policy and exactly when and how the UI updated. SwiftData takes that control back in exchange for the convenience, and when something does go wrong, there's less surface area to reach in and fix it. The framework is younger, the edge cases around CloudKit are still rougher than the mature Core Data path, and I've hit sync quirks where my only real debugging tool was waiting and watching rather than inspecting.

I also lost some of the explicitness. When everything was manual, I could see the entire flow of a change from store to screen. Now a lot of that happens inside the framework, which is wonderful right up until you need to understand why a particular update didn't propagate. There's a real tradeoff between "I don't have to think about it" and "I can't see what it's doing."

Worth it anyway

For the kind of apps I build, it's been a clear win. The maintenance burden that used to sit in my controllers, all that state reconciliation that felt like overkill every time it fired, is gone, and it took most of the code with it. I traded fine-grained control for a system that mostly just keeps the UI honest across devices on its own. After years of fighting NSPersistentCloudKitContainer to get that, I'll take the trade. Turns out the secret to syncing state across all my devices was to stop managing it myself and just let SwiftData take the iCloud.

I'm Tyler Hackbart, the founder and developer behind Juice Box Monkey Designs, where I build indie iOS and macOS apps under the Just Apps name. Most of what I write comes straight out of whatever I'm currently shipping, like this one did. You can see what I'm building at juiceboxmonkeydesigns.com.

DEV Community: Tyler Hackbart

Goodbye, Manual State Notifications. Hello SwiftData

The old way: state was the hard part

The new way: a fraction of the code

What I gave up, honestly

Worth it anyway