Posts

Post not yet marked as solved
10 Replies
First, my feedback number: FB13329733. I took one of my DTS tickets and requested some help on this issue. This seems to be an actual bug in CoreData: Every Core Data CloudKit store has several tables to store the synchronization state, and ANSCKRECORDMETADATA is one of them. It stores the maps between Core Data entities and CloudKit record types, and has a unique constraint on its ZENTITYID and ZENTITYPK attributes. When migrating an existing store, Core Data analyzes the source and destination model versions, and updates the tables so they reflect the new model version. The constraint conflict, I reported, was triggered in the process. The issue doesn’t happen when I use NSPersistentContainer because Core Data doesn’t migrate the tables when CloudKit doesn’t get involved. The migration process is completely internal to Core Data, and there is no supported way for developers to impact the behavior. The DTS engineer couldn't provide me with more details except the notice that the issue has been forwarded to the CoreData team.
Post not yet marked as solved
10 Replies
Did anyone have success with this? I'm currently facing the same issue in a project.
Post not yet marked as solved
9 Replies
I see a similar issue on dragging a view around with the onDrag modifier: In the console I see lots of identical warnings: Found no UIEvent for backing event of type: 11; contextId: 0xcb35f894 When that happens my drag cancels and I have to retry it a couple of times before my drag works
Post not yet marked as solved
11 Replies
I see the same issue and already submitted a feedback: FB12905731
Post marked as solved
8 Replies
For the cascade issue you can add deleteRule: in front of it. The issue regarding Variable 'self._$backingData' used before being initialized is something different. You are right, removing the default value fixes the compile time error but breaks automatic CloudKit sync (FB12905731).
Post marked as solved
11 Replies
I face the same issue. The app freezes and consumes all memory it has while being at 99% CPU.
Post marked as solved
8 Replies
I'm having the same issue with the same crash log. I filled a feedback with an example widget: FB12702894
Post marked as solved
1 Replies
I reached out to the Apple Developer Technical support and used one of my TSIs. I got a very nice reply explaining the error to me and I want to share my new learnings with everyone else here: “Cocoa-Error 134419” is an internal error indicating that the Core Data CloudKit aborts the persistent history analysis because the activity was deferred by the system. That normally happens when the system determines that Core Data CloudKit is using too many resources. From the app perspective, it means the app has too much data to export. Core Data CloudKit may continue the history analysis later and when the system allows, but before that, it can’t export data to CloudKit. From a developer's perspective, there is nothing you can do to prevent this (except not storing too much data in Core Data). "There is no way from the app side that can impact the resource balancing on the system side." I hope this helps everyone who is coming across this issue themself.
Post not yet marked as solved
16 Replies
I have the same issue with my apps. My most used app only has an entry from a version that I release over 1.5 years ago. Is there any update regarding this issue? I can reproduce it in the latest Xcode 12, Xcode 13 beta and previous Xcode 12 and Xcode 11 versions.