First Things First

Before we dive into creating a sort menu, we need to have something to sort. First, we'll create a simple SwiftData model and some helpers. (I've written a separate article on how I tend to work with SwiftData in previews, so I'll skip most of the details.)

import Foundation
import SwiftData
import UIKit

@Model
final class ToDoItem: Codable {
    private enum CodingKeys: CodingKey {
        case name
        case done
        case dueDate
        case creationDate
    }

    var name = ""
    var done = false
    var dueDate: Date?
    let creationDate = Date.now

    init(name: String = "", done: Bool = false, dueDate: Date? = nil) {
        self.name = name
        self.done = done
        self.dueDate = dueDate
    }

    required init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        name = try container.decode(String.self, forKey: .name)
        done = try container.decode(Bool.self, forKey: .done)
        dueDate = try container.decodeIfPresent(Date.self, forKey: .dueDate)
        creationDate = try container.decode(Date.self, forKey: .creationDate)
    }

    func encode(to encoder: Encoder) throws {
        var container = encoder.container(keyedBy: CodingKeys.self)
        try container.encode(name, forKey: .name)
        try container.encode(done, forKey: .done)
        if let dueDate {
            try container.encode(dueDate, forKey: .dueDate)
        }
        try container.encode(creationDate, forKey: .creationDate)
    }
}

@MainActor
final class PreviewModelContainerProvider {
    static let shared = PreviewModelContainerProvider()

    private let toDoItems: [ToDoItem]
    let modelContainer: ModelContainer

    var modelContext: ModelContext {
        modelContainer.mainContext
    }

    var toDoItem: ToDoItem {
        guard let item = toDoItems.first else {
            fatalError("There is no data loaded")
        }
        return item
    }

    private init() {
        let configuration = ModelConfiguration(isStoredInMemoryOnly: true)
        do {
            modelContainer = try ModelContainer(for: ToDoItem.self, configurations: configuration)
        } catch {
            fatalError("Could not create ModelContainer")
        }

        guard let previewData = NSDataAsset(name: "ToDoItemPreviewsData")?.data else {
            fatalError("Preview data not found")
        }

        do {
            toDoItems = try JSONDecoder().decode([ToDoItem].self, from: previewData)
            for toDoItem in toDoItems {
                modelContext.insert(toDoItem)
            }
        } catch {
            fatalError("Could not decode preview data")
        }
    }
}

Here, we have a JSON file with the stub data that we need to add to our Preview Assets.

[
    {
        "done": false,
        "name": "Buy groceries",
        "creationDate": 746172000
    },
    {
        "dueDate": 746258400,
        "name": "Walk the dog",
        "done": true,
        "creationDate": 746085600
    },
    {
        "dueDate": 746344800,
        "creationDate": 745999200,
        "done": false,
        "name": "Read a book"
    },
    {
        "name": "Complete homework",
        "done": true,
        "creationDate": 745912800
    },
    {
        "done": false,
        "dueDate": 746517600,
        "name": "Call mom",
        "creationDate": 745826400
    },
    {
        "dueDate": 746604000,
        "done": true,
        "name": "Pay bills",
        "creationDate": 745740000
    },
    {
        "done": false,
        "creationDate": 745653600,
        "name": "Schedule dentist appointment"
    },
    {
        "dueDate": 746776800,
        "name": "Clean the house",
        "creationDate": 745567200,
        "done": true
    },
    {
        "creationDate": 745480800,
        "done": false,
        "name": "Exercise",
        "dueDate": 746863200
    },
    {
        "name": "Prepare dinner",
        "done": true,
        "creationDate": 745394400
    }
]

The last thing we need to do is create a simple UI to display our data. Let's create a list with rows presenting all the information that each ToDoItem contains.

import SwiftData
import SwiftUI

struct ToDoItemRow: View {
    private let toDoItem: ToDoItem

    init(for toDoItem: ToDoItem) {
        self.toDoItem = toDoItem
    }

    var body: some View {
        Button {
            toDoItem.done.toggle()
        } label: {
            HStack {
                Image(systemName: toDoItem.done ? "checkmark.circle" : "circle")
                    .font(.title)
                VStack(alignment: .leading) {
                    Text(toDoItem.name)
                        .font(.headline)
                        .strikethrough(toDoItem.done)
                    HStack {
                        LabeledContent("Creation date") {
                            Text(toDoItem.creationDate.formatted(date: .long, time: .omitted))
                        }
                        LabeledContent("Due date") {
                            Text(toDoItem.dueDate?.formatted(date: .long, time: .omitted) ?? "-")
                        }
                    }
                    .font(.caption2)
                }
            }
        }
        .buttonStyle(.plain)
    }
}

struct ContentView: View {
    @Query
    private var items: [ToDoItem]

    var body: some View {
        NavigationStack {
            List {
                ForEach(items) { item in
                    ToDoItemRow(for: item)
                }
            }
            .navigationTitle("To Do")
        }
    }
}

#Preview {
    ContentView()
        .modelContainer(PreviewModelContainerProvider.shared.modelContainer)
}

With all that in place, we have a solid foundation to continue our work. Let's dive in!

Brace Yourselves - Sorting Is Coming

As you may have noticed, every time our app (or rather the preview) reloads, the data is presented in a different order. This is because each time we load our data in the preview helper, it creates new entries in memory, and we haven't specified any sorting for our @Query. We can fix that really quickly.

@Query(sort: [SortDescriptor(\ToDoItem.name)])
private var items: [ToDoItem]

Much better, we no longer have a random element, even in our previews. However, we want to allow users to change the sort parameter and order dynamically. This is a bit trickier, as we can't just create a @State with our sort descriptors. We need to extract the @Query to a separate View and feed it with our dynamic sort descriptors.

struct ToDoItemsListing: View {
    @Query
    private var items: [ToDoItem]

    init(sort sortDescriptors: [SortDescriptor<ToDoItem>]) {
        _items = Query(
            sort: sortDescriptors,
            animation: .default
        )
    }

    var body: some View {
        List {
            ForEach(items) { item in
                ToDoItemRow(for: item)
            }
        }
    }
}

struct ContentView: View {
    var body: some View {
        NavigationStack {
            ToDoItemsListing(sort: [SortDescriptor(\.name)])
                .navigationTitle("To Do")
        }
    }
}

That's it! We can now easily and dynamically change the sorting. However, there is one caveat: we can't sort by the done property of our ToDoItem. This is because Bool doesn't conform to the Comparable protocol. Luckily, that's a really simple fix.

import Foundation

extension Bool: Comparable {
    public static func < (lhs: Bool, rhs: Bool) -> Bool {
        !lhs && rhs
    }
}

Now, all properties of our model can be used for sorting. We can dynamically change SortDescriptors, so we are ready to give users control over the order in which the application presents data.

Trust Me, I'm a User

Before we give users control, we need to make sure all the gears are ready for that. We want users to be able to choose between the properties of our model. This sounds like a task for some enum. Let's create one for our ToDoItem. Of course, a simple enum is not enough; we need something more, like some form of SortDescriptor provider.

extension ToDoItem {
    enum ToDoItemSortDescriptorProvider {
        case name
        case done
        case dueDate
        case creationDate

        var sortDescriptors: [SortDescriptor<ToDoItem>] {
            switch self {
            case .name:
                [SortDescriptor(\.name)]
            case .done:
                [SortDescriptor(\.done)]
            case .dueDate:
                [SortDescriptor(\.dueDate)]
            case .creationDate:
                [SortDescriptor(\.creationDate)]
            }
        }
    }
}

Nice! But… let's think about what happens if we use those single-item SortDescriptor lists. Take, for example, the descriptor for the done property. It sorts items as it should, with false items on top and true items on the bottom, but all other properties are not considered.

Fortunately, we return a list of sort descriptors, so we just need to add more descriptors for each case. For that, we need to arbitrarily choose an order for them, so let's use this as the default order: done, dueDate, name, and creationDate. This seems to make the most sense.

var sortDescriptors: [SortDescriptor<ToDoItem>] {
    let doneDescriptor = SortDescriptor(\ToDoItem.done)
    let dueDateDescriptor = SortDescriptor(\ToDoItem.dueDate)
    let nameDescriptor = SortDescriptor(\ToDoItem.name)
    let creationDateDescriptor = SortDescriptor(\ToDoItem.creationDate)
    switch self {
    case .name:
        return [nameDescriptor, doneDescriptor, dueDateDescriptor, creationDateDescriptor]
    case .done:
        return [doneDescriptor, dueDateDescriptor, nameDescriptor, creationDateDescriptor]
    case .dueDate:
        return [dueDateDescriptor, doneDescriptor, nameDescriptor, creationDateDescriptor]
    case .creationDate:
        return [creationDateDescriptor, doneDescriptor, dueDateDescriptor, nameDescriptor]
    }
}

Much better! Next, we need to actually use it. Since we want it to be changeable by the user, we need to add some @State to our view.

@State
private var sortDescriptorProvider = ToDoItem.ToDoItemSortDescriptorProvider.done

var body: some View {
    NavigationStack {
        ToDoItemsListing(sort: sortDescriptorProvider.sortDescriptors)
            .navigationTitle("To Do")
    }
}

The easy part is behind us. Now, we need to create a UI that allows the user to change sorting parameters. There are many possible ways to implement such an interaction, but we'll create a menu accessible from the toolbar.

Of course, we could create this menu manually, but a large part of the code would be the same for each sort property. To avoid that, let's first make our enum conform to the CaseIterable protocol, especially since this change is trivial. However, that's not all we need to do before we can use it. It would be nice to have a conversion between our enum and a user-readable string. This is also painless; we just need to add a raw value for it. The last thing we need to add is yet another protocol conformance, this time to Identifiable, as we want to use it in a ForEach view builder.

enum ToDoItemSortDescriptorProvider: String, CaseIterable, Identifiable {
    case name = "Name"
    case done = "Done"
    case dueDate = "Due Date"
    case creationDate = "Creation Date"

    var id: Self {
        self
    }
    ...
}

With that in place, we can create our Menu pretty straightforwardly.

ToDoItemsListing(sort: sortDescriptorProvider.sortDescriptors)
    .navigationTitle("To Do")
    .toolbar {
        Menu {
            ForEach(ToDoItem.ToDoItemSortDescriptorProvider.allCases) { provider in
                Button {
                    withAnimation {
                        sortDescriptorProvider = provider
                    }
                } label: {
                    if provider == sortDescriptorProvider {
                        Label(provider.rawValue, systemImage: "checkmark")
                    } else {
                        Text(provider.rawValue)
                    }
                }
            }
        } label: {
            Label("Sort", systemImage: "arrow.left.arrow.right")
        }
    }

Finally, we have a menu that the user can use to choose which property the application should use to sort and present data. However, there is a flaw in the current solution: the user can choose the property but not the sort order (ascending or descending). Luckily, our code is easily modifiable to handle that as well. All we need to do is change the provider's sortDescriptors property into a method that accepts SortOrder and modify the sort menu a little.

enum ToDoItemSortDescriptorProvider: String, CaseIterable, Identifiable {
    ...
    func sortDescriptors(order: SortOrder) -> [SortDescriptor<ToDoItem>] {
        let doneDescriptor = SortDescriptor(\ToDoItem.done, order: order)
        let dueDateDescriptor = SortDescriptor(\ToDoItem.dueDate, order: order)
        let nameDescriptor = SortDescriptor(\ToDoItem.name, order: order)
        let creationDateDescriptor = SortDescriptor(\ToDoItem.creationDate, order: order)
        switch self {
        case .name:
            return [nameDescriptor, doneDescriptor, dueDateDescriptor, creationDateDescriptor]
        case .done:
            return [doneDescriptor, dueDateDescriptor, nameDescriptor, creationDateDescriptor]
        case .dueDate:
            return [dueDateDescriptor, doneDescriptor, nameDescriptor, creationDateDescriptor]
        case .creationDate:
            return [creationDateDescriptor, doneDescriptor, dueDateDescriptor, nameDescriptor]
        }
    }
}

struct ContentView: View {
    @State
    private var sortDescriptorProvider = ToDoItem.ToDoItemSortDescriptorProvider.done
    @State
    private var sortOrder = SortOrder.forward

    var body: some View {
        NavigationStack {
            ToDoItemsListing(sort: sortDescriptorProvider.sortDescriptors(order: sortOrder))
                .navigationTitle("To Do")
                .toolbar {
                    Menu {
                        ForEach(ToDoItem.ToDoItemSortDescriptorProvider.allCases) { provider in
                            Button {
                                withAnimation {
                                    if provider == sortDescriptorProvider {
                                        sortOrder = sortOrder == .forward ? .reverse : .forward
                                    } else {
                                        sortDescriptorProvider = provider
                                        sortOrder = .forward
                                    }
                                }
                            } label: {
                                if provider == sortDescriptorProvider {
                                    Label(
                                        provider.rawValue,
                                        systemImage: sortOrder == .forward ? "arrow.up" : "arrow.down"
                                    )
                                } else {
                                    Text(provider.rawValue)
                                }
                            }
                        }
                    } label: {
                        Label("Sort", systemImage: "arrow.left.arrow.right")
                    }
                }
        }
    }
}

We created a nice solution that allows the user to select not only the sort property but also the sort order. Moreover, the code is simple and maintainable, but it is not portable. Let's say we have a second model and a view presenting it. We would need to create almost all of the code again, just this time for the new model and its properties. We need to change that and stick to the DRY principle.

Prepare for More

Think a bit about what we can make generic in our case. The ToDoItemSortDescriptorProvider seems to be a good candidate, despite the fact that it needs to be different for each model. The sort menu we built operates directly on the enum for the ToDoItem provider, but it doesn't care about what information it provides, just how it provides it. That's an excellent candidate to abstract as a protocol that provider enums should conform to. We can even make it a bit more readable and add a helper property for our user-readable value, so we'll start with that.

import Foundation
import SwiftData

protocol SortDescriptorProvider: CaseIterable, Identifiable, RawRepresentable where RawValue == String, AllCases: RandomAccessCollection {
    associatedtype Model: PersistentModel

    func sortDescriptors(order: SortOrder) -> [SortDescriptor<Model>]
}

extension SortDescriptorProvider {
    var id: Self {
        self
    }

    var name: String {
        rawValue
    }
}

There is one limitation to this approach. Even though our protocol implements the RawRepresentable protocol with the associatedtype forced to String, when implementing concrete providers (considering we implement it as an enum), we need to repeat the raw value type that the provider supplies. Let's make our ToDoItemSortDescriptorProvider conform to our new protocol.

enum ToDoItemSortDescriptorProvider: String, SortDescriptorProvider {
    case name = "Name"
    case done = "Done"
    case dueDate = "Due Date"
    case creationDate = "Creation Date"

    func sortDescriptors(order: SortOrder) -> [SortDescriptor<ToDoItem>] {
            ...
    }
}

We could even remove some code here, which is always nice.

Now we need to make use of this new protocol and have the sort menu use it. For that, we need to extract it into another view. Doing that is also a good opportunity to clean up and refactor the code a bit.

struct SortMenu<Provider>: View where Provider: SortDescriptorProvider {
    @Binding
    private var sortProvider: Provider
    @Binding
    private var sortOrder: SortOrder

    init(sortProvider: Binding<Provider>, sortOrder: Binding<SortOrder>) {
        _sortProvider = sortProvider
        _sortOrder = sortOrder
    }

    var body: some View {
        Menu {
            ForEach(Provider.allCases) { provider in
                if provider == sortProvider {
                    currentProviderButton
                } else {
                    button(for: provider)
                }
            }
        } label: {
            Label("Sort", systemImage: "arrow.left.arrow.right")
        }
    }

    private var currentProviderButton: some View {
        Button {
            sortOrder = sortOrder == .forward ? .reverse : .forward
        } label: {
            Label(
                sortProvider.name,
                systemImage: sortOrder == .forward ? "arrow.up" : "arrow.down"
            )
        }
    }

    private func button(for provider: Provider) -> some View {
        Button {
            sortProvider = provider
            sortOrder = .forward
        } label: {
            Text(provider.name)
        }
    }
}

struct ContentView: View {
    ...
    var body: some View {
        ...
            .toolbar {
                SortMenu(sortProvider: $sortDescriptorProvider.animation(), sortOrder: $sortOrder.animation())
            }
    }
}

That's it; we are ready for more models and more views with a sort menu to come!

What's Next?

Right now, it might seem like we didn't save much code and even had to write more to achieve the same simple result. That's true in this particular case, but think about more realistic examples, such as models with relationships where the application presents a list of entities that links to another list of different entities. With this approach, for each such list, we need a provider enum (or struct, or class, depending on what you choose), two state variables, and one line with the SortMenu view.

One might also ask if this approach is suitable for other persistent data frameworks, and the answer is yes, it is! I chose SwiftData because I've been working with it the most lately and came up with this idea specifically for that framework, but nothing prevents you from using it for something else. All you need to do is change the SortDescriptor type used by SwiftData to some other type (e.g., SortComparator for Core Data), and you can basically use the same code.

The whole solution can be found on my GitHub, and each section of this article is a separate commit in the repository.

It All Starts With a Model

Every (or almost every) application nowadays stores some kind of data, and to work with SwiftData, we need to create a model. Since this article focuses on working with Previews rather than creating sophisticated data models, we'll use the most clichéd example there is - a to-do item.

import SwiftData

@Model
final class ToDoItem {
    var name = ""
    var done = false

    init(name: String = "", done: Bool = false) {
        self.name = name
        self.done = done
    }
}

That could be it, but I like my models to implement the Codable protocol (my motivation will become clear in the next chapter). If our model class were a simple struct or class, we'd simply add : Codable to its definition. However, since it's wrapped in the @Model macro, we need to explicitly implement this protocol. To do so, we need to add an enum with CodingKey and implement the required methods.

private enum CodingKeys: CodingKey {
    case name
    case done
}

required init(from decoder: Decoder) throws {
    let container = try decoder.container(keyedBy: CodingKeys.self)
    name = try container.decode(String.self, forKey: .name)
    done = try container.decode(Bool.self, forKey: .done)
}

func encode(to encoder: Encoder) throws {
    var container = encoder.container(keyedBy: CodingKeys.self)
    try container.encode(name, forKey: .name)
    try container.encode(done, forKey: .done)
}

Our model class is ready, and we can move further with our work.

Harness the Terminator

The saddest part of working with previews (or rather, working on any UI in any framework and/or technology) for me has always been stub data. Everyone knows Lorem ipsum; everyone has created at least one Item 1, Item 2. All that just to show something on the screen, to see how the final product could look. Everything seems fine, but it has one big disadvantage - the final product contains real data, not some ancient thesis or sequences of generated numbers. Of course, we could write some real examples with actual data, but that's a waste of time. After all, there's a reason why the Lorem ipsum generator is so widely used.

However, nowadays we have tools that can help us with that kind of work and give us the needed data. It's, of course, <here place name of your favorite AI chatbot>! We can use it to generate stubs for our models. Even the free tiers on any given platform should be able to give us reasonable results.

As I mentioned earlier, I have my motivation to make model classes compliant with the Codable protocol, and you might know at this point what it is. With codable models, we can ask a chatbot to generate data in JSON format and easily manage it as a data asset in the project.

Having explained all that, let's create a prompt we can use to make a chatbot generate our stub data (important note here: providing any information to any chatbot may feed it with your data, so be careful what you send to it, especially when working for someone).

Here is my model class:

<code of our model>

Generate for array of 10 items in JSON format.

We get, as a result, a ready-to-use list.

[
    {
        "name": "Buy groceries",
        "done": false
    },
    {
        "name": "Walk the dog",
        "done": true
    },
    {
        "name": "Read a book",
        "done": false
    },
    {
        "name": "Complete homework",
        "done": true
    },
    {
        "name": "Call mom",
        "done": false
    },
    {
        "name": "Pay bills",
        "done": true
    },
    {
        "name": "Schedule dentist appointment",
        "done": false
    },
    {
        "name": "Clean the house",
        "done": true
    },
    {
        "name": "Exercise",
        "done": false
    },
    {
        "name": "Prepare dinner",
        "done": true
    }
]

The last thing left to do is to save the result to a file. We'll name it ToDoItemPreviewsData.json and add it to Preview Assets in our project (simply drag the file into Preview Assets in Xcode).

Instead of adding this file to assets, we could add the file as part of the sources (and access it from within the bundle), but since assets can handle data files and not only images, I prefer to do it this way.

Glue It All Together

Our preparation is finished, and we can now start working on using stubs with previews. However, we don't want to create a modelContainer, load data, and create models for each view separately. Instead, we'll create a helper that does all that for us. We need to start somewhere, so let's create a simple singleton provider for our provider class.

import SwiftData

final class PreviewModelContainerProvider {
    static let shared = PreviewModelContainerProvider()

    let modelContainer: ModelContainer

    private init() {
        let configuration = ModelConfiguration(isStoredInMemoryOnly: true)
        do {
            modelContainer = try ModelContainer(for: ToDoItem.self, configurations: configuration)
        } catch {
            fatalError("Could not create ModelContainer")
        }
    }
}

With that, we can use it in our view for its preview.

import SwiftData
import SwiftUI

struct ContentView: View {
    @Query
    private var toDoItems: [ToDoItem]

    var body: some View {
        List {
            ForEach(toDoItems) { toDoItem in
                Label(toDoItem.name, systemImage: toDoItem.done ? "checkmark.circle" : "circle")
            }
        }
    }
}

#Preview {
    ContentView()
        .modelContainer(PreviewModelContainerProvider.shared.modelContainer)
}

All that works, but we don't have any data to show. We'll fix that by loading data from the file inside our PreviewModelContainerProvider constructor. However, as simple as that task sounds, we need to write quite a few lines of code.

First, to insert some models, we need to access the ModelContext of our container. The problem with this is that the mainContext of a ModelContainer is a main actor-isolated property, so we either need to make the constructor async or use @MainActor to isolate the class. We can't do the former because we keep a static instance for the singleton, so we need to isolate the whole class.

@MainActor
final class PreviewModelContainerProvider {
...
}

The second thing we need to do is load data from the file we created in the previous section. Luckily, that's really easy - we just use the NSDataAsset class from UIKit.

// Don't forget to add the UIKit import
import UIKit

@MainActor
final class PreviewModelContainerProvider {
    ...
    private init() {
        ...
        guard let previewData = NSDataAsset(name: "ToDoItemPreviewsData")?.data else {
            fatalError("Preview data not found")
        }

        do {
            let toDoItems = try JSONDecoder().decode([ToDoItem].self, from: previewData)
            for toDoItem in toDoItems {
                modelContainer.mainContext.insert(toDoItem)
            }
        } catch {
            fatalError("Could not decode preview data")
        }
    }
}

Now we have everything we need to actually use previews with stub data, as you can see in the image below.

What Else Could Be Done?

Functionally, everything is in place. Nonetheless, I like adding some helpers to my container provider that make working with previews even more straightforward.

ModelContext

We access the ModelContext through our ModelContainer instance, and we do it exactly once in this example. With a more complex data schema, we'd need to access it multiple times during initialization alone - not to mention the times we'd need access to the context inside a Preview for some delegate action or something similar. To make our code more readable, we just need to create a property inside the PreviewModelContainerProvider.

@MainActor
final class PreviewModelContainerProvider {
    ...
    var modelContext: ModelContext {
        modelContainer.mainContext
    }

    private init() {
        ...
        for toDoItem in toDoItems {
            // Don't forget to use it instead of modelContainer.mainContext
            modelContext.insert(toDoItem)
        }
        ...
    }
}

Model Instances

Some of the views in the application will use only a single instance of our models and will consume it using a constructor. In that case, we could create a property to access such models from our provider. We have all we need to return such a model, but we don't retain that data. Fortunately, to change that, we just need to create a property in the provider class and store the loaded data in it instead of a local variable.

@MainActor
final class PreviewModelContainerProvider {
    ...
    private let toDoItems: [ToDoItem]
    ...
    private init() {
        ...
        // Store loaded data to property instead of local variable
        toDoItems = try JSONDecoder().decode([ToDoItem].self, from: previewData)
        ...
    }
}

Now all that's left to do is to create a property to access a single ToDoItem instance.

var toDoItem: ToDoItem {
    guard let item = toDoItems.first else {
        fatalError("There is no ToDoItem data loaded")
    }
    return item
}

We could force unwrap the toDoItems.first element, but I want to make sure we get a proper error message in case something went wrong during the initialization. Better safe than sorry, as they say.

Let's make use of our newly created property and extract the rows showing ToDoItems to a separate view.

import SwiftData
import SwiftUI

struct ToDoItemRow: View {
    private let toDoItem: ToDoItem

    init(for toDoItem: ToDoItem) {
        self.toDoItem = toDoItem
    }

    var body: some View {
        Label(toDoItem.name, systemImage: toDoItem.done ? "checkmark.circle" : "circle")
    }
}

#Preview(traits: .sizeThatFitsLayout) {
    ToDoItemRow(for: PreviewModelContainerProvider.shared.toDoItem)
}

Final Thoughts

With everything we've created here, we can easily use Previews inside our application and effortlessly add new models as the application grows, since everything we need is in just one place. We can also easily modify stub data, as it's stored in a separate, easy-to-read JSON file.

Is this the best solution? It might be, or it might not be. It all depends on your preferences. I wanted to show you how I like to work with Previews in my applications, as I found it challenging to configure everything correctly when I first started working with SwiftData.

The whole solution can be found on my GitHub, and each section of this article is a separate commit in the repository.