Skip to main content
A Turntable game is one complete, self-contained HTML document, served inside a sandboxed WebView in the Turntable app.

​
Requirements

  • All CSS and JS inline. No external resources, no network requests (other than what the injected SDK makes on your behalf), no imports.
  • Mobile portrait, touch-first: large tap targets, one-thumb play. Include the viewport meta tag and disable text selection/tap-highlight on interactive elements: 
    <meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">
  • Instantly playable: understandable within 2 seconds. Show a one-line instruction on screen. No menus or splash screens.
  • Dark background (the feed is dark), bold readable text, generous spacing.
  • Short rounds (5–60 seconds), immediately restartable by tapping.
  • No alert/confirm/prompt, no console spam, no localStorage (it isn’t durable in the app — use Turntable.saveState instead).
  • Plain ES5-compatible JavaScript is safest. Keep the document under ~40KB.
  • Never define window.Turntable yourself — the platform injects it before your code runs.

​
The sandbox and security model

Your game document receives a short-lived, game-scoped token — not the player’s session. It can only reach SDK endpoints for your own game. It can never act on the player’s account, approve purchases, or read other games’ data. Purchase confirmations happen in native UI outside your document entirely — see Economy.

​
Manifest settings

  • requiresAccount — restrict your game to signed-in players. Enforced server-side (the document is never served to guests) and surfaced in the feed as ”🔒 Sign in to play”. Use it when your game depends on identity features that are meaningless for guests.