Developing on an Emulator

Brewser can run under a Nintendo Switch emulator, which makes a convenient middle step between Chrome and real hardware, with some important limits. In short: Chrome is your primary loop, an emulator is a secondary check for Switch-specific UI and input, and real hardware is the only source of truth for networking, graphics, and performance.

What an emulator is good for

• UI and layout at the real resolution, in the real fullscreen canvas.
• Gamepad and navigation flow: checking your app is usable with a controller before you touch hardware.
• Logic and boot: confirming the app loads and runs in the runtime, not just in a browser.

What an emulator will not tell you

• Networking. Emulators generally don't provide working internet/TCP to the runtime, so anything that uses fetch, WebSocket, accounts, multiplayer, or cloud saves and leaderboards won't behave as it does on a real console. Test networking on hardware.
• Graphics fidelity. The Switch's GPU driver stack renders differently from an emulator's: a scene that looks right in an emulator can differ on hardware, and vice versa. Never sign off on visuals from an emulator alone.
• Performance. Frame rates in an emulator (fast or slow) tell you little about the Tegra X1. Do performance work on the device.

A sensible workflow

1. Chrome: build and debug with full DevTools.
2. Emulator: sanity-check UI, fullscreen layout, and controller input in the runtime.
3. Real hardware: the final word on networking, graphics, and performance, and the only place to trust the result.

Whatever you use, the compatibility promise still holds: if it behaves differently from Chrome, that's a bug worth reporting, with a note on where you saw it (emulator vs hardware), since the two can diverge.

Related

• Debugging & Testing: the Chrome-first loop and on-device logging.
• Known Limitations: what's still a work in progress.