How I Synced Unity Game Saves Between Android and a Browser

How I Synced Unity Game Saves Between Android and a Browser — a violet cloud sync arrows above a phone and browser symbol on white.

How I Synced Unity Game Saves Between Android and a Browser — I wanted players to be able to start Gem Forge Idle on Android and continue in a browser without sending a save file to themselves. The setup that worked for me had three parts: the same verified account on both devices, a save service shared by the two editions, and a clear indication that the server had accepted the latest save. Signing in solved the identity question. It didn’t, on its own, move any progress.

Gem Forge Idle’s portrait mining screen, with the resource bar and bottom controls.
The portrait mining interface in Gem Forge Idle.

Guest play and cloud play are two different promises

I kept Guest play available because a player shouldn’t have to make an account just to try the game. A Guest save stays on the device or browser where it was created. Opening the same game on another device doesn’t move it. The cloud path is opt-in. On compatible Android and browser versions, I sign in using the same Google account and let the two clients resolve that login to the same Firebase user.

I used Firebase Authentication with Google Sign-In to identify the player, and a separate service on my site to store the save. That was my implementation, not the built-in Unity Cloud Save service or a promise that Google Play Games handles my browser saves. The server verifies the credential, resolves the user from that verified identity, and keeps the saves for different games separate. It doesn’t accept a user ID typed into a request as proof that the caller owns that save.

Give the server a way to reject stale progress

A save service needs more than an upload and download button. Say I play on the phone, then open an older browser tab that’s still holding yesterday’s snapshot. If the service accepts the last request to arrive without checking what it was based on, that browser can undo the phone’s progress. The relevant question is not which device made the request, but whether it is writing against the current save revision.

The server tracks the current revision so it can reject uploads based on an older save. A reset or deletion starts a new save generation, so a device that missed the reset can’t restore the old progress when it comes back online. An older client should not bring back a deleted save just because it comes online later. When there’s no connection or a write fails, local progress can still be useful, but the game must not label it as synced. The player needs an honest status and a retry path, not a green checkmark based on an upload that has merely started.

Gem Forge Idle’s web panel explaining Guest, Google sign-in and cloud saving, with an Account deletion link.
The panel below the Gem Forge Idle player explains Guest and cloud progress and links to account-deletion instructions.

How I Synced Unity Game Saves Between Android and a Browser

I tested both directions with the same Google account: from Gem Forge Idle on Android to the browser version, then back to Android. For a repeatable version of that test, pick a visible change: buy an identifiable upgrade or reach a milestone you can recognize on the second device. Make the change on the source device, wait for the save confirmation, then open or refresh the destination and check the actual progress. Repeat in the opposite direction with a different change. Two screens that both say you’re signed in don’t prove the same save arrived.

I also make a point of distinguishing refresh from a hard case: closing an app or tab quickly after changing something. The browser may stop a request when the page closes, so I don’t tell people that shutting the tab is a guaranteed upload. Test a quick close as a separate scenario and see whether the UI accurately explains the result on return. I don’t use an important save for destructive tests such as deletion or reset.

What to check when progress doesn’t appear

Confirm that both editions support accounts, that the same Google account is in use and that the source actually reported a server-confirmed save. Then check whether the destination loaded the current snapshot, instead of simply opening an existing local session. If you develop both clients, log the minimum information needed to compare the save versions without printing tokens or the player’s full save.

The feature made sense to me only when I could put one device down, open the other, and recognize what I’d just done. That remains my acceptance test: transfer a real change both ways, keep Guest working, and never call a pending upload a completed save. If you want to try it on a second device, here’s the browser version of Gem Forge Idle.

Follow the next build

Get new project stories, updates and real results by email.

No spam. Unsubscribe anytime.

Comments

Leave a Reply