Spectra is the inspector I built to get that time back. It's a native desktop app for inspecting Android and iOS app UIs, roughly 10MB, for macOS (Apple Silicon and Intel) and Windows. It generates locators and grades them, mirrors the device screen live, records gestures into test code, and works either through your existing Appium server or directly over ADB and WDA.

This post is the long version of that paragraph: what it is, how it's put together, what it does, and where Appium Inspector is still the better choice.

What Spectra is

Spectra sits where Appium Inspector, UIAutomator Viewer or the Xcode Accessibility Inspector sit in your workflow. You connect a device or simulator, you see the screenshot and the element tree side by side, you click an element and get its attributes and a list of locators. From there you copy a locator into your test, or export a snippet, or record a flow.

A typical session: plug in the phone, pick it in the connect dialog, and in Turbo Mode the screenshot and tree appear without an Appium server being started first. I click the button I care about, the Locators tab shows an A-graded accessibility ID at the top and a D-graded absolute XPath at the bottom, and I copy the one at the top. If the screen changes, the view follows without me touching anything.

What it doesn't do is replace your Appium server or your test framework. In Appium mode Spectra is a client of the same server your tests use, so what you see is what your tests will see. The direct mode is an addition for when you don't want a server in the middle, and you can switch between the two per session.

How it's built

The desktop shell is Tauri 2.0 with a Rust backend; the UI is React 18 with TypeScript, Zustand for state and Tailwind with Radix for components. Tauri uses the OS webview instead of bundling a browser, which is where the ~10MB and sub-second startup come from. Every ADB call, WDA request, screenshot capture and file operation runs in Rust and reaches the UI over Tauri's IPC.

There are two ways to talk to a device.

Appium mode speaks the WebDriver protocol to any Appium server, local or remote, typically with the UiAutomator2 or XCUITest driver behind it. Nothing about your Appium setup changes.

Turbo Mode skips the server. On Android, Spectra drives ADB directly for screenshots, input and the UI tree. On iOS it talks to WebDriverAgent over its HTTP API. Without the extra hop, inspection is 2 to 5x faster in my testing, and it's what makes live mirroring practical.

The third piece is the Spectra Agent, and it exists because of the spinner problem from the first paragraph. uiautomator dump calls waitForIdle() before it reads anything, and a screen with an animation is never idle, so the dump times out. The Agent is a small Android instrumentation APK (about a megabyte, some 450 lines of Kotlin) that Spectra installs when you connect in Turbo Mode. It reads the tree straight from UiAutomation.getRootInActiveWindow(), with no idle wait, and hands it back over a local socket forwarded through adb forward. It sends nothing anywhere else. If you don't want it on a device, adb uninstall com.spectra.agent removes it. There's a separate post with the details and the workarounds you can use without Spectra.

Licensing runs through Polar. A license key activates Pro on up to two machines. There's no account inside the app and no signup to download.

What it does

Turbo Mode (Pro). Direct ADB on Android and direct WDA on iOS, as described above, with no Appium server in the path.

LiveTrack (Pro). The screenshot and tree refresh on their own, with polling that adapts to how fast the device answers, and pause while the window is hidden. No refresh button in the loop.

Locator generation (Free). Eleven strategies: accessibility ID, resource-id, content-desc, text, XPath, iOS class chain, iOS predicate string, and Flutter key, type, text and semantics. Every candidate gets a grade from A to D based on how likely it is to survive a release (F-graded candidates are hidden). A Locator Builder lets you compose composite locators, and search covers text, attributes and locators.

Test Recorder (Pro). Record taps, swipes, long presses and typing on the real device, edit the steps, add assertions, replay, then export as executable test code. Think of it as codegen for mobile.

Code generation (Pro). Snippets and Page Object Model classes for WebdriverIO, Appium Python, Appium Java, Appium JS, XCUITest (Swift), Espresso (Kotlin), Detox (JS) and Maestro (YAML). As far as I know, no other inspector exports a recording to that many targets.

Multi-device (Pro). Two devices side by side, for example an Android phone and an iPhone on the same screen.

XPath Axis Builder (Pro). A visual builder for parent, sibling, ancestor and descendant relationships, for the times a plain attribute isn't enough.

Also in Free: device interactions (tap, swipe, long press, type, back, home), the Console, Logs, History and Network panels, a Prerequisite Checker that finds and installs missing ADB, Java or Appium pieces, auto-update with a "What's New" panel, and dark and light themes.

How it compares

Facts as of the current release, from the tools' own documentation and my use of them:

What Appium Inspector does better, and this matters: it's the reference client for the Appium project, it works with every Appium driver including ones Spectra doesn't target, most teams already know it, and it has no paid tier at all. If your team is standardised on it and the refresh wait isn't a daily cost for you, there is no reason to move. It also runs on Linux; Spectra ships for macOS and Windows only.

Who it's for, and who should stay put

Spectra is for QA engineers and SDETs who inspect mobile UIs many times a day and feel the wait; for automation engineers maintaining Appium, WebdriverIO, Python or Java suites who want a locator ranked before it goes into a page object; for Detox, Maestro, XCUITest and Espresso users who still need locators and don't want an Appium session just to read a tree; and for mobile developers checking accessibility IDs and layouts.

Stay on Appium Inspector if you inspect a few times a week, if you depend on a driver Spectra doesn't cover, or if you're not allowed to install a helper APK on test devices (you can still use Appium mode, but Turbo Mode's animated-screen support needs the Agent). Stay on UIAutomator Viewer if you're Android-only and it does what you need; it comes with the SDK and it's fine.

Free and Pro

Free is free forever and covers inspection: one device session, Appium mode, all inspection features, the eleven locator strategies with grades, the Locator Builder, search, device interactions, all four panels, the Prerequisite Checker, auto-update, both themes. Download and use it, no signup.

Pro is $7 a month or $50 a year, with a 14-day trial and two device activations per license. It adds Turbo Mode, LiveTrack, multi-device, code generation for the eight frameworks with Page Object Model output, the Test Recorder and the XPath Axis Builder. Teams that want volume licensing or a roadmap conversation can write to support@usespectra.dev.

What's next

Additional platforms and features are on the roadmap at https://usespectra.dev/roadmap, and there's a feature request form on the same page. I read every submission.

Spectra is free for inspection. Download at https://usespectra.dev.

This is the order I pick locators in, why, and what each one looks like when it fails. Android and iOS first, then a short Flutter section, then the part that actually fixes the problem long-term: getting IDs added where the feature is written.

The rule underneath all of it

Pick the attribute a developer set on purpose. Avoid the one the render tree happened to produce.

An accessibilityIdentifier, an android:id, a testID, a Flutter Key: someone typed those. They change when a human decides to change them. Position in a hierarchy, sibling index, the class name of a wrapper: those change whenever the layout is refactored, a design system component is swapped, or an OS update renders a control differently. Every tier below is a version of that rule.

1. Accessibility ID

It's the same strategy on both platforms and both drivers index it, so lookups are fast. By convention it's unique per screen. On Android it's content-desc (set with contentDescription). On iOS it's accessibilityIdentifier. Appium calls both accessibility id.

# Python (Appium)
driver.find_element(AppiumBy.ACCESSIBILITY_ID, "checkout_button")

// Java
driver.findElement(AppiumBy.accessibilityId("checkout_button"));

// WebdriverIO
await $("~checkout_button");

It's also what screen-reader users rely on, at least on Android where content-desc is read aloud. That makes it the last thing a developer quietly deletes, and it means the automation team and the accessibility team want the same thing.

When it breaks: the ID was generated (button_3f9a), or the same ID was reused across a list, or on Android someone put a user-facing sentence in contentDescription for TalkBack and it now changes per locale. If your app has that last problem, ask for a resource-id and leave content-desc to accessibility.

2. resource-id (Android)

Set in the layout as android:id, never shown to a user, and changed only on a deliberate rename. In the tree it appears as com.example.app:id/checkout_button.

driver.find_element(AppiumBy.ID, "com.example.app:id/checkout_button")

If you're on React Native, testID surfaces as resource-id on Android and accessibilityIdentifier on iOS in current versions, so a single prop gives you both platforms.

When it breaks: the build obfuscates or strips IDs, the app was migrated to Compose without testTag plus testTagsAsResourceId, or an ID lives inside a reused component so twenty rows share it. In the last case combine it with something else rather than falling back to XPath by index; the UiSelector note in tier 5 covers that.

3. Text, with care

Fine for a static label in a single-language app with no near-duplicates on screen. Borrowed stability everywhere else.

driver.find_element(AppiumBy.XPATH, "//*[@text='Continue']")

The day someone ships localisation, "Continue" becomes "Nastavi" for the Serbian locale and every text locator dies at once. A/B copy tests do the same thing on a smaller scale. Dynamic strings ("3 items", "Hi, Filip") change per user. If you have a translations file in the repo, you already know text is a temporary anchor.

Text is still useful as a secondary condition: an ID that's shared across a list plus the row's label narrows to one element without touching the hierarchy.

4. iOS predicate string and class chain

This is where iOS pays you back for not having resource-id. Both are native XCUITest queries and both are materially faster than XPath on a deep tree.

Predicate string filters on attributes and supports partial matching without dropping to XPath:

driver.find_element(AppiumBy.IOS_PREDICATE, 'label CONTAINS "Continue" AND visible == 1')

Class chain adds hierarchy and indexing on top of predicates:

driver.find_element(AppiumBy.IOS_CLASS_CHAIN,
    '**/XCUIElementTypeCell[`name == "cart_row"`]/XCUIElementTypeButton[1]')

The backticks are part of the class chain syntax. The way I keep them apart: if I'm filtering, predicate; if I'm navigating, class chain.

When they break: a predicate on label breaks with localisation just like text does, so prefer name (which is the accessibility identifier). Class chain with an index breaks when a cell gains a child, same as XPath, only cheaper.

5. XPath, last, and relative only

Absolute paths break the moment someone wraps a view in another layout. This is the one that comes out of an inspector when you click "copy XPath" without thinking:

/hierarchy/android.widget.FrameLayout[1]/android.widget.LinearLayout[2]/android.widget.FrameLayout[1]/android.view.ViewGroup[1]/android.widget.Button[2]

Every segment is a dependency on the current layout. One wrapper view, one reordered sibling, and it points at nothing.

If you need XPath, anchor it to a real attribute and move one hop:

//*[@resource-id='com.example.app:id/cart']/following-sibling::*[1]

Nothing breaks that except deleting the anchor. It's still slower than the tiers above (XPath means the driver has to build the whole tree as XML and evaluate the query against it on every lookup), so on iOS especially I reach for class chain before this.

An Android footnote that deserves more attention than it gets: -android uiautomator with UiSelector handles a lot of what people reach for XPath for, and it runs through UiAutomator rather than the XML tree.

driver.findElement(AppiumBy.androidUIAutomator(
    "new UiSelector().resourceIdMatches(\".*:id/cart_row\").textContains(\"Shoes\")"));

I'd rank it between resource-id and text on Android when you need a partial match or a combination.

One element, five locators

Here is one checkout button on an Android screen, as it might come out of an inspector, worst to best:

/hierarchy/android.widget.FrameLayout/android.widget.LinearLayout[2]/android.widget.Button[1]
//android.widget.Button[@text='Continue to payment']
//*[@resource-id='com.example.app:id/summary_card']/following-sibling::android.widget.Button[1]
com.example.app:id/checkout_button
checkout_button          (accessibility id)

Line one breaks on any layout change. Line two breaks when marketing renames the button or the app gets a second language. Line three survives both and breaks only if the summary card goes away. The last two survive everything short of a deliberate rename, and the accessibility ID also works on iOS if the developer used the same identifier there. When I open a screen the question is only "which of these does this element actually have", and the ranking answers itself.

Flutter

Flutter draws its own widgets, so out of the box the native tree sees one big canvas with whatever the app's semantics layer exposes. Newer Flutter versions push semantics labels through to the platform accessibility APIs, so some elements are reachable with plain accessibility id through UiAutomator2 or XCUITest. For the rest you want the Appium Flutter integration driver, which talks to the running app through the Dart VM.

Its locators, best first: key (a ValueKey on the widget), semantics label, type (widget class name), and text.

// In the app
ElevatedButton(key: const ValueKey('checkout_button'), ...)
Semantics(label: 'cart_row', child: ...)

// Java, appium-flutter-integration-driver
driver.findElement(FlutterBy.key("checkout_button"));
driver.findElement(FlutterBy.semanticsLabel("cart_row"));

Same reasoning as native: key and semantics label are things a developer typed, type is a class name that survives most refactors but not a component swap, and text inherits every localisation problem from tier 3. One caveat from the driver's own README: semanticsLabel lookups on real iOS devices have a known Flutter issue, so verify on hardware before you standardise on it.

How to talk to developers about adding test IDs

The thing that fixes locator stability long-term is a conversation, and it's easier than most QA people expect. What has worked for me:

Ask for something specific and small: "these six controls on the checkout screen need stable IDs; here's the list and the names I'd like." A ten-line PR gets merged. A policy discussion doesn't.

Name the mechanism per stack so nobody has to look it up: android:id in XML or Modifier.testTag (with testTagsAsResourceId) in Compose, accessibilityIdentifier in UIKit and SwiftUI, testID in React Native, Key in Flutter.

Agree on a naming convention once (screen_element_role, all lowercase, no spaces) and put it in the PR template. Half the value is that IDs stop being invented ad hoc.

Point at the accessibility overlap. On Android, content-desc serves TalkBack users and your tests at the same time, so the work counts twice.

Show the cost. One example of an absolute XPath from your suite next to the ID version, with the git blame of the layout change that broke it, does more than any argument.

Every hour spent here is worth ten spent hardening XPath.

Summary

This hierarchy is why Spectra grades every generated locator A to D: same logic, made visible next to each candidate instead of living in your head. The grading is in the free tier at https://usespectra.dev.

Spectra is free for inspection. Download at https://usespectra.dev.

All releases, with the .dmg (Apple Silicon and Intel) and Windows installers, are at https://github.com/Morph93/spectra-releases/releases.

1.0 to 1.1: the base and the recorder

1.0.0 and 1.0.1 (25 and 27 February) were the first public builds: the inspector itself, Appium mode, Turbo Mode over direct ADB and WDA, LiveTrack, multi-device, graded locators, the XPath Axis Builder, code generation for three frameworks (WebdriverIO, Appium Python, Appium Java), and the Spectra Agent for Android. I didn't write release notes for those two, which I regret now; the list above comes from the v1.0.0 tag in my repo.

1.1.0 (5 March) also went out without notes on the release page. The tag commit in my repo lists what it carried: the Test Recorder (record real-device gestures, replay them, add assertions, export as test code) and five more code generation frameworks, taking the total from three to eight. That list is WebdriverIO, Appium Python, Appium Java, Appium JS, XCUITest (Swift), Espresso (Kotlin), Detox (JS) and Maestro (YAML). It also included iOS reliability work: zombie xcodebuild processes blocking device switching, port conflicts when a simulator and a physical device were both active, and USB keep-alive for idle iOS sessions.

1.1.1 and 1.1.2 (6 March) were license fixes: Pro activation not persisting across restarts, a brief "Not Activated" flash before the keychain loaded, revoked activations still granting Pro until restart. 1.1.2 moved key storage to the native backends (macOS Keychain, Windows Credential Manager).

1.2.0 to 1.2.2: theme, stability, profiles

1.2.0 (6 March) added the light theme, with OS detection and a manual toggle, and fixed escape handling for accessibility IDs that contain newlines.

1.2.1 (10 March) was about running for a long time. Screenshot handling was redesigned so memory stays flat instead of climbing over hours with multiple devices connected, a blank-screen bug after extended multi-device use was fixed, and device polling became adaptive to connection speed.

1.2.2 (11 March) added Connection Profiles (save, load, rename and delete connection configurations), Full Reset in Turbo Mode (reinstall the app before connecting; Android via ADB, iOS via xcrun simctl or ideviceinstaller), auto-restore of the last used connection config, and a prerequisite check for ideviceinstaller with a Homebrew auto-fix. It also stopped a double-click on Connect from starting two connection attempts.

1.2.3: the fixes release

1.2.3 (19 March) is the one I'd point at if you asked which release changed daily use the most. From the notes:

LiveTrack polling now pauses while the window is hidden and resumes on restore, which fixed a UI freeze after minimising. Connections no longer drop after minutes of inactivity; there are keep-alive pings for both iOS Direct and Appium sessions. Search results show the true sibling-based XPath index, include elements with visible=false, and distinguish hidden elements from off-screen ones. Error toasts persist until dismissed, and connection errors moved in-dialog with actionable guidance, including a "Why does this happen?" section for WDA and xcodebuild failures.

Under the hood, locator generation was deduplicated: the Properties and Locators tabs now share one single-pass engine, which fixed three match-counting bugs. The default theme changed from Dark to System.

1.2.4: recorder polish

1.2.4 (13 April) is mostly Test Recorder work. You can type a custom locator strategy and value directly in the recorder's locator picker. Recorded steps are easier to edit (pencil icons, single-click text editing, "Add note..." placeholders). Assert mode exits automatically when you switch to Tap, Swipe or Hold. Exported flow code no longer produces duplicate variable names, so Java and JS exports compile as generated. On Windows, the console window no longer flashes during ADB commands and background polling.

What is free and what is Pro

Free, no signup: one device session, Appium mode, all inspection features, the 11 locator strategies with A to D grading, the Locator Builder, search, device interactions (tap, swipe, long press, type, back, home), the Console, Logs, History and Network panels, the Prerequisite Checker, auto-update with "What's New", and both themes.

Pro adds Turbo Mode (direct ADB and WDA, 2 to 5x faster in my testing), LiveTrack, multi-device (two devices side by side), code generation for the eight frameworks with Page Object Model output, the Test Recorder, and the XPath Axis Builder. Pro is $7 a month or $50 a year, with a 14-day trial and two device activations per license.

The Android helper that Turbo Mode installs for animated screens (Spectra Agent) has been in the app since 1.0.0; there's a separate post on why it exists.

What's next

Additional platforms and features are on the roadmap at https://usespectra.dev/roadmap, and there's a feature request form on the same page. Release notes from here on will also appear on this blog.

Spectra is free for inspection. Download at https://usespectra.dev.

$ adb shell uiautomator dump
ERROR: could not get idle state.

Almost always on a screen with a loading spinner, a shimmer placeholder, a Lottie animation, a marquee, a video, or a blinking cursor in a focused text field. The same screens make Appium's page source (and therefore Appium Inspector's refresh) take ten seconds or more, or time out entirely. I've lost enough hours to this that I want to write down what is actually happening and what works.

What the error actually means

uiautomator dump doesn't just read the accessibility tree. Before it reads anything, it calls UiAutomation.waitForIdle(1000, 10000). In plain terms: wait until there has been no accessibility event for one second, and give up after ten. You can see it in the AOSP source for DumpCommand.java; the TimeoutException from that call is what prints the error, and no XML gets written.

Every animating view fires TYPE_WINDOW_CONTENT_CHANGED on every frame. An indeterminate ProgressBar is a permanent animation. So the quiet second never comes, the ten-second budget runs out, and you get the error.

Appium's UiAutomator2 driver has the same wait, because UiAutomator itself does it. The driver exposes it as the waitForIdleTimeout setting, and as of the current driver docs the default is 10000 ms. The difference is that the driver doesn't error. It silently waits the full timeout, then proceeds with the action or the source fetch. This is why "the inspector is slow on this screen" and "dump times out on this screen" are the same bug wearing two hats. Espresso has a related story on the developer side: its "disable animations before running tests" advice exists because Espresso also waits for the main thread and its idling resources to settle.

Quick sanity check that this is your problem and not ADB: run adb shell uiautomator dump on a static screen like Settings. Instant there and hanging on your screen means it's the idle wait.

Way 1: stop the animation at the source

Best when you can. Developer options, then set Window animation scale, Transition animation scale and Animator duration scale to off. Or from the shell:

adb shell settings put global window_animation_scale 0
adb shell settings put global transition_animation_scale 0
adb shell settings put global animator_duration_scale 0

This kills system window and transition animations and most Animator-driven spinners. It does not stop everything. Lottie, video, GIF and WebP, shimmer libraries with their own timers, and custom Canvas or Choreographer loops keep going. Compose animations vary by version in my experience, so test on your app.

In Appium, the capability appium:disableWindowAnimation: true applies the same settings for the session and, as of the current driver docs, restores them afterwards on API 26 and higher.

The best version of this is a build flag or debug menu that swaps indeterminate spinners for a static state in test builds. Espresso teams do the same thing with idling resources. It's a small PR for the developers and it fixes the whole class of problem rather than one screen.

Way 2: shrink the wait (Appium)

waitForIdleTimeout is a session setting rather than a capability (the driver README has a warning box about exactly this), so you change it through the Settings API:

# Python
driver.update_settings({"waitForIdleTimeout": 500})   # ms; 0 = don't wait at all

// WebdriverIO / JS
await driver.updateSettings({ waitForIdleTimeout: 500 });

// Java
((HasSettings) driver).setSetting("waitForIdleTimeout", 500);

If you want it from the first command of the session, Appium lets you initialise any setting through a capability:

{ "appium:settings[waitForIdleTimeout]": 500 }

Trade-off: with a low value you can act before the UI has settled, so pair it with explicit waits for the element you need. The driver docs say the same, and add that a value of 0 disables the wait completely, which is exactly as risky as it sounds. actionAcknowledgmentTimeout (default 3000 ms) is the sibling setting for post-action waits; the docs suggest leaving it alone unless you have a reason.

iOS has the same disease with a different name. The XCUITest driver's waitForIdleTimeout is in seconds (default 10, 0 disables) and animationCoolOffTimeout (default 2 seconds) is the post-action equivalent. Both are settings; the first can also be set as a capability.

A note on --compressed and ignoreUnimportantViews

These get suggested a lot for this error, and they don't help with it. uiautomator dump --compressed drops nodes that aren't important for accessibility, and the UiAutomator2 driver's ignoreUnimportantViews setting does the same thing for page source. Both are good when dump is slow on a huge tree. Neither skips the idle wait. In DumpCommand.java, the compression flag is applied first and waitForIdle runs anyway, so you get a smaller tree ten seconds late, or the same error.

Use them for size. Don't expect them to fix idle.

Way 3: read the hierarchy through a door that doesn't wait

Two options that skip the accessibility idle wait entirely, with caveats:

Android Studio's Layout Inspector attaches to the app process. Debuggable builds only, and it isn't scriptable, but for a one-off "what is on this screen" it works on animated screens.

adb shell dumpsys activity top dumps the foreground activity's view hierarchy: class, id, bounds. No text or content-desc, and the format shifts between Android versions, but it's instant and it's always there.

If you own the app, Espresso or UiAutomator inside an instrumentation test with animations disabled is the reliable in-house route.

Way 4: read the accessibility tree without waitForIdle

The idle wait is something uiautomator dump chooses to do before reading. The tree itself is available at any moment: UiAutomation.getRootInActiveWindow() returns the current tree immediately. A minimal instrumentation, shipped as its own tiny APK, no changes to the app under test:

class TreeDump : Instrumentation() {
    override fun onCreate(args: Bundle?) { super.onCreate(args); start() }
    override fun onStart() {
        walk(uiAutomation.rootInActiveWindow, 0)   // no waitForIdle here
        finish(Activity.RESULT_OK, Bundle())
    }
    private fun walk(n: AccessibilityNodeInfo?, depth: Int) {
        n ?: return
        val r = Rect().also(n::getBoundsInScreen)
        Log.i("dump", " ".repeat(depth) +
            "${n.className} id=${n.viewIdResourceName} text=${n.text} desc=${n.contentDescription} $r")
        for (i in 0 until n.childCount) walk(n.getChild(i), depth + 1)
    }
}

Register it in the helper's manifest:

<instrumentation
    android:name=".TreeDump"
    android:targetPackage="your.helper.package" />

Then run adb shell am instrument -w your.helper.package/.TreeDump and read logcat, or write to a file or a socket instead.

Caveats I ran into. Only one process can hold UiAutomation at a time, so this fights with a running UiAutomator2 server session on the same device; it's either/or. The tree you get is "right now", mid-animation, so bounds of moving things are a snapshot. And if you want it in the usual XML shape for existing tooling, you're writing that serialiser yourself.

Trade-offs

Which one to use

You control the app: Way 1 (build flag or animations off) plus Way 2 with a small non-zero timeout.

Third-party or production app through Appium: Way 2 (500 to 2000 ms) plus explicit waits.

One-off "what is on screen right now": Way 3.

You need the tree reliably on animated screens, scriptable, without an Appium session: Way 4.

If you have a better trick, especially for Compose apps where I get inconsistent results with animator scale 0 across versions, I'd like to hear it. Email is support@usespectra.dev.

Why Spectra ships an agent for this

Way 4 is what Spectra does. When you connect in Turbo Mode (direct ADB, no Appium server in the middle), Spectra installs a small Android instrumentation APK called Spectra Agent, about a megabyte and roughly 450 lines of Kotlin. It starts with adb shell am instrument, listens on a local port that Spectra reaches through adb forward, and answers with the tree read straight from getRootInActiveWindow(). No waitForIdle, so a spinner on screen no longer stalls the inspection. It answers with the tree and nothing else; there's no outbound connection and it collects no data. If you don't want it on a device, adb uninstall com.spectra.agent removes it.

To be upfront about scope: the free tier inspects through your existing Appium server, so it inherits Appium's idle wait, and Way 2 above is the fix there. The agent is part of Turbo Mode, which is in Pro (14-day trial). If this screen isn't a daily problem for you, Way 1 and Way 2 are the cheaper answer. More at https://usespectra.dev.

Spectra is free for inspection. Download at https://usespectra.dev.