You don’t need to use the @Attribute macro for your properties at all unless you want to give them some custom behavior.

The same. Just make sure you always initialize the to-many properties to an empty array as you have done in your example

Initializing the ModelContainer in an onAppear of a view is too late, you need to do it directly in MyApp where yo declare the property itself.

You could enable Core Data debug logging (also used by SwiftData) to see if that gives you any important information, see https://www.hackingwithswift.com/quick-start/swiftdata/using-launch-arguments-to-debug-swiftdata-and-core-data

You could make the model properties private and rename them and then add computed properties with the old name that you can access from outside the class. var someString: String could be replaced with private var someStringStored: String? var someString: String { get { someStringStored ?? "" } set { someStringStored = newValue } }

I'm writing some tests to confirm the behavior of my app, you are actually unit testing SwiftData and not your app. As for the problem, I am not sure it's a bug and that they deliberately keep the object in the ModelContext for a short while to avoid problems for the app using it. The following test would pass though #expect(result.isDeleted)

I tried to reproduce on a iOS 18.4 large but failed, which isn't that surprising given how little information you have provided. Could you add enough context and code so we can reproduce this issue?

Maybe the underscore in the property name is causing an issue, could you try with a different name? And shouldn't that property be private so you can only access the relationship in one way?

A crash and a thrown error are two completely different things and you can not replace a crash with a thrown error with the exception of if you are deliberately crashing by calling fatalError(_) but I very much doubt that is what is happening here.

You are going to need to include relevant code and/or a more detailed description of how this happens if you want us to be able to help you

SwiftData does it automatically for you and it must do it or the autosave functionality wouldn't work. If you would only save one side of a relationship then when the app is restarted the other side would be nil or it crashes if the property is non-optional.

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.