TestKase
TestKase
|Docs
AutomateMobile

Mobile browsers

Drive mobile Safari on a real iPhone and Chrome on a real Android phone from the same /wd/hub connection.

The same POST /wd/hub/session that starts an app session can drive the device's own browser instead. You get a real mobile browser on real phone hardware — not a desktop browser in a narrow window.

Requesting a mobile browser

Set platformName to the device platform and browserName to the browser:

platformNamebrowserNameWhat you get
iOSSafariMobile Safari on a real iPhone, driven by XCUITest through WebDriverAgent
AndroidChromeChrome on a real Android phone, with a matching chromedriver downloaded automatically
{
  "platformName": "iOS",
  "browserName": "Safari",
  "testkase:options": {
    "build": "smoke-1",
    "name": "mobile safari checkout"
  }
}

Both combinations are hardware-proven on real devices.

Those two are the whole list. Anything else is refused at the start of the session, rather than quietly given to you as something else.

There is no Chrome on iOS, and asking for it would not help. Apple requires every browser on an iPhone to use Safari's engine, so Chrome, Edge and Firefox on iOS are Safari with a different toolbar. They render the same pages the same way and run the same JavaScript. Appium can only attach to Safari in any case.

Your first browser session

Plain Selenium is fine here — no Appium client needed, because the session drives a browser:

// SafariOptions sets browserName. Use ChromeOptions for Android.
SafariOptions options = new SafariOptions();
options.setPlatformName("iOS");

Map<String, Object> tk = new HashMap<>();
tk.put("build", "smoke-1");
tk.put("name", "mobile safari checkout");
options.setCapability("testkase:options", tk);

URL hub = new URL("https://x:[email protected]/wd/hub");
RemoteWebDriver driver = new RemoteWebDriver(hub, options);
driver.get("https://example.com");
driver.quit();
const { Builder } = require("selenium-webdriver");

const hub = "https://x:[email protected]/wd/hub";

const driver = await new Builder()
  .usingServer(hub)
  .withCapabilities({
    platformName: "iOS",           // or "Android"
    browserName: "Safari",         // or "Chrome" on Android
    "testkase:options": { build: "smoke-1", name: "mobile safari checkout" },
  })
  .build();

await driver.get("https://example.com");
await driver.quit();
from selenium import webdriver
from selenium.webdriver.common.options import ArgOptions

options = ArgOptions()
options.platform_name = "iOS"          # or "Android"
options.browser_name = "Safari"        # or "Chrome" on Android
options.set_capability("testkase:options", {"build": "smoke-1", "name": "mobile safari checkout"})

hub = "https://x:[email protected]/wd/hub"
driver = webdriver.Remote(command_executor=hub, options=options)
driver.get("https://example.com")
driver.quit()

iOS serves Safari, Android serves Chrome.

Picking a version

browserVersion filters the device picker — ask for a version and the allocator only considers devices that can serve it. Omit it and you get whatever our machines offers.

The capability generator shows what is provisioned right now and builds the capabilities for you.

Artifacts

A mobile-browser session records sessionType: "browser" and captures the same things an app session does — session recording, live view, device logs, Appium logs and the commands tab. See Automate Mobile.

Network capture behaves slightly differently per browser — see Network capture (HAR).