Configuring CloudKit CKModifyRecordsOperation retries to prevent duplicate writes

Goal

Configure a CloudKit modify operation so that a retry after a timeout or rate‑limited error does not create a duplicate record and does not silently overwrite concurrent edits made by another client.

Constraints and uncertainty

The operation uses a fixed CKRecord.ID to guarantee idempotency, but the chosen savePolicy (.ifServerRecordUnchanged, .changedKeys, .allKeys) determines how a retried save interacts with the server version. When the server returns CKError.serverRecordChanged, the app must decide whether to treat the error as a final conflict, merge the locally changed keys, or overwrite the server record. Additionally, partialFailure results and the isAtomic flag affect whether a batch‑level retry resends only the failed records or the whole set, and the retry‑after delay must be respected to avoid hitting rate limits.

Because the documentation leaves the conflict‑resolution strategy to the developer, the exact behavior that satisfies both “no duplicate writes” and “preserve concurrent edits” remains an open decision.

• Which savePolicy should be applied on a retry to avoid overwriting concurrent edits while still guaranteeing that the retry updates the existing record?
• Should CKError.serverRecordChanged be treated as a definitive conflict requiring user intervention, or can the app safely re‑apply only the locally changed keys?
• How can partialFailure and isAtomic be combined to retry only the records that actually failed without reprocessing those that already succeeded?