Appium 2.0 Beta: What’s New and How to Try It
Appium 2.0’s beta introduced a modular server, separately installed drivers, and plugins. Here’s what changed and how to try the Appium 2 setup safely.
Appium 2.0’s defining change was modularity: the server became platform-agnostic, platform drivers became separately installed packages, and plugins became the extension point for changing or adding server behavior. To try the Appium 2 setup, install the server, install the driver for your target platform, then check your client’s server URL, W3C WebDriver support, and capabilities.
This article explains the beta-era change and gives reproducible Appium 2 setup examples. The exact beta version and its original package tag are not established by the available sources, so these examples describe the modular Appium 2 setup rather than claiming a particular historical beta is still installable.
What changed in Appium 2.0?
Appium’s official migration guide calls Appium 2.0 its most major new release in over five years. For someone moving from Appium 1.x, the practical change is that the server, platform driver, and optional plugin have distinct roles and installation lifecycles.
| Area | Appium 1.x expectation | Appium 2 setup |
|---|---|---|
| Platform support | Drivers came with the server installation. | Install the server and the driver you need separately. |
| Updates | Platform support was coupled to the server release. | Server and driver packages have separate versions and release schedules. Check compatibility when updating. |
| Extensions | Extensions were not organized around the Appium 2 plugin model. | Plugins can intercept or alter commands, extend behavior, or adjust aspects of the HTTP server. |
| Default endpoint | /wd/hub |
/; use --base-path=/wd/hub when a client or existing setup still requires the old path. |
| Protocol | Older JSON Wire Protocol and Mobile JSON Wire Protocol clients could be in use. | Appium 2 removes those older protocols and uses W3C WebDriver. |
| Capabilities | Some projects used unprefixed Appium-specific capabilities. | Non-standard capabilities need a vendor prefix. The migration guide recommends appium:, unless the driver documents otherwise. |
| Configuration | Options were commonly supplied on the command line. | Server options can also be set in JSON, JavaScript, or YAML configuration files. |
Driver-specific commands and options belong to the driver that owns them. When a migration changes behavior, check that driver’s documentation rather than assuming every Appium server option applies to every platform.
How to try the Appium 2 setup
The following commands are Appium 2-era examples from the official migration guide. They show the modular installation flow; check the current Appium documentation for current Node.js and npm requirements, package versions, and driver compatibility before using them in a new environment.
- Choose the platform you intend to automate and confirm its driver’s requirements.
- Install the Appium server.
- Install the platform driver separately, or select drivers during server installation.
- Start the server, then configure your client to use the correct endpoint and W3C capabilities.
- Run a small session against a test device or simulator before migrating a full test suite.
Install the server, then add a driver
npm install --location=global appium
appium driver install uiautomator2
The example installs the Android UiAutomator2 driver. Select the driver that matches your target platform; installing Appium alone does not install platform support.
Install selected drivers with the server
npm install --location=global appium --drivers=xcuitest,uiautomator2
This Appium 2-era example selects the XCUITest and UiAutomator2 drivers as part of installation. Confirm that your environment meets each driver’s current platform requirements.
Check the server endpoint
Appium 2 listens at / by default. If your client still sends requests to /wd/hub, either update its remote server URL or launch Appium with the legacy base path:
appium --base-path=/wd/hub
Use one matching endpoint on both sides. A server that starts successfully can still reject session requests sent to the wrong path.
Review capabilities and the client
Use a W3C-compatible client. Prefix Appium-specific capabilities with appium: unless the driver specifies a different prefix. For example, a capability map may include appium:automationName and appium:deviceName; the exact required capabilities depend on the driver and target. Consult the platform driver’s documentation for its required and optional capabilities.
Review existing tests for JSON Wire Protocol assumptions, unprefixed non-standard capabilities, and commands that have moved into a driver. The Appium 2 migration guide also notes that the old Appium Desktop inspector is not compatible with Appium 2; use Appium Inspector instead.
What beta-era guidance means today
The title refers to Appium 2.0 Beta, but the available primary sources do not establish the exact beta package version, original beta announcement date, or whether a beta-specific package tag remains available. Do not treat an old beta command or tag as current installation advice. The installation examples above illustrate the modular Appium 2 model; use official current documentation to select versions for a live environment.
A historical Appium Pro installation article describes the driver and plugin CLI in the beta-era context. Use it as historical background; use official Appium documentation for reproducible setup.
Drivers, plugins, and hosting choices
Drivers provide platform automation. Plugins extend server behavior. Because each can have its own version and requirements, record the server, driver, and plugin versions used by a test environment and check compatibility before updating any one of them.
With a local server, your team installs and updates the server, drivers, and plugins and controls access to its test devices. With a hosted Appium environment, check which drivers and plugins the provider makes available and whether it supports the capabilities your tests require. Appium’s migration guide says a server maintainer, including a cloud provider, is responsible for making the drivers and plugins available.
Troubleshooting Appium 2 migrations
| Symptom | Likely cause | What to check |
|---|---|---|
| Session creation reports that a driver is missing or cannot be found. | The server is installed, but the platform driver is not. | Install the driver for the target platform with the Appium extension CLI, then confirm it is available in that server environment. |
| The server starts, but the client cannot reach its endpoint. | The client uses /wd/hub while Appium 2 defaults to /, or the reverse. |
Match the client URL to the server base path. Configure --base-path=/wd/hub if the legacy path is needed. |
| A session fails with a capability error. | An Appium-specific capability is unprefixed, misspelled, or unsupported by the selected driver. | Use the appium: prefix where appropriate and check the driver documentation for exact names and requirements. |
| An older client or test sends unsupported commands. | The project relies on JSON Wire Protocol or Mobile JSON Wire Protocol behavior removed in Appium 2. | Move to a W3C WebDriver-compatible client and update protocol-dependent test code. |
| A driver update breaks a previously working environment. | Drivers and server are versioned independently. | Check the server and driver versions together, review driver compatibility guidance, and pin known-good versions in reproducible environments. |
| The old desktop inspector cannot connect. | The Appium Desktop inspector is not compatible with Appium 2. | Use Appium Inspector, as directed by the migration guide. |
| A server option has no effect. | The option may have moved to a driver, be driver-specific, or be set differently in a configuration file. | Check the server and owning driver documentation, then inspect the active JSON, JavaScript, YAML, or command-line configuration. |
Performance, reliability, and maintenance
- Keep the environment reproducible. Record server, driver, plugin, client, and device or simulator versions. Independent release schedules make explicit version tracking useful.
- Update deliberately. A driver can be updated without waiting for a server release, but that independence also means compatibility should be checked rather than assumed.
- Start with a small validation run. Confirm driver discovery, endpoint, W3C capabilities, and a basic session before debugging a large suite.
- Separate infrastructure failures from test failures. Check server reachability, driver availability, and device access before diagnosing an application assertion.
- Plan hosting around control needs. Compare who maintains drivers and plugins, which capabilities are available, and who controls configuration and test devices. The migration guide does not establish a universal performance or cost winner between local and hosted setups.
Or skip the browser setup
Appium is for automating mobile apps. If your workflow also needs website screenshots, ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. It does not replace Appium or capture mobile app screens. Its one-request API returns a screenshot or PDF of a URL. See the ScreenshotNeo API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
- Cookie and consent banners are accepted like a visitor, and 60+ known consent platforms, newsletter popups, and chat widgets are removed before capture; each step can be turned off.
- Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Responses say which outcome occurred in
X-Page-VerdictandX-Billedheaders. - An MCP server gives AI agents, including Claude, Cursor, and other MCP clients, the
take_screenshot,get_page_info, andcapture_pdftools. - The free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 screenshots.
Sign up free for 1,000 screenshots a month, with no card required.
FAQ
Does Appium 2 install Android and iOS drivers automatically?
No. Install the drivers your automation needs; the server alone does not provide platform support.
Can I keep using the /wd/hub path?
Yes. Configure the server with --base-path=/wd/hub, or update the client to use Appium 2’s default root path.
Is the beta installation command guaranteed to work now?
No. The examples describe the Appium 2 modular installation flow. Check official current documentation for supported runtime requirements and versions.
Does ScreenshotNeo run Appium tests?
No. ScreenshotNeo captures websites from URLs; Appium automates mobile applications.


