When you first start playing with SwiftData, it feels like magic. You just slap the @Model macro on a class, and suddenly your data persists across app launches. It's tempting to treat these models like regular Swift classes, but that's where most developers trip up. I've seen a lot of people build their initial schemas naively, only to realize three weeks later that their database is a mess of duplicate entries and orphaned records.

The "Just Make it Work" Model

Let's say we're building a personal library app. The naive approach is to define your models as simple containers. You'd probably create a Book and an Author class, link them with a simple property, and call it a day. It looks something like this:

@Model 
class Author {
    var name: String
    var books: [Book]
    
    init(name: String) {
        self.name = name
        self.books = []
    }
}

@Model 
class Book {
    var title: String
    var author: Author?
    
    init(title: String) {
        self.title = title
    }
}

On the surface, this is fine. But here is where it breaks: data integrity. In this setup, if you add a book by "Stephen King" and then add another book by "Stephen King," you'll likely end up creating two separate Author objects with the same name. SwiftData doesn't automatically know that "Stephen King" in record A is the same person as "Stephen King" in record B. You've just introduced redundancy into your store, which makes searching, filtering, and updating your authors a nightmare.

Enforcing Uniqueness and Managing Lifecycles

To fix this, we need to move away from "simple containers" and start thinking about the model as a database schema. The first tool in your kit is the @Attribute(.unique) modifier. By marking a property—like an ISBN for a book or an email for a user—as unique, you tell SwiftData to perform an "upsert" (update or insert). If you try to insert a book with an ISBN that already exists, SwiftData will update the existing record instead of creating a duplicate.

Then there's the problem of "ghost" data. In the naive example above, if you delete an Author, what happens to their Book objects? By default, they might just hang around in the database with a null author reference. Depending on your app, that's either a memory leak of sorts or just useless clutter. I prefer to be explicit about these relationships using the @Relationship macro.

Here is how I would actually structure these models for a production app:

@Model 
class Author {
    @Attribute(.unique) var name: String
    // If the author is deleted, we want their books deleted too
    @Relationship(deleteRule: .cascade, inverse: \Book.author) 
    var books: [Book] = []
    
    init(name: String) {
        self.name = name
    }
}

@Model 
class Book {
    @Attribute(.unique) var isbn: String
    var title: String
    var author: Author?
    
    init(isbn: String, title: String) {
        self.isbn = isbn
        self.title = title
    }
}

The Trade-off: Flexibility vs. Rigidity

You might wonder why we don't just make everything unique or cascade every delete. There's a cost. Unique constraints add a small amount of overhead because SwiftData has to check for existing values before every insert. More importantly, .cascade deletes are dangerous. If you accidentally delete a "Category" model that is linked via cascade to a thousand "Product" models, those products are gone instantly.

I usually suggest starting with .nullify (the default) unless you are absolutely certain that the child object cannot exist without the parent. In our library example, a book cannot logically exist without an author in our system's context, so .cascade makes sense. But if you were linking a Book to a Genre, you'd use .nullify—because deleting the "Sci-Fi" genre shouldn't wipe out every Sci-Fi book in your library.

📋 Practical Task

Implement a Unique Recipe and Ingredient Schema

You are building a Recipe Manager. Your goal is to create two SwiftData models, Recipe and Ingredient, that prevent data duplication and handle deletions cleanly.

• Create a Recipe model with a title and a recipeID. The recipeID must be unique to ensure no duplicate recipes are added to the store.
• Create an Ingredient model with a name and quantity.
• Establish a relationship where one Recipe has many Ingredients.
• Configure the relationship so that if a Recipe is deleted, all of its associated Ingredients are also automatically deleted from the database.
• Ensure the Ingredient model has a reference back to its Recipe.