Most engineers pick a library and start building.
I pick a library and try to break it first.
The requirement
A multiplayer mobile project needed real-time turn-based sync across devices on React Native. Most real-time sync solutions are built for web. Most game state libraries assume a browser. The intersection of “works on React Native” and “handles turn-based game state reliably” is a short list.
I evaluated several options and landed on boardgame.io.
Why boardgame.io with a caveat
The repo isn’t actively maintained right now. That’s a real concern and I didn’t ignore it. But the community has already forked it, and the core abstraction — a server-authoritative state machine with deterministic move validation — is exactly right for turn-based multiplayer. boardgame.io runs on a Koa server out of the box. I was betting on the foundation, not the maintenance status.
But I wasn’t going to bet production code on it without testing it first.
What I built to validate it
Two player views rendered side by side on a single device first. That’s the fastest way to confirm the state machine is working before you introduce network variables.
Then I tested across separate devices on completely different networks. boardgame.io has a built-in Lobby system where players create or join a match with a generated match ID. I wanted to know if the sync held up end to end under real conditions, not just localhost.
It did.
What the test confirmed
The state sync was reliable across devices on separate networks. The server-authoritative model meant the client never had to trust itself — every move gets validated on the server before it’s applied, which is the right architecture for a game where the integrity of each move matters.
What it also surfaced
boardgame.io’s client is built for web. The React Native integration works but reconnection handling needs explicit attention. When a device locks or drops signal briefly, the default transport doesn’t reconnect cleanly. That needed manual handling.
Room auth was the other gap. The default Lobby has no enforcement at the join step — anyone with a match ID can join. For this project that wasn’t acceptable, so I added JWT verification at the join endpoint. Only authenticated users with a valid session can enter a room.
Both of these would have been expensive to discover mid-build. Finding them in a prototype cost a few days. Finding them in production would have cost a rewrite.
The point
That prototype was what moved the client to commit fully to production development. Not because it looked good. Because the hardest technical question had an answer before anyone had written production code around it.
Validate the architecture before you validate the UI. The UI can change. A broken multiplayer foundation cannot be patched cheaply.
Building something that needs real-time multiplayer on React Native? I’d like to hear about it.
Book a 30-minute call: cal.com/gr1ntch/30min
or reach me at odewumimighty@gmail.com