Mobile Runtime

Certyn supports two different Appium-related workflows:

• Responsive web testing: a normal web run uses browser device emulation to check mobile layouts, touch-sized UI, and mobile browser behavior.
• Mobile or desktop app testing: a mobile runtime run connects to an Appium server and controls an Android, iOS, Windows, or macOS app on a configured device, simulator, emulator, desktop session, or device-cloud session.

Use mobile runtime when the target is a native or hybrid app, not just a website at a mobile viewport.

What you need

Mobile runtime projects require a reachable Appium endpoint. In cloud deployments, the Appium server must be reachable from Certyn, usually through a hosted device farm, a public tunnel, or your self-hosted runner network.

The required project settings are:

• runtimeSurface: mobile
• mobileRuntime.appiumServerUrl: Appium server base URL
• mobileRuntime.platform: android, ios, windows, or macos

The connection metadata is provider-neutral:

• mobileRuntime.provider: generic, browserstack, saucelabs, or lambdatest; named providers only control setup guidance and defaults
• mobileRuntime.authenticationType: none or basic
• mobileRuntime.appiumUserName and mobileRuntime.appiumAccessKey: optional basic-auth credentials, stored separately from the URL; the access key is encrypted at rest and never returned after save

Common optional settings include:

• deviceName
• udid
• automationName
• app
• androidAppPackage
• androidAppActivity
• iosBundleId
• noReset
• mirrorEnabled
• extraCapabilitiesJson for namespaced W3C options such as bstack:options, sauce:options, or lt:options

Project settings provide defaults. Environment-level mobile runtime overrides can supply a different device or app target for staging, production, or device-specific environments.

A generic prepared Appium endpoint can work with only its URL because the gateway may already choose a device and launch target. Shared device-cloud hubs also need account credentials, an uploaded app reference, and whichever device constraints that provider requires.

For public endpoints, Certyn can verify the setup by opening a real short-lived session, reading a screenshot or page source, and closing the session. The verification timeout stays below one minute so it remains useful on short trial-device allocations. Private Appium endpoints are tested from their self-hosted runner during an execution.

What agents can do

Mobile-capable agents use Appium-specific tools to:

• capture screenshots and page source
• find elements by accessibility id, resource id, name, class, or XPath
• tap, type, swipe, long press, and press system keys
• navigate back or home
• launch the app under test
• change orientation
• wait for elements
• reset a stuck Appium session

API assessment runs on the API runtime surface through Explorer or Test Executor. Security-focused exploratory runs are web-only. Explorer and Test Executor can run on web or mobile, with tools filtered by the selected runtime surface.

Evidence

Mobile sessions produce the same kind of reviewable QA evidence as web sessions: screenshots, action history, agent reasoning, final outcomes, and issue details. The screenshot and Appium page source are the source of truth for mobile UI state; the live view may only mirror the device.