Why Beacon?

You want to build the next great party game for living rooms. The two paths in front of you are bad: spend weeks building networking infrastructure instead of gameplay, or ship on AirConsole and hand over 30% of your revenue plus total platform control.

Beacon is the third path. You keep the gameplay, the revenue, the branding, and the distribution. We handle the part that sucks — device discovery, cross-platform UI, reconnection, relay fallback.

The iceberg

Here's what you'd actually need to build for a production shared-screen experience. The WebSocket connection is the tip.

Discovery

  • • mDNS service registration and browsing across platforms
  • • Handling duplicate service names on the same network
  • • Fallback when mDNS is blocked (corporate/school networks)
  • • Room codes that work across local and remote connections

Connection reliability

  • • Phone screen lock drops the WebSocket — buffer inputs, resume seamlessly
  • • Android kills background sockets after 30 seconds
  • • WiFi roaming changes the device IP mid-session
  • • Switching between 2.4GHz and 5GHz bands
  • • Corporate firewalls that block WebSocket upgrade
  • • Graceful degradation on conference WiFi with 200 devices

Session management

  • • Player identity across reconnections
  • • Session state recovery — not just reconnect, but resume
  • • Host migration if the host device sleeps
  • • Handling 32 concurrent connections without latency spikes
  • • Cleaning up stale sessions and zombie connections

NAT traversal & relay

  • • Detecting when local connections can't be established
  • • Transparent fallback to cloud relay
  • • TURN-style relay for symmetric NATs
  • • Relay connection must feel identical to local — same API, same latency class

Cross-platform

  • • Native mDNS on iOS (NWBrowser), Android (NsdManager), and web (none — need fallback)
  • • WebSocket behavior differences across browsers and OS versions
  • • Background execution policies on iOS vs. Android
  • • Controller UI that works on 4-inch phones and 6.7-inch tablets

Beacon handles all of this. You call Beacon.host(controllerTemplate: "trivia-buzzer"), handle onControllerInput, and ship your game. Discovery, reconnection, buffering, relay fallback, session management, and the controller UI itself are handled for you. When something breaks on living-room WiFi at 9pm, it's our problem, not yours.

The alternatives

There are real options. Here's what each one gives you and what it doesn't.

Socket.IO / raw WebSocket

Client-server WebSocket library with rooms, broadcasting, and auto-reconnect.

What you get

  • WebSocket connection with long-polling fallback
  • Rooms and namespaces
  • Basic auto-reconnection
  • Broadcasting to groups

What you still need to build

  • Requires you to host and scale a server
  • Every message routes through the cloud, even in the same room
  • No local device discovery
  • No input buffering during disconnects
  • No NAT traversal or relay fallback
  • No controller UI — you build every screen
  • No internet = no app

You'll spend weeks building everything around the socket. The connection is the easy part.

PeerJS / simple-peer (WebRTC)

Peer-to-peer connections using WebRTC data channels.

What you get

  • Direct device-to-device connections
  • No server for data transfer (once connected)
  • Works in browsers

What you still need to build

  • Still requires a signaling server for connection setup
  • STUN/TURN servers needed for NAT traversal
  • Connection setup is slow and fragile
  • WebRTC was designed for audio/video, not input messages
  • No local network discovery
  • No session management or reconnection
  • No controller UI

You get peer-to-peer, but you fight the abstraction. WebRTC adds complexity without solving the real problems.

LiveKit / PartyKit / Liveblocks

Managed real-time infrastructure — hosted WebSocket or WebRTC servers.

What you get

  • No server to operate
  • Presence and room management
  • Reliable connections at scale
  • Good developer experience

What you still need to build

  • Cloud-first — every message routes through their infrastructure
  • You pay per-connection, even for local sessions
  • Cloud latency on every input
  • No local network discovery
  • No offline or LAN-only mode
  • No controller UI or phone-as-input abstractions
  • You're locked into their pricing and infrastructure

Solves the ops problem but not the architecture problem. You're paying for cloud latency you don't need.

Multipeer Connectivity (Apple)

Apple's framework for local peer-to-peer — powers AirDrop.

What you get

  • True local-first, no server needed
  • Bluetooth + WiFi discovery
  • Low latency on Apple devices

What you still need to build

  • Apple-only — no Android, no web, no smart TVs
  • No cloud fallback for remote players
  • Limited to Apple ecosystem
  • No controller UI
  • API is aging and can be unreliable

Great technology, wrong scope. If your audience isn't exclusively Apple, it's a non-starter.

At a glance

Beacon
DIY
AirConsole
Keep 100% of revenue
Your own branding
Ship on Steam / consoles
Sub-20ms local latency
Works offline / LAN-only
If you skip the server
No-code controller designer
Limited
Ready-made templates
Web browser controller
Build it
Auto-reconnection
Build it
Cloud relay fallback
Build it (TURN)
Cross-platform SDKs
Build each client
Their player only
Time to production
Hours
Weeks to months
Days
Ongoing infrastructure cost
$0 for local
Server hosting
30% of revenue

The short version

No existing SDK gives an indie game dev a drop-in phone controller layer with a no-code designer, ready-made templates, white-label branding, local-first networking, and a transparent cloud relay fallback.

The walled-garden platform takes 30% and your branding. The DIY route burns months you could spend on gameplay. Neither should be the only choice.

The next Jackbox Games could be built by a solo indie developer using Beacon.

Sign Up