appdyno

English · Türkçe

An agent reads the screen as elements, taps, types and swipes. It sends a push, opens a deep link, and measures how the app starts, scrolls and holds its memory. Every action answers with the screen once it has settled, so the agent sees what it did in the same call. You can watch and touch the same device in a live window. It all runs on your Mac, with no cloud and no telemetry.

Works with Claude Code, Claude Desktop, Codex, ChatGPT, Cursor, VS Code, Devin Desktop (formerly Windsurf), Antigravity, Gemini CLI, Zed, opencode, Cline and any other MCP client.

Quick start

On a Mac with Node 22 or newer:

npx -y appdyno install     # adds appdyno to the MCP clients on this Mac, asking which

Restart the client, start a simulator or an emulator or connect a phone, and ask your agent:

Open my app, go through checkout, and tell me what breaks.

Each step answers with what the device showed. When a tap takes the app down, that same answer says so, with the crash and the app's last log lines. A real one, from this repository's shop example on an iPhone simulator, where three of one product take the order down:

APP_NOT_RUNNING: tapped @7rwa "Place order"; the app died: EXC_BREAKPOINT SIGTRAP Trace/BPT trap: 5 (~/Library/Logs/DiagnosticReports/Shop-….ips)
its last log lines:
2026-11-13 15:04:41.624 Df Shop[46315:14884fe] (libswiftCore.dylib) Swift/ContiguousArrayBuffer.swift:695: Fatal error: Index out of range
  launch_app starts it again, and crashes says why it died

crashes then names the function, discount(forQuantity:), and the same checkout saved as a flow fails in CI until the bug is fixed.

Ask it as well to send your app a push, to open each link your app opens, or to measure its cold launch and keep it as a baseline. npx -y appdyno doctor says what this Mac is missing, and Install covers a phone, the Mac app and any other client.

Related MCP server: Karagöz

One call, one answer

There is no second call to look, and no fixed sleep: an answer says settled when the screen came to rest, and changed when it differs from before. A refusal has a code and a hint for the next step.

What an agent can do

All 48 tools are in Tools. Each is also a command, and a call in the library.

Push notifications and links

push sends a push by type, and answers with the screen after it. Asked with no type, it says which types this device takes, how each one is delivered, and the payload it would send.

• On a simulator an alert goes by simctl and reaches the app's own code, from fields or from APNs' own payload with a badge, a sound and a category.

• On Android a push always goes to the app itself. A debuggable build that includes Firebase Messaging takes alert, rich, background and Live Activity pushes as real FCM messages, handed straight to its Firebase SDK, with no Firebase project or key. tapped opens the app as a tapped notification does, with the push's data in the intent that launches it. Any other build takes tapped only, and the answer says what the rest need.

• With APNs set up by a person, with appdyno push setup apns, a simulator also takes rich, background, Live Activity, VoIP and widget pushes by APNs' sandbox, and a real iPhone on its cable takes those and an alert. Behind strict controls: the sandbox by default, a token only from the app's own log or typed by a person in a window's Push pane, 4 KB at most (5 for VoIP), 10 pushes a minute, and no key or token in any answer or log.

• With FCM set up, with appdyno push setup fcm, an Android device takes alert, rich, background and Live Activity pushes by FCM, behind the same kind of controls.

Until APNs is set up, a real iPhone takes no push, and the answer says so. FCM's own message was run on an API 34 emulator, and its data pushes on a Samsung phone too. The requests to Apple and Google are tested against recorded ones, and the sending to Apple against a local stand-in server: no push has yet gone through Apple's or Google's own servers in testing.

open_link opens a deep link, a universal link or an App Link and answers with the screen it led to. Given an app's id, it lists the links that app opens: on a simulator its URL schemes and the domains its signature names, on Android each filter as scheme://host/path and each App Link domain with the state Android verified it in.

Push notifications has every type on every device, and what was run on what.

The live window and the hub

appdyno hub opens every device on this Mac in one window, driven by mouse and keyboard while an agent drives it too. Its Performance pane reads frames, CPU and memory as they happen. AI Clients shows each MCP client on this Mac as it truly stands, and adds appdyno to it. A phone joins by cable, or by Wi-Fi once paired with appdyno pair. See The window and the hub.

A person approves what loses data

Nothing the agent sends counts as a yes, and no tool erases or resets a device. What asks the person first lists each action, and how a person allows them ahead of time.

On each device

What works where has every measure on every device, and how each was proved. An iPhone's live picture is experimental, and rests on undocumented Apple services that may change.

Install

1. What you need

2. Get appdyno

npm install -g appdyno     # installs the appdyno command

Or take the Mac app, which needs no terminal: download Appdyno-<version>-arm64.dmg from the releases and drag it to Applications. It runs on Apple silicon with macOS 13.5 or newer, and Add to MCP Clients in its menu bar does step 3. See The Mac app. To build appdyno from a checkout instead, see CONTRIBUTING.md.

3. Add it to your MCP client

appdyno install --dry-run  # shows the change for each client it finds, and writes nothing
appdyno install            # asks which clients; --yes takes all of them

It changes only appdyno's own entry, keeps a backup beside the file, and appdyno install --remove takes it out. Restart the client afterwards. For any other client, add this to its server list:

{
  "mcpServers": {
    "appdyno": { "command": "npx", "args": ["-y", "appdyno", "mcp"] }
  }
}

A client opened from the Dock may not find npx: if it says spawn npx ENOENT, see An app cannot find npx or adb.

4. Get a device ready

• iOS simulator: nothing more. Start one in Xcode's Simulator, or ask your agent to. appdyno ios build builds appdyno's helpers for a simulator and an iPhone ahead of time, which takes a few minutes; otherwise the first action builds the one it needs. It also deletes builds of older versions, except one that a running process still uses.

• Android emulator: create one in Android Studio's Device Manager and start it.

• Android phone: turn on Developer options (Settings, About phone, tap Build number seven times), then USB debugging in them. Connect the cable and answer Allow on the phone. For Wi-Fi, pair once under Wireless debugging, Pair device with pairing code: appdyno pair <address> <code>.

• iPhone: connect the cable and answer Trust, turn on Developer Mode, and give it a development signing identity with a profile: An iPhone or a simulator takes you through it. For Wi-Fi, pair once on the cable: appdyno pair --device <udid>.

5. Check

appdyno doctor             # what is here, what is missing, and how to fix it
appdyno devices            # what is connected
appdyno screen             # what is on the screen
appdyno hub                # every device in one window you can touch
appdyno perf survey --app com.example.app   # every measure on this device, then a page of them

Connecting a client takes each client step by step, and gets a phone ready from nothing, signing included.

On real apps

Wikipedia's own debug build, from its repository, on an Android emulator in the hub: an MCP client searches for Istanbul, opens the article, taps a link that wraps over two lines, reads that article and measures it. Every call is real, with the time it took:

The article and its picture are Wikipedia's, under their own licenses.

Seven builds of five open-source apps, each as its repository builds it, debug builds on an Android emulator (API 34) and an iOS simulator (iOS 27.2), on an M5 Pro, on 2026-11-13:

A cold start is the median of 5 after a warm-up: on Android the time to a first frame that the system reports, on the simulator the time to the first frame the frame probe sees. Memory is Android's PSS and iOS's physical footprint, after the scroll. A scroll is the median of 3 rounds of 5 swipes; Wonderous on Android draws on a surface of its own, past the frames the system counts, so that surface's frames are read instead. A simulator's and an emulator's numbers are this Mac's, and a debug build is slower than a release build: they compare one run with the next, and do not say how fast a phone is.

Trying them showed what to fix in appdyno. An app with two launcher activities, as a debug build with LeakCanary has, started the system's chooser and measured a cold start of 0 ms, and a touch on a link over two lines landed between the lines. Each fix is in the changelog.

Speed

Medians of 5 runs, through MCP over stdio, on the fixture app, on an M5 Pro, on 2026-11-10 (the phones on 2026-11-09). The iPhone is a 13 Pro Max, and the Android phone a Samsung SM-A525F:

A tap waits until the screen has been still for 200 ms and answers with what changed, so most of its time is the app's own. In a checkout, after pnpm build and with the fixture app installed on the device, node scripts/speed.mjs <device id> runs the same calls on your Mac. Speed has every call, where the time goes, and what each one proves.

Documentation

The documentation has the rest of the reference.

Security

Local only: no network listener by default, no telemetry, and you decide which devices, apps and links it may touch. Use a test device and test accounts. See SECURITY.md.

Contributing

See CONTRIBUTING.md and the Code of Conduct. CHANGELOG.md lists the releases.

License

MIT. See LICENSE.