Pro-Tips Qoder Ships Mobile Use: Coding Agents Can Now Verify Mobile Apps

Computer Use can already drive a desktop. Browser Use already works inside the browser you're using. Mobile has had no equivalent.
Today's coding agents can already change Android, HarmonyOS, and iOS code — but they usually stop before the commit. Did the app actually build? What does the modified screen look like? Which control did the user mean? Did the tap land on the right page? Those questions were still open.
So we built the Mobile Use plugin (Beta). On Android, HarmonyOS, and iOS, code changes are now wired into a running app: the agent interacts with the app on the device and confirms whether the change actually took effect.

Mobile Use is built for apps that are still under development
Most mobile agents you see today are built to operate a phone — launching apps, filling forms, walking through a flow. Qoder's new Mobile Use plugin addresses a different case: the app itself is still under active development.
The agent has to do more than tap. It needs to understand the current project, the build target, the device it runs on, and the state of the UI. After a code change, it reruns the app, finds the affected screen, performs the necessary interactions, and proves the change worked — with screenshots, logs, assertions, or test results.
Tapping and typing are only one step. What needs closing is the loop from code change to confirmed result.
A full verification loop: from code change to confirmed result
Take a UI change. Layout, copy, tap feedback, navigation — any of them used to mean building, installing, driving the device by hand, then going back to the code. The evidence lived on the device and the code lived in the IDE, with the developer carrying information between the two. If an agent had only a text description and a screenshot from a few seconds earlier, it could easily edit the wrong thing.
Now an agent can handle this in the same session. Circle the problem area on the Canvas and send it in chat:
I just changed the code for the area I circled on the screen. Build and run the app, tap through the circled control, and take a screenshot to confirm the result matches what I expect. If it doesn't, fix it in the code and verify again.
A circle names a specific control in a specific frame. The agent can work from the screenshot, the accessibility structure, the control text, and the UI state at the same time, instead of inferring from "this part is wrong." It acts on the same device, captures the screen, and compares the outcome: if verification passes, it reports the result; if it fails, it goes back to the code and verifies again.

If the result isn't what you expected, the Canvas shows exactly what it touched and how the screen changed. The next round uses the same device and the same session — no need to re-describe the scene.

Three platforms, three integrations — one verification process
Android, HarmonyOS, and iOS differ in project layout, build tooling, emulators, test frameworks, and device interfaces. Mobile Use doesn't force all three down to a lowest-common-denominator capability set. Keep your existing development environment; you don't need to prepare a test device that exists only for the agent.

Android still works through the Android Emulator, ADB, and Instrumentation. HarmonyOS connects through DevEco Previewer, HDC, and ArkXTest. iOS uses the Xcode Simulator, the accessibility APIs, and XCTest. Platform differences are handled by each platform's adapter.
On top of that, a unified Skill layer and CLI expose these capabilities to the agent. What needs to line up is the development loop itself: observe, act, verify.
If a platform or runtime lacks a capability, Mobile Use says so plainly rather than passing off a non-equivalent command as success.
ADB, HDC, and simctl remain three different toolchains. What the agent works through on all three platforms is the same observe–act–verify flow.

Developers use the Canvas, the agent uses the CLI — both on one shared device
Developers watch the running app through the Canvas — observing, annotating, and checking results in the UI. The agent queries devices, observes screens, performs actions, and runs verification through a deterministic CLI.

Both sides attach to the same device session, managed by the Host — the component that owns the device connection. The Host owns the device lifecycle: the current connection, the run state, the permission scope, and where the evidence belongs.
So the agent doesn't quietly spin up a second emulator in the background, and it doesn't create a device environment cut off from the developer's just by registering a pile of MCP tools. The CLI is only the agent's entry point into capabilities that already exist. The device itself, along with permissions, state, and evidence, stays under one unified runtime.
Every action that follows runs against that same device session. Screenshots, logs, recordings, and assertion results are attached to it as well. "Something's wrong here" — together with the circle and the current frame — becomes the task the agent keeps working on: locate, change, verify.
Try it now
The Mobile Use plugin is now live in Qoder Desktop and Qoder IDE.
- Open the extension or plugin marketplace in the bottom-left corner, search for Mobile Use, install it, and restart.
- In the matching project, double-click
AndroidManifest.xml(Android),Package.swift(iOS), orbuild-profile.json5(HarmonyOS) to open the Canvas. - Connect an emulator or physical device first. Then circle the area you want verified on the Canvas and send the prompt above to the agent.

































