Skip to content
NewiPhone Duo, live in your browser. Try it →

Testing UI tree inspector

UI Tree Inspector

See exactly which on-screen elements VibeView resolves when it attaches selectors to recorded actions, and why a selector picked the element it did.

The UI Tree Inspector shows exactly which on-screen elements VibeView sees, and lets you inspect any one of them in detail. Use it when a recorded selector looks wrong, when an element isn’t being picked up, or when you want to confirm the tree your test will run against matches what’s on screen right now.

Opening the inspector

The inspector is available whenever a session is live — you don’t need to be recording. Open it from the UI tree panel switch in the Device tab, or from the Inspect tree button in the Recorder toolbar while a recording is active; both control the same panel. It opens beside the tools panel, between the device and the tabs, so the device and the tree stay visible together; close it with the X at its top. The panel closes automatically when the session ends.

Reading the panel heading

The panel’s heading tells you how fresh the tree behind what you’re looking at is, as a one-word state next to the title:

  • current (green) — nothing on screen has changed since the tree was read. Tap-enrichment will use it.
  • stale (amber) — your last action invalidated the tree and a fresh one hasn’t landed yet. Enrichment that runs in this window may pick the wrong element.
  • refreshing (blue) — you clicked Refresh and a fresh tree is being fetched from the device.
  • empty (gray) — no snapshot has been captured yet; the panel shows “No snapshot yet”.

Below the title, a line of detail shows how many elements the tree holds and when it was read (for example, “updated 12 s ago”). When the snapshot came from a fast, reduced source, a short note under that line says so — the tree is current but may omit some nodes or labels, and a manual refresh fetches a richer one. On iOS the richer tree is read from the app the session was started with, so a session started without an app (the home screen, or a system app such as Settings) only has the reduced tree; the note says so instead of suggesting a refresh.

Selecting an element and reading its properties

Click any row in the tree to select it. The device stream draws a coral box around the selected element, with its reference (@e9) labelled just above it — click the row again, or press Escape, to clear the selection. A Properties section under the list then shows what the system knows about that element: its type, its visible text, its accessibility id, its position and size on screen, and any other field the device reports. Only the fields that element actually has are shown.

From the Properties section, Copy selector copies the identifier a recorded test would use to find that element again, so you can check it against what you expect or paste it elsewhere.

  • Hover a tree row (without clicking) — the coral box follows your pointer the same way, so you can scan the tree without committing to a selection.
  • Tap on the device — the element the system resolved for that tap pulse-highlights in the tree and scrolls into view. If no element resolved, a “No element matched this tap” line appears for that moment. This is especially useful while a recording is running, to confirm your recorded action will attach to the element you meant.

Manual refresh

If you suspect the cached tree is wrong (the system thinks the screen settled but it hasn’t, or an animation finished after settle), click the refresh button in the panel’s heading. This invalidates the cache and fetches a fresh tree from the device. The heading reads refreshing, then current when the new tree lands.

Manual refresh is the safe escape hatch — it never breaks a recording in progress, and the resulting snapshot is marked as manually refreshed so you can tell it apart from automatic ones.

Platform notes

  • iOS — full field set: text, accessibility id, type, position and size, plus placeholder and value where applicable.
  • Android — the device’s accessibility tree may not carry every field. Missing fields are simply omitted from the Properties section. The inspector still functions; you may just have less detail to work with.
  • TV devices — the inspector also works on Apple TV, Android TV, and Roku sessions, showing the elements your d-pad navigation moves focus between.
  • Apple TV and Android TV — the element that holds focus is marked focused in the list and shows Focused: Yes in its Properties. A Focused line above the list names it; click that line to select it. A TV app whose focus the device’s accessibility layer can’t see has no focused element in the tree.

When this is the wrong tool

The inspector is observational. It does not change idle detection, fix bad selectors, or rewrite recorded steps. If you find that taps consistently enrich wrong, the inspector helps you describe the problem precisely — fixing it is a separate change to the cache or idle logic.

Last updated 29 Sep 2026 Something wrong on this page? Tell us

Search the docs