Developing with AI

Point AI assistants at working, hardware-verified reference apps and let them build for the Switch

Brewser apps are built with plain HTML, JavaScript, and WebGL, with no proprietary SDK to learn. That makes AI assistants such as Claude, ChatGPT, and Copilot effective at building for the Switch. The key is to point them at working, hardware-verified examples instead of letting them guess. This page explains how.

Browse the reference apps

Every app in Brewser-apps/apps/ is live in the catalogue and runs on real Switch hardware.

Why this works

AI models hallucinate when they have to guess at a platform's quirks. Brewser removes the guesswork: every published app lives in one public repository, in one self-contained folder, following one consistent structure. Give your assistant a reference app to imitate and it has everything it needs: the manifest format, the file layout, and the input handling.


Standard web tech	Working references	One folder, one app
No proprietary SDK	Hardware-verified	Easy to imitate
HTML, CSS, JS, WebGL, and WASM: the stack AI assistants were trained on most.	Every app in the catalogue repo has been tested on a real CFW Switch. Copy what works.	A manifest.json, an index.html, and local assets. Small enough for an AI to hold in context.

The catalogue is the documentation: point your AI at a working app, not a guess.

Pick the section below that matches what you're building. Each one names the reference apps to imitate and gives you a copy-paste prompt. Swap the highlighted part for your own idea, paste it into your assistant, and iterate from there. If your assistant can browse or clone repositories (Claude Code, Cursor, and similar agent tools can), let it read the reference directly.

Three.js demos

Brewser ships a suite of Three.js demos (GPGPU water, unreal bloom, GLTF loading, real-time physics, and dynamic cube maps), all running on the console's GPU. They share one structure your AI should follow exactly: an import map that resolves three to ./build/three.module.js and three/addons/ to ./jsm/, with the Three.js build and every addon vendored locally inside the app folder. No CDN imports, no bundler, and no network at runtime.

Reference apps: threejsgpgpuwater · threejsselectiveunrealbloom · threejsloadergltf

Copy-paste prompt:

I'm building a Three.js app for Brewser (https://brewser.io), a homebrew web runtime for Nintendo Switch. Before writing any code, study this working reference and mirror its structure exactly: https://github.com/natureglass/Brewser-apps/tree/main/apps/com.natureglass.threejsgpgpuwater. It has a manifest.json at the root, index.html as the entry, and an import map that resolves "three" to ./build/three.module.js and "three/addons/" to ./jsm/, with the Three.js build and all addons vendored locally in the app folder. No CDN imports, no bundler, no network requests at runtime; every texture and model is a local file. Now build me: [a low-poly floating island with a day/night cycle, orbit controls, and soft bloom]. Target smooth 60 fps at 1280×720, make the controls work with touch, and write a manifest.json using the same fields as the reference.

Raw WebGL2 on a canvas

For shader-driven work (fluids, fractals, metaballs, generative visuals), skip the frameworks entirely. Fluid Dynamics is the reference: a full-screen canvas with getContext('webgl2'), a chain of shader passes over floating-point textures, and a feature probe that tests which float formats the GPU supports so it degrades gracefully. One HTML file, no libraries, and no network.

Reference apps: fluiddynamics · fractalzoom · metaballssim

Copy-paste prompt:

I'm building a raw WebGL2 app for Brewser (https://brewser.io), a homebrew web runtime for Nintendo Switch. Use this working reference as your structural template: https://github.com/natureglass/Brewser-apps/tree/main/apps/com.natureglass.fluiddynamics. It is a single index.html driving a full-screen canvas via getContext('webgl2'), all shaders inline, no external libraries, no network requests, and a startup probe that detects supported float texture formats and falls back gracefully. Keep a manifest.json at the root with the same fields as the reference. Now build me: [a reaction-diffusion simulation I can paint into with my finger, with a colour palette that shifts over time]. It must hold 60 fps at 1280×720 on a Tegra X1-class GPU and support multi-touch input.

Motion sensors

The Switch's gyroscope and accelerometer are exposed through the standard DeviceOrientation and DeviceMotion web events; the same code that reads a phone's tilt reads a Joy-Con's. The Sensors Playground app shows the full event surface, and Compass and DUSK show it applied. Declare the device_info permission in your manifest and the runtime handles the rest.

Reference apps: sensorsplayground · compass · dusk

Copy-paste prompt:

I'm building a motion-controlled app for Brewser (https://brewser.io), a homebrew web runtime for Nintendo Switch. Study this working reference and follow its structure and sensor handling: https://github.com/natureglass/Brewser-apps/tree/main/apps/com.natureglass.sensorsplayground. It reads the console's gyroscope and accelerometer through the standard DeviceOrientation and DeviceMotion events, declares the "device_info" permission in its manifest.json, and keeps everything in one self-contained folder with no network requests. Now build me: [a marble maze where tilting the console rolls the ball through the level]. Also add touch controls as a fallback so it stays playable in a desktop browser at brewser.io, and target 1280×720 at 60 fps.

Save data and leaderboards

Games that need to persist state use the Brewser Save SDK, a single drop-in brewser.js file. Saves are local-first (instant, works offline) and sync to the player's Brewser account in the background, so progress carries between the Switch and the browser. The Save Demo app shows the whole API: brewser.save() / brewser.load() for one-blob saves, plus a record layer (put, get, update, remove, list) for score tables. Tell your AI to copy the SDK file unchanged and only write the game code around it.

Reference app: savedemo

Copy-paste prompt:

I'm building a game with save data for Brewser (https://brewser.io), a homebrew web runtime for Nintendo Switch. Use this working reference for both the app structure and the save integration: https://github.com/natureglass/Brewser-apps/tree/main/apps/com.natureglass.savedemo. Copy its brewser.js SDK file into my app folder completely unchanged, and use only its documented API: brewser.save() and brewser.load() for the main save blob, and the record layer (brewser.put / get / update / remove / list) for high scores. Do not modify the SDK, its apiBase, or invent new endpoints; saves are local-first and sync in the background when the player is signed in. Keep a manifest.json at the root matching the reference's fields. Now build me: [an endless-runner mini game that saves the player's best distance and shows a personal top-10 run history], playable with touch and gamepad at 1280×720.

Porting a Unity WebGL game

Unity's standard WebGL export runs on Brewser, WASM and JIT included. The 2D Platformer Microgame is the packaging reference: the export's Build/ and TemplateData/ folders sit next to index.html and manifest.json, with compression disabled in Unity's publishing settings so the runtime loads the .data, .wasm, and loader files directly. Your AI's job here isn't the game, since Unity already built that; it's wiring the export into a clean, reviewable Brewser app folder.

Reference app: 2dplatformermicrogame

Copy-paste prompt:

I have a Unity WebGL export and want to package it as an app for Brewser (https://brewser.io), a homebrew web runtime for Nintendo Switch. Use this working reference as the packaging template: https://github.com/natureglass/Brewser-apps/tree/main/apps/com.natureglass.2dplatformermicrogame. The Unity export's Build/ and TemplateData/ folders live at the app root next to index.html and manifest.json, the export uses uncompressed files (compression disabled in Unity's WebGL publishing settings, so plain .data / .wasm / .framework.js / .loader.js), and the manifest declares the "storage" permission. Walk me through: [adapting my export "SpaceMiner": the right Unity export settings, the loader config in index.html, a manifest.json with sensible fields, and making the canvas fill a 1280×720 16:9 screen with gamepad input]. Everything must load locally with no CDN or network requests.

Hardware access (MIDI and USB)

Plug a MIDI controller into the Switch's USB port and a web app can talk to it through the standard navigator.requestMIDIAccess() API. MIDI Surface is the reference: it declares the usb permission in its manifest, detects connected controllers, and runs identically on Switch, desktop, and mobile from the same code.

Reference app: midisurface

Copy-paste prompt:

I'm building a hardware-connected app for Brewser (https://brewser.io), a homebrew web runtime for Nintendo Switch where MIDI devices plugged into the console's USB port are reachable via the standard Web MIDI API. Study this working reference and follow its structure: https://github.com/natureglass/Brewser-apps/tree/main/apps/com.natureglass.midisurface. It uses navigator.requestMIDIAccess(), declares the "usb" permission in its manifest.json, handles device hot-plugging, and keeps everything in one self-contained folder with no CDN or network requests. Now build me: [a pad sampler that maps the 8 pads of an AKAI LPD8 to drum sounds, with an on-screen fallback grid for touch]. It should work the same on the Switch and in a desktop browser at brewser.io, at 1280×720.

Ground rules to give your AI

Whatever you're building, these constraints keep an app Switch-ready. Paste them into your assistant's system prompt or project instructions:

Everything vendored locally: no CDNs, no runtime network calls
manifest.json at the root, index.html as the entry
Design for a 16:9 console screen: 1280×720 handheld
Touch first, gamepad friendly: no hover-only or keyboard-only UI
Declare permissions honestly: device_info, storage, usb
Keep DOM UI flat: solid fills render fastest on the console
Test in a desktop browser first: the same app runs at brewser.io
Ship a README and a clear license, like every catalogue app does

The full manifest reference, permission model, and submission requirements are at docs.brewser.io. Hand these to your AI alongside the reference app.

Once your app runs on hardware, submit it to the catalogue.

Submit your app · Browse the reference apps

Brewser runs on Nintendo Switch consoles with custom firmware. It is an independent homebrew project and is not affiliated with or endorsed by Nintendo.

On this page