Using NSPersistentCloudKitContainer causes crash for iOS 14

In iOS 14, I am trying to use the NSPersistentCloudKitContainer, but there is a crash with the following error message:

Code Block
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Must register a handler for activity identifier "com.apple.coredata.cloudkit.activity.export.[an UUID]" before submitting it'
terminating with uncaught exception of type CKException


Does anyone else have this error? Is there any workaround for this?

I have already filled a bug report FB8618522

Thanks in advance!

Replies

I have verified that the same code does not crash for iOS 13.6 devices. And the bug is still present for the newest beta of iOS 14.
Any workaround?
Facing the same issue. Xcode 12 beta 6 and iOS 14 beta 7.
Same here. I can't test iOS 14 on Device due to this bug. 😒
I encountered the same error in iOS 14.

In my case the problem was, that after app launch I was running two processes, both starting a new background task on the PersistentContainer like this:

persistentContainer.performBackgroundTask { (context) in ...


Waiting for one task to finish until starting the next solved the problem for me.

Hope this helps somebody. Previously I had no such problem running in iOS 13 though...
Encountered the same error in iOS 14.0.1.
Please file a bug and attach your application (or a sample application that reproduces this issue).
I have the same crash, it only happens on iOS14 devices, no such issues before iOS14 is released. Crash stack:

Last Exception Backtrace:
0 CoreFoundation 0x18e36e314 _exceptionPreprocess + 220 (NSException.m:199)
1 libobjc.A.dylib 0x18e08142c objc
exceptionthrow + 60 (objc-exception.mm:565)
2 CloudKit 0x193de4808 -[CKScheduler
submitActivity:withCriteria:] + 520 (CKScheduler.m:145)
3 CloudKit 0x193de832c -[CKScheduler getDeviceCountForActivity:completionHandler:] + 432 (CKScheduler.m:561)
4 CloudKit 0x193de6f2c -[CKScheduler getSuggestedXPCActivityCriteriaForActivity:completionHandler:] + 960 (CKScheduler.m:371)
5 CloudKit 0x193de4510 -[CKScheduler submitActivity:] + 332 (CKScheduler.m:91)
6 CoreData 0x193884414 -[NSCloudKitMirroringDelegate beginWatchingForChanges] + 1156 (NSCloudKitMirroringDelegate.m:573)
7 CoreData 0x1938861d4
52-[NSCloudKitMirroringDelegate performSetupRequest:]blockinvoke + 476 (NSCloudKitMirroringDelegate.m:890)
8 CoreData 0x193884f98 _92-[NSCloudKitMirroringDelegate openTransactionWithLabel:assertionLabel:andExecuteWorkBlock:]blockinvoke + 72 (NSCloudKitMirroringDelegate.m:705)
9 libdispatch.dylib 0x18dffffd0 dispatchcallblockandrelease + 32 (init.c:1454)
10 libdispatch.dylib 0x18e001ac8
dispatchclientcallout + 20 (object.m:559)
11 libdispatch.dylib 0x18e008c08 dispatchlaneserialdrain + 580 (inlineinternal.h:2548)
12 libdispatch.dylib 0x18e009768
dispatchlaneinvoke + 460 (queue.c:3862)
13 libdispatch.dylib 0x18e013528 dispatchworkloopworkerthread + 708 (queue.c:6590)
14 libsystempthread.dylib 0x18e06e908 pthreadwqthread + 276 (pthread.c:2193)
15 libsystem
pthread.dylib 0x18e07577c start_wqthread + 8
In my case it happens when I create a new persistent container, deallocating the old one. It seems that the CloudKit mirroring remains alive, then after few seconds it raises the exception.
No issues in iOS 13.x with same code.
A possibile workaround is to remove the store(s) from the old container, before deallocating it. At that point I have the following log message: "<NSCloudKitMirroringDelegate>: Told to tear down because the store has been removed.". The problem is that this "hack" raises other kind of issues for my app's logic, like UI notifications, so for me is a no go.
My case is exactly like @Michele Longhi's. Except my solution is keeping a singleton of the NSPersistentCloudKitContainer instead of destroying and recreating it multiple times.
Same here. Can't test on iOS14, this sux. Apple employees.. you need to update Xcode asap!! and fix this sh#$*
I called NSPersistentCloudKitContainer multiple times in a controller, and the same problem occurred.
After modifying the code, the instance was created only once, and then called multiple times, the problem was solved.