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.

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?

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?

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)

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 } }

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

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.

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

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

When a model object is saved its identifier is changed from a temporary one to a permanent one (so I assume the hash values also changes) so this is most likely what cases an issue here with the picker. One way to work around this is to call save() directly after the inserts.

Why not use the objects (Category) directly in the predicate since they conform to Equatable?

You haven't told us exactly what your issue is but something I spotted with your design that I don't think is correct is the relationship between Teacher and Student. As I see it your design will be simpler and more correct if you complete remove that relationship. A teacher holds (has) one or more classes A student attends (has) one or more classes So indirectly you have the relationship between Teacher and Student via the SchoolClass model. A bit unrelated but I prefer to use the @Relationship macro with the inverted argument for one of the relationship properties since it makes the code clearer for me (and it is also helpful for SwiftData)

Some will be easy to get like all teachers for a school but others will require a little more work. One important thing to remember is that you add relationships to define your models and how they relate and not for helping with some queries you might want to implement. That said, one further relationship to consider is between School and Student so that a student can only take classes that belongs to the school they are assigned to.

It looks much better but be careful with those delete rules, why do you want to delete the teacher and students if you delete a class? Both the teacher and students might be in other classes, right? I would use nullify in most cases an only use cascade if I know that was exactly what I wanted to do.

An easier solution is to wrap the string in a struct and use an array of that custom struct instead. Make sure the struct conforms to Codable. Ideally we should be able to have just an array of String but that isn’t possible currently