Skip to main content
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. Atlas opens on the Current map scope by default, built from the 20 most recently uploaded builds. This keeps the initial map current and bounded. Older or lightly exercised product areas may require widening the scope. Use the scope control to pick a time window (last 1, 7, or 30 days, or all time), a specific build, or both together, such as one build limited to the last 7 days. The dashboard view is best for visual review: scan major areas, inspect screenshots, and follow transitions between screens. To discover more of the app automatically, use Explore your app to launch parallel explorers from the dashboard.

​
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.
  • Layout - automatically uses left-to-right for deep flows and top-to-bottom for broad maps. Select the layout control to override the automatic direction.
  • 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.

​
Troubleshooting

If Atlas looks empty, first widen the default Current map scope by switching the scope control to a longer time window. If no screens exist across all builds and all time, run a test or session, 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.