I'm using SwiftData with CloudKit private database. I was able to identify the error on my device by debugging in Xcode with com.apple.CoreData.SQLDebug flag. However, in Production, I couldn't find a way to get the cause of errors.
I tried inspecting the error coming from eventChangedNotification. The NSPersistentCloudKitContainer.Event error does not contain any underlying error (neither CKError.userInfo nor in NSError.underlyingError). It only reports a partial failure with CKErrorDomain code 2.
If a user encounter an error, there seems to be no way to retrieve the error details.
Is there any way to access the error details or logs in Production?
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
We have an unreleased SwiftData app for iOS18+. While we were testing I saw reports on the forum about unexpected database migrations for codable arrays on iOS26.1.
I'd like to ask a couple of questions:
1- Does this issue originate from the new Xcode version, or is it specific to iOS 26.1?
2- Is it possible to change our attribute so that users on older iOS versions receive the same model, preventing a migration from being triggered when they upgrade to iOS 26.1?
One of our models looks like this:
struct Point: Codable, Hashable {
let x: Int
let y: Int
}
@Model
class Grid {
private(set) var gridId: String = ""
var points: [Point] = []
var updatedAt: Date = Date()
private(set) var createdAt: Date = Date()
#Index<Grid>([\.gridId])
...
}
I can think of some options like:
// 1
@Attribute(.transformable(by: CustomJsonTransformer.self)) var points: [Point] = []
// 2
@Attribute(.externalStorage) var points: [Point] = []
// 3
var points: Data = Data() // store points as data
However, I'm not sure which one to use.
What would you recommend to handle this, or is there a better strategy you would suggest?
I followed these two resources and setup history tracking in SwiftData.
SwiftData History tracking:
Track model changes with SwiftData history
For data deduplication: Sharing Core Data objects between iCloud users
In the sample app (CoreDataCloudKitShare), a uuid: UUID field is used for deduplication logic. It sorts the entities by their uuids, reserves the first one, and marks the others as deduplicated.
Would it be a viable solution to use a createdAt: Date field for the sort operation instead of a uuid field, or are dates inherently problematic?