Conflicts need an explicit resolution rule
Aliases: conflict copy · last-write-wins · merge conflict · forked replica
What it is
The same note lost a sentence on a phone in flight and gained a different sentence on the office computer; after landing, both claim to be current. Delay produces old-and-new. A conflict is two new versions that cannot be auto-merged. iCloud Notes turns that into a “conflicted copy”; some calendars quietly keep the later write. Without a public rule, people cannot tell which edit vanished, or which device to wait for next time. The rule has to be knowable in advance, not explained after data disappears.
Why it happens
Once two devices commit writes in an unaligned window, the system must pick among last-write-wins, side-by-side retention (conflict copy / fork), or field-wise merge. Last-write-wins is cheap and evaporates the earlier edit from the UI, so people conclude they never saved. Side-by-side drops no words, but “which one is my note” becomes a new task, and a title that only says “copy” is still no rule. Field-wise merge works on structured objects (contacts, events) and on free text can assemble a sentence nobody wrote. People do not need the strategy’s name. They need an expectation they can act on: catch one device up before editing offline again, or accept a second copy and know where to look. A rule that lives only in an engineer’s runbook makes every disappearance look random.
Where it stops holding
Read-only replicas, or a side clearly marked “view, cannot edit,” never produce a second new version; conflict rules do not apply. Collaborative editors with operational transformation have their own merge semantics and must not collapse to whole-document last-write-wins. Binary objects (an exported image, an encoded video) usually keep two copies or pick a side; they cannot be spliced by field. On a shared family reminder, the conflict may be two people rather than two machines, and the rule has to say whose edit, not only which device.
Applying it
- Pick and publish a strategy for objects that get edited offline: last-write-wins, conflict copies, or field-wise merge, in copy the user can see, not only in sync logs.
- Last-write-wins must leave a recoverable previous version in history; a covered sentence must not become unfindable.
- When forking, title the extra copy by source and time (“edits from the phone at 14:02”) and prompt on open that another version exists, rather than letting people trip over “copy” in the list.
- Verify on one note: edit the first sentence on a phone in airplane mode, the last sentence on an offline computer, then restore network. The result must be the declared strategy—one copy with history, two side by side, or a sentence-level merge—and the person must be able to point to where the dropped or split part went. Do not face the user with “the server wins.”