I am writing an initialization method for CloudKit. The problem that I encountered occurs when getting the user ID / account status.
I am calling [[CKContainer defaultContainer] fetchUserRecordIDWithCompletionHandler:] .
The crash is a bit later, and the debugger points me to the stream "Queue: com.apple.cloudkit.operation.callback (serial) queue".
This method is the only CloudKit-related callback method to be executed.
Here is the method itself:
[[CKContainer defaultContainer] fetchUserRecordIDWithCompletionHandler:^(CKRecordID *recordID, NSError *error) { NSLog(@"CLOUDKIT Fetching User Record ID"); if (error) { NSLog(@"[%@] Error loading CloudKit user: %@", self.class, error); } if (recordID) { NSLog(@"CLOUDKIT Found User Record ID: %@", recordID.recordName); // If there is a record ID we check for account status [[CKContainer defaultContainer] accountStatusWithCompletionHandler:^(CKAccountStatus accountStatus, NSError *error) { NSLog(@"CLOUDKIT Finding Account Status"); if (error) { NSLog(@"[%@] Error checking CloudKit availability: %@", self.class, error); } if (accountStatus == CKAccountStatusAvailable) { NSLog(@"CLOUDKIT Account Available, beginning initial sync"); // We have an available account. If we have a new user do a complete sync NSString *userRecordID = [[NSUserDefaults standardUserDefaults] stringForKey:CLOUD_KIT_CURRENT_USER_ID_USER_DEFAULT]; if (userRecordID == nil || ![recordID.recordName isEqualToString:userRecordID]){ [self syncAllData]; } else { // If there haven't been any updates, just sync as usual [self syncChanges]; } // Subscribe to zone updates [self subscribeToDefaultZoneUpdates]; } else { NSLog(@"[%@] Cloudkit account is either unavailable or restricted", self.class); } }]; } else { NSLog(@"[%@] CloudKit user Record ID not found", self.class); } }];
There are NSLogs before and after that run, but the NSLog at the very top ("CLOUDKIT Fetching User Record ID") never starts.
On failure, the log does not give me any information. Here is the thread queue from Xcode:

That's what it actually spits out in the debug navigator.
libsystem_kernel.dylib`__pthread_kill: 0x332f7df4: mov r12, #0x148 0x332f7df8: svc #0x80 0x332f7dfc: blo 0x332f7e14 ; __pthread_kill + 32 0x332f7e00: ldr r12, [pc, #4] ; __pthread_kill + 24 0x332f7e04: ldr r12, [pc, r12] 0x332f7e08: b 0x332f7e10 ; __pthread_kill + 28 0x332f7e0c: rsbeq lr, r6, #0x80000001 0x332f7e10: bx r12 0x332f7e14: bx lr
In particular, it splits into 0x332f7dfc: blo 0x332f7e14 ; __pthread_kill + 32 0x332f7dfc: blo 0x332f7e14 ; __pthread_kill + 32