This is not the most coherent post... mostly wanted to start a discussion about persistence and the future of CoreData, especially in the context of SwiftUI.
This has probably been the most exciting year for me since the initial release of Swift. When SwiftUI was announced at WWDC I literally screamed for a minute out of sheer joy and excitement. Adding on top of SwiftUI Apple releasing great frameworks like Combine, CryptoKit and adding support for websockets, Swift and iOS development has never been better!
Apple, already having pushed for the use of structs (when possible and applicable) over classes as default type for eg models, have really emphasized the need for structs in SwiftUI. In order for UI to update, models needs to be structs. And for ease of use with List (replacement of UITableView for those of you who haven’t begun the SwiftUI transition), our structs should conform to Swift 5.1 new protocol Identifiable.
How does CoreData fit into this new patterns? It doesn’t. We need to manually code support for conversion between structs and classes. Which for nested types become tedious.
Yes sure the are many third party libraries working with structs conforming to Codable. But since Apple recently released their own library for reactive programming (Combine) and updated crypto methods releasing it as a new own framework (CryptoKit) and themselves support Websockets etc, and since CoreData already exists (built on top of SQLLite?) it feels like it would make sense for Apple to make it easy to support persistence in our SwiftUI apps?
Firstly, it’s not up to us to decide which frameworks Apple should build - if you want a persistence package, you can build one or use one of the many community packages (e.g. GRDB).
Secondly, CoreData is not just a persistence/ORM framework. It’s an object graph management framework, so it necessarily requires classes for many of its features.
Is it so crazy to think that some person in Swift Forum works at Apple? No of course it is not up to us to decide.... But I was trying to see if other people would be interested in an Apple provided or Swift community provided "official" persistence solution which works nicely alongside SwiftUI, removing the need to create a class variant for all structs.
And yes I know of GRDB, it is probably one of my first choice to go with. ObjectBox also seems pretty good. Earlier I've used Disk.
Regarding what CoreData is, the very first sentence in Apple Docs: "Persist or cache data and support undo on a single device", and second subtitle is "Persistence", so surely it is used for persistence. I'm not saying you are incorrect of course, calling it a "object graph management" might be even more precise, but it would be strange to say that it is not a persistence framework.
Indeed these forums are not a good place for discussing Apple plans. Yet discussing the needs of developers who need a persistence layer which integrates well with SwiftUI sounds valid to me. After all, not only Apple people can profit from such discussion, but all Swift developers as well.
I, personally, author of GRDB, would gladly welcome ideas, suggestions, interesting use cases. When Apple eventually ships a Swift successor of Core Data, GRDB will be sherlocked. Meanwhile, we developers do need to work - and work with well-suited tools, if possible. All those discussions could surely happen in the GRDB sub forum. But there's no reason why this particular library should be the only one to profit from community brainstorming.
Core Data is a framework that you use to manage the model layer objects in your application. It provides generalized and automated solutions to common tasks associated with object life cycle and object graph management, including persistence.
Persistence is one feature, but very far from everything that CD does. The design of CD necessarily requires classes, and a Swift equivalent would likely look entirely different. That’s probably better as a community project. People generally expect Model-Layer code to be cross platform these days.
And as Xiaodi says, SwiftUI is not „official“ and has no special status whatsoever in the open source project. It’s an Apple framework for Apple‘s own platforms.
ObservableObject can also participate. And NSManagedObject conveniently conforms to that.
So you can just use @ObservedObject let data: ... instead of @Binding. One caveat is that NSManagedObject triggers update when context successfully save.
On this particular topic, I have to say that I still haven't found a way, using public APIs, to reproduce such pattern. SwiftUI gives to the FetchRequest property wrapper the managed object context stored in the environment, so that it can access the Core Data storage. I've been struggling to reproduce such a behavior. This makes me think that Core Data indeed has a better SwiftUI integration than other persistence frameworks today.
I think you're mixing two different things here. The "models" you refer to in a SwiftUI context are view models, not domain models. While it's tempting to reuse domain models as view models, keeping them separate will pay off in the long run.
For example, you may have a User class to represent a user, and a UserViewModel struct to represent the data you display on the user's profile screen. Even though these types are similar and share many properties, you should view them as entirely different things.
if you'd already adopted this separation of domain model vs. view models, switching from UIKit to SwiftUI shouldn't affect your persistence code at all, since you're persisting domain models, not view models.
That being said, it's safe to assume Apple wants to make the most of their pretty new language and may be working on (or at least thinking about) an updated persistence framework. But if and when that'll be released is for them to know and for us to find out about at WWDC
Apple made it clear that they are using "experimental" Property Wrapper API, which include "Referencing the enclosing 'self' in a wrapper type".
I guess it gave them far more power to create advanced property wrappers.
