Post

Replies

Boosts

Views

Activity

CloudKit Limitations
itle NSPersistentCloudKitContainer sharing with relational Core Data graph fails with 134060 multi-zone corruption Post I’m looking for guidance from Apple or other developers on the supported limits of NSPersistentCloudKitContainer sharing for relational Core Data graphs. My app uses Core Data + CloudKit sharing with graphs like: Athlete -> Performance -> Compevents -> CompEventsSplits and Athlete -> NewYtp -> AthPlans -> PlanWeekRow The failure mode I keep hitting is: • export fails with NSCocoaErrorDomain Code=134060 • failure reason says related objects are assigned to multiple zones • after that, I may also see Zone Not Found, history-analysis corruption, and reset/recovery that still leaves the mirrored store unusable This seems to happen once one logical graph is effectively spread across multiple CloudKit share zones. Questions: Is this an expected limitation of Core Data + CloudKit sharing for related object graphs? Is there a supported pattern to guarantee one logical graph remains in one share zone? Once 134060 multi-zone corruption occurs, is there any supported recovery path besides resetting the mirrored store? For complex shared relational app data, is NSPersistentCloudKitContainer still the recommended approach? I’m mainly trying to understand whether this is: • a bug • a design limitation • or expected behavior with a required architectural constraint If Apple engineering has guidance on the supported boundary here, I’d appreciate it.
0
0
38
1w
CloudKit Limitations
itle NSPersistentCloudKitContainer sharing with relational Core Data graph fails with 134060 multi-zone corruption Post I’m looking for guidance from Apple or other developers on the supported limits of NSPersistentCloudKitContainer sharing for relational Core Data graphs. My app uses Core Data + CloudKit sharing with graphs like: Athlete -> Performance -> Compevents -> CompEventsSplits and Athlete -> NewYtp -> AthPlans -> PlanWeekRow The failure mode I keep hitting is: • export fails with NSCocoaErrorDomain Code=134060 • failure reason says related objects are assigned to multiple zones • after that, I may also see Zone Not Found, history-analysis corruption, and reset/recovery that still leaves the mirrored store unusable This seems to happen once one logical graph is effectively spread across multiple CloudKit share zones. Questions: Is this an expected limitation of Core Data + CloudKit sharing for related object graphs? Is there a supported pattern to guarantee one logical graph remains in one share zone? Once 134060 multi-zone corruption occurs, is there any supported recovery path besides resetting the mirrored store? For complex shared relational app data, is NSPersistentCloudKitContainer still the recommended approach? I’m mainly trying to understand whether this is: • a bug • a design limitation • or expected behavior with a required architectural constraint If Apple engineering has guidance on the supported boundary here, I’d appreciate it.
Replies
0
Boosts
0
Views
38
Activity
1w