Device Sandbox

The Device Sandbox is VibeView’s interactive streaming environment. It connects you to a live iOS or Android simulator running in the cloud and streams the display to your browser in real time. You can interact with the device, install apps, inspect the UI, and record sessions — all without a local development setup.

Starting a Session

To launch a sandbox session:

1. Choose a device — open the device dropdown and pick a model (e.g., iPhone 15 Pro, Pixel 8 (Android 14 (API 34))). The dropdown is organized into sections: iOS Phones, iOS Tablets, Android Phones, Android Tablets, Apple TV, Android TV, and Roku. Identically-configured simulators appear as one entry per group, not as separate machines.
2. Start the session — click Start. If a device in that group is free your session starts immediately; if all of them are busy you are queued automatically and resume the moment one frees up.

The simulator boots in the cloud and the video feed appears in your browser once the device is ready. See Device Selection for how grouping and the start-or-queue behavior work.

TV devices (tvOS, Android TV, and Roku beta)

The device picker groups TV-category devices under Apple TV, Android TV, and Roku (beta). TV sessions use a focus-based interaction model, not touch — tapping the video canvas does nothing. Navigate with the keyboard while the session is active:

Keyboard forwarding pauses while focus is in a sandbox input, textarea, or select control, so you can still type into the sandbox chrome without firing d-pad events at the device.

See TV testing for the focus model, d-pad recording, and the TV-specific AI tools (tap_focused_tv, focus_element_tv).

Real-Time Streaming

The sandbox uses low-latency WebSocket streaming to deliver the simulator’s display as a real-time video stream. This keeps latency low enough for natural interaction — taps, swipes, and typing feel responsive even though the simulator is running remotely.

No plugins or browser extensions are required. WebSocket streaming works in all modern browsers.

Device Controls

Once the session is active, you can interact with the simulator directly through the browser:

• Tap — click anywhere on the device screen to tap.
• Swipe — click and drag to perform swipe gestures.
• Text input — click the keyboard icon in the device controls sidebar to open a text input popover. Type your text and press Enter or click Send to inject it into the simulator’s focused text field. This is faster than tapping individual keys on the virtual keyboard. During test recording, the popover always records your text as a single, clean action for reliable replay.
• Physical keyboard — while a mobile session is active you can just start typing on your computer’s keyboard and the keystrokes are sent straight to the device’s focused field — no popover required. A “Keyboard active — just type” hint appears at the bottom of the stream. Enter and Backspace are forwarded too. Keyboard forwarding pauses automatically while focus is inside a sandbox input, textarea, select, or open dialog, so you can type into the sandbox’s own fields without firing keystrokes at the device.

The controls mirror what you would do on a physical device or a local simulator, so there is no new interaction model to learn.

Installing Apps

Apps install automatically when you launch the sandbox from the Apps page: click the Start (play) button on an app’s card — or the play button next to a specific build in Build History — and the sandbox opens with that app selected. Once the session is active, the build is pushed to the simulator and launched automatically.

Pinning a specific build via URL

You can open the sandbox with a specific app build pre-selected by adding query parameters to the URL:

/sandbox?appId=<app-public-id>&buildId=<build-id>

When both params are present, the sandbox pre-selects that app and build so the install panel opens with that build pre-selected. This is the same URL shape used by the per-build Play icon on the Apps page. See Apps and builds for the full build selection workflow.

Android: no Google Play Services

VibeView’s Android phone and TV devices run AOSP (Android Open Source Project) system images. These images do not include Google Play Services (GMS) or the Google Play Store. Apps that depend on Google APIs — Firebase (push notifications, Crashlytics, Analytics), Google Maps SDK, Google Sign-In, Play Integrity, and Cast — will not function on these devices, and may crash on launch if they require GMS at startup.

Apps without GMS dependencies install and run normally. You install apps directly from your organization’s app library (see “Installing Apps” above); the Play Store is not used.

Automatic session hygiene

Sessions apply a few simulator-level tweaks automatically so recordings stay clean and AI-agent replays don’t stall on system dialogs. These run at session boot and throughout the session with no user action required. Most are iOS-specific; keyboard suppression applies to both platforms:

• On-screen keyboard suppressed (iOS and Android) — the software keyboard does not appear on text-field focus. Text input via the keyboard popover or the AI agent still works because those paths inject text below the IME layer, not through the on-screen keyboard.
• Notifications permission prompt suppressed (iOS) — the first-launch notifications dialog is pre-approved per app install, so your app starts on its own UI instead of on a permission sheet.
• Save-password autofill disabled (iOS) — the “Save Password?” prompt is turned off at boot, so form submissions don’t hand focus to a system sheet.
• System alerts auto-dismissed mid-session (iOS) — common system alerts (location, notifications, app tracking, and similar) are dismissed automatically with safe defaults: accept notifications and location, and otherwise fall back to OK / Allow / Not Now / Cancel.

All of these are applied only to your own session’s device — they never affect anyone else’s sessions. Nothing to configure — this runs on every session automatically.

Developer Tools Panel

The sidebar includes a Developer Tools panel for deeper debugging during a session.

Resizing the panel

The panel has a drag handle along its inner edge — the left edge when the panel is docked to the right, the top edge when it is docked to the bottom. Drag the handle to resize; double-click it to reset to the default size.

Constraints:

• Right-docked panel: width 280px to 640px (capped at 70% of the browser window width).
• Bottom-docked panel: height 180px up to 60% of the browser window height.

Your preferred panel size is remembered in the browser, so it sticks the next time you open the sandbox on the same machine.

Debug Logs

The Debug Logs tab shows real-time log output from the simulator in two sub-views:

• App Logs (default) — shows live application logs from the running app. On iOS, this streams NSLog and os_log output. On Android, this streams logcat output filtered to the app’s process. On iOS, app log capture starts as soon as the simulator boots and automatically narrows to the launched app once you install or open one; on Android, log capture begins once an app is installed or launched.
• System — shows VibeView’s own test-execution logs. These are primarily useful during AI-driven test execution and are empty when no test is running.

Filtering

Use the filter controls at the top of the Debug Logs tab to narrow down what you see:

• Level toggles — click the info, warn, or error buttons to show or hide logs of that severity. Each button toggles independently, so you can view only errors, or only warnings and errors, etc.
• Text search — type in the search box to filter log messages by keyword. The search is case-insensitive and matches against the log message text.

Filters apply to whichever sub-view (App Logs or System) is currently active.

Network Logs

Network request capture is coming soon — the Network Logs tab is visible in the Developer Tools panel as a placeholder, but it does not capture traffic yet.

Test Recording

The Recorder tab in the sidebar lets you capture your interactions as a test recording. Click Record to start capturing taps, swipes, text input, and button presses. A live timeline shows each captured action as you interact with the device.

Typing While Recording

When you type on your physical keyboard during a recording, VibeView aggregates the run of printable characters into a single, clean type_text action — not one action per keystroke. This keeps recordings compact and makes replay reliable. While you are mid-word, a live “Buffering: <text> (<count>)” indicator at the bottom of the stream shows exactly what will be recorded and how many keystrokes are buffered so far; it reverts to the standard keyboard hint once the run is committed.

A few behaviors to know:

• Enter records the typed text first and then a separate submit (return) action — so a “type then submit” flow is captured as two clean actions in the right order.
• Backspace while you are still typing edits the buffered text in place; only the net result is recorded (for example, fixing a typo before pressing Enter records just the corrected word). A Backspace pressed against already-committed content records a discrete delete instead.
• Focus changes flush the buffer: if you click into a sandbox field (or the recording stops), the in-flight text is committed as its action immediately so nothing leaks across the transition.

The Type Text popover is unchanged — it always records one clean type_text action regardless of the above.

Step Ranges (Begin / End Step)

Click Begin step during recording to open a named step. A small modal lets you name it (e.g., “Login”, “Navigate to settings”). The button then turns into End step — click it when you’re done with that step. Every action recorded between Begin and End belongs to that step.

You don’t have to bracket your whole recording. Anything outside any step range becomes a “gap” that the AI auto-groups into its own steps when you generate a test from the recording. Use step ranges to lock down the boundaries that matter to you — for example, isolate a tricky login flow — and let the AI infer the rest.

If you forget to click End step, recording stop closes the open step for you. If you click Begin step by mistake, use the Undo button immediately to remove it before recording further actions.

Legacy recordings. Older recordings made with the previous “Mark Step” feature continue to work. They are read as single-point markers that anchor what comes after them, matching the original behavior.

Undo and Edit

The recording timeline shows each captured gesture with icons and labels. You can:

• Undo — remove the last recorded action
• Delete — click the x button on any action to remove it

This lets you fix recording mistakes without re-recording the entire flow.

Saving

After stopping the recording, click Generate AI Test to have an LLM create natural-language step descriptions from your recording (or Clear to discard it). Review and edit the generated steps, then click Save as AI Test to save the test case. Generated tests work with hybrid replay (fast recorded replay with AI fallback).

Running tests in the sandbox

The Test Runner tab runs test cases and suites against the live session and shows progress in real time. Opening the sandbox from a suite’s Run Suite button (or from a test case) lands you here with the right test pre-selected.

Execution mode

Pick how each step runs from the Execution Mode dropdown:

• Hybrid (recommended) — replays recorded gestures where available and falls back to the AI agent when a step can’t be replayed.
• AI Only — runs every step through the AI agent.

Starting and stopping a run

• Run Test runs a single test case. Run All Cases runs every case in a suite, one after another, on the same session.
• While a run is in progress you can stop it:
  • Abort stops a single test run.
  • Abort Case stops only the case that’s currently running; a suite then continues with the next case.
  • Abort Suite stops the current case and skips the rest.
• Aborted cases and runs are recorded with a cancelled status and shown in neutral gray in run history — distinct from a red failure.

Run results, including the step timeline and any visual-regression flags, appear on the run detail page. See Tests dashboard for run history and status colors.

Session Timeout

Sessions have a configurable inactivity timeout to prevent idle simulators from consuming resources. The default is 30 minutes. When no user interaction (taps, swipes, text input) occurs for the configured duration, the session is automatically stopped.

A warning notification appears 60 seconds before the timeout fires. Any interaction with the device resets the timer. Organization administrators can adjust the timeout in Settings > Session Defaults.

Sessions can also end for plan and billing reasons, independent of activity: the Free plan caps each session at 5 minutes, and on metered plans a session ends when your included streaming minutes are used up and overage can’t be billed (usage credit exhausted, or overage disabled). Each of these shows its own 60-second warning before the session ends. See Billing for plan limits and streaming overage.

Session Permissions

Access to the Device Sandbox is governed by organization-level permission settings. Administrators can control which roles are allowed to start sessions, and these permissions apply across the organization.

If you cannot start a session, check with your organization administrator to confirm your role has sandbox access enabled.

Debugging recorded selectors

If a recorded selector doesn’t match what you expected, open the UI Tree Inspector during recording to see exactly what the system has resolved. See UI Tree Inspector.

Tips

• Choose the device model that matches your target hardware as closely as possible — screen size and OS version affect how your app behaves.
• Install your app before starting a long manual test so you do not lose time if the session times out.
• Use test recording when investigating a bug — the recorded action timeline documents the exact reproduction steps, and you can turn it into a repeatable AI test with Generate AI Test.
• If the stream feels laggy, check your network connection. The stream adapts to bandwidth, but a stable connection gives the best experience.
• For TV devices, see TV testing — navigation is keyboard-only and the AI agent gets TV-specific tools.