SwiftUI Idempotency & Duplicate Prevention (Correctness in Distributed Systems)

Most apps assume actions happen once: submitOrder () That works… until you introduce: retries after network failure background sync offline queues app relaunch recovery migration reprocessing slow server responses user double taps At that point, duplicate operations become one of the most dangerous bugs in your app. This post shows how to design idempotent systems in SwiftUI that are: safe to retry duplicate-proof crash-resilient sync-friendly production-grade 🧠 The Core Principle Retrying an operation must not change the result. If running an action twice creates a different outcome, your system is fragile. 🧱 1. What Is Idempotency? An operation is idempotent if running it multiple times has the same effect as running it once. Safe: deleteItem ( id ) Running twice → item is still deleted. Unsafe: createOrder () Running twice → two orders created. ⚠️ 2. Why Mobile Apps Need Idempotency Mobile environments guarantee retries: network timeouts trigger retries background tasks may run twic