Updated the phone to iOS 26.1 and now the app is not working anymore, even previously approved version published on App Store which works perfectly on iOS 26.0.1, and iOS 18+.
I deleted the app from the phone and installed fresh from App Store, still the same.
Logic is that on start app copies previously prepared SwiftData store file (using the same models) from app bundle to Documents directory and uses it. Currently app just hungs with loader spinner spinning as it can t connect to the store.
Getting this error in console when running from Xcode on real device with iOS 26.1 installed: CoreData: error:
CoreData: error: Store failed to load. <NSPersistentStoreDescription: 0x10c599e90> (type: SQLite, url: file:///var/mobile/Containers/Data/Application/DA32188D-8887-48F7-B828-1F676C8FBEF8/Documents/default.store)
with error = Error Domain=NSCocoaErrorDomain Code=134140
"Persistent store migration failed, missing mapping model."
UserInfo={sourceModel=(<NSManagedObjectModel: 0x10c503ac0>) isEditable 0,
entities { /// there goes some long models description
addPersistentStoreWithType:configuration:URL:options:error: returned error NSCocoaErrorDomain (134140)
Any help or workaround will be greatly appreciated.
Folks who filed their feedback report may have gotten responses from the feedback system. For people who see the same issue but haven't yet filed any feedback report, I'd like to share our investigation here to hopefully help.
To give you more context, SwiftData (with DefaultStore) uses Core Data as its underlying storage mechanism. At runtime, SwiftData converts the schema to an in-memory Core Data model (NSManagedObjectModel), and uses the model to load and persist the data store.
Before system 26.1, when handling an attribute of an array type, SwiftData converts the array type to Binary Data. On system 26.1, it instead converts the type to Transformable. This change leads to a difference between the in-memory model and the model used in the persisted data store, triggering a migration error with the following message:
Error Domain=NSCocoaErrorDomain Code=134140 "Persistent store migration failed, missing mapping model.”
To work around the issue, you might consider the following options:
A. Tweak your SwiftData schema so that the in-memory model matches the model used in the existing data store.
B. Migrate the existing data store to the model that matches the in-memory model.
Option A is relatively simple. Assuming you have the following SwiftData model, and the [String?] type triggers the issue:
@Model
final class Item {
var titles: [String?]
init(titles: [String?]) {
self.titles = titles
}
}
You can change the model to the following, which should then match the model used in the existing data store:
@Model
final class Item {
var titles: Data
var titlesArray: [String?] {
get {
try! JSONDecoder().decode([String?].self, from: titles)
}
set {
titles = try! JSONEncoder().encode(newValue)
}
}
init(titles: [String?]) {
self.titles = try! JSONEncoder().encode(titles)
}
}
You will then change the code that uses titles accordingly. Note that, with this, every time accessing titlesArray, you trigger the encoding or decoding process, which may have a performance impact.
Option B includes a relatively complicated data migration process:
-
Create the in-memory model with your current SwiftData schema, and figure out the offending attributes and their entities.
-
Make a copy of the model, and name it model_v1. Change the type of those offending attributes from
.transformableAttributeTypeto.binaryDataAttributeTypeso that model_v1 gets compatible with the existing data store. We will use model_v1 to load the existing data store. -
Make a copy of model_v1, and name it model_v2. For each offending attribute, add a new column with
.transformableAttributeType. Later, we will use a custom migration stage (NSCustomMigrationStage) to migration the existing data store from model_v1 to model_v2. -
Make a copy of the model_v2, and name it model_v3. Remove the offending attributes. This is an intermediate step so we can do the next step.
-
Make a copy of the model_v3, and name it model_v4. For each offending attribute, add a new attribute that has the same name, but is of the
.transformableAttributeTypetype. Later, we will migrate the store from model_v3 to model_v4 to move the transformable data to this attribute. -
Make a copy of the model_v4, and name it model_v5. Remove the attribute that you added at step 3. This is the final model – a model containing the attribute that has the right name and type (
transformableAttributeType). -
Set up and kick off the data migration process from model_v1 -> model_v2 -> model_v3 -> model_v4 -> model_v5.
This migration process goes through several phases. For a large data set, it may take long time, and so users may interrupt it. This is something you need to consider if going along this path. The process (step 1) assumes that you don’t change your SwiftData schema in this app update.
The good thing is that this migration process is a one-time deal. After the migration, the data and schema will match, and you don’t need to concern any more.
The attached file (SharedModelContainer.txt) demonstrates how to implement the process. You can give it a try and share if that works for your real app.
Best,
——
Ziqiao Chen
Worldwide Developer Relations.
