SwiftData crashes after changing a property struct

I came across this issue myself. I used a Codable struct in one of my models.

If you are still in development the easiest solution would be to delete the SqlLite database and start from scratch. But if your app is already out there and the user have data stored you need to migrate it.

SwiftData stores your Codable struct as encoded value. So every attempt to decode it back will fail as soon as you change any property of the struct.

You will need to use 2 Migrations to change the initial struct. We can only make changes to the entities before and after the Migration is done. SwiftData applies the changes to the underlying SQLite storage by itself. We cannot control how this is done.

In the first Migration we will create another property and map the data of TargetData to it. In the second migration we drop the old property. From now on you need to use the new property. We cannot name it the same as the old name, Migration will fail if we do so.

// to access the Items in your other code more simple use a type alias
// this will point to the newest version of CloudInterval and TargetData
typealias CloudInterval = DataSchemaV3.CloudInterval
typealias TargetData = DataSchemaV3.TargetData

enum DataSchemaV1: VersionedSchema{
    
    static var versionIdentifier: Schema.Version = Schema.Version(1, 0, 0)
    static var models: [any PersistentModel.Type] { [Self.CloudInterval.self] }
    
    @Model
    class CloudInterval {
        // ... other properties
        // specify the type explicitly to avoid confusion
        var targetData: DataSchemaV1.TargetData = TargetData()
        init(){}
    }

    struct TargetData: Codable, Equatable {
        var minHeartRate: Int = 0
        var maxHeartRate: Int = 0
        var speed: Double = 0
        var time: TimeInterval = 0
        var distance: Double = 0
        var enableTargetSpeed = false
        var enableTargetHeartRate = false
        var enableTargetTime = false
        var speedTolerance: Double = 0.02
    }
}

enum DataSchemaV2: VersionedSchema{
    
    static var versionIdentifier: Schema.Version = Schema.Version(2, 0, 0)
    static var models: [any PersistentModel.Type] { [Self.CloudInterval.self] }
    
    @Model
    class CloudInterval {
        // ... other properties
        // specify the type explicitly to avoid confusion
        var targetData: DataSchemaV1.TargetData = DataSchemaV1.TargetData()
        // we create a property with a different name that will hold our new values
        var newTargetData: DataSchemaV3.TargetData = DataSchemaV3.TargetData()
        init(){}
    }
}


enum DataSchemaV3: VersionedSchema{
    
    static var versionIdentifier: Schema.Version = Schema.Version(3, 0, 0)
    static var models: [any PersistentModel.Type] { [Self.CloudInterval.self] }
    
    @Model
    class CloudInterval {
        // ... other properties
        // we now have only the new created property here
        var newTargetData: DataSchemaV3.TargetData = DataSchemaV3.TargetData()
        init(){}
    }

    struct TargetData: Codable, Equatable {
        var minHeartRate: Int = 0
        var maxHeartRate: Int = 0
        var speed: Double = 0
        var time: TimeInterval = 0
        var distance: Double = 0
        var enableTargetSpeed = false
        var enableTargetHeartRate = false
        var enableTargetTime = false
        var speedTolerance: Double = 0.02
        // added properties here
        var integerValue: Int = 0
        var booleanValue: Bool = false
    }
}

enum DataMigrationPlan: SchemaMigrationPlan{
    // here we add the types involved in the migration
    static var schemas: [any VersionedSchema.Type] { [DataSchemaV1.self, DataSchemaV2.self, DataSchemaV3.self]}
    
    // return the stages that should be run during migration
    static var stages: [MigrationStage] { [migrationV1ToV2, migrationV2ToV3] }
    
    static let migrationV1ToV2 = MigrationStage.custom(fromVersion: DataSchemaV1.self, toVersion: DataSchemaV2.self, willMigrate: nil) { context in
        // this will run after the migration completed and we now have V2 items
        let v2CloudIntervals = try context.fetch(FetchDescriptor<DataSchemaV2.CloudInterval>())
        
        v2CloudIntervals.forEach{ v2CloidInterval in // initialize the new TargetData here and assign the values
                                                     // from the old TargetData
            v2CloidInterval.newTargetData = DataSchemaV3.TargetData()
        }
        // save changes to the context
        try context.save()
    }
    // with this migration we drop the old targetData property
    static let migrationV2ToV3 = MigrationStage.lightweight(fromVersion: DataSchemaV2.self, toVersion: DataSchemaV3.self)
}

The only thing left to do would be to use the migration while creating the container

do {
    let container = try ModelContainer(for: schema, migrationPlan: DataMigrationPlan.self, configurations: [modelConfiguration])        
    return container
} catch {
    fatalError("Could not create ModelContainer: \(error)")
}

You should make migrations when you want to make changes to your data model. If your app is not published on the App Store, I recommend deleting your application and reinstalling it. However, if you want to update your app that is on the App Store, I prefer watching this video. SwiftData Migrations Tutorial

There is 2 type of migrations in SwiftData: lightweight and complex.

While lightweight migration will execute automatically, for bigger changes you need to write your own migration plan.

Some lightweight changess:

• Adding one or more new model.
• Adding one or more new properties that have a default value.
• Renaming one or more properties.
• Deleting properties from a model.
• Adding or removing the .externalStorage or .allowsCloudEncryption attributes.
• Adding the .unique attribute and all values for that property are already unique.
• Adjusting the delete rule on relationships.

The problem in you case is you want to update a complex type, not only add two more properties.

You have more options to solve this:

1. You can make the TargetData @Model as well, and create one-to-one relationships between them.

This mean that every CloudInterval object has exactly one TargetData object attached to it. In this case, be careful not to try to insert both CloudInterval and TargetData objects, because inserting one automatically inserts the other.

2. You can create complex migration using VersionedSchema

Doing this requires four steps:

• You need to define multiple versions of our data model.
• You wrap each of those versions inside an enum that conforms to the VersionedSchema protocol. (It’s an enum only because we won’t actually be instantiating these directly.)
• You create another enum that conforms to the SchemaMigrationPlan protocol, which is where you'll handle the migrations between each model version.
• You then create a custom ModelContainer configuration that knows to use the migration plan as needed.

You can learn more about SchemaMigrationPlan from the following links:

• WWDC Notes

• HackingWithSwift