Adding SwiftData to a SwiftUI App Generated by Rork Max

Step 2: Wire the ModelContainer into the app

With the model defined, hand a ModelContainer to your app's entry point. Think of it as adding one line, .modelContainer(for:), to the App struct Rork Max generated.

import SwiftUI
import SwiftData
 
@main
struct HabitApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        .modelContainer(for: Habit.self)
    }
}

Then in ContentView, replace the @State array with @Query. This is the single most effective line in the whole article.

struct ContentView: View {
    @Environment(\.modelContext) private var context
    @Query(sort: \Habit.createdAt) private var habits: [Habit]
 
    var body: some View {
        List {
            ForEach(habits) { habit in
                Toggle(habit.name, isOn: Bindable(habit).doneToday)
            }
            .onDelete { offsets in
                for index in offsets { context.delete(habits[index]) }
            }
        }
        .toolbar {
            Button("Add") {
                context.insert(Habit(name: "New habit"))
            }
        }
    }
}

@Query streams the database contents straight into the view and re-renders automatically when anything changes. Because calling context.insert or context.delete triggers a save, you do not have to write an explicit save() each time. Using Bindable(habit) for the Toggle binding is the standard way to edit an @Model object.

At this point you have an app whose data survives a relaunch. But the real difficulty is still ahead: the day you want to change the model after shipping.

Step 3: Design schema migration from the start

When you add a property to a shipped model, existing users still have data in the old schema on their devices. With no plan, SwiftData can detect the schema mismatch at launch and crash. I once fell into this by adding createdAt later as non-optional. My test device was a fresh install so I never noticed — only existing users who received the update crashed right at launch. The worst possible pattern.

VersionedSchema and SchemaMigrationPlan prevent this. You freeze the model's shape per version and make the migration path explicit.

import SwiftData
 
enum HabitSchemaV1: VersionedSchema {
    static var versionIdentifier = Schema.Version(1, 0, 0)
    static var models: [any PersistentModel.Type] { [Habit.self] }
 
    @Model final class Habit {
        var name: String
        var doneToday: Bool
        init(name: String, doneToday: Bool = false) {
            self.name = name
            self.doneToday = doneToday
        }
    }
}
 
enum HabitSchemaV2: VersionedSchema {
    static var versionIdentifier = Schema.Version(2, 0, 0)
    static var models: [any PersistentModel.Type] { [Habit.self] }
 
    @Model final class Habit {
        var name: String
        var doneToday: Bool
        var createdAt: Date = Date.now   // new properties must carry a default value
        init(name: String, doneToday: Bool = false, createdAt: Date = .now) {
            self.name = name
            self.doneToday = doneToday
            self.createdAt = createdAt
        }
    }
}
 
enum HabitMigrationPlan: SchemaMigrationPlan {
    static var schemas: [any VersionedSchema.Type] { [HabitSchemaV1.self, HabitSchemaV2.self] }
    static var stages: [MigrationStage] {
        [.lightweight(fromVersion: HabitSchemaV1.self, toVersion: HabitSchemaV2.self)]
    }
}

Two things matter. Always give a new property a default value. And if the change is a simple addition that a default value can fill, a .lightweight stage is enough. If you need to rename fields or transform data, you write a .custom stage with willMigrate / didMigrate closures, but designing changes so they can be absorbed by lightweight migration makes operations dramatically easier.

Pass the migration plan when initializing the ModelContainer.

let container = try ModelContainer(
    for: HabitSchemaV2.Habit.self,
    migrationPlan: HabitMigrationPlan.self
)

If you cut V1 from the very first release, the second change will not catch you off guard. These days I wrap even the tiniest app in a VersionedSchema from day one, because retroactively defining "the original schema" later is far more tedious than it sounds.

Step 4: A fallback that never blocks launch

Even with migration in place, the chance of ModelContainer creation failing — disk corruption, an unexpected schema mismatch — is never exactly zero. Initialize with try! and the app will not even launch at that moment. Generated code often uses try!, so this is a spot worth fixing by hand every time.

What I actually ship is a two-tier setup that falls back to an in-memory container on failure.

@main
struct HabitApp: App {
    let container: ModelContainer
 
    init() {
        do {
            container = try ModelContainer(
                for: HabitSchemaV2.Habit.self,
                migrationPlan: HabitMigrationPlan.self
            )
        } catch {
            // Let the app launch even if persistence fails
            let fallback = ModelConfiguration(isStoredInMemoryOnly: true)
            container = try! ModelContainer(for: HabitSchemaV2.Habit.self, configurations: fallback)
            // Logging this to your crash reporter makes root-causing much faster
        }
    }
 
    var body: some Scene {
        WindowGroup { ContentView() }
            .modelContainer(container)
    }
}

Falling back to memory means data is not saved, but it at least avoids the worst experience of "crashing the instant it launches." Send the failure to your crash reporting platform and you can later trace which device and which version the migration tripped on. From the user's side it reads as "history temporarily disappeared," which I consider far better than "the app never opens again."

The order to follow when working with generated code

Looking back over these steps, the flow is to receive the screen code Rork Max produced as a "working foundation," then apply your own hands in order: persistence, wiring, migration, and fallback. What AI generates is a fast starting point; the judgment needed to turn it into an app people touch every day still rests with the maker. That is how I frame it today.

For your next move, pick just one @State in the app you are building right now, swap it to @Model, and check whether data survives a relaunch. That small step is the first switch that moves generated code from "demo" toward "product."

I hope this helps anyone else growing Rork Max output the same way. Thank you for reading.