Project

Benchmark

Measured on the same devices (iPhone 14 simulator, Pixel 9a emulator), 10 runs per action, median time. Full method, raw data and the earlier runs are in BENCHMARK.md.

¹ Not counting hidekb on the iOS 26 search keyboard, which has no key to dismiss it: every tool fails there, and looktap is the only one that reports the failure instead of claiming success.

Raw Appium is slightly faster at reading and tapping on Android, because its helper app answers in-process. But it returns about 50× more bytes per read and needs two calls per tap.

Where Appium is still the better choice: it runs on real iOS devices, plugs into existing WebDriver test suites and CI grids, and supports many more platforms. looktap drives iOS simulators (not iPhones) and Android emulators and devices, and it isn't a test framework.

#The full benchmark: looktap vs Appium vs Appium MCP: benchmark

Measured on 2026-10-15. All three tools ran the same actions on the same devices, 10 runs per feature.

#TL;DR

Update, Run 4 (looktap's own helpers, no WebDriverAgent): Android ls dropped from 2.58 s to 131 ms, and iOS ls from 1.70 s to 202 ms. Taps now take 110–120 ms on both platforms, and screenshots ~130 ms. looktap is now the fastest of the three at almost every action. See Run 4. The summary below is from Run 3.

In one line:

• Agents: looktap costs about 100–250× fewer bytes of context than the Appium MCP for the same session, and needs no setup.
• Raw speed: Appium's on-device helper reads the Android screen about 20× faster.
• Bugs: the benchmark exposed bugs in looktap. They are listed below, with their fixes.

#What was compared

Devices:

• iPhone 14 simulator, iOS 26, Apple Silicon Mac
• Pixel 9a emulator, Android, 412×917 dp at 2.625×

App: the system Settings app. It has no sign-in and no real money is involved. The deep-link step opens a custom-scheme deep link in a second installed app, at whatever screen it is on, without typing anything.

iOS WebDriverAgent:

• looktap and raw Appium used the same prebuilt WDA 15.1.3, so Appium didn't pay for an xcodebuild.
• The MCP server installed its own copy through prepare_ios_simulator, as it normally does.

#Scenario: one run

Every run started from a tool-neutral reset: a plain simctl/adb command to force-stop the apps and relaunch Settings at its root screen. The reset was not timed.

After the 10 runs, each tool did:

• burst: as many screenshots as it could in 5 s;
• teardown.

#What was measured

• Time: wall time per feature, as the median of successful runs.
• Bytes: what the tool returned. For an agent, this is roughly what lands in its context:
  • looktap: stdout
  • raw Appium: HTTP response bodies
  • MCP: the full JSON-RPC response
• Calls: commands or tool calls needed for the action. More calls means more agent turns.
• Failures: counted, not dropped. Medians use successful runs only.

#Run 4: looktap with its own native helpers

Measured on 2026-10-15, with the same devices, harness and scenario (10 runs). looktap no longer uses WebDriverAgent or uiautomator dump:

• iOS: a macOS helper reads the simulator's accessibility tree and sends touch and keyboard events through Apple's simulator frameworks.
• Android: a 7 KB helper runs with app_process and keeps one UiAutomation connection open. Emulator frames come over the emulator's gRPC API.

Only looktap was re-run. The Appium columns are Run 3's numbers, from the same devices and harness.

#Android (Pixel 9a emulator)

#iOS (iPhone 14 simulator)

What changed:

• looktap is now the fastest of the three at almost every action on both platforms, while still returning 50–3000× fewer bytes.
• Failures: 2 of 123 on Android, and none on iOS apart from hidekb, which every tool fails on the iOS 26 search keyboard. looktap reports that failure instead of claiming success.
• burst now saves a frame only when the screen changes. On a static screen that's very few frames, so its frame counts aren't comparable with Run 3's.
• iOS reads during a navigation wait for the transition to finish (up to 1.5 s). Steady-state reads take about 30–70 ms inside the helper.

Limits:

• The iOS helper uses Apple's private simulator frameworks. Touch and keyboard input were measured on Xcode 26. For Xcode 27, looktap sends input to the simulator's dtuhidd service, which is implemented but not yet measured.
• On Android, the helper holds the device's single UiAutomation connection. Run looktap teardown before using Appium or uiautomator on the same device.

The Run 3 report follows unchanged, for reference.

#Results: Android (Pixel 9a emulator)

#Results: iOS (iPhone 14 simulator)

iOS times are higher across the board for all three tools. WebDriverAgent waits for the UI to go idle (animations finished) before it completes a tap or swipe.

#What the numbers mean

#For AI agents: output size dominates

An agent pays for every byte a tool returns, as context and tokens, and for every extra call, as a turn.

• Reading the screen: looktap returns a compact list (x,y WxH label) of 1–2 KB. Appium and MCP return the full XML hierarchy: 41–124 KB per read, 50–100× larger. Most of it is attributes an agent never needs.
• Screenshots: looktap writes the PNG to disk and returns its path (~100 B). The agent opens the image only when it actually needs to see it. MCP returns 210–225 KB inline on every screenshot. In an earlier exploratory run a single MCP screenshot returned 1.8 MB, and one call took 111 s.
• Whole scenario (10 runs, 13 features): looktap returned 11–22 KB. MCP returned 2.7–3.2 MB.
• Calls per action: tap-by-label, fill and type are 1 command in looktap. They take 2 MCP calls (find, then act), so twice the agent turns.
• Setup: looktap is ready in about 0.2 s. The MCP server took 23–39 s (process start, WDA prepare, session create) before its first command.

#For raw speed: Appium's on-device helper wins at reading Android screens

On Android, looktap's ls, tap and fill take 2–5 s, because each calls uiautomator dump. That starts a fresh UiAutomation connection and waits for the UI to go idle, about 2 s every time. Appium installs a helper app that stays connected, so its screen reads take about 0.1 s.

Where no screen read is involved, looktap matches or beats both:

• back
• type
• hide keyboard
• deep link
• restart app
• setup

On iOS, all three tools go through WebDriverAgent, so action times are close. looktap adds around 0.3–0.5 s per command for starting Node and checking which device is booted.

#Burst (screenshots in 5 s)

Appium and MCP take more frames per second (23–59 vs 4–9). But every frame comes back over the wire as base64: 25 MB on iOS in 5 seconds. looktap writes frames to disk and de-duplicates them, so it reports only how many frames are distinct.

#Reliability

Across both platforms:

• looktap: 4 failures
• raw Appium: 20
• MCP: 22

Most Appium and MCP failures were in fill/type on Android. They happened right after the app switched to Settings search, which runs in a different Android package (com.google.android.settings.intelligence): UiAutomator2 keeps reporting the previous window for about 2–3 s. A 4 s settle reduced these failures but didn't remove them. The few looktap failures were the first run after setup on iOS, and the screen not yet ready on Android.

#Bugs found in looktap

#Benchmark history

These problems were found in the harness, not in the tools, and are kept here so the method can be trusted:

1. Run 1 (discarded): the "reset" between runs force-stopped Settings but not its search screen, which lives in a separate package. Most runs started on the wrong screen. Fixed by stopping both packages and relaunching with a cleared task.
2. Run 2 (discarded): a 1.5 s settle after opening Settings search was too short for UiAutomator2 (see Reliability above). Raised to 4 s for all tools.
3. Run 3: looktap 0.1.0 with WebDriverAgent and uiautomator dump.
4. Run 4: looktap with its own helpers. Only looktap was re-run (see above).

#Reproduce

# 1. devices: boot exactly one simulator and one emulator
# 2. an Appium 3 server with both drivers:
npx appium driver install xcuitest && npx appium driver install uiautomator2
npx appium --port 4723 &
# 3. optional: an installed app with a deep link, for the deep-link step
export BENCH_DEEPLINK=myapp://home BENCH_DEEPLINK_APP=com.example.myapp
# 4. run (each platform takes ~20 min for all three tools, 10 runs each)
cd bench
node full.mjs android 10            # or: node full.mjs ios 10
node full.mjs ios 3 looktap        # one tool, fewer runs
python3 mdtable.py results/ios.json # → the markdown table above

Raw per-run numbers are in bench/results/android.json and bench/results/ios.json (Run 3), and in android-run4-looktap.json and ios-run4-looktap.json (Run 4). Set BENCH_TAG to keep a run's results separate. For Appium on iOS, BENCH_PREBUILT_WDA points at a built WebDriverAgentRunner-Runner.app so Appium skips its xcodebuild.

Generated from README.md and BENCHMARK.md. Edit it there.