Maybe it's that I've been locked up at home for over a year, but my pre-WWDC predictions and desires have been front of mind earlier than usual.

Ever since Swift shipped, I've wrongly predicted each year that this would be the year we would get a replacement for Core Data.

At the risk of being wrong again, here are some reasons I think that this year (or next year, definitely next year) will be the year of Core Store - or whatever the framework is that will replace Core Data.

If you're an iOS developer who has never written a Mac app, you may not know that at one time you could scaffold a lot of your development using graphical tools.

You could use Interface Builder (later Storyboards or XIBs in Xcode) to create your visual elements.

For the past sixteen years you could use Core Data to create your model layer for in memory models or models that are persisted to disk.

"But Daniel," you say, "we can do that on iOS."

Yes, but there's a third piece you couldn't use: Cocoa Bindings.

In fact, you could use a graphical tool to connect the gui elements you created with IB to the model objects you created with Core Data.

When it worked, it was great. When it didn't, debugging was a nightmare.

But the result was that we had these different tools and frameworks for the three main components of our apps that we architected using Apple's take on Model-View-Controller.

OK - with that background let's turn to today and what I see happening. To be clear, I don't see Core Data going away in the same way that UIKit and AppKit didn't disappear when SwiftUI came on the scene.

But...

Core Data is not Swift friendly.

Core Data is designed to persist object graphs. Items that are stored are NSManagedObjects.

In Swift, we tend to use value types for our model instances when we can.

In SwiftUI we now use value types for our views as well.

Swift and SwiftUI are clearly the future of development on Apple platforms.

If you've been watching the Swift Evolution forums lately you've noticed that the long anticipated and discussed asynchronous support in Swift has moved to the forefront.

Core Data is not friendly to value types, asynchronous code, multi-threading, or even Optionals.

Sure, we can get it to do what we need it to do - but just as Swift and SwiftUI are modern rethinking of what we need in a language and a visual framework given today's needs and knowledge, the time feels right to do so for our model layer as well.

"But Daniel," you object, "if the view are value types and the model is made up of value types - what changes in our application?"

That's where the graphic from James Dempsey's classic song "MVC" comes to mind.

You have the two hard cookies of View and Model with the cream-filling in between representing the controller layer.

In SwiftUI this is enabled with property wrappers. @State allows us to treat value typed properties as if they are reference types. @Binding allows us to connect to someone else's value type property and change it and react to changes. In addition we can connect to @ObservableObjects and be notified of changes.

In my own apps I end up with something like a View Model - which, of course, was originally built on the notion of bindings at Microsoft.

Combine also allows us to process changes to data to transform the individual pieces into the shape we want to display to the user.

These property wrapped elements and Combine pipelines are our bindings.

Once Combine and SwiftUI get revised to support our asynch future, we're set for a new take on how we persist, update, and retrieve values.

I have no idea if it's coming, what it will look like, or what it will be called, but the single flow of data that Apple has been promoting in the SwiftUI data flow examples are similar in spirit to redux or elm-like systems.

That's why I imagine a Core Store that plays the role of the store in those systems.

Maybe, like @ObservableObjects, the store itself will be a reference type but what it stores can be value or reference types.

In addition, in the last half-dozen years Core Data has gotten much easier to set up and query. I imagine those lessons will come to Core Store with sensible defaults in the same way that autolayout and sensible defaults came to SwiftUI.

I also imagine that just as the truth of our SwiftUI GUIs live in code that are reflected in visual tools, the truth of Core Store will live in code with a tool that makes it possible for us to visually edit our data graphs. Instead of Core Data generating class files, our swift files will be reflected in the Core Store tool.

Why this year?

Async/await and asynch/await for sequences have both been implemented and are queued up to be part of Swift Next - which I assume we'll see at WWDC.

Why not this year?

There is a lot more of the asynch proposals that haven't landed yet. Maybe this will need to wait a year until those are released and better tested.

Anyway - that's my first thought on what we might see at WWDC 2021.

(Note - Paul Hudson makes the excellent point that a more consistent and sensible name would be SwiftData.)