skip to content

When should an Appium suite drive Chrome or Safari as the app under test rather than your own app?

level: seniorimportance: must knowfreq 55%

answer

  1. the browser is the application under test
  2. no artifact, one capability, page live at once
  3. still a real device underneath
  4. two browsers by construction, never one

basics

~20 s

Drive the browser when the subject is the web property itself on a phone: the session asks for a browser, installs nothing, and starts on the page. It means Chrome on Android and Safari on iOS.

solid answer

~40 s

Use a browser session when the subject is the **web property itself** on a real handset. The session is asked for with `browserName`, installs no artifact, and comes up already addressed at the page, so setup collapses to one capability plus whatever start-up preferences the platform offers. Use an application session when the behaviour under test belongs to your app — its own screens, its lifecycle, its device integrations. Two consequences are worth saying out loud. First, a browser session is inherently **two browsers**: Chrome on **Android** and Safari on **iOS**, driven by two different bridges, so it is cross-browser coverage whether you wanted it or not. Second, you are still on a device — real screen size, real keyboard, real network — which is exactly why it is worth doing at all.

go deeper

for a junior

Be able to state the rule simply: if the thing being tested is a website opened on a phone, drive the browser; if it is your own app's screens, drive the app. Name the browser per platform.

for a middle

Explain what changes mechanically between the two shapes: no artifact is installed, the session starts on the page, and each platform supplies its own browser and its own web bridge.

for a senior

Argue the decision with its costs. Two bridges to maintain, start-up preferences on one platform only, and a page inside your own app that a browser session does not reach at all.

for a principal

Own the coverage claim. Decide deliberately what mobile-web coverage means for the product, what it does not prove about the app, and what maintaining two browsers costs the team over time.

## Two session shapes, one decision An Appium session is shaped by what you tell it the application is. - **An application session** names an artifact. The driver installs it and everything happens inside your app. - **A browser session** names a browser with `browserName`. Nothing of yours is installed; the phone's own browser is the application under test and the session comes up addressed at a page. The decision is not stylistic. It changes what gets installed, which component answers your commands, which capabilities are even meaningful, and what you are entitled to claim afterwards. ## What a browser session buys you Take the livestock-weighing product for farms: a native weighing app, and beside it a responsive weigh-in dashboard that farmhands open in whatever browser shipped with their phone. For the dashboard, the browser session is the right shape, and it is cheap: - **No artifact.** Nothing to build, nothing to install, no per-build packaging step in front of the run. - **One capability to ask.** `browserName` is the ask, and it is one of the standard W3C names, so it needs no vendor prefix. - **The page is live immediately.** On Android the session comes up in a `CHROMIUM` context; on iOS `appium:safariInitialUrl` can put Safari on the weigh-in page before your first command. - **Ordinary WebDriver above the seam.** Typing a weight, selecting an animal tag and submitting the record is portable code. - **A real handset underneath.** Real viewport, real on-screen keyboard, real touch input — the properties that make mobile web different from the same page on a desktop. ## What it does not cover A browser session's application *is the browser*. Everything that belongs to your own app stays outside it: - your app's native screens, navigation and its own lifecycle, - anything that depends on the app being installed, signed or launched, - the app's device integrations and its behaviour when it goes to the background, - a page rendered *inside* your app, which lives in your app's process rather than in Chrome or Safari and is therefore a different session shape entirely. That last distinction catches teams out. "We render the same dashboard in the app" is not the same claim as "the browser session covers it". The markup may be identical; the surrounding chrome, the navigation, the lifecycle and the failure modes are not. ## Platform honesty: you are buying two browsers | | Android | iOS | |---|---|---| | Browser you get | Chrome, package `com.android.chrome` | Safari | | Web bridge | a Chromedriver process | Apple's remote web inspector | | Start-up preferences | no `appium:safari*` family | `appium:safariInitialUrl`, `appium:safariAllowPopups`, `appium:nativeWebTap` | | Starting context | `CHROMIUM` | not a `CHROMIUM` context | There is no configuration that makes both platforms hand you the same browser. The moment the team decides to run mobile-web coverage through Appium, it has decided to maintain two browsers and two bridges. That is often exactly what you want — those are the two engines your users actually have — but it must be a decision, not a surprise discovered when one platform's runs start failing on their own. ## Deciding it on the farm product A workable rule for that product, in order: 1. **Is the subject the dashboard as served on the web?** Browser session. It is the cheapest honest way to exercise it on a real handset. 2. **Is the subject something the native weighing app does?** Application session. A browser cannot reach your app's screens. 3. **Is the subject the dashboard as embedded inside the app?** Neither shortcut applies — that page belongs to your app's process, and reaching it is a different session shape. 4. **Is the subject the page's markup and layout, with no device behaviour involved?** Then question whether it needs a device at all before you spend a mobile session on it. ## The costs to name out loud Saying "just run it in the browser" without naming the costs is the answer that marks a candidate as untested: - Two bridges mean two independent things to keep working, and one shared symptom will have two different causes. - Start-up preferences exist on one platform only, so the two runs can reach the page by different routes unless you make them match. - The device is still real: an emulator image without Chrome has no browser for the session to launch. - Tap behaviour is not identical, because one platform exposes a native-tap preference for web elements and the other performs clicks inside the browser. The senior answer is therefore not "browser sessions are for web apps". It is: the browser session is the right shape when the browser genuinely is the application under test, and choosing it means signing up for two browsers, two bridges and a capability block that cannot be shared.

  • Your farm dashboard also renders inside the native app. Does the browser session cover that?
    No. A browser session's application is Chrome or Safari, and a page rendered inside your own app lives in your app's process instead. The markup may be identical, but the surrounding chrome, navigation, lifecycle and failure modes are the app's, so it is a different session shape and needs its own coverage.
  • What start-up preferences does a browser session give you, and on which platform?
    On iOS the XCUITest driver applies `appium:safariInitialUrl`, `appium:safariAllowPopups` and `appium:nativeWebTap` while creating the Safari session, and `mobile: updateSafariPreferences` changes preferences later. The Android Chrome session has no `appium:safari*` counterpart, so anything the iOS run gets for free there has to be performed as an explicit step on Android.

saying these in an interview costs you the question

  • Claims a browser session also covers the native app's own screens
  • Says both platforms run the same browser in a browser session
  • Thinks a browser session removes the real device from the picture
  • Treats a green Safari run as evidence the Android run will pass
  • Expects appium:safari preferences to configure Android's Chrome