check the creatorUserRecordID field of the CKRecord https://developer.apple.com/documentation/cloudkit/ckrecord/1462208-creatoruserrecordid

not sure of this, but what thread does Auth.auth().addStateDidChangeListener {} call into? Inside that, you're using the viewContext, which must used be on the main thread.

I suggest turning on all the debugging capabilities of Core Data, this article does a great job summarizing them https://useyourloaf.com/blog/debugging-core-data/

if there is a question here, the answer is to do what it says "Retry after X seconds". The actual time is included in the info dictionary of the error. Here's a snippet from CloudCore, an open-source sync engine, that shows how it retrieves this info… private func handle(error: Error, …) { guard let cloudError = error as? CKError else { … return } switch cloudError.code { case .requestRateLimited, .zoneBusy, .serviceUnavailable: if let number = cloudError.userInfo[CKErrorRetryAfterKey] as? NSNumber { let pauseUntil = Date(timeIntervalSinceNow: number.doubleValue) } … } }

In my experience, no. You should manually trigger your sync logic.

can you reproduce in iOS 16.2? If yes, file a bug in FeedBack Assistant

fwiw having the share link in and of itself doesn't give any access to the root record or zone being shared.

Yes, checking that box encrypts the data on CloudKit. You can learn more about it here https://developers.apple.com/videos/play/wwdc2021-10015/?time=1285 BUT, you might consider storing passwords in the Keychain instead.

explore CoreImage https://developer.apple.com/documentation/coreimage

sounds like a race condition

please file a bug report in the Feedback Assistant app.

FetchRequeset has its own sort descriptors. Better to let it resort itself. Also, is Table optimized for lots and lots of items?

AFAIK, No. ARBodyTracking uses the lidar sensor to detect 3D body position. You can use Vision to detect 2D body pose information on a video, if that helps.

I, too, have noticed that the pricing information seems to have been scrubbed from Apple's websites. Looking at my existing containers, it appears the public storage limits fall and rise based on active users. In the CloudKit dashboard, head over to Telemetry, Usage to see for yourself.

imo "occasional crash" almost always means "race condition". Look at refactoring your code to add and remove objects in the - (void)renderer:(id )renderer updateAtTime:(NSTimeInterval)time callback?