What Happens to a Player's Progress When They Change Phones?
A player spends six months on your game, buys the season pass, reaches level 400 — then gets a new phone and their progress is gone. Support tickets pile up, the store reviews turn savage, and the root cause is a design decision you made on day one without realizing it. Here is what actually has to be true for "change phones" to mean "keep playing."
Q: Why is a device ID not a save system?
Because a device ID — IDFA, GAID, Android ID — is an attribution token, not an identity. It resets on factory reset, vanishes on a new device, and is increasingly gated behind privacy prompts (ATT, GDPR, and platform defaults). The moment a player changes hardware, that ID is gone, and if your progress is keyed to it, so is their account. Identity has to come from something the player carries: an email, a phone number, or an SSO. Anything else quietly turns a phone upgrade into data loss, and players blame your game, not their OS.
Q: How do you resolve a cloud-save conflict without deleting the player's stuff?
Last-write-wins is the trap: the player plays offline for three days, comes online, and their fresh local progress gets overwritten by a stale cloud file from Tuesday. Version vectors and operation logs (CRDTs) merge cleanly but cost storage and engineering you may not need. For a casual game, field-level optimistic merge is the sweet spot — merge currency, levels, and cosmetics as separate fields, taking the higher or newer value per field — which keeps conflict rates low and loses almost nothing. The catch: decide what counts as truth. Server-authoritative fields (currency, unlocks) must be validated server-side, not trusted off a client timestamp.
Q: Offline-first or cloud-first?
Offline-first means the game plays locally and syncs in the background: smooth on bad networks, but higher conflict rate and a bigger cheat surface. Cloud-first means every action checks the server: clean, but unavailable the instant the connection drops — fatal in markets where connectivity is the exception. The pragmatic answer for casual games is offline-first with background merge plus server validation on the few fields that matter. You trade a little conflict handling for an experience that works everywhere.
Q: How do you stop cheaters from forging a save?
A local save is a plaintext JSON file a player can edit with a text editor or a memory editor — set coins to nine billion, unlock everything. Defense starts at the protocol: don't let the client hold the truth for anything valuable. Server-sign or server-store currency and unlocks, validate on every sync, and run anomaly detection (a player gaining ten years of currency in a day is not a bug, it's a flag). Anti-cheat isn't only a ban-hammer after the fact; the save format itself should make forging useless.
| Strategy | Conflict loss | Cost | Right for |
|---|---|---|---|
| Last-write-wins | high | tiny | throwaway data |
| Version vectors / CRDT | none | high | collaborative state |
| Field-level merge | low | medium | casual games |
