Every app makes every other app better.
Parlor runs one matchmaking pool across every app on the network. This page is the deeper story: how cross-app play works, what the math says, and what never crosses the wall.
One game, many skins.
A Parlor game lives on the server: the position, the clocks, the rules. Each player's app renders that state in its own UI and sends moves back.
Players never leave your app
A user silencing an alarm in one app plays a user waiting out a loading screen in another. Each sees the game in their own app's design. Parlor is the table they sit down at, not the room they walk into.
Clients are pure renderers
Every move is validated server-side against the authoritative position, and the server pushes state frames over a WebSocket. If your client can draw a board and send a move, it qualifies. SwiftUI, web, VR.
Global by default. Private by choice.
Global pool
The default. Your players match against players from every app on the network, inside a rating band that widens while they wait. Your app inherits the whole network's liquidity on day one.
Private pool
Opt in per app. Matches stay inside your own user base. You keep server-authoritative games, clocks, and ratings. You give up shared liquidity, which is a real cost, so choose it for product reasons, not by reflex.
Why five small apps beat one.
A live match needs a rating-compatible opponent queued at the same moment you are. That is a coincidence, and coincidences scale with pool size.
One app, alone, on a weekday morning. The chance that one of those six players queues in the same 15 seconds as you is poor. The queue stalls, the feature feels dead, and dead features train users to stop trying.
The same app plus four peers on the shared pool. Five times the coincidences. Waits collapse, bands stay tight, and every new app on the network moves this number the right way for everyone.
Illustrative numbers, not measurements. The direction is the point: liquidity compounds across apps, and it is the one thing no single app can build alone.
About 15 seconds, or you know.
Liquidity is probabilistic. Your UX should not be.
- Bands widen while you waitMatchmaking starts inside a tight Elo band and widens it gradually, trading a little fairness for a match instead of stalling.
- The 15 second signalIf the pool has not produced a fair human match in about 15 seconds, your app knows early enough to offer a bot fallback. The user gets a game either way. Bot games do not count toward game-active pricing.
- Quick modes are boundedEach activity has a quick mode with a hard shape. For chess, a three-puzzle drill under three minutes. Apps use it as a completion gate: a wake-up check in an alarm app, a pass-the-time in a loading screen.
Shared pool, unshared doubt.
A network-wide rating is only worth having if nobody can fake it.
- Server-authoritative everythingMoves are validated against the authoritative position. Clocks run on the server, with disconnect grace. Resign, timeout, and abandonment are handled where the game lives.
- One Elo, one transactionEach player carries a single rating across the network, with a provisional badge under 10 games. Result and rating commit together, so a client cannot forge either.
- Receipts, not claimsApps verify completed sessions through the API, with timestamps from the server clock. A gate is done when Parlor says it is done.
Partners own their users.
Cross-app play does not mean cross-app identity. The wall between apps is deliberate.
- Parlor holds an opaque id and gameplay, nothing elseYou provision players by your own user ids. Parlor never sees emails or names, serves no ads, and sells no data.
- What crosses the wallOpponents see a generated handle, a parts-based avatar, a rating, and by default the app someone plays from. That is the whole list.
- You can leave cleanlyDelete players at any time through the API. The relationship with your users stays yours.