if you’re asking if there’s an automatic way then no there isn’t but doing this should be pretty straightforward, check if the move has already been done when the app starts and if not load the data from UserDefaults and store it using your SwiftData models.

I didn't notice Feature was a many-to-many relationship, I thought the array was owned by the Car/CarData object, my bad. There is really no point in making your models conform to Identifiable and have a custom id property since they already conform to this protocol (unless you have some specific reason to use your own identifier value). I have no idea if this could help with the duplicate Feature objects issue but maybe it could be worth trying by removing the id property and use the default one instead.

Your copy methods are in my opinion flawed, you create a new instance of the main object but you re-use the relationship object instead of making a new copy of that as well, so called deep copying. So in Car you should have func copy() -> Car { Car( name: "temporaryNewName", carData: carData.copy() //<-- New instance ) } And in CarData you need to do something similar but loop over the features array and copy each element. Perhaps unrelated but why do you need both Car and CarData, can't they be merged and personally I prefer to use the @Relationship property wrapper for my relationship properties to make the intention clearer

It still saves to disk by default, what has changed is when it saves. It used to be rather quickly but now as you mentioned it saves with a much larger delay or when the app quits or goes into the background.

A workaround is to store the Int value for MediaType in Media instead and use a computed property to switch between Int and MediaType @Model class Media { private var type: Int var mediaType: MediaType { get { MediaType(rawValue: type) } set { type = newValue.rawValue } } } //... } Which would give a predicate where we use Int values in the filtering static var predicate: (Predicate<Media>) { let image = MediaType.image.value let predicate = #Predicate<Media> { media in media.type == image } return predicate } Two other observations, you don't need a id property for your model, the @Model macro makes the type conform to PeristentModel that extends Identifiable so you already have that id property And secondly I would personally use an enum instead of a struct: enum MediaType: Int, Codable, Equatable, Hashable { case image = 0 case video case audio }

I believe you need to rethink your design then, you can't have a bunch of different operations that needs to be saved together spread over different actors. It's just not possible. Maybe work with struct's instead so you can pass them between actors and have only one central actor that converts from struct objects to model objects and handles the storing and saving of objects in a single transaction.

Do you have a question you want to ask?

One solution could be to actually call save() and then have a manual rollback function that when called would delete the object with a given id. That way you could hopefully avoid creating strong dependencies between your services (actors). Of course if there are cases that are more complicated than the one in your code that returns a single id a solution like this could easily become quite complex so it depends on your use case if this is doable.

Use an Array instead of a Set in your model, use Date instead of DateComponents as the element type. If using an array gives you warnings in the console similar to CoreData: fault: Could not materialize Objective-C class named "Array" from declared attribute value type "Array" of attribute named ... then you can wrap the Date property in a Codable structure and use that as a type struct ToDoDate: Codable { let date: Date } In model: var dates: [ToDoDate] = []

My guess is that this is because SQLite only support 64 bit integers so it won't work "out of the box" but require some extra work to store this type

But if you don’t like a movie anymore should a Friend or Movie really be deleted then, isn’t it the relationship that should be deleted/removed? Think about it…

How do you know T.ModelType has a property recordName?

I am pretty sure OP meant this particular sort descriptor

It makes no sense to sort against handlers.first (or at all against a to-many relationship) so I would remove this requirement

This seems like expected behavior to me and not a bug.