I'm experiencing the following error with my SwiftData container when running a build:
Code=134504 "Cannot use staged migration with an unknown model version."
Code Structure - Summary
I am using a versionedSchema to store multiple models in SwiftData. I started experiencing this issue when adding two new models in the newest Schema version. Starting from the current public version, V4.4.6, there are two migrations.
Migration Summary
The first migration is to V4.4.7. This is a lightweight migration removing one attribute from one of the models. This was tested and worked successfully.
The second migration is to V5.0.0. This is a custom migration adding two new models, and instantiating instances of the two new models based on data from instances of the existing models. In the initial testing of this version, no issues were observed.
Issue and Steps to Reproduce
Reproduction of issue: Starting from a fresh build of the publicly released V4.4.6, I run a new build that contains both Schema Versions (V4.4.7 and V5.0.0), and their associated migration stages. This builds successfully, and the container successfully migrates to V5.0.0. Checking the default.store file, all values appear to migrate and instantiate correctly.
The second step in reproduction of the issue is to simply stop running the build, and then rebuild, without any code changes. This fails to initialize the model container every time afterwards. Going back to the simulator after successive builds are stopped in Xcode, the app launches and accesses/modifies the model container as normal.
Supplementary Issue: I have been putting up with the same, persistent issue in the Xcode Preview Canvas of "Failed to Initialize Model Container" This is a 5 in 6 build issue, where builds will work at random. In the case of previews, I have cleared all data associated with all previews multiple times. The only difference being that the simulator is a 100% failure rate after the initial, successful initialization. I assume this is due to the different build structure of previews. Lastly, of note, the Xcode previews fail at the same line in instantiating the model container as the simulator does. From my research into this issue, people say that the Xcode preview is instantiating from elsewhere. I do have a separate model container set up specifically for canvas previews, but the error does not occur in that container, but rather the app's main container.
Possible Contributing Factors & Tested Facts
iOS: While I have experienced issues with SwiftData and the complier in iOS 26, I can rule that out as the issue here. This has been tested on simulators running iOS 18.6, 26.0.1, and 26.1, all encountering failures to initialize model container. While in iOS 18, subsequent builds after the successful migration did work, I did eventually encounter the same error and crash. In iOS 26.0.1 and 26.1, these errors come immediately on the second build.
Container Initialization for V4.4.6
do {
container = try ModelContainer(
for:
Job.self,
JobTask.self,
Day.self,
Charge.self,
Material.self,
Person.self,
TaskCategory.self,
Service.self,
migrationPlan: JobifyMigrationPlan.self
)
} catch {
fatalError("Failed to Initialize Model Container")
}
Versioned Schema Instance for V4.4.6 (V4.4.7 differs only by versionIdentifier)
static var versionIdentifier = Schema.Version(4, 4, 6)
static var models: [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 = try ModelContainer(
for: schema, migrationPlan: JobifyMigrationPlan.self
)
} catch {
fatalError("Failed to Initialize Model Container")
}
Versioned Schema Instance for V5.0.0
static var versionIdentifier = Schema.Version(5, 0, 0)
static var models: [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
]
}
Addressing Differences in Object Names
Type-aliasing: All my model types are type-aliased for simplification in view components. All types are aliased as 'JobifySchemeV446.<#Name#>' in V.4.4.6, and 'JobifySchemaV500.<#Name#>' in V5.0.0
Issues with iOS 26: My type-aliases dating back to iOS 17 overlapped with lower level objects in Swift, including 'Job' and 'Material'. These started to be an issue with initializing the model container when running in iOS 26. The type aliases have been renamed since, however the V4.4.6 build with the old names runs and builds perfectly fine in iOS 26
If there is any other code that may be relevant in determining where this error is occurring, I would be happy to add it. My current best theory is simply that I have mistakenly omitted code relevant to the SwiftData Migration.
iCloud & Data
RSS for tagLearn how to integrate your app with iCloud and data frameworks for effective data storage
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Created
Hello 👋,
I encounter the "This model instance was invalidated because its backing data could no longer be found the store" crash with SwiftData. Which from what I understood means I try to access a model after it has been removed from the store (makes sense).
I made a quick sample to reproduce/better understand because there some case(s) I can't figure it out.
Let's take a concrete example, we have Home model and a Home can have many Room(s).
// Sample code
@MainActor
let foo = Foo() // A single reference
let database = Database(modelContainer: sharedModelContainer) // A single reference
@MainActor
class Foo {
// Properties to explicilty keep reference of model(s) for the purpose of the POC
var _homes = [Home]()
var _rooms = [Room]()
func fetch() async {
let homes = await database.fetch().map {
sharedModelContainer.mainContext.model(for: $0) as! Home
}
print(ObjectIdentifier(homes[0]), homes[0].rooms?.map(\.id)) // This will crash here or not.
}
// Same version of a delete function with subtle changes.
// Depending on the one you use calling delete then fetch will result in a crash or not.
// Keep a reference to only homes == NO CRASH
func deleteV1() async {
self._homes = await database.fetch().map {
sharedModelContainer.mainContext.model(for: $0) as! Home
}
await database.delete()
}
// Keep a reference to only rooms == NO CRASH
func deleteV2() async {
self._rooms = await database.fetch().map {
sharedModelContainer.mainContext.model(for: $0) as! Home
}[0].rooms ?? []
await database.delete()
}
// Keep a reference to homes & rooms == CRASH 💥
func deleteV3() async {
self._homes = await database.fetch().map {
sharedModelContainer.mainContext.model(for: $0) as! Home
}
self._rooms = _homes[0].rooms ?? []
// or even only retain reference to rooms that have NOT been deleted 🤔 like here "id: 2" make it crash
// self._rooms = _homes[0].rooms?.filter { r in r.id == "2" } ?? []
await database.delete()
}
}
Calling deleteV() then fetch() will result in a crash or not depending on the scenario.
I guess I understand deleteV1, deleteV2. In those case an unsaved model is served by the model(for:) API and accessing properties later on will resolve correctly. The doc says: "The identified persistent model, if known to the context; otherwise, an unsaved model with its persistentModelID property set to persistentModelID."
But I'm not sure about deleteV3. It seems the ModelContext is kind of "aware" there is still cyclic reference between my models that are retained in my code so it will serve these instances instead when calling model(for:) API ? I see my home still have 4 rooms (instead of 2). So I then try to access rooms that are deleted and it crash. Why of that ? I mean why not returning home with two room like in deleteV1 ?
Because SwiftData heavily rely on CoreData may be I miss a very simple thing here. If someone read this and have a clue for me I would be extremely graceful.
PS:
If someone wants to run it on his machine here's some helpful code:
// Database
let sharedModelContainer: ModelContainer = {
let schema = Schema([
Home.self,
Room.self,
])
let modelConfiguration = ModelConfiguration(schema: schema, isStoredInMemoryOnly: false)
debugPrint(modelConfiguration.url.absoluteString.replacing("%20", with: "\\ "))
return try! ModelContainer(for: schema, configurations: [modelConfiguration])
}()
extension Database {
static let shared = Database(modelContainer: sharedModelContainer)
}
@ModelActor
actor Database {
func insert() async {
let r1 = Room(id: "1", name: "R1")
let r2 = Room(id: "2", name: "R2")
let r3 = Room(id: "3", name: "R3")
let r4 = Room(id: "4", name: "R4")
let home = Home(id: "1", name: "My Home")
home.rooms = [r1, r2, r3, r4]
modelContext.insert(home)
try! modelContext.save()
}
func fetch() async -> [PersistentIdentifier] {
try! modelContext.fetchIdentifiers(FetchDescriptor<Home>())
}
@MainActor
func delete() async {
let mainContext = sharedModelContainer.mainContext
try! mainContext.delete(
model: Room.self,
where: #Predicate { r in
r.id == "1" || r.id == "4"
}
)
try! mainContext.save()
// 🤔 Calling fetch here seems to solve crash too, force home relationship to be rebuild correctly ?
// let _ = try! sharedModelContainer.mainContext.fetch(FetchDescriptor<Home>())
}
}
// Models
@Model
class Home: Identifiable {
@Attribute(.unique) public var id: String
var name: String
@Relationship(deleteRule: .cascade, inverse: \Room.home)
var rooms: [Room]?
init(id: String, name: String, rooms: [Room]? = nil) {
self.id = id
self.name = name
self.rooms = rooms
}
}
@Model
class Room: Identifiable {
@Attribute(.unique) public var id: String
var name: String
var home: Home?
init(id: String, name: String, home: Home? = nil) {
self.id = id
self.name = name
self.home = home
}
}
Hi everyone,
I am experiencing an iCloud provisioning problem I cannot resolve, and Developer Support has not been able to help.
My App ID:
com.exaqservices.ArkyvTiles
Symptoms:
1. In Xcode (v16.2), enabling iCloud in Signing & Capabilities repeatedly fails with:
The app ID does not include the iCloud container. Click Try Again.
Clicking Try Again does nothing. The error persists forever.
2. In Certificates, Identifiers & Profiles:
• The iCloud capability is enabled for this App ID.
• The CloudKit container is selected.
• But the portal no longer shows the “iCloud Documents” checkbox, which used to be required for ubiquitous document support.
3. Xcode cannot regenerate provisioning profiles because it claims the App ID is missing the iCloud container — even though the container is attached.
4. Provisioning profiles on the Apple Developer site all appear expired, and new ones do not generate correctly.
5. The App Store Connect interface also does not show an iCloud Services section under App Information → Capabilities as older guides describe.
Expected Behavior:
Since iCloud and the CloudKit container are enabled on the App ID, Xcode should successfully enable:
• com.apple.developer.icloud-services
• com.apple.developer.icloud-container-identifiers
• com.apple.developer.ubiquity-container-identifiers (if needed)
• com.apple.developer.ubiquity-kvstore-identifier
Instead, the entitlements never propagate.
What I suspect:
This seems like an App ID metadata mismatch or a stale backend entry where:
• the CloudKit container is attached but the entitlement isn’t linked,
• the “iCloud Documents” flag is missing due to a UI transition,
• provisioning profiles cannot be regenerated because the App ID is not updating correctly.
What I need help with:
Can someone from Apple engineering confirm:
• Whether my App ID metadata is corrupted,
• If entitlements need to be manually refreshed,
• Or if the “iCloud Documents” toggle has moved or is no longer exposed?
This is blocking development completely — I cannot build, sign, or deploy the app with iCloud.
Thank you!
Alan Metzger
Our app saves its data to iCloud by default. In most cases, this is working as intended & the data can be synced across devices with no problems.
But recently, in testing, we discovered a situation where it's possible to save data before the NSMetadataQuery finishes & starts downloading the cloud files. When this happens, the query will then finish, and return the NEW file (with no other versions or conflicts).
Is there a way to ensure that writing a file (version A) to ubiquitous storage when another version (version B) exists in the cloud is treated as a conflict, rather than just stomping all over the other version?
I've tried querying the file metadata for the file URL (NSURLIsUbiquitousItemKey, NSMetadataUbiquitousItemDownloadingStatusKey, NSURLUbiquitousItemDownloadRequestedKey, NSURLUbiquitousItemHasUnresolvedConflictsKey) before saving, but it just returns nil.
Topic:
App & System Services
SubTopic:
iCloud & Data
Hi,
I’m completely stuck with a very strange CloudKit problem that started recently and has now killed all iCloud sync for a live production app.
What is happening
Production container: iCloud.gainzCloud (created ~11 months ago, has been working perfectly until now)
In Xcode 26.0 (17A321):
→ Signing & Capabilities → iCloud is enabled
→ Container correctly shows as iCloud.gainzCloud
→ App builds and runs on device/simulator with zero provisioning or container errors
CloudKit Dashboard (https://icloud.developer.apple.com/dashboard/): completely blank – “No containers found”
Result: CloudKit sync is dead for every user (development + production environments)
What I know for sure
Apple Developer Support confirmed the container iCloud.gainzCloud still exists and is correctly attached to my Team ID on their backend
Personal iCloud (Mail, Notes, Photos, etc.) syncs perfectly on the same Mac / same Apple ID under macOS Tahoe 26.1
I have NOT changed the password on either the Apple ID or the Developer Program account
New containers I create appear in Xcode but never show up in the Dashboard
Environment
macOS Tahoe 26.1 (latest)
Xcode Version 26.0 (17A321)
Has anyone on the new Tahoe/Xcode 26 releases seen the CloudKit Dashboard suddenly go completely empty while Xcode still “sees” the container just fine?
Any known trick to force the dashboard to re-index containers or clear whatever cache is broken?
Thanks a lot in advance – this is blocking all iCloud functionality for a released app with active users.
Topic:
App & System Services
SubTopic:
iCloud & Data
Apple WTF? What did you do to all my Apps? none of them work in iOS26.1 (all worked in 26.0).
XCode simply says:
CoreData: error: addPersistentStoreWithType:configuration:URL:options:error: returned error NSCocoaErrorDomain (134140) *
SwiftData is supposed to do all these automatically 🤷🏻
Hello,
If I want to modify records in my public database, this works fine. However, if I change from public to private in the requesturl, I get the response: "500 - Internal Error".
According to the CK WebService Reference, it is possible to access the private database.
Could someone explain to me if it is really an internal error and if it could be fixed by Apple, since I would like to access my own private database with the server-to-server key.
Thanks in advance.
it seems that is going to the appstore to find the app to execute the share but my app is not in the appstore yet. I am using a sandboxed user and a non sandboxed user, I have tried real phones connected to xcode and simulator same effect, looking for how to test my ckshare in testflight thanks
I am an individual developer, and I want to create a demo. Do I need to develop an app for both iOS and Android to accomplish this?
Has Apple provided a simple demo or not?
Topic:
App & System Services
SubTopic:
iCloud & Data
I've run into a strange issue.
If a sheet loads a view that has a SwiftData @Query, and there is an if statement in the view body, I get the following error when running an iOS targetted SwiftUI app under MacOS 26.1:
Set a .modelContext in view's environment to use Query
While the view actually ends up loading the correct data, before it does, it ends up re-creating the sqlite store (opening as /dev/null).
The strange thing is that this only happens if there is an if statement in the body. The statement need not ever evaluate true, but it causes the issue.
Here's an example. It's based on the default xcode new iOS project w/ SwiftData:
struct ContentView: View {
@State private var isShowingSheet = false
var body: some View {
Button(action: { isShowingSheet.toggle() }) {
Text("Show Sheet")
}
.sheet(isPresented: $isShowingSheet, onDismiss: didDismiss) {
VStack {
ContentSheetView()
}
}
}
func didDismiss() { }
}
struct ContentSheetView: View {
@Environment(\.modelContext) private var modelContext
@Query public var items: [Item]
@State var fault: Bool = false
var body: some View {
VStack {
if fault { Text("Fault!") }
Button(action: addItem) {
Label("Add Item", systemImage: "plus")
}
List {
ForEach(items) { item in
Text(item.timestamp, format: Date.FormatStyle(date: .numeric, time: .standard))
}
}
}
}
private func addItem() {
withAnimation {
let newItem = Item(timestamp: Date())
modelContext.insert(newItem)
}
}
}
It requires some data to be added to trigger, but after adding it and dismissing the sheet, opening up the sheet with trigger the Set a .modelContext in view's environment to use Query. Flipping on -com.apple.CoreData.SQLDebug 1 will show it trying to recreate the database.
If you remove the if fault { Text("Fault!") } line, it goes away. It also doesn't appear to happen on iPhones or in the iPhone simulator.
Explicitly passing modelContext to the ContentSheetView like ContentSheetView().modelContext(modelContext) also seems to fix it.
Is this behavior expected?
If an app is using top-level models, meaning they exist outside the VersionedSchema enum, is it safe to keep them outside of the VersionedSchema enum and use a migration plan for simple migrations. Moving the models within the VersionedSchema enum I believe would change the identity of the models and result in data being lost, although correct me if I'm wrong in that statement.
The need presently is just to add another variable to the model and then set that variable within the init function:
var updateId = UUID()
The app is presently in TestFlight although I'd like to preserve data for users that are currently using the app.
The data within SwiftData is synchronized with CloudKit and so I'd also like to avoid any impact to synchronization.
Any thoughts on this would be greatly appreciated.
Hello,
the last days I was trying to solve a bug in my Unit Tests related to the CoreData "NSManagedObjectContextObjectsDidChange" Notification.
Im using some kind of Notification handler to save and abstract that for the UI and while the tests are running this notification was triggered with objects that doesn't exists anymore, which has resulted in a crash.
After some debugging I have detected, that the objects in here are really old. The objects here was from few tests ago, where a Merge Conflict happened. In the meantime there was a plenty of resets and deletes of the whole db. I have also seen that the bad notification is the first in the stack trace of the main thread, which is in my opinion also not usual.
So the real question is:
The only difference what I have found for the bad notification to the real notification, was the existence of the key "NSObjectsChangedByMergeChangesKey" in the UserInfo dictionary of the ObjectsDidChange Notification. But this key is nowhere found in the documentation of Apple. Also the search engines does not produce any result. So what is this key and when is this key contained in this notification and when not?
Maybe if I understand this, it helps me to understand the overall issue ...
I'm seeing this over and over on the CloudKit Console at: https://icloud.developer.apple.com/dashboard/home, and sign out and sign in does not resolve it.
Error looking up Developer Teams
Please sign out and try again.
[Sign Out]
Anyone experience this? Is there a work around for this?
When I used to do Migrations, I always used ETL and then push to a dev system to review/test before going production.
The migration support is SwiftData is fine for a little tweak.
I might as well just just use new schema and context and write the custom code than use the SwiftData migration support.
Hello,
In our app, we’ve modeled our schema using inheritance introduced in iOS 26.0, and we’re implementing SwiftData History to re-fetch models only when necessary.
@Model public class Transaction {
@Attribute(.preserveValueOnDeletion)
public var date: Date = Date()
public var amount: Double = 0
public var memo: String?
}
@Model public final class Spending: Transaction {
public var installmentIndex: Int = 1
public var installment: Int = 1
public var installmentID: UUID?
}
If data has been deleted from database, we need to check a date property to determine whether to re-fetch datas.
To do this, we added the preserveValueOnDeletion attribute to date property so we could retrieve it from the History tombstone value.
However, after adding this attribute, a crash occurs. There is a console log
Could not cast value of type 'Swift.ReferenceWritableKeyPath<Shared.ModelSchemaV5.Transaction, Foundation.Date>' (0x106bf8328) to 'Swift.PartialKeyPath<Shared.ModelSchemaV5.Spending>' (0x1094f21d8).
and error log attached
StrictMoneyChecking-2025-11-07-105108.txt
I also tried this in the recent SampleTrip app, and fetching all history after a deletion causes the same crash.
Is this issue currently being worked on or under investigation?
After Xcode 26.1 was updated and installing the OS 26.1 simulators, my app started crashing related to transformable properties. When I checked my schema, I noticed that properties with array collection types are suddenly set with an option transformable with Optional("NSSecureUnarchiveFromData")], even though I do not use any transformable types. I verified the macros, no transformable was specified. This is causing ModelCoders to encode/decode my properties incorrectly.
This is not an issue when I switch back to OS 26.0 simulators.
Here is what I thought
I want to give each user a unique container, when the user login or register, the user could isolate their data in specific container.
I shared the container in a singleton actor, I found it's possible to update the container in that actor.
But I think it won't affect the modelContext which is in the Environment.
Does SwiftData allow me or recommend to do that?
I have one target building and filling the SwiftData store and then copying the same store file to another target of the app to use the contents.
That worked fine from iOS 17 to iOS 26.0.1
Under iOS 26.1 I am getting following error:
CoreData: error:
This store file was previously used on a build with Persistence-1522 but is now running on a build with Persistence-1518.
file:///Users/xxx/Library/Developer/CoreSimulator/Devices/0FE92EA2-57FA-4A5E-ABD0-DAB4DABC3E02/data/Containers/Data/Application/B44D3256-9B09-4A60-94E2-C5F11A6519E7/Documents/default.store
What does it mean and how to get back to working app under iOS 26.1?
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.
Hi, I'm using SwiftData in my app, and I want to sent data to iCloud with CloudKit, but I found that If the user turns off my App iCloud sync function in the settings App, the local data will also be deleted.
A better way is maintaining the local data, just don't connect to iCloud.How should I do that?
I need guidance!!! I'm just getting started with CloudKit
And I would be appreciated!