You ask an agent to check whether your app displays a reminder at 9 a.m. The app is running, but it’s only 8:15. Next, the agent needs to check an invitation panel that slides up from the bottom of the screen, known as a bottom sheet. Before the agent can inspect it, someone has to send an invitation or the agent has to find a debug menu that triggers it.
Both checks require the agent to control the test conditions: what time the app thinks it is, and which events its logic receives. Repeated screen interactions and waiting can make those conditions awkward to reach.
Is there a way to make these conditions easily accessible to agents so they can adjust them accordingly without interacting with the UI? Let’s find out.
Expose the controls your agent needs
Appduct lets an agent call functions inside your app while it runs. Your team registers each function as a tool, giving it a name, description, and a schema that defines the data it accepts. Only the tools you register are reachable through Appduct.
Your team decides what those tools do by implementing handlers - functions that execute when an agent sends a corresponding command through Appduct. For example, a set_feature_flag handler might change a flag, advance_time might move the app’s test clock forward, and simulate_invite_received might dispatch an application event. Each handler uses your app’s own logic, while the tool’s description and input schema tell the agent how to invoke it.
The same principle applies across supported technologies. Appduct supports native iOS apps in Swift, native Android apps in Kotlin, React Native, Flutter, and web apps. Each has its own integration: register a function, then let the agent call it.
The agent needs access to a running build with Appduct included. Standard release builds leave it out by default, and you can opt in for internal quality assurance (QA) builds.
Connect the running app to the agent
The agent reaches those tools through Appduct’s MCP server. The Appduct SDK runs inside the app, and a background service, called the daemon, runs on your computer.
For a mobile session, the agent calls appduct_connect. Appduct creates a short-lived connection link and opens it in a running simulator or emulator. On a physical phone, you can scan a QR code instead.
The link tells the SDK where to connect and carries a single-use session token. The app connects back to the daemon over an encrypted WebSocket and shares its registered tools.
Once the app joins the session, the agent can list its tools, read their descriptions and input schemas, and call them. The MCP server routes those calls through the daemon to handlers inside the app. Results and app events travel back through the same session. The agent guide covers the setup.
Agents that work in a shell can use the CLI too, and you can call the same tools by hand or from test scripts.
Move the app’s clock to the moment you want to check
Let's return to the reminder scheduled for 9 a.m.
Without controls for the app’s time, the agent has to wait until the reminder is due or use whatever time settings your test environment provides. Checking the moment before it’s due, the moment after, and the same schedule in another timezone means preparing each condition again.
You can design the app so its scheduling logic gets time through a small interface. That interface provides the current time and the timezone the app uses for its schedule. Give it two implementations: a production version that reads the real clock, and a version for QA builds that lets you set and advance time and choose a timezone.
Your scheduling logic uses the same interface in both builds. In the QA build, register tools that call the adjustable implementation. For example, set_time sets a particular instant, set_timezone selects the timezone, advance_time moves the clock forward, and reset_time returns it to real time.
The agent can discover those tools and put the app at 8:59 in the selected timezone. Using UI automation alongside Appduct, it checks that the reminder hasn’t appeared. For the screen interactions and inspection, a tool such as agent-device lets an AI agent tap controls, read the app’s interface, and capture screenshots on iOS and Android. It then calls appduct_call_tool with arguments such as:
{
"name": "advance_time",
"args": { "seconds": 60 }
}The handler advances the app’s clock, allowing the agent to verify that the reminder appears at 9 a.m. The same principle can be used to test how the app behaves in different time zones.
With those controls exposed through Appduct, the agent can check the moments before and after a scheduled action in one QA session. It chooses the time, observes the app’s behavior, and repeats the checks after a code change without waiting for the real clock to reach each moment.
Open the bottom sheet you want to test
Suppose your app receives workspace invitations while the user browses their projects. An invite_received event makes the app present a bottom sheet with the inviter’s name, the workspace name, and options to accept or dismiss the invitation. The QA task is to check that sheet’s layout and interactions.
Without a direct trigger, the agent needs another account to send an invitation or has to navigate through a debug menu. Each repeat includes those setup steps and screenshots to find the right controls before the sheet is even open. That spends time and tokens on reaching the component under review.
Your team can register a tool such as simulate_invite_received. Its handler dispatches the app’s invite_received event with test invitation data. The existing listener opens the bottom sheet through the same presentation code used when a real invitation arrives.
The agent discovers the tool and calls appduct_call_tool with arguments such as:
{
"name": "simulate_invite_received",
"args": {
"inviteId": "qa-invite-4821",
"inviterName": "John Doe",
"workspaceName": "Mobile team"
}
}The sheet opens on the screen the agent is already testing. Using UI automation alongside Appduct, it can inspect the text and button layout, dismiss the sheet with a gesture, and trigger it again with a longer workspace name to check how the content fits.
If the sheet opens asynchronously, the app can report when it’s ready through a declared Appduct event:
await postEvent("invite_sheet_presented", { inviteId });The tool dispatches an event into the app; this signal reports the result back to the agent. The agent can discover it with appduct_list_events and use
appduct_wait_for_event
to wait for the current presentation before starting its UI checks. It can take its inspection screenshot once the sheet is ready, avoiding repeated screenshots to check whether it has appeared.
With Appduct, the agent can trigger the sheet with one tool call and repeat the check with different invitation data. Its UI interactions go toward exercising the sheet’s content and behavior, with fewer setup steps and screenshots consuming time and tokens.
Start with one agent task
An agent driving mobile QA needs controls for the conditions it’s checking. Waiting for a scheduled action or repeating a flow to open one bottom sheet can consume the session before the agent reaches the behavior under review.
Appduct makes the controls your team writes discoverable and callable by the agent. A tool can flip a feature flag, adjust the app’s time source, or dispatch a specific application event. Completion signals let the agent wait for the work to finish before checking its result.
Pick one QA task you want an agent to run and expose a small control it needs. Give the tool a clear description and input schema, connect the agent, and ask it to check the behavior. Follow the quick start, or try a playground before adding Appduct to your app.
