The Device Preview pane

Device Preview drops the app you’re building into a realistic phone frame so you can eyeball it at true handset size while your agents work. Open it from the wrench menu in the left toolbar → Device Preview — if a preview is already open, it’s focused instead of opening a duplicate.

Using it

1. Type your app’s address in the URL field — the placeholder says it plainly: localhost:3000 — your app’s dev server. Bare localhost or IP addresses get http:// automatically; anything else gets https://.
2. Press Enter or click Load.
3. Pick the engine with the segmented control — Chromium or Android emulator (the native tier below) — then pick the device size from the dropdown: iPhone 16 Pro, iPad Pro 11“, Galaxy S24 Ultra, or Pixel 8.

Which engine am I actually looking at?

The tabs name the rendering engine, not the phone, because that’s what determines whether what you see is accurate:

Tab	What it really is	Needs
Chromium	The engine Android’s Chrome and WebView use — so Android sizes reflect real Android rendering	nothing
WebKit	Safari’s engine, running natively on Windows	one-time ~300 MB add-on
My device	Your actual iPhone, iPad, or Android phone	Expo Go (free)
Android emulator	A real Android OS	~2.2 GB, one time

An Apple size in Chromium is a layout check only — Safari’s engine isn’t emulated there, so iOS-specific quirks won’t appear. The pane says so under the toolbar rather than letting the bezel imply otherwise. Device size is a separate dropdown precisely because size and engine are independent — an iPhone-shaped frame doesn’t make the renderer Safari.

Testing iOS from Windows

Apple only ships Xcode and the iOS Simulator for macOS, and there is no Linux or WSL route around that — so a native iOS simulator on Windows is not possible, from Mastery HQ or anything else. What is possible, and what these two tabs do:

WebKit — Safari’s engine

The WebKit tab renders in Playwright’s WebKit build: genuinely Safari’s engine, so real WebKit CSS/JS differences appear that Chromium hides. Click and scroll it like a normal page.

Be clear about the limit: it is desktop WebKit, not iOS Safari. It won’t reproduce iOS scroll momentum, fixed-position and viewport quirks, GPU behaviour, or touch/focus event ordering. It also runs at roughly 3 frames per second — measured on a 1206×2622 px capture, about 330 ms per frame — because WebKit has no screen-streaming API and every frame is a separate screenshot. That is fine for layout and rendering, and no use at all for judging animation smoothness.

It’s an optional add-on (~300 MB) rather than part of the installer, so you only download it if you want it. Install it from the tab itself, and remove it any time from Settings → Setup to reclaim the space.

My device — the real thing

The My device tab is the only true-iOS option, and it needs no Mac. Install Expo Go (free, on the App Store and Google Play), click Pair my device, and scan the QR code. Your Expo / React Native app then runs on the actual hardware — real iOS, real Safari, real touch. The same QR works for an Android phone or tablet.

Your phone must be on the same Wi-Fi as this PC. If nothing connects after about 45 seconds, the pane says so — the usual cause is Windows Firewall blocking Node on private networks. Try tunnel mode routes around firewalls, foreign networks, and guest Wi-Fi with client isolation; it works anywhere, just slower.

Once a page is loaded, the Load button becomes a reload button (circular arrow) — click it to force-refresh the same URL after your agent ships a change.

Preview an Expo / React Native app (one command)

Building a mobile app with an agent? Two tiers, both one sentence:

Instant web preview — say “preview my app on a phone”. Mastery HQ finds the Expo app in your project (the folder itself, or monorepo slots like apps/mobile), starts expo start --web as a managed background process, and points the phone frame at it the moment it’s up — hot-reloading as your agent keeps editing. Zero downloads, but it’s the app’s web build: native-only modules (camera, haptics) don’t run.

Native Android preview — say “preview my app on android” (or “native preview”). Your app runs for real, in a managed Android emulator streamed into the pane:

1. First run only: a consent card offers the Android SDK download from Google (~2.2 GB — platform tools, emulator, Android 15 system image; you’re accepting the Android SDK License). It installs into Mastery HQ’s own app folder — no admin rights, no Android Studio, nothing system-wide.
2. Android boots headlessly (progress shows in the pane), then Expo installs Expo Go into the emulator and opens your app in it.
3. The pane shows the live screen: click to tap, drag to swipe, scroll to scroll, type to type. The Stop button (or “stop the app preview”) ends the run; the emulator stays warm so the next preview boots fast.

Native modules that ship with Expo (camera APIs, haptics, sensors) behave like a real device here. Projects using custom native modules (a dev client / expo-dev-client) can’t run in Expo Go — those still need expo run:android with Android Studio, and the pane will say so honestly.

Say “preview my app at C:\path\to\project” (either tier) to point at a specific folder.

iOS: Apple only allows iOS simulation on a Mac, so the iPhone frame always uses the web build. For real-device testing, Expo Go on your phone (npx expo start, scan the QR code) works well.

Good to know

• The frame renders at the device’s real CSS-logical resolution and then scales to fit the pane — resize the pane freely; proportions stay true.
• Your chosen device and URL persist with the pane across restarts.
• The emulator needs hardware acceleration (see the FAQ) and about 5 GB of disk once installed.
• Public sites that block embedding won’t render here — this pane is for your app during development, not general browsing. For browsing, use the Browser pane.