Publish rollout: when players get the new version

Your update goes live the moment the publish command finishes. But players don't all switch to it at the same instant. That's on purpose: a tile always opens from whatever is already on the player's phone so it starts instantly, instead of making them wait while it checks for a newer version. So the update reaches people quickly, not instantly.

The player's situation	When they get your update
They have never opened your tile on this phone	Right away. Nothing is saved on their phone yet, so it downloads your newest version.
They have opened your tile on this phone before	On their next open after this one. To start instantly, the tile opens the copy already saved on their phone — the old version — and downloads your new one in the background while they play. The following open uses it.
Your tile is open on their screen right now	Within about 30 seconds a "Reload" option appears — nothing is needed from them to make it show up. They keep playing the old version until they tap it.

A few things that are always true:

• A tile never swaps versions out from under someone mid-play. Players finish what they're doing and reload when they choose.
• One exception, and it's the important one: if your update changed the shape of saved data (you bumped TILE_SCHEMA_VERSION), reloading isn't optional. Those players see a "Reload required" message and switch to the new version as soon as they tap it — including on that first open in row two above. This is why a migration matters: it's what carries their existing games and rooms across the change instead of wiping them.
• If the tile is closed, or open but sitting in the background, nothing happens until they come back to it. That's why an update you publish at night shows up as a reload prompt the next morning.
• Your own phone is a special case. Publishing tells your own devices right away, so your next open is always the new version — handy for checking your work, but a reminder that your experience is faster than a player's.