Platform Requirements

The canonical list of the platform's technical requirements: every constraint and number lives here; other articles link to this page instead of repeating them. The same fact set is served machine-readable by the minit_get_requirements tool of the Minit MCP server. Connect it to validate your game as you build.

How to read this page#

• Hard requirement: enforced. Violating one gets the upload rejected, fails review, or breaks the game on players' devices.
• Recommendation: not enforced, but makes your game load faster, play better, and reach more players.

Bundle#

Your game ships as a single ZIP uploaded through the Creator Console. See Your First Game for the upload flow.

Hard requirements#

• The bundle must be a ZIP file. A single self-contained .html file is also accepted at upload — Studio packs it into a ZIP client-side (using that file as the root index.html) before the same validation below applies.
• The uploaded ZIP must not exceed 50 MB. For a single-file HTML build this is checked twice: against the original .html file you pick, before Studio packs it (so an already-oversized file never reaches the packer), and again against the packed ZIP itself — the packed archive is what actually gets uploaded and enforced server-side, and packing occasionally grows an already-dense file (e.g. one with large base64-embedded media) rather than shrinking it.
• index.html must sit at the root of the ZIP, not inside a sub-folder.
• The ZIP must contain JavaScript: at least one .js file, or a self-contained index.html with an inline <script> block.
• index.html must include a <script> tag, external or inline:

<script src="js/game.js"></script>

<script>
  // game code inline
</script>

• The bundle must be self-contained: every file the game needs (JS, CSS, images, audio, fonts) inside the ZIP. No CDN URLs or remote fetches at runtime.
  • Exception: an MRAID playable's mraid.js reference. An MRAID (Mobile Rich Media Ad Interface) playable conventionally has <script src="mraid.js"> (whose filename is exactly mraid.js — any folder, case-insensitive, but not a look-alike like custom-mraid.js) without shipping that file — Minit's app supplies a compatible window.mraid shim at runtime, so the reference is allowed to resolve to nothing. Every other missing script reference still fails validation.

Recommendations#

• Keep the bundle under 5 MB. 50 MB is the ceiling, not the target.

Tip: Compress your assets before zipping. Audio bitrate and image resolution are usually the biggest wins.

Viewport & rendering#

All hard requirements. Games render full-screen inside a mobile WebView.

• Portrait orientation only.
• Design against approximately 960 × 1480 (roughly 2:3). This is the reference resolution the engine templates ship with, and it is close to the slot a game is actually given — noticeably wider than a phone screen, so a layout built for a tall 9:19-ish handset leaves the sides empty.
• Responsive to any portrait aspect ratio. The reference above is a starting point, not a guarantee: the real ratio varies by device and by surface, so never hardcode pixel dimensions. Use vw/vh/% or window.innerWidth/window.innerHeight, and read them again on resize. No letterboxing or clipping.

canvas.width = window.innerWidth;
canvas.height = window.innerHeight;

• overflow: hidden on the document body.

body { overflow: hidden; }

• The canvas (or game container) must fill the viewport.

canvas { display: block; width: 100%; height: 100%; touch-action: none; }

• Cap the frame rate at 60 FPS and use delta-time so game speed is frame-rate-independent:

const FRAME_TIME = 1000 / 60; // skip the frame if elapsed < FRAME_TIME

Forbidden APIs#

All hard requirements. Games must not use:

• localStorage
• sessionStorage
• fetch()
• XMLHttpRequest
• External CDN resources: no scripts, stylesheets, fonts, or other assets from external URLs
• Device hardware APIs: no camera, microphone, GPS, accelerometer
• Cookies
• Navigation and links: no <a href> to other pages, window.open, location.href/assign/replace/reload, or <meta http-equiv="refresh">. The game must stay on its own document for the whole play — the host detects a second document load and tears the game down.

Tip: To persist something for a player (a best score, a preference), use the SDK's userData API. See Saving User Data. To hand a result back to the host, use window.minit.reportResult(...) instead of any navigation — see Reporting Results.

SDK requirements#

The platform injects its SDK into your game at runtime as window.minit.

Hard requirements#

• Signal readiness when your game can be played (see Game Ready Signal).
• Call window.minit.reportResult(score) exactly once when the game ends.

window.minit.reportResult(score);

• score must be a number, never a string or null. No required range; higher wins by default, and the game's configuration can invert this. Full API: Reporting Results.

Recommendations#

• Pass a short flavorText: a 1–2 sentence line shown alongside the score.

window.minit.reportResult(12500, { flavorText: "Caught 12 fish!" });

• Time the delay option (ms) to your closing animation, typically 500–1000 ms.
• Don't include a script tag for the SDK: the app injects window.minit at runtime.

Controls#

Games run on phones: touch is the only input.

Hard requirements#

• Touch / pointer events only: no keyboard, no hover.

document.addEventListener('pointerdown', handler);

• No mechanics that require a physical keyboard.

Recommendations#

• Use pointer events (pointerdown, pointermove, pointerup): they cover touch and mouse, so the game stays testable in a desktop browser.

canvas.addEventListener('pointermove', (e) => { e.preventDefault(); });

• Set touch-action: none on the canvas so the browser doesn't intercept touches:

canvas { touch-action: none; }

Gameplay#

Hard requirements#

• A clear, unambiguous ending that triggers the reportResult call; no open-ended or looping games.
• Each Post is a self-contained experience: games are shown in any order, so each must stand alone for a first-time player.
• No in-game progression systems: no XP, levelling, unlockables, or cross-session state.
• No loading screens: instantly playable. Pre-load everything inside the ZIP.
• No monetisation, accounts, logins, leaderboards, or social features.

Recommendations#

• Aim for a complete, satisfying session (no fixed duration required).
• Add a brief first-play tutorial when it helps players start: keep the game immediately playable instead of gating it behind a long flow. For npm-package games, build it with the SDK overlay, gate it with shouldShowTutorial(), and persist completion via userData on every reportResult call so returning players never see it twice; see Interactive Tutorials.