# Appium Inspector lost its web app and became a desktop client plus a server plugin > Appium Inspector is the GUI that shows an app screenshot next to its page source so a tester can pick selectors by hand. It ships today as a standalone Electron application or as an Appium server plugin, and the old hosted web app is no longer run by the Appium team. **appium/appium-inspector** — A GUI inspector for mobile apps and more, powered by a (separately installed) Appium server - Repository: https://github.com/appium/appium-inspector - Website: https://appium.github.io/appium-inspector/ - Stars: 1,907 · Forks: 407 - Language: JavaScript - License: Apache-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/appium-appium-inspector ## What the screenshot-plus-source pairing actually solves Writing an Appium locator by hand is guesswork unless you can see what the driver sees. Appium Inspector puts two views of the same app state side by side: a screenshot of the application page and its page source. From that pairing you can find an element, interact with it, and read back what the server reports. The README lists the core features as specifying the Appium server details, interacting with the app screenshot, searching for elements and interacting with them, and running Appium driver commands directly. The important constraint is stated in the project description itself: the Inspector is powered by a separately installed Appium server. It is not a server, not a driver and not a test runner. It is a client that talks to a server someone else started. That division shapes everything about installation, and it is why the documentation splits system requirements from the app download. The audience is narrower than the name suggests. The tool targets the human writing or debugging selectors, mostly during authoring and triage, not the CI pipeline that eventually executes those selectors unattended. ## Two distribution formats, and the web app is off the table The README states the Inspector is released in two formats. The first is a standalone desktop application for macOS, Windows and Linux, downloaded from the Releases section of the repository. The second is an Appium server plugin, with details in the plugin README under `plugins/README.md`. Because the plugin ships inside the server's own plugin model, version compatibility between Inspector and server becomes a concrete thing to check rather than a guess. The third format is gone, or at least disowned. A note in the README says the Inspector was formerly released as a web application hosted at `https://inspector.appiumpro.com`, that the site is no longer related to the Appium team, and that you should use the standalone app or the plugin version. The same note adds that the Appium team is exploring the idea of hosting an up-to-date version of the web app in the future. Read that as an open question, not a plan: anyone whose workflow still assumes a browser-hosted Inspector has to migrate to a desktop install or a plugin. The build configuration in the repository shows this is not a single artefact. `package.json` exposes three separate build targets: ## One codebase, three build targets, and a base path for the plugin The npm scripts make the architecture visible. `build:browser` runs `vite build` for the browser bundle, `build:electron` runs `electron-vite build` for the desktop app, and the top-level `build` script chains browser, electron and plugin. The plugin build is the interesting one: ```json "build:browser:url": "vite build --base $PUBLIC_URL", "build:plugin": "vite build --base /inspector --outDir ../../plugins/dist-browser" ``` The plugin build hardcodes the base path `/inspector` and writes outside the app tree into `../../plugins/dist-browser`. That tells you the browser code is shared with the plugin rather than reimplemented, and that the plugin expects to be served under an `/inspector` prefix by the Appium server. The `--base $PUBLIC_URL` variant exists for people hosting their own browser build at a custom path. The desktop target is packaged by electron-builder, driven by a root `electron-builder.json`: ```json "pack:electron": "electron-builder build --publish never" ``` `--publish never` means the local packaging step does not upload anything, which is what you want when producing an internal build. Development entry points are `dev:browser` running `vite` and `dev:electron` running `electron-vite -w` for watch mode. ## Linting moved off ESLint, but the e2e suite is disabled The repository has migrated to oxlint and oxfmt. The scripts are plain about it: ```json "lint": "oxlint -c oxlint.config.mjs .", "format": "oxfmt -c oxfmt.config.mjs .", "format:check": "oxfmt -c oxfmt.config.mjs --check ." ``` There are matching config files at the root, `oxlint.config.mjs` and `oxfmt.config.mjs`. That is a small thing but it has a practical consequence for contributors: the lint and format commands are not what an older checkout or a blog post would tell you to run. The more consequential entry is the test chain. `test` runs lint plus unit and integration suites through vitest, and the individual suites are `vitest run unit` and `vitest run integration`. But `test:e2e` is: ```json "test:e2e": "echo 'Currently not functional - TODO: fixme'" ``` So end-to-end coverage of the desktop application is declared broken in the project's own package manifest. Unit and integration tests still gate merges, but the layer that would exercise the packaged Electron app against a real server is not running. For a tool whose entire value is correct interaction with a live Appium session, that gap is worth knowing before you rely on an Inspector upgrade to catch a regression. ## Cloud integrations are first-class, and that shapes when you reach for the plugin The README devotes a long table to built-in integrations with cloud device providers, with documentation links for SauceLabs, HeadSpin, BrowserStack, TestMu AI (formerly LambdaTest), TestingBot, ExperiTest, RobotQA, Remote TestKit, BitBar, Kobiton and further providers beyond the truncated table. Each is a link to that provider's own Appium Inspector integration page. What this tells you is that the Inspector is not purely a local desktop tool in practice. When your session runs on a hosted device farm, having the Inspector point at that endpoint is the normal workflow, and that is exactly where the plugin form earns its place, because it ships with the server rather than needing a local GUI on the machine driving the tests. The desktop app remains the right choice when the session endpoint is reachable from your laptop and you want to click through the app yourself. The plugin is the right choice when the server is remote, when you want Inspector versioned alongside the server, or when several engineers share one server configuration. ## Cost of adopting and keeping up Licensing is Apache-2.0, stated in `package.json` and matched by the LICENSE file at the repository root. The package is authored by the Appium Developers with homepage, bugs URL and repository all pointing at the Appium organisation, so the licence is permissive with no copyleft obligation on code that links to it. That is a licensing statement, not legal advice. The upgrade cost lives in version coordination. The repository is not archived and the last push was on 2026-10-14, so work is landing continuously, and the recent tags follow a calendar-version scheme: 2026.9.2 on 2026-09-20, 2026.7.1 on 2026-07-27 and 2026.5.1 on 2026-05-04. `package.json` records the same 2026.9.2 version. Because the Inspector, the Appium server and the individual drivers all version independently, the practical maintenance task is keeping three moving parts aligned rather than tracking a single dependency. Translations are handled through Crowdin, and the README links a Crowdin project still named appium-desktop, which is a historical name carried over from the era when the tool was Appium Desktop. If you maintain a localized fork of the UI, that mismatch between the repository name and the Crowdin project name is a small but real piece of friction. ## Conclusion Adopt Appium Inspector when someone on your team writes Appium selectors by hand and needs to see page source beside a live screenshot, and prefer the standalone app for local work or the plugin when the Appium server is remote and versioned with your test stack. Do not adopt the former web app at inspector.appiumpro.com, which the README states is no longer related to the Appium team. Before committing, read the System Requirements and Installation pages the README links, then confirm that the desktop build matches the Appium server version your drivers expect, because the Inspector is a separate release train and the two version lines, 2026.9.2 here and whatever your server runs, do not move together. ## FAQ ### How do I install Appium Inspector? The README gives two formats: a standalone desktop application for macOS, Windows and Linux from the repository's Releases section, and an Appium server plugin whose details are in plugins/README.md. It points to the System Requirements and Installation pages on the project documentation site for more detail. ### Is the web version of Appium Inspector still available? The README states the Inspector was formerly hosted at https://inspector.appiumpro.com but that the site is no longer related to the Appium team, and it directs users to the standalone app or the plugin version. The team says it is exploring hosting an updated web app in the future. ### Does Appium Inspector include the Appium server and drivers? No. The project description calls it a GUI inspector powered by a separately installed Appium server, so the server and any drivers are separate installations you point the Inspector at through its server details settings. ### Which cloud device providers does Appium Inspector integrate with? The README's table links integrations for SauceLabs, HeadSpin, BrowserStack, TestMu AI (formerly LambdaTest), TestingBot, ExperiTest, RobotQA, Remote TestKit, BitBar and Kobiton among others, each pointing at that provider's own documentation page. ## Sources - [appium/appium-inspector on GitHub](https://github.com/appium/appium-inspector) - [License: Apache-2.0](https://github.com/appium/appium-inspector/blob/main/LICENSE) - [Project website](https://appium.github.io/appium-inspector/) - [README](https://github.com/appium/appium-inspector/blob/main/README.md) - [Releases](https://github.com/appium/appium-inspector/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/appium-appium-inspector