Devices

Devices is VibeView’s interactive streaming environment. It connects you to a live iOS, Android, Apple TV, Android TV or Roku device 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 start a session from Devices:

1. Choose a device — pick a model in the device list on the left of the page (e.g., iPhone 15 Pro, Pixel 8 (Android 14 (API 34))). The list is organized into sections: iOS Phones, iOS Tablets, Android Phones, Android Tablets, Apple TV, Android TV, and Roku, with the newest OS first in each. Type in its search field to narrow the list: a model (“pixel”), an OS version (“18.2”) or a section name (“tv”). Identically-configured simulators appear as one entry per group, not as separate machines. With an app picked, a device whose OS is older than the app’s minimum stays in the list but can’t be chosen, and says what it needs (for example, “needs iOS 18.0+”). A foldable model’s entry carries a Foldable badge — see Foldable devices below.

2. Pick an app (optional) — use the App picker at the top of the device list. It lists every app in your organization, each labeled with its platform, and shows the app’s own icon once one is chosen. Choose one to have it installed when the device starts, or No app for a bare device. The device list then shows only devices that can run that app; No app shows every device. Opening Devices from an app’s Play button pre-selects that app and a device that can run it: the one you last used for that platform, otherwise a free phone (or TV, for a TV app) on the newest OS. Picking a device or an app while a session is open switches to the new device; see Running sessions.

3. Start the session — click Start session. 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 panel button at the top of the device list hides it; the button at the left of the bar above the stage brings it back. On a phone, opening Devices from the sidebar shows the device list first: pick a device to see it, and use the back button above the stage to return to the list. Opening a session’s link, Play from an app, or a link from a test or group goes straight to the device.

Before the session starts, the stage shows the device you picked and what will run on it. If you have used VibeView before, up to three of your recent devices appear under Recent — one click starts that device again. With an app picked, Recent lists only devices that can run it, and starts them with that app.

If the app’s only build is a React Native debug build that loads its JavaScript from a Metro dev server, a banner above the stage says so: the session has no dev server, so the app would show an error screen. Stream it with vibeview dev, or upload a release build.

Opening the address of a session that has already ended shows a note saying so, and the page is ready to start a new session on the same device. Opening a teammate’s session address says whose session it is; only its owner can use it, and only its owner or an organization admin can end it. To watch or drive it, ask the owner for a collaboration link.

On a phone-size screen the bar above the stage wraps into two rows, and the tools panel starts hidden: open it with the panel button.

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.

iPhone and iPad sessions are shown inside that model’s own device frame, with the screen’s real rounded corners — so what you see on the stage matches the shape of the hardware you picked. Apple TV sessions appear inside a TV frame. Android phones, Android foldables and Android TV appear inside a neutral phone, foldable or TV frame sized to the emulator’s screen: a foldable’s frame follows the fold (the cover screen when closed, the inner screen when open), and when an Android device turns to landscape its frame turns with it. The frame appears as soon as you pick the device, before the session starts, and the video fills its screen once the device is ready. Other devices (Android tablets, Roku, and the stage before you pick one) use a generic device frame.

While a session is live, a small floating bar sits centred under the device with a Rotate button, plus Open, Partial and Closed buttons on a foldable (see Foldable devices). TV and Roku sessions have no bar. The bar is a shortcut: the same controls, and an exact hinge angle, are in the Device tab.

Running sessions

The Running section at the top of the device list shows every session of yours that is live right now: sessions you started on this page, sessions an AI agent or vibeview dev started for you, and devices your test runs are using. Each row names the device, the app and how long it has been running, and carries a note when something else is using it:

• Agent driving — an AI agent is using the device. Agent session means an agent started it but isn’t using it right now.
• vibeview dev — your vibeview dev loop is connected. Dev session means it was started by vibeview dev but the loop isn’t connected.
• Running a test — a test run is using the device. Clicking it opens the run, once the run has a page to open. That leaves Devices, so if a session of yours is on screen it asks first: your sessions end about a minute after you leave Devices.
• Queued — waiting for a free device.

Click a row to open that session. If you’re in the middle of something that would be lost — a queue place, an unsaved recording, a running test, connected guests — Devices asks first. A session of yours you switch away from keeps running while Devices is open, so you can move between several devices and come back to each one. It still ends when nobody uses it for your organization’s session timeout — its row shows Ends in … for the last minute, and opening it and using the device keeps it — and about a minute after you close the page, unless a test is running on it. If Devices loses its connection to a session you switched away from, its row says Can’t keep it running · open it; open it to keep it, or it ends about a minute later. Each running session counts toward your plan’s concurrent sessions and streaming minutes.

To end one of your own sessions from the list, use the end button on its row (it appears when you point at the row, and is always shown on a touch screen). A session an agent or vibeview dev is using has no end button in the list; open it and use End session, which asks first, because ending it stops the agent’s work or your dev loop. Switching away from such a session, or closing the page, doesn’t end it.

TV devices (tvOS, Android TV, and Roku)

The device list groups TV-category devices under Apple TV, Android TV, and Roku. 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 an input, textarea, or select control on the page, so you can still type into the page’s own controls 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).

Foldable devices

Any device with a hinge is a foldable: the iPhone Duo (iOS) and Android foldables such as the Pixel 9 Pro Fold. The page shows one screen at a time — whichever one is actually in use. A foldable’s entry in the device list carries a Foldable badge so you know before you start a session.

A foldable session starts closed, showing the smaller cover screen. From there you can fold it to three postures from the Device tab (see The Device tab below), or from the floating bar centred under the device, which has Rotate and one button per posture, with the device’s current posture highlighted:

• Closed — the cover screen, the device’s normal at-rest state.
• Partial — opened partway; the larger inner screen takes over.
• Open — fully open, inner screen.

The presets move the hinge to the same angles on every foldable: Closed is 0 degrees, Partial 120 and Open 180. You can also set an exact hinge angle instead of a preset, from 0 to 180 degrees, if you need something in between. Each device names an angle by its own ranges, defined by the device, so the posture it reports for the same angle can differ — 160 degrees is usually Partial on the iPhone Duo and always Open on the Pixel 9 Pro Fold. The Device tab names the angle you set by that device’s own ranges, and the posture the device reports always wins. The iPhone Duo’s ranges and an Android example are below.

Screenshots, recordings and test runs always follow whichever screen is currently showing. A test recorded on a foldable device replays starting from whatever posture the device is in when the run begins, so keep the device folded the way the test expects before you start it, or set that posture explicitly with ?posture= — see below. The AI agent can also fold and unfold the device as part of a test (beta). You can rotate a foldable in any posture.

If you change posture several times in quick succession, the device ends on the last posture you chose. For the first few seconds after a session starts the device may not be ready to fold yet; the fold is then not applied, the device stays as it was, and you can simply try again.

Foldables are phones, not part of the TV lineup — Apple TV, Android TV, and Roku sessions are unaffected by any of this.

iPhone Duo

The iPhone Duo reads an angle as Closed at 0 degrees and Open from 170 up. In between, which screen it uses — and so whether it reads Closed or Partial — depends on how the hinge got there. Opened or closed in one go from shut or from fully open, it switches at about 85 degrees either way: below that it uses the cover screen (Closed), from there the inner screen (Partial). Moved in small steps, it keeps the screen it already had: opening a little at a time can keep the cover in use up to about 160 degrees, and closing a little at a time can keep the inner screen in use until the device is shut. The Device tab and the floating bar label angles by the one-go reading; the posture the device reports is always the answer.

On the iPhone Duo, the device folds while you drag the angle slider, and a preset moves the hinge smoothly rather than jumping, so the screen changes over within about a second, just as it does on the device. The 3D model (below) turns to show the screen that faces you as the device folds: the inner screen once the hinge passes about 55 degrees on the way open, and the cover again below about 45 degrees on the way shut — the same points at which Xcode’s Device Hub turns its model. Which screen the device itself is using is its own decision, and it can lag behind: part-way open, it can keep the cover screen in use while the inner screen, now facing you, still shows its unfold animation or stays dark. While the screen facing you is not yet the one the device is using, taps on it are ignored; they work again as soon as the device switches over, which it normally does as a fold settles at Closed, Partial or Open. The one exception is opening from an angle part-way open at which the device is still using the cover screen (for example, an exact angle of around 75 degrees, which reads Closed): the device only moves to the inner screen once the hinge has opened a good way further from where it was resting, so Partial, or a slightly larger angle, can leave it on the cover and the posture then still reads Closed. Opening a short way from shut, the inner screen can also light up for a moment and then hand back to the cover; the posture is reported once the device has settled. The reported angle always says where the hinge actually is. Choose Open, or close the device first, to bring the inner screen up from there. Where the 3D model is not available, the flat view always shows the screen the device is using, so it stays live and tappable at any angle.

When your browser supports it, an iPhone Duo session is shown as a 3D model of the device that folds along with the posture you set, and you tap and drag directly on whichever screen is open. Both screens stay live on the model the whole time, each showing what that screen is actually displaying — the home screen or your app on the screen in use, the device’s own fold animation on the other while the hinge moves, and black once that other screen settles off — so as the model turns, the fold itself carries you from one screen to the other, as it does in Xcode’s Device Hub.

Opening the device switches the stream to the larger inner screen automatically, in landscape — there is nothing else to configure.

How your app looks on the inner screen depends on the iOS SDK it was built with:

• Earlier than iOS 27.0: iOS runs the app in compatibility mode. It keeps its iPhone size in the middle of the inner screen, with black on either side.
• iOS 27.0: iOS resizes the app to a wide window on the inner screen, so layouts that adapt to width (a two-pane layout, for example) show up. The app isn’t fold-aware, though: it isn’t told where the fold is, and a strip along one edge stays black for the status bar.
• iOS 27.1 or later: the app fills the whole inner screen and can lay itself out around the fold.

This is how iOS itself shows such apps, not a problem with the stream, and the cover screen is unaffected. When VibeView can tell which SDK your build used, it shows a short note explaining this while the inner screen is in use; you can dismiss it for the rest of the session. For fold-aware layouts that use the whole inner screen, rebuild your app with the iOS 27.1 SDK or later and upload the new build.

Android foldables

An Android foldable names an angle the same way whichever direction the hinge came from, by ranges the device itself defines. On the Pixel 9 Pro Fold, for example, up to 30 degrees is Closed, 31 to 149 is Partial (Android’s half-opened posture) and 150 and up is Open. An Android foldable uses its inner screen whenever it is not closed, so Partial — half open, like a laptop or a book — keeps the inner screen, and only Closed switches to the cover screen.

There is no 3D model for Android foldables: each is shown as a flat view of its one screen, which changes size as it folds — the larger inner screen while it is partly or fully open (near-square on the Pixel 9 Pro Fold), the narrower cover screen when it is closed. The view resizes with it, and taps land where you tap on whichever screen is showing. The inner screen is shown as the device holds it; an Android foldable rotates like a phone, switching between portrait and landscape, in any posture.

Your app sees the fold through the same Android APIs it uses on any foldable phone: Jetpack WindowManager reports a fold down the middle of the inner screen while the device is partly or fully open (a vertical fold held upright, a horizontal one — tabletop — when the device is turned sideways half open), and no fold at all on the cover screen. Test your fold-aware layouts by moving between Partial and Open.

Starting folded to a specific posture

Add a posture parameter to the session’s page URL (or the embed URL) to start a foldable session already in a given posture, instead of the default closed:

/sandbox?posture=open

Accepted values are open, partial, and closed. It’s applied once, right after the session goes live; it has no effect on a device that doesn’t fold.

Real-Time Streaming

VibeView 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.
• Device buttons — a column of controls sits to the right of the device. The first group is common to every platform: Home presses the device’s home button on phones, tablets, and TV; Screenshot saves a PNG of the current screen to your computer at the device’s full resolution, named after the app, the device and the time — it takes up to a second, and the button is dimmed while it captures. If the device doesn’t answer in time, it saves the picture from the video instead, which can be smaller than the screen, and the confirmation says so; on Roku and foldable devices it always saves the picture you see; Type text opens a small field for sending a whole string at once on phones and tablets. Rotate is not in this column: it is on the floating bar under the device, where it switches an iPhone, iPad, or Android device between portrait and landscape (the iPhone Home screen itself stays portrait — apps rotate; TV and Roku are landscape-only, so there is no Rotate button there). The button lights up as soon as you press it and stays lit until the device has turned. On a foldable device, Rotate works closed, half-open, and open. On the iPhone Duo each press turns the device a quarter turn clockwise (portrait, landscape, upside down, landscape the other way, then back to portrait), its 3D model turns with it straight away, and the screen shows whatever the app on it does — an app that supports the new orientation turns its layout to stay upright, while the Home screen and portrait-only apps turn with the device; an Android foldable switches between portrait and landscape like a phone. Below that are the controls specific to the device you are on — Lock on iPhone and iPad, Back and Recent apps on Android, and the full d-pad with Back and Menu on TV devices. During test recording, sending text through Type text always records as a single, clean action for reliable replay. The whole column dims and stops responding while an AI test is driving the device.
• 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. Enter and Backspace are forwarded too. On iPhone and iPad sessions running iOS 18 or later, editing shortcuts reach the device as well: Cmd+A, Cmd+C, Cmd+X, Cmd+V, Cmd+Z and Cmd+Shift+Z, the arrow keys (alone or with Shift, Option or Cmd to select or jump by word and line), Option or Cmd with Backspace or Delete, and Escape; Tab and Shift+Tab go to the device once you have clicked the device screen. On Windows and Linux use Ctrl where a Mac uses Cmd. Browser shortcuts such as Cmd+R or Cmd+W are never sent, Cmd+C stays with the page while text on the page is selected, and shortcuts are not sent while you are recording a test (a replay cannot press them). Pasting text that was copied outside the app may show iOS’s own Allow Paste prompt. Keyboard forwarding pauses automatically while focus is inside an 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. Appearance, text size, contrast, animations, colour filters, the status bar, location, deep links and permissions live in the Device tab of the tools panel — see The Device tab below.

Installing Apps

Apps install automatically when you open Devices from the Apps page: hover an app’s row and click Play — or click the play button next to a specific build in Build history — and Devices 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 Devices 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 page 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 Play Store

The Google Play Store is not available on VibeView devices. You install apps directly from your organization’s app library (see “Installing Apps” above); the Play Store is not used.

Apps that depend on Play-Services-backed features — Firebase (push notifications, Crashlytics, Analytics), Google Maps SDK, Google Sign-In — work on Android phone and tablet devices. On Android TV devices, Google Play Services is not available, so TV apps that require it at startup may not function.

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 (iPhone and iPad on iOS 18 and later, 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 prompts (location, notifications, app tracking, save password, Bluetooth, and similar) are dismissed automatically with safe defaults: accept notifications and location, and otherwise fall back to OK / Allow / Not Now / Cancel. Only system prompts are answered: an alert your own app shows stays on screen for you, a recording, or the AI agent to handle. The “Open in “App”?” confirmation a link raises is never answered by this: when VibeView opens a link into your app it answers Open itself, and a confirmation for any other app stays on screen. If the device is too slow to respond, the confirmation can stay on screen for you to answer.

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.

Tools panel

The panel beside the device carries the Device, Recorder, Run a test, and Logs tabs. It is always available — there is nothing to switch on. Recorder and Run a test appear once an app is in context. Before a session is live, the Recorder says Start a device to record and turns Record on once the device is up and your app is open; the Run a test and Logs tabs say in one line what they do until then. Network capture is not yet available.

The Device tab

The Device tab is the first tab in the panel and is always available, before and during a session:

• UI tree panel — a switch that opens the UI tree inspector beside the tools panel. It is disabled with a note that it needs a live session until one starts.
• Session — while a session is active this section shows the app and its version and build, the device model and OS version, and when the session started. Permissions switches between Auto-grant (system prompts are answered for you) and Manual (you answer every prompt yourself); it applies to the next app install. Before a session starts, this section shows the device and app you have picked along with the permissions setting.
• Audio — once the session has sound turned on for you, a Sound slider (starting muted — move it up to turn sound on), an Output picker for which speaker plays it, and an Input picker for speaking into the device with your microphone. See Device audio for what platforms support sound today.
• Simulator — the device settings you can change mid-session. Each one appears only on devices that support it, so the rows you see depend on the device you started:
  • Posture (foldable devices only) folds the device to Closed, Partial, or Open. Turn on Set by angle to drag a slider to an exact hinge angle from 0 to 180 degrees instead of picking a preset. See Foldable devices above.
  • Appearance switches the device between light and dark. Not available on Apple TV or Roku.
  • Text size sets the device’s system text size on a slider. On iOS it runs through twelve steps, from extra small through the accessibility sizes; on Android it runs through eight. The current step’s short name is shown beside the slider.
  • Increase contrast (iOS, Android and Android TV) turns on the system’s higher-contrast rendering.
  • Reduce motion (iOS, Android and Android TV) turns the system’s animations and transitions off. Android sessions start with it on so screens settle instantly and recordings do not catch a screen mid-transition; turn it off when you want to watch a transition as a user would see it.
  • Reduce transparency (iOS) replaces the system’s blurred backgrounds with solid ones.
  • Show borders (iOS, and Android and Android TV where the device allows it) outlines every view’s bounds on screen, so you can see how a layout is composed.
  • Liquid Glass (iOS 26 and later) adjusts the system’s Liquid Glass material. Depending on what the device offers, you get an opacity slider, a switch between the clear and tinted looks, or both.
  • Colour filter shows the screen as someone with a colour-vision difference sees it — grayscale, protanopia, deuteranopia, or tritanopia. Where the device supports applying the filter itself, it does, and the note under the row reads “Applied on the device, so everyone watching this session sees it.” Otherwise the note reads “Previews how the screen looks…” and the filter is drawn in your browser: it never leaves it, so the device is unchanged and screenshots, recordings and test runs are unaffected.
  • Clean status bar (iOS phones and tablets only) replaces the status bar with the one used for App Store screenshots — 9:41, a full battery, and full Wi-Fi and cellular signal. Turn it off to go back to the device’s own status bar.
  • App language runs your app in another language — for checking translations or taking localized screenshots. Picking one restarts the app in that language; the device itself, its status bar and other apps keep theirs, and Device language goes back to the device’s own. Your app only shows the languages it ships translations for; any other choice shows its default language. It is available on iPhone, iPad, Apple TV, and Android phones, tablets and TVs running Android 13 or later (Roku channels follow the device’s language). The row is locked while a recording is in progress, because a recording does not capture the language change.
  • Location shows the coordinates currently set on the device, or “Not set”, with a button to open a map picker and set a new latitude and longitude.
  • Orientation (iPhone, iPad, and Android) switches the device between portrait and landscape — the same action as the Rotate button on the bar under the device. On the iPhone Duo, either choice turns the device one quarter turn clockwise, in any posture. An Android foldable switches between portrait and landscape like a phone, in any posture.
  • Open link (phones and tablets only) opens a link that your app registers a custom URL scheme for — for example atlas://home. Type the link and press Open or Enter. An app must be installed first, because the link is delivered to that app, and links the app does not handle are refused, as are links that would leave it for the web browser, the device’s settings, or the file system. Anything that stops the link opening is shown under the field. Open link is unavailable while you are recording.
• Stream — shows the stream’s current quality tier, the live frame rate, the bitrate, and, when available, its latency. The quality tier adapts to your connection, so a drop here explains a softer picture.
• Manage — Copy session id copies the session’s public identifier to your clipboard.

Rows appear only on devices that support them, so the list above is the full set rather than what any one device shows. Apple TV and Roku show no device settings at all — only the browser-side Colour filter. Device settings are not saved in a recording — a recorded test replays the steps you performed, not the settings you changed before or during it.

Resizing the panel

The panel has a drag handle along its left edge. Drag the handle to resize it (280px to 640px wide, capped at 70% of your browser window); double-click the handle to reset it to the default width. Your preferred width is remembered in the browser, so it sticks the next time you open Devices on the same machine.

To get the panel out of the way entirely, use the panel button in the bar above the stage; press it again to bring it back.

Debug logs

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

• App (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 Logs tab to narrow down what you see:

• Level toggles — click the info, warn or error filters 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 or System) is currently active.

Network logs

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

Test Recording

The Recorder tab lets you capture your interactions as a test recording. Click Record to start capturing taps, swipes, text input and button presses. Each captured step appears in the panel as you go, with the gesture, what it acted on, and a checkmark once it is committed. When you are done, stop the recording: Generate with AI writes the test’s steps from it and Discard throws it away. See Saving.

Opened from Create test > Record on the Tests page, Devices shows the Recorder and starts recording by itself once your app is open. The menu next to Record has Import recording and Export recording (a recording as a JSON file, for debugging).

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>)” readout in the status line at the bottom of the page shows exactly what will be recorded and how many keystrokes are buffered so far; the buffering cell reads “buffer ok” once the run is committed and playback is healthy.

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 field on the page (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

A recording is saved as a test through its generated steps. After stopping the recording, click Generate with AI to have an LLM write a plain-language step for each thing you did (or Discard to throw the recording away). The generated steps include a few Verify ... steps where a result should be checked (see Checking results with Verify steps). They open in Review steps, the same screen Create test uses: name the test, edit the steps, pick its groups, the tests to run before it and its start state, then Save, or Save and run to run it on this session right away (here it does not open the Run dialog). If you close the review, Review steps in the Recorder opens it again, with your edits, without generating again. After the save, the Recorder says the recording was saved instead of offering Generate again. The recording is saved with the test, so a Smart run replays it: your recorded gestures are replayed first, and the AI takes over only for a step that can’t be replayed.

Generating uses AI, billed to your organization’s usage credit or to your own API key if you have added one. Under the button the Recorder names the model it will use and who pays; it shows no price. It uses your organization’s default model from Settings > AI configuration, the same model AI test runs use. If Generate with AI is refused because you are out of usage credit, buy credits in Settings > Plan and usage; if it says there is no API key, add yours in Settings > AI configuration. Then generate again. The recording stays in the Recorder until you discard it or end the session.

Ending the session

End session, in the bar above the stage, ends the session and releases the device. While a recording is in progress, or a stopped recording hasn’t been saved as a test, it asks first: ending the session discards the recording.

Turning the device off from its own menu (slide to power off on an iPhone or iPad) or restarting it (Restart in an Apple TV’s Settings) also ends the session: a simulator can’t power itself back on. The notice usually says the device was turned off (or restarted); if the device stops responding before that can be confirmed, the session shows as stopped unexpectedly instead. Either way, start a new session to continue. Android devices turned off from their power menu end the session the same way, but the notice still says the device stopped unexpectedly.

Run a test

The Run a test tab runs saved tests of your app on the device you have open, and shows progress in real time. It is for debugging a step from a state you set up by hand. To run tests on devices of their own, use the Run dialog on the Tests page; it never opens Devices.

The tab needs a live session with your app installed. Run on this device stays off until the app is installed on the device (a Roku channel included), so a run never starts on a device without your app.

• What to run: a saved test of the app, or a whole group (listed as Group · name).
• Start from the current screen: ticked by default. There is no reset before the first test, so it begins where the device is now and keeps what you set up by hand. Later tests in a group still use their normal start state. Untick it to start each test from its own start state, which can clear the app’s data or reinstall it (on Roku, the channel is reinstalled).
• Run on this device starts the run on this session.

The tab uses Smart AI use: it replays recorded and learned paths and uses AI only where the screen changed or a step has no path. No AI and AI only are in the Run dialog’s Advanced section. Only Developers and Admins can run tests; a Viewer sees why instead of the button.

Stopping a run

• A single test shows Cancel.
• A group shows Cancel this test, which stops only the test that is running and lets the group go on with the next one, and Cancel the group run, which stops the current test and skips the rest.
• Cancelled tests and runs are recorded with a cancelled status and shown in neutral gray in run history — distinct from a red failure.

When a run finishes, the tab shows its step timeline and an Open run link. Run results, including the step timeline and any visual-regression flags, appear on the run detail page. See The Tests page for run history and status colors.

Status line

A single line along the bottom of the page reports the session at a glance: the device it is running on, the stream’s latency and frame rate, what is in the keyboard buffer, and whether the recorder or the test runner is working. A measurement that the stream cannot report is left out rather than shown as zero. Warnings about a session that is about to end appear here too, in amber. While a session is live, the line also reads Keyboard: type to send (or, on a TV device, D-pad: arrow keys, Enter to select · type to send) as a reminder that your computer’s keyboard drives the device.

Session Timeout

Sessions end on their own when nobody uses them for your organization’s idle timeout (30 minutes by default; organization administrators change it in Settings > Session defaults). What counts as use:

• touching, typing on or rotating the device (from Devices, an SDK page, an embed, a share link, or a collaboration guest who can control it);
• an agent or script acting on the device through the API or the CLI (taps, typing, installs, launches);
• each step of a test or group run, whether it runs from the Run a test tab, the CLI or the API;
• your app reloading from vibeview dev (a save that Fast Refreshes, or a reload);
• speaking into the device microphone.

Keeping a tab open, watching, listening to device sound, reading the screen or the UI tree, polling the session, and a vibeview dev connection that isn’t reloading anything don’t count. A session with no browser tab open (held only by the API, the CLI or the MCP server) never ends for being idle in under five minutes, whatever the setting.

About a minute before an idle session ends you get a warning: in amber in the status line here, as an Ending in countdown on share, embed and collaboration pages, and in the session’s API responses for the CLI, the MCP server and scripts. Using the session before the time runs out keeps it going and withdraws the warning. When the timeout ends the session, the notice names the cause and the limit (for example, “idle for 2 min”) and points to the setting. If a session ends in the middle of a run (for example, you stop it, or the usage credit runs out), the run says the session ended and at which step, rather than reporting a failure in your app.

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 in the status line before the session ends. See Billing for plan limits and streaming overage.

An iPhone, iPad or Apple TV session can also end if the device fills up its storage. Each session’s device can hold up to 25 GB of data (your app, its files, downloads). At 15 GB a warning appears in the session log. At 25 GB the session shows a 60-second Device storage limit reached warning and then ends; deleting files on the device before the time runs out keeps it going. Rarely, when the device host itself runs low on space, the session using the most storage gets the same warning sooner (only a session holding 15 GB or more). Android sessions are not affected: their device storage is fixed.

On the Free plan, the session bar says Free sessions last 5 min from the moment a session starts and counts down the time left once it is live. In the last minute it turns into an amber Ending in 32s countdown, the same one visitors on a share link see. When the 5-minute cap, or the month’s included minutes, ends a Free session or stops a new one from starting, an upgrade card replaces the usual notice: it lists what the Dev plan includes and offers Upgrade to Dev (straight to checkout), See all plans, and — for the monthly limit — a smaller link to top up usage credit. Members who aren’t Organization Admins see the card with a note to ask an admin to upgrade instead of those buttons. Paid plans have no session-length limit and keep the usual notices.

Session Permissions

Access to Devices 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 is allowed to start sessions.

The Permissions control in the Device tab switches between Auto-grant (system prompts are answered for you) and Manual (you answer every prompt yourself).

Debugging recorded selectors

If a recorded selector doesn’t match what you expected, open the UI tree inspector from the Device tab (or the Recorder) 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 with AI.
• 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.