iOS cluster control is one computer centrally managing and batch-operating several iPhones, with no jailbreak, no signing, and no dev boards.
An iOS script can be recorded in the screencast, written in the IDEA plugin, or handed to a model in plain language.
Last month a woman running a Xiaohongshu matrix asked me whether getting iPhones to post notes on their own meant signing up for a programming class first. Tutorials online had scared her. She thought it was three months of syntax. I told her no. She could have a phone running on its own that afternoon. Get the phone onto the console first, then tap a few times in the screencast and record a short run.
Three ways in, and what each one owns
Script recording in the console’s screencast. However you tap and swipe on that picture, it writes the actions down and saves them as a script you can replay. This is the fastest way in. Five minutes gets you a first version. Run it right after recording. Once it runs through, you have the most basic automation.
Writing code in IDEA means installing the dev plugin. Create a multi-module project and set the project type to “EasyClick iOS USB Edition - Script Project”. Then link the console’s debug address, which defaults to 127.0.0.1:8019. Once it connects, you can run scripts against a real device from inside IDEA. With several devices attached, select the one you are debugging, then run.
The plain-language route uses iEasyRun. The software supports the MCP protocol, so agents such as Claude and WorkBuddy can connect to the iPhone and carry out operations. This route suits jobs that need a judgment, for example deciding how to reply after reading a message. The MCP article tests where the line with handwritten code sits.
A recorded script can be opened in the plugin and edited further. A finished flow can be scheduled by a model from a layer above.
What recorded code looks like, and why you still edit it
Scripts are JavaScript. Record “open the app, tap twice” and what you actually get is a string of action code with coordinates in it.
In a recorded script, the coordinates line up exactly with the screencast picture and the screenshots. Where you see the button on the screencast is where the coordinate is written. To tap a spot, measure that spot.
Recording cannot capture judgment. Waiting until a page has loaded, retrying once when a tap hits nothing, closing a popup and then continuing: none of that logic gets recorded. Recording only replays the actions you made. The recorded base usually goes back into the code so you can add waits and retries. How to measure coordinates, why a wait can only be a length of time, and how a failure should end are taken apart in the three pitfalls article.
For someone starting from zero: record first. Editing the generated code has a much lower barrier than writing against a blank file. After two or three rounds of edits, that small bit of JavaScript structure starts to look familiar on its own.
If you do not want the plugin, there is the HTTP interface
At the script layer there is a JS object called usbHidEvent, available on iOS USB edition 10.7.0 and above. Taps, swipes, and the other actions all go through it.
If your team writes Python or Go and does not touch JavaScript, there is another route. The console exposes an HTTP interface. POST to the addresses under http://<console IP>:8019/openapi/usbhid, with the same parameters as the JS object. A third-party language can call HTTP and send touch and key events into the phone, and the script logic stays in the language you already use.
This route shows up in two kinds of team: backends that are already Python, and scripts that have to talk to the team’s own systems. For an individual user, installing the IDEA plugin is less fuss.
All three ways of writing land on the phone at the same layer: touch and key events inside the USB cable. The difference is whether the logic lives in the recording, in the plugin, or in your own language.