Launch configuration

Launch configurations are reusable values applied when Revyl starts your app. Each named configuration has one type:

• Environment variable stores one key-value pair. Android receives it as a string Intent extra. iOS receives the compatible -KEY value argument pair.
• iOS argument set stores an exact ordered list of argument tokens. Revyl passes those tokens unchanged to iOS simulators and physical devices. Android does not receive them.

Common Use CasesCopy Anchor Link

• Auth bypass tokens: skip OAuth flows by injecting a pre-issued test token, so every test starts authenticated without clicking through a login screen
• Feature flags: turn specific features on or off for testing before flipping them for real users
• Custom testing flags: enable test-only debug menus, mock data modes, or skip animations for faster, more deterministic runs
• Environment URLs: point your app at staging, dev, or a local tunnel without rebuilding
• API keys and secrets: credentials your app reads at startup, without baking them into the binary

Create A Launch ConfigurationCopy Anchor Link

1. Go to Library > Launch Configurations.
2. Click New launch configuration.
3. Enter a name and choose Environment variable or iOS argument set.
4. Enter the value, or type launch arguments as one command line: --mode staging --debug. Quote a value that contains spaces, such as --name "Ada Lovelace". The preview under the field shows the exact ordered tokens your app receives.
5. Turn on Secret for credentials or tokens, then save.

Attach configurations to a test in its Launch Configuration section. The attachment order is significant: Revyl flattens attached argument sets in that order. Runtime-selected sets follow in flag order, and inline tokens are appended last. On iOS, all explicit argument tokens precede the legacy -KEY value pairs generated from environment-variable configurations.

Android test and session forms hide iOS argument sets. An Android-only API or CLI run rejects explicit iOS arguments. A mixed-platform workflow applies them to iOS children and skips them for Android children.

Sensitive ValuesCopy Anchor Link

An environment value or an entire iOS argument set can be marked secret. Revyl encrypts secret payloads, masks them in the Library and immutable execution snapshot, and scrubs the individual values or tokens from worker diagnostics. Secret payloads can only be replaced, not viewed. Non-secret payloads remain visible in both the Library and the execution report's launch snapshot.

Changing a non-secret variable to secret protects future runs, but does not rewrite report history. Changing a secret variable to non-secret requires a replacement value because Revyl never reveals the existing secret.

Launch Configuration vs Global VariablesCopy Anchor Link

These serve different purposes:

CLI And Session OverridesCopy Anchor Link

Select a stored environment configuration with repeatable --launch-var and a stored iOS argument set with repeatable --launch-arg-set. Add exact inline tokens with repeatable --launch-arg=<token>:

revyl device start --platform ios \
  --launch-var API_URL \
  --launch-arg-set AuthTestArguments \
  --launch-arg=--route \
  --launch-arg="sign in"

Inline environment values and argument tokens are non-secret. Do not place credentials in them because they can appear in shell history, process arguments, and execution reports.

For Expo cloud-agent runs, launch vars pair well with a test-only auth deep link: start revyl dev with --launch-var, then send the app-specific auth link with revyl device navigate. See Auth Bypass Deep Links for the full flow.

Core Data concurrency checksCopy Anchor Link

To enable Apple’s Core Data concurrency assertions, create an iOS argument set containing:

-com.apple.CoreData.ConcurrencyDebug 1

Attach it to the iOS test. Revyl preserves this as two ordered tokens, ["-com.apple.CoreData.ConcurrencyDebug", "1"], including app relaunches. Xcode scheme arguments alone do not configure Revyl launches.

The equivalent CLI run is:

revyl test run <test> \
  --launch-arg=-com.apple.CoreData.ConcurrencyDebug \
  --launch-arg=1

When supported crash evidence is available, the authenticated report’s Performance → Runtime checkers section shows Core Data queue violation detected. A matched crash without a supported diagnosis shows App crash detected. These informational findings do not change the verdict, including passing runs, and also appear on workflow child test reports without steps or an AI summary. Public share views omit runtime findings. Raw crash files remain internal.

Report JSON exposes these entries in runtime_checker_findings, with kind core_data_queue_violation or unclassified_app_crash. No crash finding means no usable diagnosis, not proof that the app was crash-free. This feature covers collected JSON IPS evidence from iOS simulator test finalization; it does not backfill historical reports or diagnose interactive sessions, legacy .crash files, or other debugging flags.

Crash findings include the earliest matching crash time in first_observed_at and last_observed_at (the same UTC instant for this report-level diagnosis). The time comes from the IPS captureTime process termination field, not report creation, file modification, or collection time. A confirmed Core Data diagnosis uses the earliest crash supporting that diagnosis, even if an unrelated crash happened earlier.

Each finding's row starts with an approximate recording offset you can click to seek. Without a recording origin, it shows the UTC crash time without a seek action. Historical findings without timestamps show a dash. The CLI also displays the UTC time. Raw crash contents remain internal.

Expanding the finding shows up to 32 selected frames from each of the crashed-thread and exception backtraces. Frames are restricted to the app bundle and supported Apple images. Source references contain only a basename and line number, never a build-machine path. Original frame numbers are retained, so gaps may indicate omitted frames. CLI reports and JSON include the same selected stacks.

Symbols and source locations are taken from the crash report when available; this does not add dSYM upload or symbolication. Missing or unsafe symbols show Symbol unavailable. If no approved frames remain, the report says so. Other threads, binary paths and runtime load addresses, registers, process metadata, raw IPS text, known instrumentation details, and configured secret values are excluded. These are partial stacks, not complete crash reports.

App-bundled frames, including third-party frameworks, also retain the binary basename, build UUID, architecture, and image offset when valid and available. Use the UUID to find the dSYM from the same simulator build. Add the image offset to that binary's preferred __TEXT address from its dSYM, then resolve it with atos. See Apple's symbolication guidance. The report and CLI display these details; JSON exposes them as app_image on each app frame. Older findings may omit them. Revyl does not upload dSYMs or perform additional symbolication automatically.