1. The man who had written scripts for six years
Late last year a friend came to me and said he had been writing iOS automation scripts for six years and had started to doubt the whole exercise.
His words were that he now spent more time writing scripts than the scripts spent working for him.
I asked to see his schedule for the previous three months. In that period he had written nine new scripts and edited fourteen old ones, eleven of those because an app had changed its layout. Only two were genuinely new business requirements.
That ratio says a lot. Most of his energy was not going into new needs but into a race against interface changes, and that race is exactly what AI phone control handles well and scripts handle badly.
So in March we ran a comparison: five kinds of flow, each run both ways, over three weeks, logged daily.
The conclusion up front. Of the five kinds of flow, only two genuinely belonged on AI. The other three were less work on scripts. Replacing everything with AI was the first idea this test killed.
One thing to settle first. AI phone control does not replace cluster control scripts, it divides work with them. iOS cluster control and Apple cluster control have barely changed at the device layer in recent years. What changed is the task layer above it. The question is not whether to keep writing iOS automation scripts, but which flows deserve to become one. To see how this AI layer installs and coexists with existing scripts, the steps are in the iEasyRun iOS USB documentation.
2. How the test was set up
The devices were his existing iPhones, seventeen of them across two models, connected by cable on a rack. No Bluetooth board and no OTG board, because nothing moves. If you would rather not run a cable to every phone, an iPhone can also connect over the local network, covered further down.
Accounts were split into three business groups, and within each group the same flows ran. The comparison was simple: write two versions of each flow, one scripted and one described to AI, assign them to different device groups, and run for three weeks.
Four things were recorded: completion rate, failure reasons, minutes of human intervention, and one that is hard to quantify but matters most, the time to recover after a layout change.
3. Five kinds of flow, both ways
| Flow type | Scripts | AI | Which to use |
|---|---|---|---|
| Layout changes often (publishing) | Re-record after every update | Usually untouched | AI |
| Lots of exceptions (comment replies) | Exceptions skipped | Sorted by rule and handled | AI |
| Fixed steps (scheduled patrol) | Stable, low failure rate | Works, no advantage | Scripts |
| One-off jobs | Not worth writing | Describe it and run | AI |
| Account security | Not applicable | Not applicable | Neither, keep manual |
That table is the most useful output of the whole exercise. Each row is worth a word.
4. Flows whose layout changes: scripts race the updates
Publishing was his worst headache. Three platforms, layouts moving roughly every two months, and every move breaks the paths inside a script.
Over three weeks the script side re-recorded twice, over an hour each time. The AI side re-recorded nothing, but added three sets of rules: how to close a new pop-up, where the publish entry moved to, and what to do when the drafts folder is full. A little over an hour in total.
The gap is not in the time per recovery but in the nature of the work. Re-recording is repetition. Adding rules accumulates. After the first set of rules, the next layout change mostly passes without attention.
5. Lots of exceptions: scripts skip, AI sorts
Comment replies were the other category.
The scripted approach skips exceptions. That sounds fine until you run it, and see that thirty percent of comments count as exceptions: spam, repeated posting, questions with no answer in the knowledge base, follow-ups that ask one more thing. Skipping means nobody handles that thirty percent, and a human still has to go back through it.
The AI version sorted those exceptions into four categories and handled them, taking completion from seventy percent to over ninety. The remaining tenth it does not guess at, it flags. That turned out to be easier to live with than scripts, because you know what was left undone instead of wondering what was missed.
6. Fixed-step flows: scripts are simply better
This one runs against expectation.
Scheduled patrol work has fixed steps, fixed positions and predictable failures. The script version failed twice in three weeks, both times because a device dropped offline. AI could run it too, with no advantage, and each run took longer because it reads the screen to decide.
So we left that category on scripts. Not because AI cannot do it, but because it gains nothing.
7. One-off jobs: where AI clearly wins
Seven one-off jobs came up in three weeks: exporting the history of one account, cross-checking a batch of orders against a list, tidying the naming of a set of assets.
The scripted approach would mean writing seven scripts to be used once, which is pure waste. The AI approach is to describe the job in a conversation and let it run.
This is AI’s genuine addition, because before, this work was never automated at all. It looked like too much trouble, so people did it by hand.
8. Account security: keep it manual
Password changes, rebinding a phone number, logging in from a new location. Whatever else gets automated, these three should not.
The reason is not capability but cost. Getting these wrong does not mean rerunning a job, it means losing the account. We excluded them from the start.
9. Skipping the cable: the local network route
Everything above ran on cables. Seventeen cords and two hubs look tidy on a rack, but every added device means another cord, and before buying one you have to check whether the machine still has a free port.
An iPhone has a second route that needs no cable. The phones and the computer join the same local network instead. Installation still requires one USB connection, for the phone-side program, the developer image and the licence binding, and once those steps are done the cable comes out. Daily jobs then run over the network.
The saving lands in three places. No cables to buy, which is the most direct part. No powered hubs either, and those are the best known source of faults in a matrix. And placement stops being a constraint, since phones can sit across several rooms instead of needing a dedicated rack.
Three things trip people up the first time.
The licence type. The wireless build binds a device licence, the USB build binds a different type, and they are not interchangeable. Choose the wrong one and the device is detected but behaves badly once you run something.
The naming. In the downloader the option is the offline iOS version, the control side installs as the offline wireless cluster control and mirroring build, and the workstation scan option is the offline iOS build. One thing, three labels, and it is where first installs usually stall. Those labels are in Chinese.
The network. Cables fail through poor contact, wireless fails through weak signal. Two walls between a phone and the router will stop the scan, so bring the phone closer to prove it works, then move it back.
We did not switch, purely because those phones never move and the cables were already run. Starting from scratch today, I would try the wireless build first, especially where devices need to be spread out.
10. How the two run together
Running both beats running either alone, and the arrangement is straightforward.
The device layer is shared. Phones connect, get scanned into the list, get aliases and groups, and both the scripted and AI sides see the same list. Selecting a device never means switching screens.
Flows are routed by nature. Changing layouts and dense exceptions go to AI. Fixed steps stay on scripts. One-off jobs skip flows entirely and get described in a conversation.
Records land in one place. Both sides write into the execution history with status, target device and errors. Check every record early on, then switch to spot checks after a couple of weeks.
To see this arrangement in practice, the AI agent conversation page and workflow canvas cover the mechanics. Where exactly the line falls between the two is set out in more detail in this division of labour.
11. The three-week record
| Metric | Scripts | AI |
|---|---|---|
| Completion rate, exceptions included | 71% | 92% |
| Re-recordings | 2, roughly 3 hours | none |
| Time adding rules | not applicable | roughly 1 hour |
| One-off jobs | each needs a new script | described and run |
| Average time per run | shorter | slightly longer |
One point to be clear about. AI takes longer per run, because it spends a step reading the screen. It wins on completion rate and on surviving layout changes, not on speed.
So the question is not which is faster. It is whether the work will change. If it will, hand it to AI. If it will not, leave it on scripts.
12. Questions that came up
Do I need new devices? No, the existing iPhones work as they are, over a cable, without a jailbreak or signing. Add a hub with an independent power supply, which affects stability more than anything else.
How detailed does the first set of rules need to be? Detailed enough to cover the common eighty percent. The remaining twenty is handled by one fallback rule, flag anything uncertain for a human. Do not expect to finish it in one pass.
What does model usage cost? Daily fixed flows barely touch the model, since re-running a saved workflow does not consume calls. Only jobs that need on-the-spot planning are billed.
Do I need a second computer? One machine handled seventeen devices, provided there are enough USB ports and stable power. Beyond that, split across machines by business.
Can AI report work as done when it was not? It can, which is why we keep the execution history and check it after a run. It is also why the fallback rule says flag for a human rather than try your best.
Does this conflict with cluster control software? No. Device connection, mirroring and grouping stay as they are. AI sits on top as the task layer. What to check before spending on the device side is set out in the script purchase guide.
Where should a beginner start? With a one-off job. The cost of getting it wrong is lowest, and the difference between describing something and writing a script is immediately obvious.
13. In closing
Back to his question. Should he keep writing cluster control scripts.
Yes, but fewer flows deserve one. Steps that stay fixed and interfaces that rarely move are still steadiest on scripts. What is genuinely shrinking is the category of script written to chase a layout change and thrown away when it moves. That work belongs on AI.
His routine now is to run a new flow in a conversation twice, and only then decide whether it deserves a script or a workflow. That order took his re-recording count from more than a dozen over three months down to two.
If you are weighing the same switch, pick one flow whose layout changes often and try that, rather than moving everything at once. One flow running cleanly makes the rest of the decision much clearer.
About EasyClick: A phone automation AI-agent platform covering Android no-root, iOS no-jailbreak and HarmonyOS Next, offering script development, Apple cluster control, local central control & mirroring, and cloud control systems. → Explore all products
Ready to build it for real?
Every approach in this article can be built with EasyClick capabilities on iEasyClick — full documentation, developer tools and automation products, free to try.