13.7 · Syncing data across devices: conflicts, tombstones and CloudKit

The moment data lives on two devices, every write can conflict with another. Sync is a design problem first, an API problem second.

Mental model. You need three answers up front: how to name a record (stable ids), how to know what changed (versions or timestamps) and what wins when both sides changed.

Sync

Identity, change tracking, conflict resolution and deletion.

1. How would you design multi-device sync: identity, change tracking, conflict resolution, deletions and CloudKit? 13.7.1 · L8
   Sync is replicating state between devices that can change it offline and concurrently. Build it from four ideas. Stable identity: every record has a globally…

More in Persistence & data

• 13.1 · Where data belongs, and the Keychain
• 13.2 · SQLite fundamentals: transactions, WAL, constraints, indexes and migrations
• 13.3 · The Core Data stack, contexts and faults, concurrency, and migrations
• 13.4 · SwiftData: models, contexts, predicates, actors and schema evolution
• 13.5 · The repository pattern and cache design
• 13.6 · Crashes mid-write, integrity, backups and data protection
• 13.8 · UserDefaults surprises and FileManager essentials
• 13.9 · Reading query plans, typing and NULL, WAL locking, savepoints and full-text search
• 13.10 · Merge conflicts, faults and batch requests, delete rules, and the SwiftData context
• 13.11 · Keychain status codes, detecting corruption, an LRU cache and library trade-offs