# Drizz Docs Drizz automates mobile apps with Vision AI. Write tests in plain English and run them on Android and iOS. Drizz automates native Android, iOS and mobile web apps using Vision AI. Tests are written in plain English and run on both platforms without selectors, locators or XPATH. {% hint style="success" %} New to Drizz — the [Quickstart](/start-here/quickstart) takes about 10 minutes and ends with a passing test. {% endhint %} ## Get started | | | | ------------------------------------------------------------- | ------------------------------------------------------------- | | [**Introduction**](/start-here/introduction) | What Drizz is and how a step executes | | [**Quickstart**](/start-here/quickstart) | Install, connect a device, run your first test | | [**Platform & device support**](/start-here/platform-support) | What runs where — Android, iOS, local, cloud, private devices | | [**Use cases**](/start-here/use-cases) | Scenarios Drizz automates, and what it does not cover | ## Set up the desktop app | | | | ----------------------------------------------------------- | ------------------------------------------------------ | | [**Download & install**](/desktop-app/download-and-install) | Get the app onto your Mac | | [**Sign in & get access**](/desktop-app/sign-in-and-access) | Workspace accounts, organizations, trials | | [**Set up a device**](/desktop-app/device-setup-wizard) | Guided wizard for Android emulators and iOS simulators | | [**Tour of the interface**](/desktop-app/interface-tour) | Editor, device panel, console, Memory | ## Write tests | | | | ------------------------------------------------------------- | ---------------------------------------------- | | [**The shape of a test**](/writing-tests/writing-tests) | Structure, comments, the command palette | | [**Command index**](/writing-tests/command-index) | Every command Drizz understands, in one table | | [**Which variable do I use?**](/writing-tests/which-variable) | Store, SET, datasets and placeholders compared | | [**Modules**](/writing-tests/modules) | Reusable flows, called from any test | | [**Memory & blockers**](/writing-tests/memory-and-blockers) | Dismiss popups automatically across a suite | | [**Recipes**](/writing-tests/recipes) | Complete, runnable end-to-end examples | ## Run tests | | | | --------------------------------------------------------------- | -------------------------------------------- | | [**Test plans**](/running-tests/test-plans) | Group tests, choose devices, set concurrency | | [**Devices**](/running-tests/devices) | Local, cloud and private devices | | [**Self-healing**](/running-tests/self-healing) | How Drizz repairs failed steps mid-run | | [**Reading a report**](/reports-and-debugging/reading-a-report) | Steps, screenshots, statuses, recordings | ## Automate & integrate | | | | -------------------------------------------------------- | ------------------------------------------------- | | [**API overview**](/automate-and-integrate/api-overview) | Authenticate, upload a build, trigger a run | | [**CI/CD**](/automate-and-integrate/ci-cd) | GitHub Actions, Jenkins, GitLab, Bitbucket, Azure | | [**Jira**](/automate-and-integrate/jira) | Raise issues from failed tests | ## Reference | | | | ------------------------------------------------------------- | --------------------------------------- | | [**Troubleshooting**](/reports-and-debugging/troubleshooting) | Symptom, then fix | | [**Known limitations**](/reference/known-limitations) | Platform gaps and unsupported scenarios | | [**Glossary**](/reference/glossary) | Terms used across these docs | | [**Changelog**](/reference/changelog) | What changed and when | *** *Last updated: 6 August 2026* # Introduction How Drizz works — Vision AI, plain-English commands, and the five stages every test step runs through. Drizz automates mobile apps from plain-English instructions, resolving each target visually at run time. | | | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | **Platforms** | Android · iOS · Mobile web | | **What you write** | Plain English, one instruction per line | | **What you don't need** | No selectors, no XPath, no accessibility IDs etc | | **Portability** | The same file runs on Android and iOS | | **Watch out** | Ambiguous descriptions resolve to different elements between runs — use the app's exact visible wording for better control and stable tests | ## A test looks like this ``` # ShopEase — search for a product OPEN_APP com.shopease.android Wait Until 5 Seconds Validate that the home screen is visible Tap on the search icon Type running shoes in the search field Tap on the first search result Wait Until 3 Seconds Validate that the product detail page is visible ``` No setup file, no page objects, no element locators. ## What Drizz does not require | | | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **No selectors** |

A step names the element as it appears:
Tap on Login CTA,
not driver.findElement(By.id("btn\_login\_primary")). Renaming an ID does not break a test

| | **One script, both platforms** | A step describes intent; Drizz resolves it against the current screen. Some commands differ per platform — see [Known limitations](/reference/known-limitations) | | **No instrumentation** | No SDK, no debug build, no test code in the app. Drizz drives the app from outside | ## How a step executes Every line runs through the same five stages. | Stage | What happens | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------- | | **1 · Capture** | The system captures the current screen and uses available visual context to better understand what’s displayed. | | **2 · Classify** | The line is routed to a command type — tap, type, validate, scroll, system. The first word of the line determines the routing | | **3 · Locate** | Vision AI finds the target described and returns its position. This stage fails when a description is ambiguous | | **4 · Act** | The tap, type or swipe happens at that position | | **5 · Verify** | Drizz confirms the screen changed as the step implies. A `Validate` gets up to **3 attempts** before failing | Note: The 3 attempts do not replace a wait. Add `Wait Until Seconds` before a step that runs after navigation — see [Waits & timing](/writing-tests/waits-and-timing). ## Automatic behavior | | | | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Caching** | Drizz reuses how it resolved a step on a screen it has seen before. Cached steps run faster and cost fewer DT, so a suite speeds up over its first few runs. See [Caching](/running-tests/caching) | | **Unblocking** | A popup in the way — a permission prompt, a promo sheet, a network retry — is dismissed using the app's blocker rules, with no step in the script. See [Memory & blockers](/writing-tests/memory-and-blockers) | ## Common mistakes | What you write | What happens | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Tap on the button` | Resolves to a different element depending on screen state. Quote the element's visible label | | `Tap on Proceed to Pay` when the button reads `Charge Now` | Paraphrasing misses the element, or hits the wrong one. For strict logic use double quotes, else the test runs purely on the intent to pass the screen state | | `Scroll` with no direction | Unreliable. Always give a direction and quote the target | ## Next * [Quickstart: your first test](/start-here/quickstart) * [Platform & device support](/start-here/platform-support) * [Use cases](/start-here/use-cases) *** *Last updated: 6 August 2026* # Quickstart: Your first test Write and run your first Drizz test in about 10 minutes, on a device connected to the desktop app. Connect a device, write commands in individual lines, and run them locally from the desktop app. | | | | ----------------- | ------------------------------------------------------------------------------------------------ | | **Time** | \~10 minutes, most of it device boot | | **Platforms** | Android · iOS | | **Where it runs** | Locally, on the device connected to your Mac; Real or Emulator/Simulator | | **Watch out** | On an Android emulator, disable the soft keyboard first — it covers elements and makes taps fail | ## Prerequisites * Drizz desktop app installed and signed in — see [Download & install](/desktop-app/download-and-install) and [Sign in & get access](/desktop-app/sign-in-and-access). Work email addresses only * One Android emulator, iOS simulator or attached physical device, created with the [guided setup wizard](/desktop-app/device-setup-wizard) — the supported setup path. Opening the Connect Device screen with nothing connected starts the wizard * Soft keyboard disabled, on an Android emulator {% hint style="success" %} Disable the Android emulator's soft keyboard before the first run. It is the most common cause of unexplained tap failures. ```bash adb shell ime disable com.google.android.inputmethod.latin/com.android.inputmethod.latin.LatinIME adb shell settings put global show_ime_with_hard_keyboard 0 ``` {% endhint %} ## Copy this A complete test against ShopEase, the demo app used throughout these docs. {% tabs %} {% tab title="Android" %} ``` # ShopEase — search for a product and open it OPEN_APP com.shopease.android Wait Until 5 Seconds Validate that the home screen is visible Tap on the search icon Wait Until 2 Seconds Type running shoes in the search field Tap on the first search result Wait Until 3 Seconds Validate that the product detail page is visible ``` {% endtab %} {% tab title="iOS" %} ``` # ShopEase — search for a product and open it OPEN_APP com.shopease.ios Wait Until 5 Seconds Validate that the home screen is visible Tap on the search icon Wait Until 2 Seconds Type running shoes in the search field Tap on the first search result Wait Until 3 Seconds Validate that the product detail page is visible ``` The bundle ID is the only difference from the Android test. {% endtab %} {% endtabs %} ## Steps 1. Open the desktop app and go to the **Connect Device** screen. 2. Select the emulator, simulator or attached device and wait for it to show as connected. Unlock a physical Android device first — Drizz refuses a locked device. 3. If the app under test (AUT) is not already installed, use the **Connect Device** modal to browse and select the APK or IPA file from your local device. The app will be uploaded to the connected device. Note: If the AUT is already installed, select it from the app list. No upload is required. 4. Create a test file in the editor. 5. Press `/` on an empty line to open the command palette — the authoritative list of supported commands. The editor prompts *"Type '/' for Drizz supported commands"*. 6. Paste the test above. 7. Replace three values: the package name, `running shoes`, and the two screen descriptions, so they match the app under test. 8. Run the test and watch the console panel. 9. Confirm the run banner reads passed and every line carries a green decorator in the editor. ## What you see during a run * **Live execution** on the connected, one per step, as each step executes. * Live logs, shows exact reason of every execution, command by command. * **A status decorator** in the editor beside each line: running, passed, failed. * **Token usage** after execution. Wait steps are free. A passing run takes 30–60 seconds on a warm emulator. The first run is the slowest: Drizz caches how it resolved each step on each screen, so the second and third runs of the same test are faster; if the test command and respective screen remains same. ## If a step fails Download Debug Report: Open the before-screenshot of the failing step. | What you see | Fix | | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | A screen you didn't expect | The failure is in an earlier step. Fix that one first | | The right screen, element visible | The description doesn't match. Use the app's exact on-screen text | | The right screen, element below the fold | Add `Scroll down until "Add to Cart" is visible` before the step | | A spinner, screen mid-load | Add or lengthen the `Wait Until Seconds` before the step | | A popup covering everything | Dismiss it once in Memory rather than in every test — see [Memory & blockers](/writing-tests/memory-and-blockers) | | A black screen | A secure screen. The OS blocks capture there, for Drizz and every other tool | **Report Issue** lets you report an issue you’re currently experiencing with the platform. Use it to provide details about the problem so the platform team can investigate it. ## Common mistakes | What you write | What happens | | ---------------------------------------- | --------------------------------------------------------------------------------------------------------- | | `OPEN_APP` with no package | Fails by design. The package argument is required | | No wait after `OPEN_APP` | The next command runs against a splash screen and fails | | `Tap on the button` | Ambiguous — resolves differently between runs | | `Wait until the page loads` | Not a fixed duration. Write `Wait Until 5 Seconds` | | Ten-second waits everywhere as insurance |

The suite gets slow and a real timing bug

stays hidden

| | Wrong scroll direction | Scroll direction is determined by the thumb’s movement on the UI, mimicking how a real user would scroll. | ## Next * [The shape of a test](/writing-tests/writing-tests) * [Command index](/writing-tests/command-index) * [When a step fails](/reports-and-debugging/when-a-step-fails) *** *Last updated: 6 August 2026* # Platform & Device support Which platforms and device types Drizz supports, and where each one runs — locally, in the Drizz cloud, or on private devices. Drizz automates native Android, native iOS and mobile web. Physical iPhones and iPads are supported, not only simulators. | | | | --------------- | ------------------------------------------------------ | | **Platforms** | Android · iOS · Mobile web | | **Android** | Emulator · Physical device | | **iOS** | Simulator · Physical iPhone/iPad | | **Run targets** | Local (your Mac) · Drizz device cloud · Private device | ## Prerequisites * macOS host, Apple Silicon or Intel * Drizz desktop app installed and signed in * Xcode, opened at least once — iOS only * Desktop app — physical iPhone or iPad only * An Apple development team, free or paid — physical iPhone or iPad only ## Support matrix | Platform | Device type | Local | Drizz cloud | | -------------- | ----------------------------- | ----- | ----------- | | **Android** | Emulator | ✅ | ✅ | | **Android** | Physical device (USB) | ✅ | ✅ | | **iOS** | Simulator | ✅ | ✅ | | **iOS** | Physical iPhone / iPad (USB) | ✅ | ✅ | | **Mobile web** | Browser on a connected device | ✅ | ✅ | ✅ Supported · ❌ Not applicable **Public/Private devices** on cloud are hardware your organization owns, reserved for your org — used for compliance requirements, specific handsets, and SIM, carrier testing etc. ## Desktop app and Drizz Cloud | | **Desktop app** | **Drizz Cloud** | | ------------------ | --------------------------------------------------------- | ----------------------------------------------------- | | **Runs on** | Your Mac, against a connected or emulated physical device | Drizz infrastructure, against the device cloud | | **Used for** | Authoring: Writing tests, debugging, iteration | Orchestration: Suites, regression, CI, scheduled runs | | **Parallelism** | One device at a time | Many tests at once | | **Feedback** | Live — the device and console together | A report after the run | | **App under test** | Installed on the connected device | A registered app, uploaded to Drizz cloud | A test file is identical on both surfaces. A test written against a local emulator runs in the cloud unedited when the registered build matches. Editing tests on local changes the same on device. | Task | Surface | | ----------------------------------- | --------------------------------------------------- | | Writing a new test | Desktop app | | Debugging one failing step | Desktop app — the device is visible during the run | | Running 40 tests before a release | Cloud | | Running one test across six devices | Cloud | | Gating a build in CI | Cloud, via a [test plan](/running-tests/test-plans) | | Testing on hardware your org owns | Cloud, on a private device | ## Device setup {% tabs %} {% tab title="Android" %} **Emulator.** The [guided setup wizard](/desktop-app/device-setup-wizard) creates a Pixel 7 profile named **DrizzPhone** on an Android 14 (API 34) Google Play ARM64 image. **Physical device:** 1. Enable **Developer options** and **USB debugging** on the device. 2. Connect the device by USB. 3. Accept the debugging prompt on the device. 4. Run `adb devices` and confirm it lists as `device`, not `unauthorized`. 5. Unlock the device. Drizz checks lock state and refuses a locked device. {% endtab %} {% tab title="iOS" %} **Simulator:** 1. Install Xcode and open it once to complete first-run setup. 2. Launch a simulator. 3. Select the simulator in Connect Device. Drizz builds and installs WebDriverAgent on first connect — one to two minutes the first time, cached afterwards. **Physical iPhone or iPad**, from desktop app v1.8.0 on both Apple Silicon and Intel Macs: 1. Install Xcode on the Mac. 2. Connect the device by USB and trust the Mac when prompted. 3. Enable **Developer Mode** on the device: Settings → Privacy & Security → Developer Mode, then restart the device. 4. Select an **Apple development team** in the desktop app. 5. Trust the developer certificate: Settings → General → VPN & Device Management → your certificate → Trust. Build requirements for physical hardware: * A simulator-only build does not install on a physical device. * An app installed from the App Store cannot be replaced by a sideloaded build of the same bundle ID. Uninstall the store version first. * iOS test plans in the cloud require a real-device build. {% hint style="warning" %} **Free Apple developer accounts expire weekly.** Provisioning profiles from a free team last 7 days, and there's a cap on sideloaded apps. Use a paid Apple Developer account for anything beyond a trial. {% endhint %} {% endtab %} {% endtabs %} ## Mobile web Automated through a browser on a connected Android emulator or iOS simulator. The same commands apply; Drizz reads the rendered page visually rather than through the DOM. ## Host machine The desktop app is a signed macOS `.dmg`, in Apple Silicon and Intel builds. See [Download & install](/desktop-app/download-and-install). ## Common mistakes | What you do | What happens | | -------------------------------------------------------- | ------------------------------------------------------------ | | Select a locked Android device | Drizz refuses the connection. Unlock the device first | | Install a simulator-only build on a physical iPhone | Drizz warns you. The install fails. Use a real-device build | | Sideload over an App Store install of the same bundle ID | The install fails. Uninstall the store version first | | Run a free Apple developer team beyond 7 days | The provisioning profile expires and the app stops launching | ## Next * [Set up a device](/desktop-app/device-setup-wizard) * [Devices: local, cloud & private](/running-tests/devices) * [Known limitations](/reference/known-limitations) *** *Last updated: 6 August 2026* # Use cases The scenarios teams automate with Drizz — onboarding, authentication, search, checkout, navigation and full regression suites. | | | | ---------------- | ------------------------------------------------------------------------------------ | | **Platforms** | Android · iOS · Mobile web | | **Best for** | End-to-end functional flows, | | **Also handles** | Cross-app flows, location-dependent flows, API-seeded data | | **Watch out** | Secure screens — payment PIN entry renders black to any capture tool, Drizz included | ## Prerequisites * Drizz desktop app installed and signed in * The app under test registered * A `login_module` module, for the checkout example below — see [Modules](/writing-tests/modules) ## Scenarios
ScenarioCovers
User onboardingFirst launch, permission prompts, profile setup, tutorial skips
AuthenticationLogin, OTP, social sign-in, logout, session expiry
Search & filterQuery entry, result lists, sort and filter combinations, empty states
Product & catalogCategory browsing, product detail, variants, wishlists
Checkout & paymentCart, address, coupons, order summary, confirmation
App navigationTab switching, deep links, back behavior, state after backgrounding
Regression suitesAll of the above, across devices, on every release
Each is an ordinary Drizz test. None requires a different tool or a special mode. ## Copy this A checkout flow against ShopEase, the demo app used throughout these docs. ``` # ShopEase — add to cart and reach checkout CALL login_module Tap on the search icon Type running shoes in the search field Tap on the first search result Wait Until 3 Seconds Store the price as listed_price Tap on Add to Cart Wait Until 2 Seconds Validate that Item added to cart is visible Tap on the cart icon Wait Until 2 Seconds Validate that the total matches {{listed_price}} Tap on Proceed to Checkout Wait Until 3 Seconds Validate that the checkout page is visible CLEAR_APP com.shopease.android ``` ## Beyond a single app | Flows | Action items | | --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | **Flows that leave your app** | An OTP arriving in the SMS app, a payment handoff, an OAuth screen in a browser | | **Location-dependent flows** | Set a location with `SET_GPS(latitude=, longitude=)` before the app reads it | | **Data-seeded flows** | Call your own API mid-test to create the state a scenario needs, then assert the UI matches — see [API steps](/writing-tests/api-steps) | | **Many accounts or environments** | One script, one [dataset](/writing-tests/which-variable/datasets) per environment | Worked examples of each are in [Recipes](/writing-tests/recipes). ## Common mistakes | What you do | What happens | | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Put a 60-step journey in one test | A failure mid-flow is hard to isolate and stabilize. One scenario per test is the pattern these docs assume | | Assert on a payment PIN screen | The screen renders black to any capture tool, Drizz included | | Automate a device matrix before one device is stable | Every device repeats the same failure | ## Next * [Quickstart: your first test](/start-here/quickstart) * [Recipes](/writing-tests/recipes) * [Known limitations](/reference/known-limitations) *** *Last updated: 6 August 2026* # Download & install Download the Drizz desktop app, check your Mac meets the requirements, and install it. The desktop app is the authoring and debugging surface. It drives a device plugged into or emulated on your own Mac. {% hint style="info" %} `Drizz Desktop.dmg` → drag to `/Applications` {% endhint %} | | | | ------------------- | -------------------------------------------------------------------------------- | | **Platforms** | macOS - Apple Silicon and Intel | | **Builds** | Apple Silicon: `latest-mac-arm64.dmg` · Intel: `latest-mac-x64.dmg` | | **Minimum macOS** | 12 or later | | **Free disk space** | 20–30 GB for Android tooling · 40–50 GB for Xcode and iOS simulators | | **Watch out** | Sign-in is work email only. A personal address is rejected at the sign-in screen | ## Prerequisites * macOS 12 or later * Apple Silicon, or 64-bit Intel with virtualization support * 8 GB memory minimum, 16 GB recommended * 20–30 GB free disk for Android · 40–50 GB free disk for iOS * A work email address on your company's domain ## Get the right build Two builds ship. Apple menu → **About This Mac** reports the chip. | Your Mac | Build | Download | | ------------------------------ | ---------------------- | -------------------------------------------------------- | | Apple Silicon (M1, M2, M3, M4) | `latest-mac-arm64.dmg` | [`DOWNLOAD`](https://www.drizz.dev/download-desktop-app) | | Intel | `latest-mac-x64.dmg` | [`DOWNLOAD`](https://www.drizz.dev/download-desktop-app) | ## Install {% tabs %} {% tab title="Apple Silicon" %} 1. [Download](https://www.drizz.dev/download-desktop-app). 2. Open the `.dmg`. 3. Drag **Drizz Desktop** into `/Applications`. 4. Launch it from `/Applications` — not from the mounted disk image. 5. Sign in with your work email. See [Sign in & get access](/desktop-app/sign-in-and-access). 6. Confirm the app opens on the Connect Device screen. {% endtab %} {% tab title="Intel" %} 1. [Download](https://www.drizz.dev/download-desktop-app). 2. Open the `.dmg`. 3. Drag **Drizz Desktop** into `/Applications`. 4. Launch it from `/Applications` — not from the mounted disk image. 5. Sign in with your work email. See [Sign in & get access](/desktop-app/sign-in-and-access). 6. Confirm the app opens on the Connect Device screen. {% endtab %} {% endtabs %} Note: The arm64 build on an Apple Silicon Mac runs natively. The x64 build on an Apple Silicon Mac runs under translation, and emulator performance drops. ## System requirements These cover the desktop app plus the Apple and Google tooling it drives. The tooling accounts for the disk and memory figures; the app itself is small. | Component | Requirement | Why | | ---------------- | --------------------------------------------------------- | --------------------------------------------------------- | | Operating system | macOS 12 or later | Required by the Xcode versions Drizz supports | | Processor | Apple Silicon or 64-bit Intel with virtualization support | Android emulators need virtualization | | Memory | 8 GB minimum, 16 GB recommended | Emulators, simulators and builds are memory-hungry | | Storage | 20–30 GB free for Android · 40–50 GB free for iOS | SDK packages, system images, Xcode and simulator runtimes | | Network | Stable connection | SDK downloads, sign-in, device provisioning | ## Windows support Every shipped desktop build to date has been macOS, in the two variants above. Windows is not supported. The desktop app is not required to run tests on cloud. Drizz Cloud runs test plans in a browser, on any operating system. ## Set up a device A device is required before a test can run. The [guided setup wizard](/desktop-app/device-setup-wizard) installs and configures the Android and Apple tooling, and is the supported path. Open the Connect Device screen with nothing connected to start it. ## Common mistakes | What you do | What happens | | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | Download the Intel build on an Apple Silicon Mac | It runs under translation, slowly, and emulator performance is poor. Reinstall the arm64 build | | Run Drizz from the mounted disk image | Updates fail, because the app can't replace itself on a read-only volume. Drag it to `/Applications` first | | Sign in with a personal Gmail or Outlook address | Rejected at sign-in. Use your work email | | Install with 10 GB free | The Android system image download fails partway through step 7 of the wizard. Free up space first | | Expect the app to work with no Android or Apple tooling installed | There's nothing to connect to. Run the setup wizard | ## Next * [Sign in & get access](/desktop-app/sign-in-and-access) * [Set up a device: guided wizard](/desktop-app/device-setup-wizard) * [Networks, proxies & preflight](/desktop-app/networks-and-preflight) *** *Last updated: 6 August 2026* # Sign in & get access Sign in to the desktop app with your work email, how your organization is created, and what to do when you see nothing. Drizz signs you in with Google SSO on your work email domain and places you in your company's organization automatically. | | | | ---------------------- | ----------------------------------------------------------------------------------- | | **Sign-in method** | Google SSO, work email domain only | | **Personal addresses** | Blocked | | **Your organization** | Created automatically by the first person from your domain | | **Trials** | Enabled by Drizz after your first sign-in, not instantly | | **Watch out** | Signed in but no apps or files is an access problem, not data loss. Don't reinstall | ## Prerequisites * Drizz desktop app installed in `/Applications` * A Google account on your company's email domain * For trials: an instance enabled by your Drizz contact ## Sign in 1. Launch Drizz Desktop from `/Applications`. 2. Click **Sign in with Google**. 3. Select your work account in the browser window that opens. 4. Return to the app. 5. Confirm you land on the Connect Device screen. Tokens are stored in the macOS keychain. Signing out clears them. ## Account requirements
RequirementDetail
Email domainYour company's work domain. Personal domains are blocked at sign-in
Domain mismatchIf your company signs in to Google with a different domain than the one on your business cards, use the Google one
Account typeOrganization accounts only. There is no personal tier
## How your organization is created The first person from an email domain to sign in creates the organization. Everyone from that domain who signs in afterwards joins it. No configuration is required. Everything is org-scoped and shared with colleagues in the same organization: * Tests, modules and folders * Datasets * Memory — app context and blocker rules * Registered apps and test plans * Reports * Your token wallet ## Trials need approval On a trial, Drizz enables your instance after your first sign-in. Sign-in succeeding is not the same as access being live. The first-day sequence is: install, sign in, then wait for your Drizz contact to confirm the instance is enabled. ## Signed in but you see nothing An empty app after a successful sign-in is an access problem, not data loss. Files are not stored in the app, and reinstalling changes nothing. | What you're seeing | Cause | Fix | | -------------------------------------------- | --------------------- | -------------------------------------------------------------------------------------- | | No apps and no files, first day | Trial not yet enabled | Contact your Drizz representative | | Sign-in completes but the app doesn't log in | Known issue | Quit and relaunch. If it persists, use [Report an issue](/desktop-app/report-an-issue) | ## Common mistakes | What you do | What happens | | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | Sign in with a personal address | Blocked. There's no personal tier | | Reinstall the app when you see an empty file list | Nothing changes. The list is empty because of access, not the install | | Assume your account is live the moment sign-in succeeds | On a trial, access is enabled separately. Check with your Drizz contact | | Share one account across the team | Everyone is in the same org anyway — sign in with your own email so reports and runs are attributable | ## Next * [Set up a device: guided wizard](/desktop-app/device-setup-wizard) * [Networks, proxies & preflight](/desktop-app/networks-and-preflight) * [Report an issue](/desktop-app/report-an-issue) *** *Last updated: 6 August 2026* # Updates How the desktop app updates itself, what a forced update does, and how to install one by hand if the download fails. The desktop app updates itself. Optional updates are taken on demand; forced updates install before work continues. | | | | -------------------- | ------------------------------------------------------------------------------- | | **Platforms** | macOS | | **How it checks** | Automatically in the background, while the app is open | | **Where you see it** | An update prompt in the sidebar | | **Two kinds** | Optional — take it when you like · Forced — installs before you can continue | | **Watch out** | A forced update restarts the app. Save your open test file before you start one | ## Prerequisites * Drizz desktop app running from `/Applications`, not from a mounted `.dmg` * Network access to the Drizz download host * No unsaved test files open ## Update types {% tabs %} {% tab title="Optional" %} 1. Read the update prompt in the sidebar. 2. Click the prompt to download and install, or ignore it and keep working. 3. Confirm the app restarts on the new version. Ignoring the prompt leaves the current version running. The app has no changelog surface, so a skipped update is the first thing to rule out when behavior changes. {% endtab %} {% tab title="Forced" %} 1. A full-screen overlay with a progress bar appears. 2. The download and install run to completion. 3. The app restarts itself. A forced update cannot be deferred, and it restarts the app mid-authoring. Save the open file when the overlay appears. Forced releases carry fixes for defects that break runs — a broken device connection, a failing sign-in. {% endtab %} {% endtabs %} ## When the automatic download fails A flaky network or a corporate proxy blocking the download host stops the automatic download. The overlay offers a manual installer download. 1. Click the [manual installer link](https://www.drizz.dev/download-desktop-app). 2. Open the downloaded `.dmg`. 3. Drag **Drizz Desktop** into `/Applications`, replacing the existing copy. 4. Launch the app from `/Applications` and confirm the new version loads. If the download is unreachable from your network, run **Help → Network Preflight** first. Blocked update downloads and blocked sign-in have the same causes. See [Networks, proxies & preflight](/desktop-app/networks-and-preflight). ## Common mistakes | What you do | What happens | | ------------------------------------------------------------ | -------------------------------------------------------------------------------- | | Run Drizz from the mounted `.dmg` instead of `/Applications` | Updates fail silently — the app can't replace itself on a read-only volume | | Leave an unsaved test file open for days | A forced update restarts the app underneath you. Save your work | | Ignore the sidebar prompt for weeks, then report a bug | You may be reporting something already fixed. Update first, then report | | Quit the app during a forced update | You'll get the overlay again on next launch. Let it finish | | Reinstall from an old `.dmg` you kept | You go backwards, and the next forced update immediately pulls you forward again | ## Next * [Download & install](/desktop-app/download-and-install) * [Networks, proxies & preflight](/desktop-app/networks-and-preflight) * [Report an issue](/desktop-app/report-an-issue) *** *Last updated: 6 August 2026* # Set up a device: Guided wizard The guided wizard installs and configures everything needed to run an Android emulator or an iOS simulator on your Mac. The guided wizard is the supported setup path. It installs the Android or Apple tooling, creates a device, and boots it. {% hint style="info" %} `Connect Device` → nothing connected → **Set up a device** {% endhint %} | | | | ---------------- | ------------------------------------------------------------------------- | | **Platforms** | Android · iOS | | **What you get** | A booted Android emulator, or a booted iOS simulator | | **First run** | 5–10 minutes, most of it one download | | **Approval** | Every shell command is shown to you and waits for Approve or Skip | | **Watch out** | Safe to re-run any number of times — already-installed things are skipped | ## Prerequisites * Drizz desktop app installed and signed in * macOS 12 or later * Homebrew installed * Java from the Homebrew `openjdk@17` package (Android) * Xcode installed from the Mac App Store and opened once (iOS) * 20–30 GB free disk for Android · 40–50 GB free disk for iOS ## Start the wizard 1. Open the desktop app. 2. Go to **Connect Device**. 3. Select the platform — **Android** or **iOS**. 4. Click **Set up a device**. With no emulator or simulator present, Drizz offers the guided setup instead of an empty device list. 5. Approve or skip each command as it is presented. 6. Confirm the wizard finishes on a booted device listed in the device picker. The manual guides — [Android setup](/desktop-app/android-setup) and [iOS simulator setup](/desktop-app/ios-simulator-setup) — cover the cases where the wizard fails, or where a configuration it doesn't create is required. ## Approval and risk badges Each step displays the exact shell command it will run, with a risk badge, and waits for **Approve** or **Skip**. Nothing runs unapproved. Across a full run the wizard installs software, edits `~/.zshrc`, and downloads several gigabytes. | Badge | Means | | ------------ | ------------------------------------------------------------------------------------------------ | | **safe** | Reads state, or installs into a Drizz-managed path. Nothing on your machine changes meaningfully | | **moderate** | Installs software, or downloads several gigabytes | | **elevated** | Changes your shell environment — writing `ANDROID_HOME` and `PATH` into `~/.zshrc` | **Skip** passes over any step you would rather run yourself, or that is already set up in a non-standard location. The wizard continues from the next step. ## Re-running Step 1 of every wizard is a diagnostic of what is already present. Anything already installed is skipped silently, and only missing items are presented for approval. Re-run the wizard after a failed step or an unwanted skip. ## Platform flows {% tabs %} {% tab title="Android" %} Ten steps, ending with a booted emulator. | # | Step | What it does | | -- | -------------- | ------------------------------------------------------------------------------------------ | | 1 | Check | Diagnoses what's already present — Android Studio, adb, the SDK, the system image | | 2 | Android Studio | Installs Android Studio with Homebrew | | 3 | adb | Installs the Android platform tools and links `adb` into the SDK path the emulator expects | | 4 | SDK tools | Downloads the command-line tools — `sdkmanager` and `avdmanager` | | 5 | Env vars | Writes `ANDROID_HOME` and `PATH` into `~/.zshrc` | | 6 | Licenses | Accepts the Android SDK licenses | | 7 | System image | Downloads the Android 34 Google Play ARM64 image — about 1.8 GB, and the slow step | | 8 | Create AVD | Creates an emulator called **DrizzPhone** on a Pixel 7 profile | | 9 | Launch | Starts the emulator in the background | | 10 | Wait | Waits for the emulator to finish booting | A first run takes 15–30 minutes, almost all of it in step 7. Later runs take seconds, because steps 2 through 8 are skipped. The emulator is named **DrizzPhone**, which identifies it in Android Studio's device list and in `adb devices` output. {% endtab %} {% tab title="iOS" %} Two phases. Xcode cannot be downloaded programmatically — it ships through the Mac App Store or the Apple Developer Portal, and neither has a public download URL. **Phase 1 — download gate.** 1. Click the wizard's link, which opens the App Store on the Xcode page. 2. Install Xcode. 3. Open Xcode once and dismiss the license screen. 4. Click **I've installed & opened Xcode** in the wizard. 5. Confirm the check passes. Drizz verifies that `/Applications/Xcode.app` exists. The command-line tools alone do not pass this check. **Phase 2 — setup wizard.** Seven steps on the same approve/skip flow as Android, ending with a booted simulator. Opening Xcode once is required because accepting the Xcode license from the command line only works after the first-launch license screen has been dismissed in Xcode's own window. Otherwise the license step waits for a click that cannot arrive in a background process. Creating a project is not required. Simulator names come from Apple's tooling — iPhone 17, iPhone Air and so on. Drizz cannot rename them, so there is no iOS equivalent of DrizzPhone. The wizard boots the first available shut-down iPhone. {% endtab %} {% endtabs %} ## Known limitations ### Java must be in the Homebrew location The SDK steps expect Java at the Homebrew `openjdk@17` path. Java installed elsewhere makes steps 4, 6, 7 and 8 fail. Install Java through Homebrew, or skip those steps and run them from a terminal that has your Java on its `PATH`. ### The license step can hang Clicking "I've installed & opened Xcode" without opening Xcode starts a license step that never finishes. Quit the wizard, open Xcode, dismiss the license screen, and re-run. ### Android Studio may not land in `/Applications` A known Homebrew cask behavior on first install. Reinstall the cask, then re-run the wizard: ```bash brew reinstall --cask android-studio ``` ### An emulator that crashes after launch fails quietly Step 10 times out without reporting a cause. Read the emulator's own log: ```bash cat /tmp/emulator.log ``` ## Common mistakes | What you do | What happens | | -------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | Follow a manual Android Studio guide first | You'll do 20 minutes of work the wizard does for you, in paths it won't recognize | | Approve step 7 | A 1.8 GB download over a bad connection. Start it somewhere with real bandwidth | | Skip step 5 because you don't want `~/.zshrc` edited | Drizz still works, but `adb` and `emulator` won't be on your own terminal's `PATH` | | Click "I've installed & opened Xcode" after only installing it | The license step hangs. Open Xcode once, then re-run | | Re-run the wizard from scratch after one failed step | Fine, and expected. It skips everything already done | | Assume a timed-out step 10 means the wizard is broken | The emulator crashed. Read `/tmp/emulator.log` | ## Next * [Android setup (manual)](/desktop-app/android-setup) * [iOS simulator setup](/desktop-app/ios-simulator-setup) * [Physical iOS device setup](/desktop-app/ios-physical-device) *** *Last updated: 6 August 2026* # Android setup Set up an Android emulator and the command-line tools by hand, when the guided wizard isn't the right path. Install the Android tooling manually, create an emulator, and put `adb` on your `PATH`. | | | | -------------------- | --------------------------------------------------------------------------------------------------- | | **Platforms** | Android | | **Use this when** | The [guided wizard](/desktop-app/device-setup-wizard) failed, or you need a specific device profile | | **You need on PATH** | `adb`, `emulator`, `sdkmanager`, `avdmanager` | | **Disk space** | 20–30 GB | | **Watch out** | Disable the emulator's soft keyboard, or taps after typing will fail | ## Prerequisites * Drizz desktop app installed and signed in * macOS 12 or later * 20–30 GB free disk space * Java — the Homebrew `openjdk@17` package is the configuration Drizz is tested against * An Android SDK location you can write to {% hint style="success" %} The [guided setup wizard](/desktop-app/device-setup-wizard) performs everything on this page, shows every command before it runs, and takes 15–30 minutes unattended. {% endhint %} ## Copy this Run these three commands once the emulator is running. They are the verification plus the required soft-keyboard fix. ```bash # 1. Confirm your Mac can see the emulator adb devices # 2. Confirm the emulator binary is on your PATH emulator -list-avds # 3. Disable the soft keyboard — do this on every emulator you create adb shell ime disable com.google.android.inputmethod.latin/com.android.inputmethod.latin.LatinIME adb shell settings put global show_ime_with_hard_keyboard 0 ``` `adb devices` lists a working emulator as `device`. `unauthorized`, `offline`, or an empty list means Drizz cannot see it either. ## Do you need the full Android Studio install? Drizz requires the Android SDK, an emulator system image, and the command-line tools. Android Studio supplies all three, and is the route the guided wizard takes. Both paths produce the same outcome: a running emulator that `adb devices` can see. {% tabs %} {% tab title="Path A — Android Studio" %} The heavier install, with a GUI for creating and managing emulators. 1. Download Android Studio from [developer.android.com/studio](https://developer.android.com/studio), matching your Mac's chip. 2. Run the installer and complete first-run setup, granting the permissions it asks for. 3. Open **Device Manager** and [create a virtual device](https://developer.android.com/studio/run/managing-avds). A recent Pixel profile on Android 34 with Google Play matches what the wizard creates. 4. Start the emulator and wait for it to finish booting. 5. Run `adb devices` and confirm the emulator lists as `device`. Android Studio installs the emulator binaries, but not everything Drizz needs on your `PATH`. Continue with **Install the command-line tools** below. {% endtab %} {% tab title="Path B — Command-line tools only" %} A smaller install with no GUI. Emulators are created and launched from a terminal. 1. Install the SDK command-line tools, the platform tools and a system image. 2. Create an AVD with `avdmanager`. 3. Launch it with `emulator`. 4. Run `emulator -list-avds` and confirm the AVD is listed. 5. Run `adb devices` and confirm the emulator lists as `device`. Java is required. The Homebrew `openjdk@17` package is the configuration Drizz is tested against. {% endtab %} {% endtabs %} ## Install the command-line tools Android Studio installs the emulator binaries by default. `avdmanager`, `sdkmanager` and running `emulator` from any terminal need the following steps. ### 1. Install the SDK components 1. Open **Android Studio → Settings** (Preferences on older macOS). 2. Go to **Languages & Frameworks → Android SDK**. 3. Open the **SDK Tools** tab. 4. Enable **Android Emulator**, **Android SDK Platform-Tools** and **Android SDK Command-line Tools**. 5. Click **Apply**. 6. Note the **Android SDK Location** shown at the top of that screen. The next step needs it. ### 2. Add them to your PATH All three directories live inside your SDK location. | Tool | Directory | | -------------------------- | ----------------------------------------- | | `emulator` | `/emulator` | | `adb` | `/platform-tools` | | `sdkmanager`, `avdmanager` | `/cmdline-tools/latest/bin` | 1. Add the exports to `~/.zshrc`: ```bash # Replace with the path shown in Android Studio's SDK Manager export ANDROID_HOME="" export PATH="$ANDROID_HOME/emulator:$ANDROID_HOME/platform-tools:$ANDROID_HOME/cmdline-tools/latest/bin:$PATH" ``` 2. Restart your terminal. 3. Run `emulator -list-avds`. A list of AVDs confirms the change applied; `command not found` means it has not. Use the `/emulator` directory. The older copy inside `/tools` is deprecated and does not support current features. ## Disable the soft keyboard Required on every emulator you create. The on-screen keyboard covers elements, which makes the tap after a `Type` step fail as undoable. ```bash adb shell ime disable com.google.android.inputmethod.latin/com.android.inputmethod.latin.LatinIME adb shell settings put global show_ime_with_hard_keyboard 0 ``` ## Connect from Drizz 1. In the desktop app, open **Connect Device** and choose **Android**. 2. Select your emulator from the list. Boot it from here if it is not already running. 3. Choose the app under test. 4. Confirm the device panel shows the emulator as connected. Drizz attaches to an emulator that is already running rather than booting a second one. If two are running, close both and reconnect. ## Common mistakes | What you do | What happens | | -------------------------------------------- | ------------------------------------------------------------------------- | | Skip the soft-keyboard commands | Taps immediately after a `Type` step fail as undoable, on random screens | | Use the deprecated `/tools/emulator` binary | Modern emulator features don't work. Use `/emulator` | | Connect with the phone or emulator locked | Drizz refuses a locked device by design. Unlock it | | Run this whole page before trying the wizard | You do the work manually, and the wizard would have skipped it all anyway | ## Next * [Set up a device: guided wizard](/desktop-app/device-setup-wizard) * [Real Android device](/desktop-app/android-real-device) * [Report an issue](/desktop-app/report-an-issue) *** *Last updated: 6 August 2026* # Android real device Connect a real Android phone or tablet over USB — developer options, USB debugging, and the adb check that answers most problems. Enable USB debugging, connect the device by USB, confirm `adb` sees it, unlock it, connect from Drizz. | | | | -------------- | --------------------------------------------------------------------------- | | **Platforms** | Android (physical device, over USB) | | **Requires** | Developer options and USB debugging enabled on the phone | | **The check** | `adb devices` must list it as `device` | | **Lock state** | The device must be **unlocked**. Drizz refuses a locked device | | **Watch out** | `unauthorized` means the debugging prompt on the phone hasn't been accepted | ## Prerequisites * Drizz desktop app installed and signed in * An Android phone or tablet * A data-capable USB cable — charge-only cables carry no data * `adb` on your `PATH` — see [Android setup](/desktop-app/android-setup) * A raised screen timeout on the device ## Copy this ```bash # Should print your device's serial followed by the word "device" adb devices # If it's missing entirely, restart the adb server and check again adb kill-server && adb start-server adb devices ``` ## Set it up 1. Enable **Developer options** on the phone: Settings → About phone → tap **Build number** seven times. The menu path varies by manufacturer. 2. Enable **USB debugging** in Settings → System → Developer options. 3. Connect the phone to your Mac by USB. 4. Accept the "Allow USB debugging?" prompt on the phone, and tick **Always allow from this computer**. 5. Run `adb devices` and confirm the phone lists as `device`, not `unauthorized`. 6. Unlock the phone. Drizz checks lock state before connecting and refuses a locked device. 7. In the desktop app, open **Connect Device** and select your phone. 8. Choose the app under test. 9. Confirm the device panel shows the phone as connected. ## Reading `adb devices` | Output | Cause | Fix | | ---------------------------- | ----------------------------------------- | ---------------------------------------------------------------------------- | | ` device` | Ready | Connect from Drizz | | ` unauthorized` | The debugging prompt hasn't been accepted | Unlock the phone and accept it. Tick "always allow" | | ` offline` | adb has lost the connection | `adb kill-server && adb start-server`, or replug | | Nothing listed | The Mac can't see the device at all | Try another cable — many charge-only cables carry no data. Then another port | | A device you don't recognize | A running emulator | No action. Emulators and physical devices both appear in the list | Keep the device unlocked and plugged in for the whole run. A screen lock mid-run ends the session. ## Disable the soft keyboard Required on physical devices as well as emulators. An open keyboard covers the next element and makes the tap after a `Type` step fail. ```bash adb shell ime disable com.google.android.inputmethod.latin/com.android.inputmethod.latin.LatinIME adb shell settings put global show_ime_with_hard_keyboard 0 ``` For a phone that ships a different keyboard, substitute its package name. ## Common mistakes | What you do | What happens | | ------------------------------------------------- | ------------------------------------------------------------------------------- | | Use a charge-only USB cable | The device never appears in `adb devices`. Nothing about the error says "cable" | | Miss the debugging prompt on the phone | `unauthorized`. Unlock, replug, and accept it | | Leave the screen locked | Drizz refuses to connect. Unlock before connecting | | Let the screen lock mid-run | The run dies partway. Raise the screen timeout on your test device | | Forget to turn off the soft keyboard | Taps right after a `Type` step fail as undoable | | Assume Drizz is broken when the device is missing | Run `adb devices` first. If adb can't see it, Drizz can't either | ## Next * [Android setup (manual)](/desktop-app/android-setup) * [Set up a device: guided wizard](/desktop-app/device-setup-wizard) * [Report an issue](/desktop-app/report-an-issue) *** *Last updated: 6 August 2026* # iOS simulator setup Install Xcode, open it once, launch a simulator, and connect it to Drizz. What happens on the first connect. Install Xcode, open it once, boot a simulator, connect from the desktop app. {% hint style="info" %} `Connect Device` → **iOS** → pick a simulator {% endhint %} | | | | ----------------- | -------------------------------------------------------------------------------- | | **Platforms** | iOS (simulator) | | **Requires** | Xcode, installed from the App Store and **opened once** | | **Disk space** | 40–50 GB | | **First connect** | A minute or two longer — Drizz builds WebDriverAgent, then caches it | | **Watch out** | Installing Xcode isn't enough. If you never open it, the simulator won't connect | ## Prerequisites * Drizz desktop app installed and signed in * macOS 12 or later * **Xcode**, installed from the Mac App Store and opened at least once with the license screen dismissed * Xcode command-line tools installed * 40–50 GB free disk space {% hint style="success" %} The [guided setup wizard](/desktop-app/device-setup-wizard) performs everything on this page except the Xcode download, which Apple does not allow any app to automate. {% endhint %} ## Set up Xcode 1. Install **Xcode** from the Mac App Store. 2. Open Xcode once and dismiss the license screen. Creating a project is not required. 3. Install the command-line tools when Xcode prompts on first launch. 4. Confirm `/Applications/Xcode.app` exists. Drizz checks for the full app, not the command-line tools. Opening Xcode once is required because Drizz accepts the Xcode license from the command line during setup. That only works after the first-launch license screen has been dismissed in Xcode's own window. Otherwise the command waits for a click that cannot arrive in a background process, and it hangs. ## Boot a simulator 1. Open Xcode → **Open Developer Tool** → **Simulator**. 2. Select any iPhone simulator. 3. Wait for it to finish booting, and leave it running. Drizz connects to a booted simulator. Outside the guided wizard, it does not install one. ## Connect from Drizz 1. In the desktop app, open **Connect Device** and choose **iOS**. 2. Select your simulator from the list. 3. Choose the app under test. 4. Confirm the device panel shows the simulator as connected. ## First connect Drizz builds and installs **WebDriverAgent** onto the simulator on the first connect. That takes one to two minutes. | Behavior | Detail | | ------------- | -------------------------------------------------------------------------- | | Build caching | The build is cached and reused, so later connects are fast | | Pre-build | Drizz pre-builds WebDriverAgent in the background when the app starts | | Apparent hang | A first connect can take up to two minutes before the device panel updates | ## Simulator vs physical device | Capability | Simulator | Physical device | | ----------------------------- | ---------------------- | -------------------------------------------------- | | Authoring and debugging | ✅ | ✅ | | Camera, Bluetooth, biometrics | ❌ | ✅ | | Real push notifications | ✅ | ✅ | | Hardware-only app builds | ❌ | ✅ | | Cost and availability | Free, always available | Requires an Apple development team and a USB cable | Setup for hardware is on [Physical iOS device setup](/desktop-app/ios-physical-device). iOS steps run approximately twice as slow as the equivalent Android steps. This is a platform characteristic, not a property of the test. ## Common mistakes | What you do | What happens | | --------------------------------------------- | --------------------------------------------------------------------------------- | | Install Xcode but never open it | Setup hangs on the license step, and the simulator won't connect | | Install only the command-line tools | Drizz checks for the full `Xcode.app` and refuses. Install Xcode itself | | Assume the first connect is stuck | It's building WebDriverAgent. Wait two minutes before restarting anything | | Quit the simulator between runs | Every connect starts from cold. Leave it booted while you're authoring | | Rely on `CLEAR_APP` for a clean state on iOS | It's effectively a no-op on iOS. Reset in-app, or reinstall between tests | | Use `PRESS_DEVICE_BACK_BUTTON` in an iOS test | The command doesn't exist on iOS. Tap the back button or swipe from the left edge | ## Next * [Physical iOS device setup](/desktop-app/ios-physical-device) * [Set up a device: guided wizard](/desktop-app/device-setup-wizard) * [Tour of the interface](/desktop-app/interface-tour) *** *Last updated: 6 August 2026* # iOS physical device Connect a real iPhone or iPad — developer mode, the Apple team picker, signing, and the free-account limits. Real iPhones and iPads are supported from desktop app v1.8.0, on both Apple Silicon and Intel Macs. {% hint style="info" %} `Connect Device` → **iOS** → your device → pick your Apple team {% endhint %} | | | | ------------------- | ------------------------------------------------------------------------------ | | **Platforms** | iOS (physical device, from v1.8.0) | | **Requires** | Xcode, a USB cable, Developer Mode on the device, an Apple developer team | | **Free Apple team** | Profiles expire after **7 days**, and there's a cap on sideloaded apps | | **App build** | Must be a **real-device build** — a simulator build won't install | | **Watch out** | You have to trust the developer certificate on the device before anything runs | ## Prerequisites * Drizz desktop app v1.8.0 or later, signed in * Xcode installed and opened once — see [iOS simulator setup](/desktop-app/ios-simulator-setup) * An Apple development team, free or paid * An iPhone or iPad, unlocked, with a USB cable * A real-device build of the app under test ## Set up the device 1. Install Xcode on your Mac and open it once. See [iOS simulator setup](/desktop-app/ios-simulator-setup). 2. Connect the device by USB. 3. Tap **Trust** when the device asks whether to trust this computer. 4. Enable **Developer Mode** on the device: Settings → Privacy & Security → Developer Mode. 5. Restart the device when prompted. Developer Mode does not take effect until the restart. 6. In Drizz Desktop, open **Connect Device** and select your device. 7. Select your Apple development team in the team picker. 8. Click connect. Drizz signs WebDriverAgent and installs it onto the device. 9. Trust the developer certificate on the device: Settings → General → VPN & Device Management → your certificate → **Trust**. 10. Confirm the device panel shows the device as connected. Until the certificate is trusted at step 9, iOS refuses to launch anything Drizz installed, and the connection fails with a signing error that does not name the Trust step. ## Apple team types Drizz labels free and paid teams in the picker and warns when a free team is selected. These limits are Apple's, not Drizz's. | Limit | Free team | Paid team | | ----------------------------- | --------------------------------------------------- | ----------------------------------------- | | Provisioning profile lifetime | **7 days**, then re-sign by reconnecting from Drizz | Standard Apple Developer Program duration | | Sideloaded app cap | Capped — reached quickly on a shared test device | Higher | | Paid-account entitlements | Unavailable | Available | ## Installing your app | Rule | Consequence | | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | The build must be a real-device build | A simulator build will not install on hardware. Drizz names this reason in the error rather than failing generically | | An App Store copy blocks a sideloaded build of the same bundle ID | iOS will not let a self-signed build replace an App Store install. Uninstall the store version from the device first | iOS test plans on the Drizz device cloud also require a real-device build. ## Common mistakes | What you do | What happens | | -------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | Skip the Trust step on the device | The connection fails with a signing error. Settings → General → VPN & Device Management → Trust | | Enable Developer Mode but not restart | Developer Mode doesn't take effect until the restart | | Use a simulator build on hardware | It won't install. Drizz names the reason — build for a real device | | Sideload over an App Store install of the same app | Blocked by iOS. Uninstall the store version first | | Use a free Apple team for an ongoing suite | It breaks every 7 days when the profile expires. Use a paid account | | Unplug the device mid-run | The session dies. Keep it connected and unlocked for the whole run | | Leave the device locked | Drizz checks lock state and refuses a locked device | ## Next * [iOS simulator setup](/desktop-app/ios-simulator-setup) * [Real Android device](/desktop-app/android-real-device) * [Report an issue](/desktop-app/report-an-issue) *** *Last updated: 6 August 2026* # Networks, proxies & preflight Run the network preflight check, read its results, and work with corporate proxies and TLS inspection. Preflight reports whether the desktop app can reach every service it needs, and names the layer that fails. {% hint style="info" %} `Help` → **Network Preflight** {% endhint %} | | | | ---------------------- | --------------------------------------------------------------------------------------------------------------------- | | **Platforms** | macOS | | **When it runs** | Automatically before device setup, and any time you ask for it | | **What "ready" means** | Every check shows **OK** and the connection status reads **Ready** | | **Corporate TLS** | Drizz reads the macOS system certificate store — no configuration needed when the root certificate is installed there | | **Watch out** | Works on a hotspot but not on office wifi means TLS inspection or an egress rule, not a Drizz fault | ## Prerequisites * Drizz desktop app installed * A network connection * For corporate networks: the company root certificate in the macOS **system** keychain ## Run preflight 1. Open **Help → Network Preflight**. 2. Click **Run**. Drizz also runs this check automatically before desktop setup. 3. Read the **connection status** at the top. 4. Identify the rows that are not **OK**. Preflight names the specific service or network layer that failed. 5. Fix the topmost failing row. A failure high in the list explains the failures below it. 6. Click **Run** to re-execute the check. 7. Confirm every check shows **OK** and the status reads **Ready**, then click **Continue**. ## What it checks Four layers, in the order they matter. | Layer | What's being confirmed | | --------------------- | --------------------------------------------------------------------------------- | | **Network integrity** | DNS resolution, proxy routing, HTTPS reachability | | **Sign-in** | That the identity services behind sign-in are reachable and your session is valid | | **Platform services** | That the services which allocate devices and store your tests respond | | **Live connection** | That the real-time channel used to stream device state and logs stays open | ## Corporate networks, proxies and TLS inspection Drizz reads the **macOS system certificate store**. On a network with a TLS-inspecting proxy, no configuration is required when the company root certificate is installed in the system keychain. | Symptom | Diagnosis | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Works on a phone hotspot, fails on the office network | **Cause:** TLS inspection or an egress rule. **Fix:** run preflight on both networks and compare which rows differ. That list goes to IT | | Preflight fails only on the corporate network | **Cause:** the corporate root certificate is not in the macOS system keychain. **Fix:** install it in the system keychain, not a user keychain or a browser store | | Runs start and then die partway | **Cause:** a proxy terminating long-lived connections after a fixed idle period. **Fix:** exempt the real-time connection from the idle timeout | | An automatic app update can't download | **Cause:** the same egress rules that block sign-in. **Fix:** run preflight before treating the update as broken. See [Updates & forced updates](/desktop-app/updates) | Checks to raise with IT when preflight fails on a corporate network: * Is the corporate root certificate installed in the **system** keychain, not just a user keychain or a browser store? * Is HTTPS egress to Drizz's domains allowed, including the real-time connection? * Is there a proxy that terminates long-lived connections after a fixed idle period? ## Common mistakes | What you do | What happens | | ------------------------------------------------------------ | ---------------------------------------------------------------------- | | Debug a failing run for an hour before running preflight | Preflight would have named the failing layer in 20 seconds | | Assume "works on hotspot, not on office wifi" is a Drizz bug | It's TLS inspection or an egress rule. Take the preflight output to IT | | Install the corporate certificate in a browser only | Drizz reads the macOS system store. It needs to be there | | Re-run preflight without fixing anything | Same result. Fix the topmost red row, then re-run | | Ignore an amber real-time connection row | Runs start and then die partway. That row is the reason | | Reinstall the app to fix a network problem | Nothing changes. The network is outside the app | ## Next * [Download & install](/desktop-app/download-and-install) * [Updates & forced updates](/desktop-app/updates) * [Report an issue](/desktop-app/report-an-issue) *** *Last updated: 6 August 2026* # Tour of the interface A map of the desktop app window — what each panel does and what each control means. The desktop app is one window with seven areas plus a wallet badge. | | | | ------------- | ------------------------------------------------------------------- | | **Platforms** | macOS | | **Left** | Sidebar and file explorer — profile, projects, tests, modules | | **Center** | Editor — your test file, multiple tabs, `/` for the command list | | **Right** | Device panel and variables | | **Bottom** | Console — live logs, per-step screenshots, run status | | **Watch out** | The wallet badge is the first thing to check when a run won't start | ## Prerequisites * Drizz desktop app installed and signed in * A connected device for the device panel and console to populate ## Panels
#AreaPurpose
1SidebarProfile, Discover, a link to these docs, update prompts, and the collapsible Drizz Studio panel
2File explorerProjects, tests, modules and folders, and the Online / Local toggle
3–4EditorThe open test file. Multiple tabs, / command hints, autocomplete, per-step status decorators, save and save-as with unsaved-change tracking
5Device panelConnected devices, the device picker, app selection, connect and disconnect
6Variables panelThe variables available to the open file, colored by whether they resolve
7ConsoleLive execution log, per-step screenshots, run status banner
8Wallet badgeDT balance
Two surfaces sit alongside the window layout: | Surface | Purpose | | ---------- | ------------------------------------------------------------------- | | **Chat** | Describe a test in plain English and have Drizz generate the script | | **Memory** | Org-level context and blocker rules for an app | ## Editor controls | Control | Behavior | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `/` on an empty line | Opens the command palette with autocomplete. The editor shows the hint *"Type '/' for Drizz supported commands"*. The palette is the authoritative command list | | Tabs | Several test files open at once. The active tab shows an unsaved-change indicator | | Step decorators | A status marker in the gutter on each line during and after a run — passed, failed, running, not yet reached | | Module expansion | A `CALL` line shows the module's body inlined beneath it, indented and read-only. ***Edits are made in the module file*** | | Command Guidelines | Explain command level particulars and ready to use command examples. Mentions best practice for all commands. | ## Device panel | State | Behavior | | ----------------- | ------------------------------------------------------------------------------------------------------------------- | | Devices available | Pick a device, pick the app under test, connect. The panel shows the connected device, its OS version and its state | | No device set up | The panel offers the [guided setup wizard](/desktop-app/device-setup-wizard) | ## Variables panel | Color | Meaning | | --------- | -------------------------------------------------------------------------------- | | **Green** | The variable resolves against the selected dataset | | **Red** | The variable does not exist in the selected dataset. That step fails at run time | ## Console | Element | Meaning | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | Live log lines | Step-by-step execution output for the current run | | Status banner | Run status and the run's token usage | | *"Predicted Action drizzing fast ⚡"* | The step resolved from cache instead of by Vision AI. It ran in a fraction of the time and cost a fraction of the tokens | | Steps you didn't write | Automatic popup dismissal, from blocker rules defined in Memory for your app | ## Wallet badge | Fact | Detail | | ---------------------- | ------------------------------------------------------------------------------------------ | | Shows | Remaining DT balance, and DT used by the current run | | Vague run-start errors | An exhausted balance can present as a server or availability error. Check this badge first | | After a top-up | The badge does not always refresh immediately. Navigate away and back | ## Reporting a problem **Report Issue** bundles logs, recent screenshots and device state and sends them to Drizz support. See [Report an issue](/desktop-app/report-an-issue). ## Common mistakes | What you do | What happens | | -------------------------------------------- | ------------------------------------------------------------------------------- | | Hunt through menus for the command list | Press `/` on an empty line. That palette is the complete list | | Ignore a red variable in the variables panel | The run fails on that step. Fix it before you press run | | Read a failure from the log alone | The per-step screenshot answers most failures. Open the before-screenshot first | | Edit the inlined module body under a `CALL` | It's read-only. Edit the module itself | | Debug a vague "run won't start" error | Check the wallet badge before anything else | | Describe a symptom in an email to support | Use Report Issue. It sends the logs, screenshots and device state with it | ## Next * [Projects, tests & modules](/desktop-app/projects-tests-and-modules) * [Report an issue](/desktop-app/report-an-issue) * [Set up a device: guided wizard](/desktop-app/device-setup-wizard) *** *Last updated: 6 August 2026* # Projects, tests & modules How the file explorer organizes work — tests, modules, folders, the green M badge, and the Online/Local toggle. A project holds two file types — tests and modules — organized into folders in the file explorer. {% hint style="info" %} **At a glance** `New File` → Test · Module · Folder {% endhint %} | | | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | **File types** |

Test — one end-to-end flow
Module — reusable steps called from tests

| | **Telling them apart** | Modules carry a green **M** badge in the file explorer | | **Workspace** | **Online** syncs with your org · **Local** shows drafts on your Mac | | **Scope** | Everything is org-scoped — your colleagues see the same tests and modules | | **Watch out** | Deleting a project that holds a module breaks every test that calls it, Drizz warns while taking this action. Resolving modules is the way out. | ## Prerequisites * Drizz desktop app installed and signed in * A project in your organization ## File types
TestModuleFolder
ContainsOne end-to-end flow, one step per lineA block of steps called from many testsTests, modules and other folders
BadgeNoneGreen M in the file explorerFolder icon
Edited inThe editorThe editor—
RunsLocally on a connected device, or in the cloud through a test planOnly when called from a testNot runnable
SupportsValidations, conditionals, scrolling, system commands, module callsThe same commands as a testExpand and collapse
Called by—CALL <module_name>—
Functional effect of nestingNone — a test in a folder behaves the same as one at the rootNoneOrganization only
Full module syntax, parameters and nesting rules are on [Modules](/writing-tests/modules). ## Calling a module ``` CALL login_module ``` The module's body appears inlined beneath the call, indented and read-only. Edits are made in the module file, not in the inlined copy. ## Naming conventions | Item | Convention | Example | | ------ | --------------------------------------- | ---------------------------------------------------------------- | | Test | The flow's purpose, prefixed with an ID | `T01 — Invalid search feedback`, not `test1` | | Module | What it does, in `snake_case` | `login_module`, `city_selection_from_homepage`, not `T01_module` | | Folder | Feature, sprint or team | — | ## Online and Local | View | Shows | | ---------- | ------------------------------------------------------------------------ | | **Online** | Files synced with your organization's project — what your colleagues see | | **Local** | Drafts and locally stored files on your own Mac | **Test plans run what is Online. A file left in Local does not run in the cloud.** ## Sharing and module dependencies Your organization is created automatically from your email domain. Tests, modules, folders, datasets and Memory are all org-scoped and visible to every member. A module is a dependency of every test that calls it: | Action | Effect | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | `CALL` with no matching module | The step fails | | Deleting a project that holds a module | Every test calling that module breaks. The warning is easy to miss | | Renaming a module | Every `CALL` using the old name gets auto updated, editing modules applies changes to all test where that module will be called in future. | ## Creating a file 1. Click **New File**. 2. Select **Test**, **Module** or **Folder**. 3. Name it per the conventions above. 4. Confirm it appears in the file explorer tree. ## Common mistakes
What you doWhat happens
Delete a project to tidy upEvery test calling a module in it breaks, and the warning is easy to miss
Name tests test1, test2Unreadable at 40 files. Name them for the flow
Edit the inlined module body under a CALLIt's read-only. Edit the module file
Type CALL login_module straight throughAutocomplete lags. Type CALL, pause for the dropdown, then pick
Assume your files are privateEverything is shared with your organization
Leave work in Local and expect a cloud plan to run itTest plans run what's Online. Sync it
## Next * [Modules](/writing-tests/modules) * [Tour of the interface](/desktop-app/interface-tour) * [The shape of a test](/writing-tests/writing-tests) *** *Last updated: 6 August 2026* # Report an issue Report Issue bundles your logs, screenshots and device state and sends them to Drizz support in one click. **Report Issue** in the desktop app collects the logs, screenshots and device state support needs, and sends them. {% hint style="info" %} `Report Issue` — in the desktop app {% endhint %} | | | | ------------------ | ---------------------------------------------------------------------------------------------------- | | **Platforms** | macOS | | **What it sends** | Only platform related support, device and connection state. For testcase refernece mention thread ID | | **When to use it** | Anything you can't explain from the run report and the troubleshooting table | | **Why** | Support gets the evidence immediately instead of asking for it tomorrow | | **Watch out** | Send it while the problem is fresh — the bundle carries *recent* logs, not all history | ## Prerequisites * Drizz desktop app installed and signed in * The problem reproduced recently — the bundle carries recent logs only * One line describing what you expected and what happened ## Check these first These resolve most reports in under a minute. 1. Check the wallet badge. A vague server or availability error can be an exhausted balance. 2. Run **Help → Network Preflight**, especially if the same test worked on another network. See [Networks, proxies & preflight](/desktop-app/networks-and-preflight). 3. Open the before-screenshot of the failing step in report. A screen other than the expected one means the real failure is an earlier step. 4. Confirm you are on the current version. See [Updates & forced updates](/desktop-app/updates). ## Send a report 1. Reproduce the problem, or send the report during an occurrence. 2. Open **Report Issue** in the desktop app. 3. Write one specific line in the description field with Thread ID. 4. Submit. Drizz attaches the logs, screenshots and device state automatically — no manual attachment is required. ## What the bundle contains | Included | Why support needs it | | ------------------------------- | ------------------------------------------------------------------------------------------- | | **Application logs** | What the app was doing at the moment it went wrong, including anything that failed silently | | **Recent screenshots** | What was actually on the device screen | | **Device and connection state** | Which device, which platform, whether it was connected, what state it was in | | **App and environment details** | Your version, so support knows whether you're hitting something already fixed | The bundle carries **recent** logs and screenshots, not full history. Evidence from a problem hit three days earlier may have rolled off. For an intermittent problem, send the report on an occurrence. ## When to use it | Situation | Use Report Issue | | --------------------------------------------------------------------------------------------------------------------------- | ---------------- | | A run fails and neither the run report nor the [troubleshooting table](/reports-and-debugging/troubleshooting) explains why | ✅ | | Sign-in completes but the app doesn't log you in, and relaunching didn't help | ✅ | | A device shows up in `adb devices` or Xcode but not in Drizz | ✅ | | A step behaves differently from one run to the next with no change to the script | ✅ | | Anything hangs | ✅ | ## What to put in the description The bundle carries the facts. The description carries the intent. | Include | Example | | -------------------------------------- | --------------------------------------------- | | What you expected to happen | The cart screen opens | | What happened instead | The tap fails as undoable | | Which test and which step | T04 step 7 — tap on Add to Cart | | Whether it's every run or intermittent | Every run since this morning | | Which platform | Fails on the iOS simulator, passes on Android | One line covering all five: ` T04 step 7 — tap on Add to Cart fails on the iOS simulator, passes on Android, every run since this morning` ## Common mistakes | What you do | What happens | | -------------------------------------------------------- | -------------------------------------------------------------------- | | Email a description of the symptom | Support asks for logs, and you lose a day to the round trip | | Use Report Issue three days after the problem | The relevant logs may have rolled off. Do it while it's live | | Send the bundle with no description | Support has the evidence but not what you expected to see | | Photograph the error with your phone | The bundle already contains the real screenshots | | Use it before checking your wallet balance | A vague server error is often an empty wallet | | Use it for a device problem before running `adb devices` | If adb can't see the device, Drizz can't either — and that's the fix | ## Next * [Networks, proxies & preflight](/desktop-app/networks-and-preflight) * [Troubleshooting](/reports-and-debugging/troubleshooting) * [Updates & forced updates](/desktop-app/updates) *** *Last updated: 6 August 2026* # Drizz AI Describe a flow in plain language and Drizz explores the app and writes the script for you. Android only, best under 25 steps. Chat takes a plain-language description of a flow, runs it on a live device, works out each step as it goes, and produces a script. | | | | ----------------- | --------------------------------------------------------------- | | **Platforms** | Android · iOS | | **Where it runs** | A local Android emulator connected to the desktop app | | **Best length** | \~20–25 steps per run | | **Not generated** | API steps, module calls, `Store` and `SET` — add those yourself | | **Watch out** | The output is a first draft, not a finished test | Drizz AI is also referred to as Fathom. ## Prerequisites * Drizz desktop app installed and signed in * A local Android emulator running * The emulator connected to the desktop app * The app under test installed and open on that emulator ## Run a test with Chat 1. Click the chat icon at the top left of the editor. 2. Intent: one or two sentences describing the scenario, including any data the flow needs, such as a phone number, a search term or an address. 3. End Condition: state the condition to end the test execution 4. Watch the run. Drizz executes on the emulator one step at a time, looking at the current screen, deciding the next action and performing it. 5. Answer any question Drizz asks. It pauses on an unexpected screen, a navigation loop or an ambiguous path, and resumes once you reply. 6. Review the generated script, which opens in the editor when the run finishes. ## What gets generated | Included | Detail | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | UI actions | The full sequence performed during the run | | `IF` blocks | Where the intent implied conditional behavior, so the script reflects the app's real branching rather than the single path this run took | | Validation commands | Where checks were specified in the intent or during the run | | Navigation steps | The steps needed to reach the flow | ## Edit and save the output The output is an ordinary Drizz script. Before saving: 1. Tighten any description that reads vaguely against the app's exact wording. 2. Add waits after anything that navigates or calls the network. 3. Add the validations that matter. Generated scripts under-validate. 4. Replace repeated setup with a `CALL` to a shared module. 5. Add any `Store`, `SET` or `API:` steps the flow needs. 6. End the script with `CLEAR_APP`. 7. Save the test and run it once from the editor to confirm it passes unattended. A saved Chat script behaves like any other test — add it to a test plan, run it on the device cloud, use it for regression. ## Limits | Limit | Detail | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | API/Variable/Module support | Only fuctional UI testing is supported | | Run length | \~20–25 steps. Beyond that Drizz loses track of the flow and produces missed steps or inconsistent behavior. Split a long journey into two or three runs and stitch the scripts together, or make the shared prefix a module | | Not generated | API steps, module calls, `Store` and `SET`. Add them afterwards | | Conventions | Chat has no knowledge of your naming, your module library or your validation depth | | Not suited to | Long regression journeys, flows needing API setup, and any test that must be exactly right on the first pass | ## Common mistakes | What you write | What happens | | ------------------------------------------------- | ------------------------------------------------------------------------ | | An intent covering a 40-step journey | Drizz loses context partway. Split it | | `test the checkout flow` | Too vague. Name the screens, the data and the end check | | Expecting `API` `SET` or `CALL` in the output | Not generated. Add them in the editor | | Saving the generated script unedited | Under-validated, and descriptions may not match your app's exact wording | | Waiting for Chat while it's asking you a question | It pauses for clarification. Answer it and the run resumes | ## Next * [The shape of a test](/writing-tests/writing-tests) * [Modules](/writing-tests/modules) * [Authoring rules](/writing-tests/authoring-rules) *** *Last updated: 6 August 2026* # The shape of a test The structure of a Drizz test: one instruction per line, five beats, and the command palette that lists everything Drizz understands. A Drizz test is a plain text file: one instruction per line, running top to bottom. | | | | ---------------- | ------------------------------------------------------------ | | **Format** | Plain text. No selectors, no page objects, no SDK | | **Comments** | Lines starting with `#` are skipped | | **Command list** | Press `/` on an empty line in the editor | | **Test shape** | Setup → Navigate → Act → Validate → Clean up | | **Watch out** | If a command isn't in the `/` palette, Drizz doesn't have it | ## Prerequisites * Drizz desktop app installed and signed in * A connected device or emulator * A registered app — `com.shopease.android` in these examples * A project with at least one test file ## Copy this ``` # T04 — Search and add to cart CALL login_module Tap on the search icon Wait Until 2 Seconds Type running shoes in the search field Tap on the first search result Wait Until 3 Seconds Validate that the product detail page is visible Store the price as listed_price Tap on Add to Cart Wait Until 2 Seconds Validate that Item added to cart is visible CLEAR_APP com.shopease.android ``` ## Write a test 1. Open a test file in the desktop app. 2. Press `/` on an empty line to list every command Drizz supports. 3. Write one instruction per line, in the app's own wording. If the button reads `Charge Now`, write `Charge Now`. 4. Order the lines Setup → Navigate → Act → Validate → Clean up. 5. Add a `Validate` after each step that navigates, submits or pays. 6. End with `CLEAR_APP ` so the next test starts from first launch. 7. Run the test and confirm every step resolved in the report. ## The five beats | Beat | What it does | Commands | | ---------------- | ---------------------------------------- | ---------------------------------------------------- | | **1 · Setup** | Open the app and get to a known state | `CALL login_module`, `OPEN_APP com.shopease.android` | | **2 · Navigate** | Get to the screen under test | `Tap`, `Scroll`, `Wait` | | **3 · Act** | The scenario itself | `Tap`, `Type`, `MAP_ACTION` | | **4 · Validate** | Assert the outcome | `Validate` | | **5 · Clean up** | Leave the device ready for the next test | `CLEAR_APP com.shopease.android` | One scenario per test. ## Writing the lines
RuleDetail
Plain English, in the app's own wordsUse the exact wording on screen. Tap on Charge Now
Continuous modeDrag and select the lines if you only plan to run those over particular screens.
Note: Continuous mode works for the current state of UI
The / palette is the authoritative listIt shows every supported command, with autocomplete for package names, modules and variables. The same list is on the Command index
Repeated setup belongs in a moduleLogin, choosing a city, setting an address — write it once and CALL it. See Modules
Popups that can appear anywhere belong in MemoryNot in every test. See Memory & blockers

Comments start with #
Eg.

Tap on Proceed to Pay
# Tap on Apply Coupon
Use them to label sections and to park a step that shouldn't run yet
## Common mistakes | What you wrote | What happens | | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A test that covers login, search *and* checkout | One failure blocks three scenarios, and the report can't tell you which one is actually broken | | No `CLEAR_APP` at the end | The next test starts on whatever screen this one left behind, and passes or fails for unrelated reasons | | `Tap on the payment button` when the button reads `Charge Now` | Vision AI has to guess which control you meant. Wrong element, or a step that fails intermittently. Use double quotes to perform actions on spefic UI element | | A command copied from an old script that isn't in the `/` palette | The line is classified as something else, or fails at run time. The palette is the source of truth | | The same login steps pasted into 30 tests | A UI change to login breaks 30 tests instead of one module | | An `IF` block for a promo popup, repeated in every test | The popup still interrupts the tests you forgot. Put it in Memory once | ## Next * [Command index](/writing-tests/command-index) — every command, one table * [Tap](/writing-tests/tap) — the most-used command * [Waits & timing](/writing-tests/waits-and-timing) — fixed waits and where they go *** *Last updated: 6 August 2026* # Command index Every command Drizz understands, in one table — syntax, what it does, and where the detail lives. Every command Drizz understands, in one table. A command that isn't here isn't a command — press `/` in the editor to confirm. ## Prerequisites * A connected device or emulator * An open test file ## Commands
CommandWhat it doesPage
# <text>A comment. The line is skippedThe shape of a test
Tap on <description>Tap an element described in plain EnglishTap
Type <text> in <field>Enter text into a field, focusing it for youType
Validate <condition>Assert something is true on screenValidate
Scroll <direction>Scroll by a fixed amount Scroll
Scroll <direction> by <n>%Scroll by a specific amountScroll
Scroll <direction> until "<target>" is visibleScroll until something comes into viewScroll
Swipe / Drag / SlideSynonyms of Scroll — same directional behaviorScroll
Wait Until <n> SecondsPause for a fixed timeWaits & timing
IF <condition> { … }Run steps only when the condition holdsConditionals
ELSE IF <condition> { … }Next branch when the IF doesn't matchConditionals
ELSE { … }Fallback branchConditionals
MAP_ACTION Tap on <description>Coordinate-based tap for unlabeled or canvas elementsMAP_ACTION
MAP_ACTION Drag <from> to <to>Drag a slider, seekbar, map pin or swipe-to-confirm controlMAP_ACTION
OPEN_APP <package>Launch an appSystem commands
KILL_APP <package>Force-stop an appSystem commands
CLEAR_APP <package>Wipe app data and reset to first launchSystem commands
MINIMISE_APP <package>Send the app to the backgroundSystem commands
PRESS_DEVICE_BACK_BUTTONAndroid hardware backSystem commands
SET_GPS(latitude=<lat>, longitude=<lon>)Mock the device locationSystem commands
ENABLE_WIFI / DISABLE_WIFITurn wifi on or offSystem commands
TOGGLE_LOCATIONToggle location servicesSystem commands
SET <var> = "<value>"Assign a variableStore & SET
SET <var> = screen(<description>)Capture structured data off the screenStore & SET
{{var}}Reference a variable in any commandWhich variable do I use?
{{var.field}}Reference one field of a structured variableWhich variable do I use?
CALL <module>Run a reusable moduleModules
CALL <module>(<param>={{value}})Run a module with parametersModules
PARAM <name>Declare a module parameter, inside the moduleModules
API:<api_name>Call a registered APIAPI steps
## Syntax conventions | Convention | Detail | | ------------------------------------------- | ---------------------------------------------------------------- | | **Angle brackets are placeholders** | `` means you type `com.shopease.android` | | **Keywords are case-insensitive** | `Validate`, `validate` and `VALIDATE` all work | | **System commands are written in capitals** | `OPEN_APP`, not `open_app` | | **Validation keywords** | `Validate`, `Verify`, `Confirm` and `Check` are the same command | | **Scroll conjunctions** | `until`, `till` and `untill` are all accepted after `Scroll` | | **Variables** | Anything in `{{ }}` is substituted before the step runs | ## Common mistakes | What you wrote | What happens | | --------------------------------- | ---------------------------------------------------------------------------------------------------------- | | `OPEN_APP` with no package name | Fails by design. The package argument is required | | `OPEN_APP:(com.shopease.android)` | Not supported. Use a space: `OPEN_APP com.shopease.android` | | `open_app com.shopease.android` | System commands are written in capitals — write `OPEN_APP` | | `Wait until the cart loads` | Accepted by the editor, but only fixed-duration waits are confirmed to wait. Write `Wait Until 10 Seconds` | ## Next * [The shape of a test](/writing-tests/writing-tests) — how the commands fit together * [Tap](/writing-tests/tap) — the most-used command * [Waits & timing](/writing-tests/waits-and-timing) — fixed waits and where they go *** *Last updated: 6 August 2026* # Actions Tap an element by describing it in plain English, and the six ways to describe it so only one element matches. `Tap` presses one element on screen. The description identifies the element; Vision AI locates it. | | | | ----------------- | ----------------------------------------------------------------- | | **Platforms** | Android · iOS | | **Targets by** | Visible text, icon, position, neighboring element, section, color | | **Best target** | The element's exact visible label | | **Also accepted** | `Tap`, `Tap on`, `Tap the` — all the same command | | **Watch out** | Paraphrasing the label is the most common cause of a wrong tap | ## Prerequisites * A connected device or emulator * An open test file * The target screen reachable by the steps above the tap ## Copy this ``` OPEN_APP com.shopease.android Wait Until 5 Seconds Tap on the search icon Type running shoes in the search field Tap on the first search result Wait Until 3 Seconds Validate that the product detail page is visible Tap on Add to Cart Wait Until 2 Seconds Validate that Item added to cart is visible ``` ## Write a tap step 1. Read the element's exact visible label off the screen. 2. Write `Tap on