Greetings my fellow engineers,
I use SwiftData in my iOS app. The schema is unversioned and consists of a single model. I've been modifying the model for almost two years now and relying on automatic database migrations. I had no problems for all that time, but now trying to add a property to the model or even remove a property from the model results in an error which seems like SwiftData is no longer capable of performing an automatic migration.
The log console has things like the following:
CoreData: error: NSUnderlyingError : Error Domain=NSCocoaErrorDomain Code=134190 "(null)" UserInfo={reason=Each property must have a unique renaming identifier}
CoreData: error: reason : Can't find or automatically infer mapping model for migration
CoreData: error: storeType: SQLite
CoreData: error: configuration: default
CoreData: annotation: options:
CoreData: annotation: NSMigratePersistentStoresAutomaticallyOption : 1
CoreData: annotation: NSInferMappingModelAutomaticallyOption : 1
CoreData: annotation: NSPersistentStoreRemoteChangeNotificationOptionKey : 1
CoreData: annotation: NSPersistentHistoryTrackingKey : 1
CoreData: error: <NSPersistentStoreCoordinator: 0x7547b5480>: Attempting recovery from error encountered during addPersistentStore: 0x753f8d800 Error Domain=NSCocoaErrorDomain Code=134140 "Persistent store migration failed, missing mapping model."
Have you ever encountered such an issue? What are my options?
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
Activity
Hi. I'm hoping someone might be able to help us with an issue that's been affecting our standalone watchOS app for some time now.
We've encountered consistent crashes on Apple Watch devices when the app enters the background while the device is offline (i.e., no Bluetooth and no Wi-Fi connection). Through extensive testing, we've isolated the problem to the use of NSPersistentCloudKitContainer. When we switch to NSPersistentContainer, the crashes no longer occur.
Interestingly, this issue only affects our watchOS app. The same CloudKit-based persistence setup works reliably on our iOS and macOS apps, even when offline. This leads us to believe the issue may be specific to how NSPersistentCloudKitContainer behaves on watchOS when the device is disconnected from the network.
We're targeting watchOS 10 and above. We're unsure if this is a misconfiguration on our end or a potential system-level issue, and we would greatly appreciate any insight or guidance.
Hello,
I'm trying to work on an iPadOS and macOS app that will rely on the document-based system to create some kind of orientation task to follow.
Let say task1.myfile will be a check point regulation from NYC to SF and task2.myfile will be a visit as many key location as you can in SF.
The file represent the specific landmark location and rules of the game.
And once open, I will be able to read KML/GPS file to evaluate their score based with the current task.
But opened GPS files does not have to be stored in the task file itself, it stay alongside.
I wanted to use that scenario to experiment with SwiftData (I'm a long time CoreData user, I even wrote my own WebDAV based persistent store back in the day), and so, mix both on file and in memory persistent store, with distribution based on object class.
With CoreData it would have been possible, but I do not see how to achieve that with SwiftData and DocumentGroup integration.
Any idea how to do that?
I'm trying to use the new (in tvOS 26) video streaming service automatic login API from the VideoSubscriberAccount framework:
https://developer.apple.com/documentation/videosubscriberaccount/vsuseraccountmanager/autosignintoken-swift.property
It seems that this API requires an entitlement. This document suggests that the com.apple.smoot.subscriptionservice entitlement is required.
https://developer.apple.com/documentation/videosubscriberaccount/signing-people-in-to-media-apps-automatically
However, it seems more likely that com.apple.developer.video-subscriber-single-sign-on is the correct entitlement.
https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.video-subscriber-single-sign-on
Which is the correct entitlement and how do I obtain it?
I don't want to fully comply with the video partner program.
https://developer.apple.com/programs/video-partner/
I just want to use this one new automatic login feature.
In a document based SwiftData app for macOS, how do you go about opening a (modal) child window connected to the ModelContainer of the currently open document?
Using .sheet() does not really result in a good UX, as the appearing view lacks the standard window toolbar.
Using a separate WindowGroup with an argument would achieve the desired UX. However, as WindowGroup arguments need to be Hashable and Codable, there is no way to pass a ModelContainer or a ModelContext there:
WindowGroup(id: "myWindowGroup", for: MyWindowGroupArguments.self) { $args in
ViewThatOpensInAWindow(args: args)
}
Is there any other way?
I have made a Swift App for MacOS 15 under XCode 16.3, which runs fine. I also want to run it under the previous MacOS 14. Unfortunately it crashes without even starting up (it does not even reach the first log output statement on the first view)
The crash reason is
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4
Terminating Process: exc handler [2970]
I have set the miminium deployment to MacOS 14.0 but to no effect. The XCode machine is a MacOS 15.4 on Arm M3 and the target machine is MacOS 14.7.5 on Intel (MacBook Air)
I think it might be related to the compiler and linker settings.
Hi,
Not sure how to describe my issue best: I am using SwiftData and CloudKit to store my data.
In the past, when I tested my app on different devices, the data would sync between the devices automatically. For whatever reason this has stopped now and the data no longer syncs. No matter what I do, it feels as if all the data is actually stored just locally on each device.
How can I check if the data is actually stored in the cloud and what could be reasons, why its no longer synching between my devices (and yes, I am logged in with the same Apple ID on all devices).
Thanks for any hint!
Max
I have not had any successful Schema Migration with CloudKit so far so I'm trying to do with with just very basic attributes, with multiple Versioned Schemas
This is the code in my App Main
var sharedModelContainer: ModelContainer = {
let schema = Schema(versionedSchema: AppSchemaV4.self)
do {
return try ModelContainer(
for: schema,
migrationPlan: AppMigrationPlan.self,
configurations: ModelConfiguration(cloudKitDatabase: .automatic))
} catch {
fatalError("Could not create ModelContainer: \(error)")
}
}()
var body: some Scene {
WindowGroup {
ItemListView()
}
.modelContainer(sharedModelContainer)
}
And this is the code for my MigrationPlan and VersionedSchemas.
typealias Item = AppSchemaV4.Item3
enum AppMigrationPlan: SchemaMigrationPlan {
static var schemas: [any VersionedSchema.Type] {
[AppSchemaV1.self, AppSchemaV2.self, AppSchemaV3.self, AppSchemaV4.self]
}
static var stages: [MigrationStage] {
[migrateV1toV2, migrateV2toV3, migrateV3toV4]
}
static let migrateV1toV2 = MigrationStage.lightweight(
fromVersion: AppSchemaV1.self,
toVersion: AppSchemaV2.self
)
static let migrateV2toV3 = MigrationStage.lightweight(
fromVersion: AppSchemaV2.self,
toVersion: AppSchemaV3.self
)
static let migrateV3toV4 = MigrationStage.custom(
fromVersion: AppSchemaV3.self,
toVersion: AppSchemaV4.self,
willMigrate: nil,
didMigrate: { context in
// Fetch all Item1 instances
let item1Descriptor = FetchDescriptor<AppSchemaV3.Item1>()
let items1 = try context.fetch(item1Descriptor)
// Fetch all Item2 instances
let item2Descriptor = FetchDescriptor<AppSchemaV3.Item2>()
let items2 = try context.fetch(item2Descriptor)
// Convert Item1 to Item3
for item in items1 {
let newItem = AppSchemaV4.Item3(name: item.name, text: "Migrated from Item1 on \(item.date)")
context.insert(newItem)
}
// Convert Item2 to Item3
for item in items2 {
let newItem = AppSchemaV4.Item3(name: item.name, text: "Migrated from Item2 with value \(item.value)")
context.insert(newItem)
}
try? context.save()
}
)
}
enum AppSchemaV1: VersionedSchema {
static var versionIdentifier: Schema.Version = Schema.Version(1, 0, 0)
static var models: [any PersistentModel.Type] {
[Item1.self]
}
@Model class Item1 {
var name: String = ""
init(name: String) {
self.name = name
}
}
}
enum AppSchemaV2: VersionedSchema {
static var versionIdentifier: Schema.Version = Schema.Version(2, 0, 0)
static var models: [any PersistentModel.Type] {
[Item1.self]
}
@Model class Item1 {
var name: String = ""
var date: Date = Date()
init(name: String) {
self.name = name
self.date = Date()
}
}
}
enum AppSchemaV3: VersionedSchema {
static var versionIdentifier: Schema.Version = Schema.Version(3, 0, 0)
static var models: [any PersistentModel.Type] {
[Item1.self, Item2.self]
}
@Model class Item1 {
var name: String = ""
var date: Date = Date()
init(name: String) {
self.name = name
self.date = Date()
}
}
@Model class Item2 {
var name: String = ""
var value: Int = 0
init(name: String, value: Int) {
self.name = name
self.value = value
}
}
}
enum AppSchemaV4: VersionedSchema {
static var versionIdentifier: Schema.Version = Schema.Version(4, 0, 0)
static var models: [any PersistentModel.Type] {
[Item1.self, Item2.self, Item3.self]
}
@Model class Item1 {
var name: String = ""
var date: Date = Date()
init(name: String) {
self.name = name
self.date = Date()
}
}
@Model class Item2 {
var name: String = ""
var value: Int = 0
init(name: String, value: Int) {
self.name = name
self.value = value
}
}
@Model class Item3 {
var name: String = ""
var text: String = ""
init(name: String, text: String) {
self.name = name
self.text = text
}
}
}
My experiment was:
To create Items for every version of the schema
Updating the typealias along the way to reflect the latest Item version.
Updating the Schema in my ModelContainer to reflect the latest Schema Version.
By AppSchemaV4, I have expected all my Items to be displayed/migrated to Item3, but it does not seem to be the case.
I can only see newly created Item3 records.
My question is, is there something wrong with how I'm doing the migrations? or are migrations not really working with CloudKit right now?
Hi! I use Tips with CloudKit and it works very well, however when a user want to remove their data from CloudKit, how to do that?
In CoreData with CloudKit area, NSPersistentCloudKitContainer have purgeObjectsAndRecordsInZone to delete both local managed objects and CloudKit records, however there is no information about the TipKit deletion.
Does anyone know ideas?
Hi all,
In my SwiftUI / SwiftData / Cloudkit app which is a series of lists, I have a model object called Project which contains an array of model objects called subprojects:
final class Project1
{
var name: String = ""
@Relationship(deleteRule: .cascade, inverse: \Subproject.project) var subprojects : [Subproject]?
init(name: String)
{
self.name = name
self.subprojects = []
}
}
The user will select a project from a list, which will generate a list of subprojects in another list, and if they select a subproject, it will generate a list categories and if the user selects a category it will generate another list of child objects owned by category and on and on.
This is the pattern in my app, I'm constantly passing arrays of model objects that are the children of other model objects throughout the program, and I need the user to be able to add and remove things from them.
My initial approach was to pass these arrays as bindings so that I'd be able to mutate them. This worked for the most part but there were two problems: it was a lot of custom binding code and when I had to unwrap these bindings using init?(_ base: Binding<Value?>), my program would crash if one of these arrays became nil (it's some weird quirk of that init that I don't understand at al).
As I'm still learning the framework, I had not realized that the @model macro had automatically made my model objects observable, so I decided to remove the bindings and simply pass the arrays by reference, and while it seems these references will carry the most up to date version of the array, you cannot mutate them unless you have access to the parent and mutate it like such:
project.subcategories?.removeAll { $0 == subcategory }
project.subcategories?.append(subcategory)
This is weirding me out because you can't unwrap subcategories before you try to mutate the array, it has to be done like above. In my code, I like to unwrap all optionals at the moment that I need the values stored in them and if not, I like to post an error to the user. Isn't that the point of optionals? So I don't understand why it's like this and ultimately am wondering if I'm using the correct design pattern for what I'm trying to accomplish or if I'm missing something? Any input would be much appreciated!
Also, I do have a small MRE project if the explanation above wasn't clear enough, but I was unable to paste in here (too long), attach the zip or paste a link to Google Drive. Open to sharing it if anyone can tell me the best way to do so. Thanks!
SwiftData crashes 100% when fetching history of a model that contains an optional codable property that's updated:
SwiftData/Schema.swift:389: Fatal error: Failed to materialize a keypath for someCodableID.someID from CrashModel. It is possible that this path traverses a type that does not work with append(), please file a bug report with a test.
Would really appreciate some help or even a workaround.
Code:
import Foundation
import SwiftData
import Testing
struct VaultsSwiftDataKnownIssuesTests {
@Test
func testCodableCrashInHistoryFetch() async throws {
let container = try ModelContainer(
for: CrashModel.self,
configurations: .init(
isStoredInMemoryOnly: true
)
)
let context = ModelContext(container)
try SimpleHistoryChecker.hasLocalHistoryChanges(context: context)
// 1: insert a new value and save
let model = CrashModel()
model.someCodableID = SomeCodableID(someID: "testid1")
context.insert(model)
try context.save()
// 2: check history it's fine.
try SimpleHistoryChecker.hasLocalHistoryChanges(context: context)
// 3: update the inserted value before then save
model.someCodableID = SomeCodableID(someID: "testid2")
try context.save()
// The next check will always crash on fetchHistory with this error:
/*
SwiftData/Schema.swift:389: Fatal error: Failed to materialize a keypath for someCodableID.someID from CrashModel. It is possible that this path traverses a type that does not work with append(), please file a bug report with a test.
*/
try SimpleHistoryChecker.hasLocalHistoryChanges(context: context)
}
}
@Model final class CrashModel {
// optional codable crashes.
var someCodableID: SomeCodableID?
// these actually work:
//var someCodableID: SomeCodableID
//var someCodableID: [SomeCodableID]
init() {}
}
public struct SomeCodableID: Codable {
public let someID: String
}
final class SimpleHistoryChecker {
static func hasLocalHistoryChanges(context: ModelContext) throws {
let descriptor = HistoryDescriptor<DefaultHistoryTransaction>()
let history = try context.fetchHistory(descriptor)
guard let last = history.last else {
return
}
print(last)
}
}
I'm developing an app that uses CloudKit synchronization with SwiftData and on visionOS I added an App Settings bundle. I have noticed that sometimes, when the app is open and the user changes a setting from the App Settings bundle, the following fatal error occurs:
SwiftData/BackingData.swift:831: Fatal error: This model instance was destroyed by calling ModelContext.reset and is no longer usable.
The setting is read within the App struct in the visionOS app target using @AppStorage and this value is in turn used to set the passthrough video dimming via the .preferredSurroundingsEffect modifier. The setting allows the user to specify the dimming level as dark, semi dark, or ultra dark.
The fatal error appears to occur intermittently although the first time it was observed was after adding the settings bundle. As such, I suspect there is some connection between those code changes and this fatal error even though they do not directly relate to SwiftData.
Hi all
I have a problem with core data, where when a new user login that is different from the previous user i delete all of core data by using "destroyPersistentStore".
Then i recreate the persistent store, this works when i am testing. When it does not work for one of my users when she test.
I am not sure why this should not work, i have added the code i use to destroy the persistent store below.
This code is run after login but before the view changes away from my login view.
// Retrieves the shared `AppDelegate` instance
guard let appDelegate = UIApplication.shared.delegate as? AppDelegate else {
return
}
appDelegate.destroyDataSyncBackground()
// Get a reference to a NSPersistentStoreCoordinator
let storeContainer =
appDelegate.persistentContainer.persistentStoreCoordinator
// Delete each existing persistent store
for store in storeContainer.persistentStores {
if let url = store.url {
do {
try storeContainer.destroyPersistentStore(
at: url,
ofType: store.type,
options: nil
)
} catch {
print("Failed to deleted all")
}
} else {
print("Failed to deleted all")
}
}
// Re-create the persistent container
appDelegate.persistentContainer = NSPersistentContainer(
name: "CueToCue" // the name of
// a .xcdatamodeld file
)
// Calling loadPersistentStores will re-create the
// persistent stores
appDelegate.persistentContainer.loadPersistentStores {
(store, error) in
// Handle errors
let description = NSPersistentStoreDescription()
description.shouldMigrateStoreAutomatically = true
description.shouldInferMappingModelAutomatically = true
appDelegate.persistentContainer.persistentStoreDescriptions = [description]
}
// Reapply context configuration
let viewContext = appDelegate.persistentContainer.viewContext
viewContext.automaticallyMergesChangesFromParent = true
viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy
do {
try viewContext.save()
appDelegate.recreateDataSyncBackground()
} catch {
print("Debug: saving delete all failed.")
}
}
The function "destroyDataSyncBackground" just set the my sync class to nil so stop any changes to core data while the code is running.
The function "recreateDataSyncBackground" recreate the sync class so fetch, post and patch requests is made again.
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
I have started from here: Apple's guide on the sharing core data objects between iCloud users and I have created a sample project that has Collections and Items. Everything works great while I stay on Swift 5, like with the initial project.
I would like to migrate to Swift 6 (Default Actor Isolaton @MainActor, Approachable Concurrency: Yes) on the project and I am stuck at extension CDCollection: Transferable { ... }. When compiling with Swift 5, there is a warning: Conformance of 'NSManagedObject' to 'Sendable' is unavailable in iOS; this is an error in the Swift 6 language mode.
After resolving almost all compile-time warnings I'm left with:
Conformance of 'CDCollection' to protocol 'Transferable' crosses into main actor-isolated code and can cause data races.
Which I don't think will work, because of the warning shown above. It can be worked around like:
nonisolated extension CDCollection: Transferable, @unchecked Sendable
Then there are errors:
let persistentContainer = PersistenceController.shared.persistentContainer Main actor-isolated static property 'shared' can not be referenced from a nonisolated context.
I've created the following class to have a Sendable object:
struct CDCollectionTransferable: Transferable {
var objectID: NSManagedObjectID
var persistentContainer: NSPersistentCloudKitContainer
public static var transferRepresentation: some TransferRepresentation {
CKShareTransferRepresentation { collectionToExport in
let persistentContainer = collectionToExport.persistentContainer
let ckContainer = CloudKitProvider.container
var collectionShare: CKShare?
if let shareSet = try? persistentContainer.fetchShares(
matching: [collectionToExport.objectID]),
let (_, share) = shareSet.first
{
collectionShare = share
}
/**
Return the existing share if the collection already has a share.
*/
if let share = collectionShare {
return .existing(share, container: ckContainer)
}
/**
Otherwise, create a new share for the collection and return it.
Use uriRepresentation of the object in the Sendable closure.
*/
let collectionURI = collectionToExport.objectID
.uriRepresentation()
return .prepareShare(container: ckContainer) {
let collection = await persistentContainer.viewContext
.perform {
let coordinator = persistentContainer.viewContext
.persistentStoreCoordinator
guard
let objectID = coordinator?.managedObjectID(
forURIRepresentation: collectionURI
)
else {
fatalError(
"Failed to return the managed objectID for: \(collectionURI)."
)
}
return persistentContainer.viewContext.object(
with: objectID
)
}
let (_, share, _) = try await persistentContainer.share(
[collection],
to: nil
)
return share
}
}
}
}
And I'm able to compile and run the app with this change:
let transferable = CDCollectionTransferable(
objectID: collection.objectID,
persistentContainer: PersistenceController.shared
.persistentContainer
)
ToolbarItem {
ShareLink(
item: transferable,
preview: SharePreview("Share \(collection.name)!")
) {
MenuButtonLabel(
title: "New Share",
systemImage: "square.and.arrow.up"
)
}
}
The app crashes when launched with
libdispatch.dylib`_dispatch_assert_queue_fail:
0x1052c6ea4 <+0>: sub sp, sp, #0x50
0x1052c6ea8 <+4>: stp x20, x19, [sp, #0x30]
0x1052c6eac <+8>: stp x29, x30, [sp, #0x40]
0x1052c6eb0 <+12>: add x29, sp, #0x40
0x1052c6eb4 <+16>: adrp x8, 63
0x1052c6eb8 <+20>: add x8, x8, #0xa0c ; "not "
0x1052c6ebc <+24>: adrp x9, 62
0x1052c6ec0 <+28>: add x9, x9, #0x1e5 ; ""
0x1052c6ec4 <+32>: stur xzr, [x29, #-0x18]
0x1052c6ec8 <+36>: cmp w1, #0x0
0x1052c6ecc <+40>: csel x8, x9, x8, ne
0x1052c6ed0 <+44>: ldr x10, [x0, #0x48]
0x1052c6ed4 <+48>: cmp x10, #0x0
0x1052c6ed8 <+52>: csel x9, x9, x10, eq
0x1052c6edc <+56>: stp x9, x0, [sp, #0x10]
0x1052c6ee0 <+60>: adrp x9, 63
0x1052c6ee4 <+64>: add x9, x9, #0x9db ; "BUG IN CLIENT OF LIBDISPATCH: Assertion failed: "
0x1052c6ee8 <+68>: stp x9, x8, [sp]
0x1052c6eec <+72>: adrp x1, 63
0x1052c6ef0 <+76>: add x1, x1, #0x9a6 ; "%sBlock was %sexpected to execute on queue [%s (%p)]"
0x1052c6ef4 <+80>: sub x0, x29, #0x18
0x1052c6ef8 <+84>: bl 0x105301b18 ; symbol stub for: asprintf
0x1052c6efc <+88>: ldur x19, [x29, #-0x18]
0x1052c6f00 <+92>: str x19, [sp]
0x1052c6f04 <+96>: adrp x0, 63
0x1052c6f08 <+100>: add x0, x0, #0xa11 ; "%s"
0x1052c6f0c <+104>: bl 0x1052f9ef8 ; _dispatch_log
0x1052c6f10 <+108>: adrp x8, 95
0x1052c6f14 <+112>: str x19, [x8, #0x1f0]
-> 0x1052c6f18 <+116>: brk #0x1
The app still crashes when I comment this code, and all Core Data related warnings.
I'm quite stuck now as I want to use Swift 6.
Has anyone figured CloudKit, CoreData and Swift 6 for sharing between users?
I have the following code running on macOS and iOS:
CKQuerySubscription *zsub = [[CKQuerySubscription alloc] initWithRecordType:ESS_CLOUDCONTROLLER_RECORDTYPE_PUSHNOTE predicate:[NSPredicate predicateWithFormat:@"TRUEPREDICATE"] subscriptionID:@"pushZSub" options:CKQuerySubscriptionOptionsFiresOnRecordUpdate|CKQuerySubscriptionOptionsFiresOnRecordCreation|CKQuerySubscriptionOptionsFiresOnRecordDeletion];
zsub.zoneID = zid;
CKNotificationInfo *inf = [[CKNotificationInfo alloc] init];
inf.shouldSendContentAvailable = YES;
inf.desiredKeys = @[ESS_PN_RECORDFIELD_KEY_OVERALLDATE];
zsub.notificationInfo = inf;
CKModifySubscriptionsOperation *msop = [[CKModifySubscriptionsOperation alloc] initWithSubscriptionsToSave:@[zsub] subscriptionIDsToDelete:nil];
msop.qualityOfService = NSQualityOfServiceUserInitiated;
msop.modifySubscriptionsCompletionBlock = ^(NSArray<CKSubscription *> * _Nullable savedSubscriptions, NSArray<CKSubscriptionID> * _Nullable deletedSubscriptionIDs, NSError * _Nullable operationError) {
dispatch_async(dispatch_get_main_queue(), ^{
if (savedSubscriptions.count == 1) { //works also when already created.
compH(YES, nil);
} else {
compH(NO, nil);
}
});
};
[self.database addOperation:msop];
(code synopsis: after i create a custom zone (not shown in code), I add a ckquerysubscription to it for a specific record type, configured as a silent notification)
When I change the according record in my Mac app, I get an immediate silent push on iOS.
On macOS, however, after I change the record in my iOS app, I don't get one. Sometimes, one silent push makes it through every now and then a minute+ late or so, and after that, it's going missing again.
What's the deal? Everything's set up correctly (com.apple.developer.aps-environment is set, container-identifiers are the same, icloud services are the same, ubiquity-kvstore-identifier are the same).
I obviously register for remote notifications in both apps. I see all the records and subscriptions and zones in both the Mac and iOS app.
I tried setting alertBody to an empty string, or soundName to an empty string, or both to an empty string: no difference
I tried having different subscriptions for my Mac and iOS app, since they use different bundle ids, but that was merged into one subscription server-side, so I'm thinking that's not it
I tried making it not-silent by setting contentAvailable to NO and adding a full alertBody, title and subtitle. Again, worked on iOS, not on macOS.
This has been going on since macOS 14 Sonoma (when I first got reports of this. Now running on macOS 26.3). Before Sonoma, it worked just fine.
Now I thought perhaps it's because I had a subscription on the default zone, and not a custom one, so I tried subscribing to changes on a record in a custom zone (see code above), but that did not change anything either.
It's all working fine, only the push notifications are not making it through to the Mac app.
If I sudo killall apsd (kill the push service daemon), the last push notification suddenly miraculously makes it through, by the way.
At this point, I'm out of ideas and would very much appreciate pointers as to how to debug this. Polling every 30 seconds for changes is so 1990s.
Speaking of which, this is a rather long-time-running app (started in 2011). Could my CloudKit database be “too old” or “corrupted” or whatever?
Thank you kindly,
– Matthias
Hello,
I have a iOS app I was looking at porting to Mac.
I'm having an issue with both the Mac (Designed for iPad) and Mac Catalyst Destinations. I can't test Mac due to too many build issues.
I'm trying to assign a new NSManagedObject into a NSPersistentStore.
let object = MyObject(context: context)
context.assign(object, to: nsPersistentStore)
This works fine for iOS/iOS Simulator/iPhone/iPad. But on the Mac it's crashing with
FAULT: NSInvalidArgumentException: Can't assign an object to a store that does not contain the object's entity.; {
Thread 1: "Can't assign an object to a store that does not contain the object's entity."
I'm experiencing a critical issue with SwiftData custom migrations where objects created during migration appear to be inserted successfully but aren't persisted or found by queries after migration completes. The migration logs show objects being created, but subsequent queries return zero results.
I'm migrating from schema version V2 to V2_5, which involves:
Renaming Person class to GroupData
Keeping the same data structure but changing the class name while keeping the old class.
Using a custom migration stage to copy data from old to new schema
Below is an extract of my two schema and migration plan:
Environment:
Xcode 16.0,
iOS 18.0,
Swift 6.0
SchemaV2
enum LinkMapV2: VersionedSchema {
static let versionIdentifier: Schema.Version = .init(2, 0, 0)
static var models: [any PersistentModel.Type] {
[AnnotationData.self, Person.self, History.self]
}
@Model
final class Person {
@Attribute(.unique) var id: UUID
var name: String
var photo: String
var requirement: String
var statue: Bool
var annotationId: UUID?
var number: Int = 0
init(id: UUID = UUID(), name: String = "", photo: String = "", requirement: String = "", status: Bool = false, annotationId: UUID? = nil, number: Int = 0) {
self.id = id
self.name = name
self.photo = photo
self.requirement = requirement
self.statue = status
self.annotationId = annotationId
self.number = number
}
}
}
Schema V2_5
static let versionIdentifier: Schema.Version = .init(2, 5, 0)
static var models: [any PersistentModel.Type] {
[AnnotationData.self, Person.self, GroupData.self, History.self]
}
// Keep the old Person model for migration
@Model
final class Person {
@Attribute(.unique) var id: UUID
var name: String
var photo: String
var requirement: String
var statue: Bool
var annotationId: UUID?
var number: Int = 0
init(id: UUID = UUID(), name: String = "", photo: String = "", requirement: String = "", status: Bool = false, annotationId: UUID? = nil, number: Int = 0) {
self.id = id
self.name = name
self.photo = photo
self.requirement = requirement
self.statue = status
self.annotationId = annotationId
self.number = number
}
}
// Add the new GroupData model that mirrors Person
@Model
final class GroupData {
@Attribute(.unique) var id: UUID
var name: String
var photo: String
var requirement: String
var status: Bool
var annotationId: UUID?
var number: Int = 0
init(id: UUID = UUID(), name: String = "", photo: String = "", requirement: String = "", status: Bool = false, annotationId: UUID? = nil, number: Int = 0) {
self.id = id
self.name = name
self.photo = photo
self.requirement = requirement
self.status = status
self.annotationId = annotationId
self.number = number
}
}
}
Migration Plan
static let migrationV2toV2_5 = MigrationStage.custom(
fromVersion: LinkMapV2.self,
toVersion: LinkMapV2_5.self,
willMigrate: { context in
do {
let persons = try context.fetch(FetchDescriptor<LinkMapV2.Person>())
print("=== MIGRATION STARTED ===")
print("Found \(persons.count) Person objects to migrate")
guard !persons.isEmpty else {
print("No Person data requires migration")
return
}
for person in persons {
print("Migrating Person: '\(person.name)' with ID: \(person.id)")
let newGroup = LinkMapV2_5.GroupData(
id: person.id, // Keep the same ID
name: person.name,
photo: person.photo,
requirement: person.requirement,
status: person.statue,
annotationId: person.annotationId,
number: person.number
)
context.insert(newGroup)
print("Inserted new GroupData: '\(newGroup.name)'")
// Don't delete the old Person yet to avoid issues
// context.delete(person)
}
try context.save()
print("=== MIGRATION COMPLETED ===")
print("Successfully migrated \(persons.count) Person objects to GroupData")
} catch {
print("=== MIGRATION ERROR ===")
print("Migration failed with error: \(error)")
}
},
didMigrate: { context in
do {
// Verify migration in didMigrate phase
let groups = try context.fetch(FetchDescriptor<LinkMapV2_5.GroupData>())
let oldPersons = try context.fetch(FetchDescriptor<LinkMapV2_5.Person>())
print("=== MIGRATION VERIFICATION ===")
print("New GroupData count: \(groups.count)")
print("Remaining Person count: \(oldPersons.count)")
// Now delete the old Person objects
for person in oldPersons {
context.delete(person)
}
if !oldPersons.isEmpty {
try context.save()
print("Cleaned up \(oldPersons.count) old Person objects")
}
// Print all migrated groups for debugging
for group in groups {
print("Migrated Group: '\(group.name)', Status: \(group.status), Number: \(group.number)")
}
} catch {
print("Migration verification error: \(error)")
}
}
)
And I've attached console output below:
Console Output
The NSMetadataUbiquitousItemDownloadingStatusKey indicates the status of a ubiquitous (iCloud Drive) file.
A key value of NSMetadataUbiquitousItemDownloadingStatusDownloaded is defined as indicating there is a local version of this file available. The most current version will get downloaded as soon as possible .
However this no longer occurs since iOS 18.4. A ubiquitous file may remain in the NSMetadataUbiquitousItemDownloadingStatusDownloaded state for an indefinite period.
There is a workaround: call [NSFileManager startDownloadingUbiquitousItemAtURL: error:] however this shouldn't be necessary, and introduces delays over the previous behaviour.
Has anyone else seen this behaviour? Is this a permanent change?
FB17662379
Hi, I am building an iOS app with SwiftUI and SwiftData for the first time and I am experiencing a lot of difficulty with this error:
Thread 44: Fatal error: Never access a full future backing data - PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(<ID> <x-coredata://<UUID>/MySwiftDataModel/p1>)), backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(<ID> <x-coredata://<UUID>/MySwiftDataModel/p1>)) with Optional(<UUID>)
I have been trying to figure out what the problem is, but unfortunately I cannot find any information in the documentation or on other sources online. My only theory about this error is that it is somehow related to fetching an entity that has been created in-memory, but not yet saved to the modelContext in SwiftData.
However, when I am trying to debug this, it's not clear this is the case. Sometimes the error happens, sometimes it doesn't. Saving manually does not always solve the error.
Therefore, it would be extremely helpful if someone could explain what this error means and whether there are any best practices to do with SwiftData, or some pitfalls to avoid (such as wrapping my model context into a repository class).
To be clear, this problem is NOT related to one area of my code, it happens throughout my app, at unpredictable places and time. Given that there is very little information related to this error, I am at a loss at how to make sure that this never happens.
This question has been asked on the forum here as well as on StackOverflow, Reddit (can't link that here), but none of the answers worked for me.
For reference, my models generally look like this:
import Foundation
import SwiftData
@Model
final class MySwiftDataModel {
// Stable cross-device identity
@Attribute(.unique)
var uuid: UUID
var someNumber: Int
var someString: String
@Relationship(deleteRule: .nullify, inverse: \AnotherSwiftDataModel.parentModel)
var childModels: [AnotherSwiftDataModel]
init(uuid: UUID = UUID(), someNumber: Int = 1, someString: String = "Some", childModels: [AnotherSwiftDataModel] = []) {
self.uuid = uuid
self.someNumber = someNumber
self.someString = someString
self.childModels = childModels
}
func addChildModel(model: AnotherSwiftDataModel) {
self.childModels.append(model)
}
func removeChildModel(by id: PersistentIdentifier) {
self.childModels = self.childModels.filter { $0.id != id }
}
}
and the child model:
import Foundation
import SwiftData
@Model
final class AnotherSwiftDataModel {
// Stable cross-device identity
@Attribute(.unique)
var uuid: UUID
var someNumber: Int
var someString: String
var parentModel: MySwiftDataModel?
init(uuid: UUID = UUID(), someNumber: Int = 1, someString: String = "Some") {
self.uuid = uuid
self.someNumber = someNumber
self.someString = someString
}
}
For now, you can assume I am not using CloudKit - i know for a fact the error is unrelated to CloudKit, because it happens when I am not using CloudKit (so I do not need to follow CloudKit's requirements for model design, such as nullable values etc).
As I said, the error surfaces at different times - sometimes during assignments, a lot of times during deletions of related models, etc.
Could you please explain what I am doing wrong and how I can make sure that this error does not happen? What are the architectural patterns that work best for SwiftData in this case? Do you have any examples of things I should avoid?
Thanks