Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.revyl.com/llms.txt

Use this file to discover all available pages before exploring further.

Tests, sessions, and workflows produce reports that feed the Atlas app map Atlas is Revyl’s app map. It turns observed test and session activity into a searchable graph of screens, variants, and transitions so you can understand what Revyl has actually seen in your app. Use Atlas to check coverage, inspect product flows, find paths to important areas, and review whether a report discovered a new state or revisited known screens.

​
How Atlas Gets Data

Atlas is built from real device observations. Test runs, workflows, and exploratory sessions produce reports with screenshots, actions, transitions, and metadata. Atlas layers that evidence into an app-level graph. Atlas groups similar screens together even when the content changes, so the map stays focused on your app’s structure instead of every user, list item, or loading state. A newly uploaded build may have no Atlas data until at least one run or session observes it. After a run completes, Atlas can also lag briefly while report data is processed.

​
Dashboard

Open an app and go to Atlas to see the app-level map. From a report, use the Atlas action to jump into the map filtered to the app and build that produced the run. The dashboard view is best for visual review: scan major areas, inspect screenshots, and follow transitions between screens.

​
Terms and View Options

Atlas uses a few map-specific terms:
  • Screen cluster - one logical screen, grouped from many observed screenshots that appear to be the same place in the app.
  • Variant - a related state of a screen, such as loading, empty, logged-out, error, permission prompt, or populated content.
  • Observation - one real screenshot/action moment from a test run or session.
  • Transition - a path between screens, usually tied to the tap, swipe, or other action that moved the app forward.
  • Coverage - the set of screens and transitions touched by a test, workflow, session, build, or time window.
  • Product area - an Atlas grouping for screens that belong to the same part of the app, such as onboarding, checkout, or settings.
The dashboard gives you a few ways to inspect the same data:
  • Map - shows the app as a flow graph, useful for seeing how screens connect.
  • Grid - shows the same screen clusters without the graph layout, useful for scanning screenshots quickly.
  • Show variants - expands each screen into its observed states so you can inspect edge cases and dynamic UI.
  • Heat - colors screens and paths by activity density, making frequently observed areas stand out.
  • Clusters - draws product-area groupings behind the graph so large maps are easier to reason about.
  • Compact - tightens the layout for dense apps; switch back to original spacing if you want a more literal graph shape.
  • Details panel - opens when you select a screen and shows screenshots, variants, evidence, and incoming/outgoing transitions.

​
CLI Usage

For CLI setup and command usage, see the Atlas CLI docs on GitHub.

​
Troubleshooting

If Atlas looks empty, run at least one test or session against the app/build first, then wait briefly for report processing. If the graph looks too broad, narrow it from the dashboard by build, report, or surface scope. If a screen looks duplicated, inspect its variants and observations from the details panel.