In Appium, what does `browserName` make the Android and iOS drivers do at session start?

middlemust knowfreq 62%

answer

nothing of yours gets installed
the driver launches an existing browser
each platform brings its own web bridge
Chromedriver here, remote web inspector there

basics

~20 s

browserName makes each driver start the platform's own browser and wire a web bridge to it: the Android drivers launch Chrome and proxy page commands to Chromedriver, while XCUITest launches Safari and drives it through Apple's remote web inspector.

solid answer

~40 s

browserName changes what the driver installs, what it launches and who answers your commands. On Android nothing of yours is installed; the drivers launch com.android.chrome, start a Chromedriver process and proxy the page-level commands to it, so the session comes up in a CHROMIUM context with the page already addressable. On iOS the XCUITest driver launches Safari and drives the page through Apple's remote web inspector, applying the Safari start-up preferences — appium:safariInitialUrl, appium:safariAllowPopups, appium:nativeWebTap — as part of creating the session. After the handshake the two look identical from your code: it is plain WebDriver against a page. Underneath they share nothing but the capability name.

`browserName` changes what the driver installs, what it launches and who answers your commands. On **Android** nothing of yours is installed; the drivers launch `com.android.chrome`, start a **Chromedriver** process and proxy the page-level commands to it, so the session comes up in a `CHROMIUM` context with the page already addressable. On **iOS** the **XCUITest** driver launches **Safari** and drives the page through Apple's remote web inspector, applying the Safari start-up preferences — `appium:safariInitialUrl`, `appium:safariAllowPopups`, `appium:nativeWebTap` — as part of creating the session. After the handshake the two look identical from your code: it is plain WebDriver against a page. Underneath they share nothing but the capability name.

code

json · 14 lines

json

{
  "android": {
    "platformName": "Android",
    "appium:automationName": "UiAutomator2",
    "browserName": "Chrome"
  },
  "ios": {
    "platformName": "iOS",
    "appium:automationName": "XCUITest",
    "browserName": "Safari",
    "appium:safariInitialUrl": "https://farm.example/weigh-in",
    "appium:safariAllowPopups": false
  }
}

go deeper

for a junior

Know that browserName means no artifact is installed and an existing browser is launched instead. Be able to name the browser per platform without guessing at what happens underneath.

for a middle

This is your tier. Walk through session start on both platforms: what launches, what web bridge is stood up, and which component answers a find in a Chrome session versus a Safari one.

for a senior

Turn the mechanics into triage. Say where you would look first when finds fail on one platform only, and why a shared symptom never implies a shared cause across the two bridges.

for a principal

Frame the cost of running two bridges permanently: two sets of diagnostics, two sets of upgrades, and a shared test layer whose portability stops at the capability block.

What changes the moment `browserName` is in the payload

Three things change, and they are worth separating because they fail separately.

What is installed. Nothing of yours. There is no artifact for the driver to push, so the whole install-and-sign half of a normal session simply does not happen.
What is launched. The platform's own browser, already present on the device.
Who answers your commands. Not the native automation agent alone. A browser session needs a web bridge, and each platform brings a completely different one.

The third point is the one interviewers are usually probing. A candidate who says "Appium opens the browser" has described a third of it; the interesting part is the handoff.

Android: launch Chrome, stand up Chromedriver, proxy the web commands

On Android the drivers resolve the browser to Chrome — package com.android.chrome — and launch it. In parallel they stand up a Chromedriver process and proxy the page-level half of the protocol to it. Chromedriver is the component that knows how to find an element in a rendered page, click it and read its text; the Android agent on the device is not doing that work.

The session reports its context as CHROMIUM, so it starts addressed at the page rather than at a native view tree.
Your first find is answered by Chromedriver, which is why a page-level failure produces Chromedriver-shaped diagnostics.
appium:automationName still selects the Android driver — UiAutomator2 — even though the browser half is Chromedriver's work.
The Android drivers expose mobile: getChromeCapabilities, which reports the capabilities handed across to Chromedriver.
If Chrome is absent from the image, there is no browser to launch and the session has nothing to drive.

iOS: launch Safari, attach the remote web inspector, apply the Safari preferences

On iOS the driver is XCUITest and the browser is Safari. XCUITest launches Safari and drives the page through Apple's remote web inspector — Apple's own debugging channel — rather than through anything Chromedriver-shaped. Because the driver is the thing starting Safari, it can also apply preferences before your first command:

appium:safariInitialUrl fixes the page Safari is showing when control returns to the test.
appium:safariAllowPopups decides whether script-opened pop-up windows are permitted.
appium:nativeWebTap decides whether clicks become native taps at translated coordinates.
mobile: updateSafariPreferences is the XCUITest execute method for changing preferences after the session exists.

Side by side

Step	Android	iOS
Artifact installed	none	none
Launched	Chrome (`com.android.chrome`)	Safari
Web bridge	a Chromedriver process	Apple's remote web inspector
Driver in charge	UiAutomator2 and the Android drivers	XCUITest
Start-up preference family	none in the `appium:safari*` shape	`appium:safariInitialUrl`, `appium:safariAllowPopups`, `appium:nativeWebTap`
Starting context	`CHROMIUM`	not a `CHROMIUM` context

What is identical afterwards

Once the session exists, the code is boringly portable. Opening the farm weigh-in dashboard, typing an animal's weight, choosing a tag from a select and submitting the record is the same WebDriver code on both platforms, because both are answering the same page-level command set. That is the whole appeal of a browser session and the reason teams reach for it when the thing under test is a web property rather than an app.

The portability stops precisely at the capability block and at the bridge. Two examples of the seam:

A start-up preference that exists only on Apple's side means the iOS run can begin already on the target page while the Android run has to get there itself.
A page-level command that starts failing has a Chromedriver-shaped explanation on Android and a remote-web-inspector-shaped explanation on iOS. The symptom is shared; the cause is never shared.

Failure shapes worth recognising

Session comes up but every find fails on Android. Look at the web bridge, not at the native agent — the on-device Android server is not the component answering finds in a CHROMIUM context.
Session comes up on the wrong page on iOS. Check whether appium:safariInitialUrl was set, and whether the run is silently relying on it while the Android job navigates by hand.
Taps land in the wrong place on iOS Safari but not on Android Chrome. That is the coordinate-translation family, and it exists only on the Apple side.
"It works on my machine" for one platform only. Expected: you are running two different browsers driven by two different bridges, and only the test code above them is shared.

The short version to say out loud in an interview: browserName replaces the artifact with a browser, and each platform then supplies both its own browser and its own way of talking to a page inside it.

## What changes the moment `browserName` is in the payload Three things change, and they are worth separating because they fail separately. 1. **What is installed.** Nothing of yours. There is no artifact for the driver to push, so the whole install-and-sign half of a normal session simply does not happen. 2. **What is launched.** The platform's own browser, already present on the device. 3. **Who answers your commands.** Not the native automation agent alone. A browser session needs a *web bridge*, and each platform brings a completely different one. The third point is the one interviewers are usually probing. A candidate who says "Appium opens the browser" has described a third of it; the interesting part is the handoff. ## Android: launch Chrome, stand up Chromedriver, proxy the web commands On Android the drivers resolve the browser to Chrome — package `com.android.chrome` — and launch it. In parallel they stand up a **Chromedriver** process and proxy the page-level half of the protocol to it. Chromedriver is the component that knows how to find an element in a rendered page, click it and read its text; the Android agent on the device is not doing that work. - The session reports its context as `CHROMIUM`, so it starts addressed at the page rather than at a native view tree. - Your first `find` is answered by Chromedriver, which is why a page-level failure produces Chromedriver-shaped diagnostics. - `appium:automationName` still selects the Android driver — UiAutomator2 — even though the browser half is Chromedriver's work. - The Android drivers expose `mobile: getChromeCapabilities`, which reports the capabilities handed across to Chromedriver. - If Chrome is absent from the image, there is no browser to launch and the session has nothing to drive. ## iOS: launch Safari, attach the remote web inspector, apply the Safari preferences On iOS the driver is **XCUITest** and the browser is **Safari**. XCUITest launches Safari and drives the page through **Apple's remote web inspector** — Apple's own debugging channel — rather than through anything Chromedriver-shaped. Because the driver is the thing starting Safari, it can also apply preferences before your first command: - `appium:safariInitialUrl` fixes the page Safari is showing when control returns to the test. - `appium:safariAllowPopups` decides whether script-opened pop-up windows are permitted. - `appium:nativeWebTap` decides whether clicks become native taps at translated coordinates. - `mobile: updateSafariPreferences` is the XCUITest execute method for changing preferences after the session exists. ## Side by side | Step | Android | iOS | |---|---|---| | Artifact installed | none | none | | Launched | Chrome (`com.android.chrome`) | Safari | | Web bridge | a Chromedriver process | Apple's remote web inspector | | Driver in charge | UiAutomator2 and the Android drivers | XCUITest | | Start-up preference family | none in the `appium:safari*` shape | `appium:safariInitialUrl`, `appium:safariAllowPopups`, `appium:nativeWebTap` | | Starting context | `CHROMIUM` | not a `CHROMIUM` context | ## What is identical afterwards Once the session exists, the code is boringly portable. Opening the farm weigh-in dashboard, typing an animal's weight, choosing a tag from a select and submitting the record is the same WebDriver code on both platforms, because both are answering the same page-level command set. That is the whole appeal of a browser session and the reason teams reach for it when the thing under test is a web property rather than an app. The portability stops precisely at the capability block and at the bridge. Two examples of the seam: - A start-up preference that exists only on Apple's side means the iOS run can begin already on the target page while the Android run has to get there itself. - A page-level command that starts failing has a Chromedriver-shaped explanation on Android and a remote-web-inspector-shaped explanation on iOS. The symptom is shared; the cause is never shared. ## Failure shapes worth recognising - **Session comes up but every find fails on Android.** Look at the web bridge, not at the native agent — the on-device Android server is not the component answering finds in a `CHROMIUM` context. - **Session comes up on the wrong page on iOS.** Check whether `appium:safariInitialUrl` was set, and whether the run is silently relying on it while the Android job navigates by hand. - **Taps land in the wrong place on iOS Safari but not on Android Chrome.** That is the coordinate-translation family, and it exists only on the Apple side. - **"It works on my machine" for one platform only.** Expected: you are running two different browsers driven by two different bridges, and only the test code above them is shared. The short version to say out loud in an interview: `browserName` replaces the artifact with a browser, and each platform then supplies both its own browser and its own way of talking to a page inside it.

How would you check which capabilities the Android side handed to Chromedriver?
The Android drivers expose the execute method `mobile: getChromeCapabilities`, which reports the capability set passed across to Chromedriver for the browser half of the session. It is the honest way to answer "what did the driver actually send" instead of inferring it from your own capability block. There is no equivalent on the Apple side, where Safari is driven through the remote web inspector.
Why does the Android browser session start in a CHROMIUM context rather than a native one?
Because the browser is the application under test and the page is what you asked to automate. `CHROMIUM` is the name Appium gives a Chrome-backed web context, and starting there means your first find already runs against the rendered page. On iOS the equivalent session starts against Safari's page too, but it is not reported under that name.

Asking for browserName is like ordering a taxi instead of shipping your own car: a vehicle is already waiting on the ground, but which vehicle you get is decided entirely by the city you landed in.

saying these in an interview costs you the question

Says the on-device Android agent matches page elements in a Chrome session
Believes the same bridge process serves Safari and Chrome
Thinks Appium ships its own browser with the server
Cannot say which platform reports a CHROMIUM context
Assumes the Appium server itself parses the page and matches selectors

In Appium, what does `browserName` make the Android and iOS drivers do at session start?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What changes the moment browserName is in the payload

Android: launch Chrome, stand up Chromedriver, proxy the web commands

iOS: launch Safari, attach the remote web inspector, apply the Safari preferences

Side by side

What is identical afterwards

Failure shapes worth recognising

▾common follow-ups2 questions

▾analogy~20 s

▾red flags5 flags

What changes the moment browserName is in the payload

Android: launch Chrome, stand up Chromedriver, proxy the web commands

iOS: launch Safari, attach the remote web inspector, apply the Safari preferences

Side by side

What is identical afterwards

Failure shapes worth recognising

answer

go deeper

What changes the moment `browserName` is in the payload

What changes the moment `browserName` is in the payload