Qoder Lets Agents Test Three-Platform Apps on Real Devices

Alibaba’s Qoder released the Mobile Use plugin (Beta) today. It is trying to solve not the problem of “getting AI to write code a little faster,” but a more difficult problem that Coding Agents have faced for a long time: after the code has been changed, who will run the app to confirm that the page really appears, that the controls users click are actually clicked, and that the changes have not broken another flow?

Mobile Use connects code changes, app execution, device interaction, and result confirmation across Android, HarmonyOS, and iOS into a closed loop. In other words, an Agent no longer stops at submitting code or generating a diff. It can continue into the mobile runtime environment, observe the interface, perform actions, and then determine from the feedback whether the change has actually taken effect.

This is also a fairly pragmatic step for Qoder in the Coding Agent competition: the hardest part of automating mobile development has never been writing a button. It has been crossing the walls beyond the code—build tools, emulators, system permissions, UI states, and device interfaces.

Why Agents Always Stop Before Submission

Traditional Coding Agents can generally complete three types of tasks: reading code repositories, modifying files, and running some command-line tests. For backend projects, this workflow is already quite useful. But for mobile apps, a large part of correctness does not exist in the source code text.

For example, suppose the requirement is “change the home page’s login button to the primary color and navigate to the account page after it is clicked.” The Agent may accurately modify the layout files, theme configuration, and routing code, and may even pass static checks successfully. But that does not mean the delivery is complete:

• The app may not install at all because of signing, dependency, or build-configuration issues;
• The color may have been changed on a component that is not used by the current theme;
• Multiple similar controls may exist on the page, and the Agent may target the wrong button;
• The click action may trigger the event, but the navigation stack may not switch to the expected page;
• Verification may pass on Android, while layout, permission, or lifecycle differences appear on iOS or HarmonyOS.

These problems essentially require “seeing” and “doing.” Calling the compiler alone can answer, at most, “Can the code compile?” Only by placing the app in a runtime environment and executing a series of user actions can we get closer to answering, “Does the feature work?”

Mobile Use hands this process over to the Agent: first observe the current page and control states, then perform interactions such as clicking, typing, and swiping, and finally check page changes, text content, or test assertions. It turns mobile verification from a manual acceptance step into a development step that can be orchestrated by an Agent.

The Three Platforms Are No Longer Flattened by a Single Lowest Common Denominator

A key design choice in Mobile Use is that it does not simplify Android, HarmonyOS, and iOS into a single interface that “looks unified but has compromised capabilities in practice.” The official solution uses platform adapters to handle low-level differences, while providing observation, operation, and verification capabilities to Agents at the upper layer through unified Skills and a CLI.

Specifically:

• Android: Uses Emulator, ADB, and Instrumentation for app installation, device control, and test interactions;
• HarmonyOS: Connects to DevEco Previewer, HDC, and ArkXTest to support HarmonyOS projects and its testing system;
• iOS: Uses Xcode Simulator, Accessibility, and XCTest for simulator execution, accessibility-tree access, and automated testing.

This layered approach is closer to a real development toolchain. The upper-layer Agent does not need to know every platform’s device commands, but it also does not mistakenly assume that all three platforms have exactly the same runtime capabilities. For developers, existing project structures, build tools, and testing frameworks can continue to be used, without having to prepare an additional set of test devices solely for Qoder.

This is especially important. The problem with many cross-platform automation solutions is not that they lack a unified API, but that their unified API retains only the lowest common denominator across platforms. It can tell an Agent, “There is a clickable element here,” but may not accurately express the iOS accessibility hierarchy, a HarmonyOS page container, or an Android-specific permission state. Ultimately, the Agent gets an overly sanitized world in which the code passes, while it may fail on a real device.

Qoder’s approach is to unify the workflow layer rather than forcibly unify underlying capabilities: regardless of how different the platforms are, the Agent works through “observe—operate—verify”; the specific implementation for each platform is handled by its adapter.

The Real Value Is “Verification,” Not “Automated Clicking”

Connecting an Agent to an emulator is nothing new. Script tools have long been able to launch apps, find elements, and perform clicks. The product value of Mobile Use depends on whether it can place these actions inside the Coding Agent’s reasoning loop.

Ideally, a task would look like this:

1. The Agent reads the requirements and code context and locates the page and logic that need to be modified;
2. It modifies the code and starts the build process for the corresponding platform;
3. It installs or runs the app and reads the current interface and interactive elements;
4. It performs actions such as clicking, typing, and going back according to the requirements;
5. It compares page states, text, routes, or test results;
6. If it finds a failure, it returns to the code and continues making changes;
7. It rebuilds and retests until the task requirements are met, or clearly reports why it cannot complete the task.

This goes a step beyond “having a large model write a UI test script.” Test scripts usually require developers to define element-locating methods and assertions in advance. An Agent closed loop, by contrast, attempts to connect requirements, code, runtime results, and the next round of changes. It may not replace a complete quality-assurance system, but it could first take on the most time-consuming smoke verification and regression checks during development.

For development teams, the benefits are concentrated in three main scenarios. First is synchronized cross-platform modification: when an interaction requirement involves Android, HarmonyOS, and iOS simultaneously, the Agent can build and verify each platform separately, reducing omissions such as “changing one platform and forgetting the other two.” Second is UI-detail adjustment: issues involving spacing, copy, button states, and navigation relationships cannot be proven by a compiler, but can be discovered quickly through runtime verification. Third is issue reproduction: when developers can describe an interaction path in natural language, the Agent can try to reproduce it and record where it fails, shortening the distance from feedback to diagnosis.

“Capability Does Not Exist” Is More Important Than “Pretending to Succeed”

Qoder officially emphasizes that if a platform or the current runtime environment does not have a certain capability, Mobile Use will state this explicitly rather than using an apparently successful but actually non-equivalent command to pretend that the task is complete.

This may sound like a product detail, but it is actually a dividing line determining whether an Agent tool can enter real-world engineering. The most dangerous thing about an automation system is not failure, but packaging an unverified result as a success. For example, an environment may be unable to read the complete control tree, yet the tool returns “found and clicked”; an iOS capability may be unavailable in the simulator, yet the system treats the simulator result as a real-device result; or a system may block a permission dialog while the task log records only that the command executed successfully.

For developers, an Agent’s logs must distinguish at least three states: operation successful, verification failed, and verification unsupported by the current environment. The first two can still trigger another round of fixes, while the third requires human intervention or a change of environment. Mobile Use’s emphasis on “clearly exposing capability boundaries” indicates that Qoder is attempting to prioritize observability over automation rate.

Of course, the Beta version is still some distance from truly unattended mobile delivery. Passing in a simulator does not mean passing on every real device, and an accessibility tree is not the same as visual understanding. Features involving cameras, Bluetooth, push notifications, sensors, vendor ROMs, or complex system permissions still require real devices and human judgment. Cross-platform adapters solve the problem of tool integration; they do not automatically eliminate product differences among the three operating systems.

Whose Way of Working Will It Change?

For individual developers, Mobile Use means handing the repetitive task of “clicking through everything once after finishing” over to an Agent in advance. For small and medium-sized teams, it may reduce the cost of constantly switching among frontend, client, and testing work, allowing a developer to receive more complete feedback before submitting changes. For large teams, its value is more likely to lie in standardization: packaging common build, launch, and smoke-test processes as Skills so that different projects can invoke capabilities on each platform in a consistent way.

But it will not make test engineers irrelevant. Mobile quality issues have a pronounced long tail: combinations of different device models, operating-system versions, network conditions, background switching, and permissions far exceed the coverage of any single set of automated workflows. A more realistic division of labor is for Agents to handle frequent, deterministic, and repeatable verification, while test engineers handle risk design, exceptional scenarios, real-device matrices, and final quality judgments.

From an industry perspective, Qoder is pushing the boundary of Coding Agents from “the code repository” toward “runnable software.” Previously, many Agent products defined the endpoint as generating a patch, passing tests, or creating a pull request. Mobile Use moves the endpoint one step further: the code must start in the target environment and work along the user’s path. This change may not immediately produce an impressive demo, but it is closer to the engineering value that enterprises are willing to pay for.

Qoder had previously provided the Qoder Mobile product for viewing Agent progress, approving actions, and adding instructions from a phone. Mobile Use addresses a different layer of the problem: not whether a person can manage an Agent on a phone, but whether the Agent can operate and accept the app on the phone. Both expand Qoder’s product boundaries, but Mobile Use has a more direct impact on the development workflow itself.

Conclusion: The Next Challenge for Mobile Agents Is a Trustworthy Closed Loop

Code generation is no longer the most difficult part of a Coding Agent’s work. What truly determines whether it can enter production is whether it can continue working under real-world constraints, while honestly telling developers what has been verified and what is merely inferred.

The answer currently offered by Qoder Mobile Use Beta is to use native platform toolchains to handle differences among the three platforms, and then use unified Skills and a CLI to hand observation, operation, and verification over to the Agent. This direction is more cumbersome than “one interface controlling every device,” but it is also more reliable.

If future versions can further support real-device connections, the integration of visual and accessibility information, automatic fixes after failures, and more detailed records of testing evidence, Mobile Use may evolve from a convenient plugin into infrastructure for mobile Agent workflows. At this stage, the most noteworthy aspect is not its claim that Agents can already develop apps independently, but that it has finally begun to address head-on the question of how to prove that an app really works after the code has been changed.

Sources

• ITHome: Alibaba Qoder Launches Mobile Use Plugin, Connecting Agent Closed-Loop Verification Across HarmonyOS, Android, and iOS: Introduces the release of Mobile Use Beta, its three-platform underlying adapters, and its capability boundaries.
• Qoder Mobile Official Page: Introduces Qoder Mobile’s remote control, task synchronization, and mobile Agent management capabilities.

This article was compiled from publicly available information. Product features and compatibility are subject to subsequent updates from Qoder.