Hi, I came up with a solution based on the code signing certificate check. According to my early tests, it works reliable. Can you confirm?

I’m running into a similar issue with SwiftUI views presented in sheets not properly deinitializing instances of associated properties. Just tested your snippet with Xcode 15 RC and the DeinitPrinter doesn’t execute its deinit regardless of the detents configuration. In fact, it shows the same faulty behavior even without specifying any detents and using a standard full-size sheet. I’m still investigating, but I wanted to ask whether you can confirm this behavior and whether you’ve found a fix or a workaround. Also, have you filed a feedback?

The issue seems to be resolved on iOS 17.2! See this thread on Stack Overflow.

os.log types seem to be annotated as Sendable starting with Xcode 16 β3.

Hi there, I was wondering if you ever managed to sort this out. By the way, are your fields encrypted or unencrypted?

I have recently investigated this and from my observations, the ancestor record can include full field data, but only under specific conditions. When you create the CKRecord to upload from system fields using CKRecord.encodeSystemFields(with:) and restore it with CKRecord.init(coder:), then fill in the fields manually, CloudKit will not populate the fields of the ancestor record in a serverRecordChanged error. You will only get the record metadata. If instead you upload a CKRecord that was created from a full archive using CKRecord.encode(with:), or one that was fetched directly from CloudKit, the ancestor record in the conflict will contain all fields. In short: encodeSystemFields(with:) → ancestor has only metadata encode(with:) or fetched record → ancestor has all fields