Most teams add achievements as a user profile column and lose everything when the player reinstalls. Achievements need granular event tracking and a state machine that survives outside the app. Otherwise you rebuild progress from memory every time a device changes. The decision is where that state lives and how events flow into it.
What actually decides whether achievements stick
The trigger logic and where you store the unlock state.
Fire an achievement the moment a player crosses a threshold - say, collecting 100 coins - and save that unlock immediately to persistent storage. The achievement will survive app reinstalls and device changes. Wait until the end of a session or leave the state in memory? Reinstalls wipe it.
Three things control durability. When you check the condition determines whether unlocks happen in real time or get batched at session-end. Where you write the unlock determines whether progress survives on the same device only or carries across platforms. Whether you log the event determines whether you can replay the logic server-side and recover any unlock missed during a network dropout.
We covered the sync and recovery patterns in leaderboards and achievements. The same principles apply: write state changes as soon as they happen, and treat the event log as the source of truth when the local state and server state diverge.
The questions to settle before you write code
Before we touch a line of code, we settle three questions with the client: what counts as an achievement, where the unlock happens, and what survives a reinstall.
What counts as an achievement. Is it tied to a single action or a streak? Does it need cumulative data across sessions? We built streaks in Destiny AI Journal and level unlocks in Jungle Jump. The logic is different and the tracking changes.
Where the unlock happens. Client-side checks are instant but easy to manipulate. Server checks are secure but add latency. For offline games like Snow World, we validate locally and sync when the player reconnects.
What survives a reinstall. Achievements in local storage vanish when the player reinstalls. Cloud-synced achievements persist but require an account system. We make that call based on whether social sharing of unlocked achievements is part of the design.
These three boundaries determine the rest of the build. We document them before the prototype so the implementation matches what the game actually needs.
How to build achievements that survive reinstalls
The achievement data lives outside the app. When someone deletes and reinstalls your game, the achievements come back because they are stored server-side, tied to their account. Local-only achievements disappear with the app.
You track state, not every action. Store the current progress counters and unlock flags in a database. When a player completes a level, increment the counter. When it hits the threshold, flip the unlock flag to true. The database holds one row per achievement per player, not a log of every move they made.
Events feed the state machine when actions happen during gameplay. When the player earns 100 coins, the event triggers an update to the coin counter. The state persists; the event does not need to. This pattern keeps the database small and lookups fast, which matters when checking unlock conditions every frame.
Retention depends on progression systems that feel fair. Achievements that reset on reinstall make players assume the game lost their data. They leave before they hit the tutorial. Server-side state removes that risk.
What to check before you ship
Run the achievement system in a private test build with all unlock conditions dialed down. If the first achievement requires ten wins, drop it to two. If a milestone needs thirty minutes of play, set it to three. You need to watch the entire flow complete in under ten minutes.
Check that progress survives a force-close and a reinstall. Kill the app mid-session, reopen it, and verify counters pick up where they left off. Uninstall, reinstall, and confirm achievement state returns if tied to an account. If your cross-platform mobile apps sync through a backend, test the sync path under poor network conditions. Dropped packets should queue retry attempts, not lose progress.
Test edge cases: what happens if two achievements unlock in the same frame? If the user dismisses a popup before the animation completes? If they trigger an unlock while offline? Write a test script that hits all milestones in sequence. Watch for race conditions or missing UI states.
Verify event logging. Every unlock should write a timestamped entry you can query later. If an achievement fails to trigger, the log tells you whether the condition was met but the reward didn't fire, or the condition itself never happened.
How to tell your achievement system is working
Track three signals, not just unlock counts.
First, check completion rates by tier. If less than 60% of active players unlock your first-tier achievements, the triggers are too strict or too obscure. If more than 90% unlock everything in the first session, the progression curve is too flat.
Second, measure time between unlock and next session. Players who unlock an achievement and return shortly after are engaged. Players who unlock and never come back saw the achievement as a stopping point. That means your reward timing is wrong.
Third, watch server sync failures. Track achievements server-side? Log every failed POST. A 5% failure rate sounds small until you realize it means one in twenty players loses their progress during a network hiccup.
None of this needs analytics software. Query your database, grep your server logs, or add three console statements. The data tells you whether the system works before players start complaining.
Top comments (0)