Explore your app

Explore sends parallel agents through your app on real devices. Each explorer takes a different path, records what it sees, and adds that evidence to Atlas. Use Explore when you want broad product discovery before you know which flows should become durable tests. To keep a shared main or staging Atlas current, use the post-merge CI, weekly CI or Cursor setup recipes. Feature-branch builds and PR merges do not move evidence into those branches; the routine builds the intended source and explores that exact build.

​

1. Open Explore

From Atlas, click Map app above the apps list. Inside an app, click Explore app in Atlas or on the app’s Explorations page, or choose it from Run on the app’s Builds page. You can also open Sessions and choose Explore. The app is selected automatically when you start from inside an app or your organization has only one uploaded app. Otherwise, choose the app you want to map.

​

2. Choose the build

Choose App → Branch → Build. The branch starts from the current view or app default. Automatic uses that branch’s default build; Latest build uses its newest usable build, even when the branch is pinned. All branches uses the newest usable build on any of the app’s branches. Choose Exact build to keep the exploration fixed to one uploaded artifact. See Build branches. Use a preview or production-like build that contains every screen and native dependency you want Revyl to reach.

​

3. Plan the exploration

Choose how many explorers to run, how they should divide the work, and how long they can explore.

• Balanced mixes broad discovery, deeper flows, edge cases, complete journeys, and less obvious paths.
• Surface sweep prioritizes distinct screens, tabs, menus, and top-level areas.
• Journey focus follows multi-step flows to their natural end states.
• Hard edges looks for settings, permissions, empty states, and setup blockers.

More explorers can cover more ground in parallel. Every requested explorer is launched. If other device sessions are already using your organization’s concurrency, the extra explorers wait in the queue and start as capacity frees, and the run shows how many are queued.

​

4. Prepare sign-in and runtime settings

If the app requires authentication, describe how explorers should sign in. Keep credentials in stored launch variables or an auth bypass instead of writing secrets into the instructions. You can reuse authentication context from the previous exploration or customize it per explorer when different accounts should take different paths. Open Device & runtime when you need to:

• Attach stored launch variables.
• Supply non-secret inline environment values.
• Choose a device model and OS version.

Open Advanced and use Exploration notes for product areas, flows, or states you especially want explored. Keep the goal broad enough that the explorers can still discover unexpected paths.

​

5. Launch and watch

Click Launch 3 explorers (the number matches your selection). Revyl shows each explorer as its device starts and its status changes. Click View run to follow every explorer, watch discoveries arrive, inspect findings, and jump into the resulting Atlas map. You can leave the page while the run continues. From an exploration report, choose Run again to open a new launch with the previous build selection, explorer plan, shared authentication guidance, stored launch variables, device target, duration, and exploration notes prefilled. Review the settings before launching. Inline environment values are not stored and must be entered again when the previous run used them. To stop the run and release its devices, click Cancel exploration from the live run or report.

​

6. Read the result

An exploration can finish in a few different states:

• Completed: the explorers finished and Atlas processed their maps.
• Partial: at least one explorer produced a usable map, but another lane did not finish processing.
• Failed: the run could not produce a usable result.
• Cancelled: someone stopped the run before it finished.

An explorer may complete after reporting a blocker such as OTP, missing test data, payment setup, or unavailable credentials. Treat those findings as instructions for the next run, not as proof that the rest of the app was covered. After processing finishes, open Atlas to inspect the discovered screens, variants, transitions, and evidence. Turn important paths into tests when they should be checked on every release.

​

Troubleshooting

If explorers stop at sign-in, add an auth bypass or the required stored launch variables and run again. If fewer explorers launch than requested, stop unneeded device sessions or wait for capacity to become available. If Atlas is partial, open the report to see which lanes completed and which were blocked or failed. If an important area is missing, add a short note that names the area without prescribing every tap, then start another exploration.