Engineering guides / App maintenance and rescue
By Arte Soft engineering · 24 October 2026
Repairing sync conflicts without choosing silent data loss
Synchronization problems are often described as missing data, but the underlying failure may be a conflict policy, duplicate operation or stale interface. Start by tracing one record across devices. A repair should explain which state wins, what is preserved and how the person knows a conflict occurred.
The decision to make
Identify stable record identities and the history of changes. A name or timestamp alone may not distinguish an update from a new item. Compare local state, queued operations and server versions before applying a cleanup. Deleting duplicates without understanding how they were created can remove legitimate records while leaving the defect ready to repeat.
Write down the business meaning of a conflict. Merging two independent checklist items may be safe; overwriting two edits to a monetary value may not be. A delete competing with an offline update needs a deliberate rule. “Last write wins” is a policy with consequences, not a neutral technical default that suits every data type.
A useful scope of work
A diagnostic scope should create a controlled two-device scenario with separate edits, a reconnect sequence and inspectable record versions. Review retry identities, server acknowledgements and change tokens. For CloudKit-backed code, application-specific conflict resolution remains important even when a framework handles transient errors. Distinguish transport recovery from the decision about competing business values.
The repair phase should implement the agreed merge or user-resolution rule and add regression cases. Include repeated delivery, partial batch failure and deletion. Preserve evidence before any production repair script changes customer records. If existing data needs reconciliation, scope the migration separately from preventing new conflicts and require a reversible or reviewed procedure.
Acceptance checks to agree before delivery
Sync repair acceptance should compare stored records, not simply watch a loading indicator disappear. Use controlled identities and deliberately competing changes on two devices. These checks exercise the merge policy, replay behavior and deletion rules while keeping any existing production-data reconciliation separate from prevention of new divergence.
- Edit the same record offline on two devices and verify the documented conflict outcome after reconnection.
- Replay a previously acknowledged change and confirm that it does not create a new logical record.
- Delete on one device while editing on another and inspect the resulting state and user explanation.
- Reproduce a partial failure and verify the documented atomicity: all-or-nothing for atomic batches, or successful items persist while failed items retry without duplication.
Constraints and what to send us
Send the data model, identifiers, sync architecture and a sanitized example of divergence. Use designated test accounts and records; do not reproduce an issue by deleting real shared calendars or production content. A network-success message is not enough to verify synchronization. The acceptance evidence should compare persisted state on both devices and the server, where accessible.
Our own product reference and a starting engagement
Synchronization diagnosis and conflict-policy implementation. Cloud Calendars provides an owned product reference for multi-source calendar workflows. That reference does not establish the right merge rule for your records. A first engagement can isolate one reproducible divergence and agree a safe repair before touching existing production data.
Read the portfolio reference narrowly
Cloud Calendars is a multi-provider calendar product reference. Its public listing is not evidence that it uses the CloudKit conflict mechanisms discussed here. The implementation plan must follow your actual source of truth, API contracts and batch atomicity.
Relevant Arte Soft work
Cloud Calendars: Sync & Widget is our own product or engineering project. It provides context for the work we discuss here; it is not a claim of identical results for every client deployment.
Sources and further reading
Need help with Synchronization diagnosis and conflict-policy implementation?
Send the current app, system or brief, the behaviour you need and your constraints. We can agree a discovery, implementation or repair scope with concrete acceptance criteria.
Discuss this with Arte Soft