ios – Container Failing to Initialize After a Profitable Migration & Initialization

I am experiencing the next error with my SwiftData container when operating a construct:

Code=134504 “Can’t use staged migration with an unknown mannequin model.”

I’m utilizing a versionedSchema to retailer a number of fashions in SwiftData. I began experiencing this problem when including two new fashions within the latest Schema model.
Ranging from the present public model, V4.4.6, there are two migrations.

The primary migration is to V4.4.7. It is a light-weight migration eradicating one
attribute from one of many fashions. This was examined and labored efficiently.

The second migration is to V5.0.0. It is a customized migration including two new fashions, and instantiating cases of the 2 new fashions primarily based on information from cases of the prevailing fashions. Within the preliminary testing of this model, no points have been noticed.

Challenge and Steps to Reproduce

Copy of problem: Ranging from a recent construct of the publicly launched V4.4.6, I run a brand new construct that comprises each Schema Variations (V4.4.7 and V5.0.0), and their related migration levels. This builds efficiently, and the container efficiently migrates to V5.0.0. Checking the default.retailer file, all values seem emigrate and instantiate accurately.

The second step in copy of the problem is to easily cease operating the construct, after which rebuild, with none code adjustments. This fails to initialize the mannequin container each time afterwards. Going again to the simulator after successive builds are stopped in Xcode, the app launches and accesses/modifies the mannequin container as regular.

Supplementary Challenge: I’ve been placing up with the identical, persistent problem within the Xcode Preview Canvas of “Didn’t Initialize Mannequin Container” It is a 5 in 6 construct problem, the place builds will work at random. Within the case of previews, I’ve cleared all information related to all previews a number of instances. The one distinction being that the simulator is a 100% failure charge after the preliminary, profitable initialization. I assume that is because of the completely different construct construction of previews.
Lastly, of notice, the Xcode previews fail on the similar line in instantiating the mannequin container because the simulator does. From my analysis into this problem, individuals say that the Xcode preview is instantiating from elsewhere. I do have a separate mannequin container arrange particularly for canvas previews, however the error doesn’t happen in that container, however reasonably the app’s essential container.

iOS: Whereas I’ve skilled points with SwiftData and the complier in iOS 26, I can rule that out as the problem right here. This has been examined on simulators operating iOS 18.6, 26.0.1, and 26.1, all encountering failures to initialize mannequin container. Whereas in iOS 18, subsequent builds after the profitable migration did work, I did ultimately encounter the identical error and crash. In iOS 26.0.1 and 26.1, these errors come instantly on the second construct.

My Particular person Expertise: That is my first migration involving the addition of latest fashions to my schemas. I’ve expertise with light-weight and customized migrations in versionedSchemas, however had problem when first constructing V5.0.0. Whereas that code builds and migrates efficiently, I imagine I could also be omitting some necessary code that’s now inflicting points.

Container Initialization for V4.4.6

do {
        container = attempt ModelContainer(
            for:
            Job.self,
            JobTask.self,
            Day.self,
            Cost.self,
            Materials.self,
            Particular person.self,
            TaskCategory.self,
            Service.self,

            migrationPlan: JobifyMigrationPlan.self
        )
    } catch {
        fatalError("Didn't Initialize Mannequin Container")
    }

Versioned Schema Occasion for V4.4.6 (V4.4.7 differs solely by versionIdentifier)

static var versionIdentifier = Schema.Model(4, 4, 6)

static var fashions: [any PersistentModel.Type] {
    [Job.self, JobTask.self, Day.self, Charge.self, Material.self, Person.self, TaskCategory.self, Service.self]
}

Container Initialization for V5.0.0

    do {
        
        let schema = Schema([Jobify.self,
                            JobTask.self,
                            Day.self,
                            Charge.self,
                            MaterialItem.self,
                            Person.self,
                            TaskCategory.self,
                            Service.self,
                            ServiceJob.self,
                            RecurerRule.self])
        
        container = attempt ModelContainer(
            for: schema, migrationPlan: JobifyMigrationPlan.self
        )
    } catch {
        fatalError("Didn't Initialize Mannequin Container")
    }

Versioned Schema Occasion for V5.0.0

static var versionIdentifier = Schema.Model(5, 0, 0)

static var fashions: [any PersistentModel.Type] {
    [
        JobifySchemaV500.Job.self,
        JobifySchemaV500.JobTask.self,
        JobifySchemaV500.Day.self,
        JobifySchemaV500.Charge.self,
        JobifySchemaV500.Material.self,
        JobifySchemaV500.Person.self,
        JobifySchemaV500.TaskCategory.self,
        JobifySchemaV500.Service.self,
        JobifySchemaV500.ServiceJob.self,
        JobifySchemaV500.RecurerRule.self
    ]
}

Migration Phases | V4.4.6 -> V4.4.7, V4.4.7 -> V5.0.0

static var migrateV446toV447 = MigrationStage.light-weight(fromVersion: JobifySchemeV446.self, toVersion: JobifySchemeV447.self)

static var V447toV500 = MigrationStage.customized(
    fromVersion: JobifySchemeV447.self,
    toVersion: JobifySchemaV500.self,
    willMigrate: nil,
    didMigrate: { context in
        
        var providers: [JobifySchemaV500.Service] = []
        
        let descriptor: FetchDescriptor = FetchDescriptor(predicate: #Predicate { service in
            service.rawFrequency != 0
        })
        
        do {
            providers = attempt context.fetch(descriptor)
        } catch {
            print("Didn't fetch JobifySchemaV500.Service from context")
        }
        
        var serviceJobs: [JobifySchemaV500.ServiceJob] = []
        
        for service in providers {
            for job in service.jobs {
                
                /// If service comprises fees for Job, create a brand new serviceJob following the foundations of the prevailing Service
                
                if !service.fees.isEmpty && service.frequency != nil {
                    var serviceJob: JobifySchemaV500.ServiceJob = ServiceJob(from: job, and: service)
                    
                    serviceJobs.append(serviceJob)
                    
                }
            }
        }
        
        for serviceJob in serviceJobs {
            context.insert(serviceJob)
        }
        
        do {
            attempt context.save()
        } catch {
            print("Failed to avoid wasting context after inserting [JobifySchemaV500.ServiceJob] throughout migration V447toV500")
        }
    }
)

1. Sort-aliasing: All my mannequin sorts are type-aliased for simplification in view elements. Every kind are aliased as ‘JobifySchemeV446.<#Identify#>’ in V.4.4.6, and ‘JobifySchemaV500.<#Identify#>’ in V5.0.0

2. Points with iOS 26: My type-aliases relationship again to iOS 17 overlapped with decrease degree objects in Swift, together with ‘Job’ and ‘Materials’. These began to be a problem with initializing the mannequin container when operating in iOS 26. The kind aliases have been renamed since, nonetheless the V4.4.6 construct with the previous names runs and builds completely high-quality in iOS 26

If there may be another code that could be related in figuring out the place this error is going on, I might be joyful so as to add it. My present greatest idea is solely that I’ve mistakenly omitted code related to the SwiftData Migration.