Dev Scenario Docs Beta
Getting started / How it drives your app

How Dev Scenario drives your app

You can test any app as it is, with nothing added to it. When you want more — faster runs, or the app's network traffic — you link a small library into your debug build. Your store builds never change.

Two ways to drive the app

Choose the mode in Driver settings. The same flows run in both modes; only the speed and what you can see change.

Black-box

Default · no app changes

Dev Scenario drives the app from outside, the way a user would, through the platform's own automation layer.

  • Android: UIAutomator
  • iOS: WebDriverAgent, on simulators and real iPhones
  • Works with any build — debug, release or straight from the store
  • Nothing to link, nothing to ship

In-app SDK

Opt-in · fastest

The driver runs inside your app's own process, so steps don't wait on the system's accessibility layer.

  • Espresso speed on Android, the speed of tests written in Xcode on iOS
  • Android, iOS and Flutter
  • Lets a flow switch on test-only code paths in your app with setSystemProperty (Android today)
  • One dependency in your debug build
Black-box
In-app SDK
Changes to your app
None
One debug dependency
Speed
Good
Espresso / XCUITest level
Store / release builds
Yes
Debug builds, unless you opt in
Inspector, runs, CI
Yes
Yes

Network monitoring needs the interceptor

To see your app's requests and responses — and to mock them — Dev Scenario needs a small interceptor inside the app's HTTP client. Without it, flows still run; the Network tab just stays empty and mocks have nothing to answer.

  • Android (OkHttp): add the interceptor to your client, or apply the Gradle plugin and every OkHttpClient is wired for you
  • iOS (URLSession): a Swift package, manual or automatic
  • Flutter (dart:io, http, dio): a Dart package

It is independent of the driver mode: use it with black-box runs or with the in-app SDK. Calls are tagged with the flow and step that made them, so a failed step shows the request behind it.

Setup takes a few lines per platform: Android, iOS, Flutter. The app also shows copy-ready snippets under Network → Setup.

Release builds stay clean

Both libraries are meant for debug and test builds. Set up as the guide shows, they are not part of a production build unless you deliberately opt in. Details per platform.

  • Android, debug-only by default: the Gradle plugins only touch debug builds, and the plain dependency uses debugImplementation.
  • Android: even if a release build links the SDK, it stays off unless the app is debuggable or you opt in through the manifest.
  • iOS and Flutter: you start the SDK yourself, inside #if DEBUG (Swift) or kDebugMode (Dart), so it never runs in a release build.
Testing an optimized build? You can opt a staging or QA variant in — for example variants("debug", "stagingRelease") in the Gradle plugin. Keep the libraries out of the build you ship to the store.
Previous
← Quickstart
Next
Library setup →