Where Do iOS Scripts Come From? A Side-by-Side of Building, Buying, and AI

Writing the steps you repeat every day into code, and letting the phone run them, is an automation script. Cluster control is the layer above the script, used to manage many devices at once.

The real cost of a script is in the first change

Last winter a friend who does cross-border customer support came to me and said he wanted to take the scripts back and maintain them himself. Two years earlier he had outsourced twelve iOS automation scripts and paid in one lump. In the third year the platform redesigned, every page path changed, and all twelve scripts broke together. The original author said changes are now charged per job, eight hundred for one script. That comes to nearly ten thousand, and the next redesign has to be paid again.

The price of the first delivery is only the start. How many times it will change over the next two years, and who decides each change, is the actual bill. How much one change costs has to be asked separately. Where a script comes from depends on the things that will happen again later. The three paths each have a length: building in-house can be changed, buying finished starts fast, and AI generation has a low cost per run. Whether the flow will change, and whether someone on the team can take it, decides which path you take.

Five hard measures, and a side-by-side of the three paths

Five hard measures, compared directly. Delivery speed decides how soon you see the first batch of results:

Criterion	Good	Average	Poor
First script usable	Same day to three days	One to two weeks	More than a month
Small flow change	Changed the same day	Waiting in a queue for a slot	Renegotiate the requirement
Add a new platform	Reuse the existing flow, within two days	Rewrite a copy	Quote again
Cost of trial and error	Low, change any time	Medium	Pay once per change

Ask how long it takes tomorrow to add one condition. Cost per script decides how the books are kept:

Criterion	Good	Average	Poor
First build	Labor time	Quoted per script	Quoted per script, maintenance excluded
Later changes	Your own time	Charged per change	Charged per change, and the price goes up
Reuse	One flow reused across platforms	One copy per platform	One copy per account
Hidden cost	Little	Communication and scheduling	Repeated rework

A per-script quote looks clear. The hidden assumption is that the flow will not change again. When you compare, multiply in the number of changes over the next six months. Maintainability decides whether, three months later, you can still tell this is something you wrote:

Criterion	Good	Average	Poor
Parameters externalized	Accounts and fields all external	Partly external	Hardcoded
Exception handling	Retry, timeout, and a screenshot kept as evidence	Some of that	Stops on an error
Delivery form	Source, or a project you can package yourself	An executable	Can only run remotely
Takeover difficulty	Another person can read it	The original author has to walk through it	Nobody can take it

The capability ceiling decides whether you can do more complex work:

Criterion	Good	Average	Poor
Logic	Conditions, loops, retries, subflows	Sequential execution plus a simple condition	Record and replay only
Recognition	Template matching plus OCR	Only one of those	Tap by coordinate only
Many devices together	Dispatch by group, take parameters per device	One phone only	One phone only
Extensibility	Has an API, can connect to your own system	Closed	Closed

The business will grow. Today you only need scheduled posts. Next year you may need to take orders, roll up data, and branch on the result. Ask at delivery what happens when logic has to be added later. That can save a rewrite. Last is the risk that you cannot switch away later:

Criterion	Good	Average	Poor
Who owns the code	Source is in your hands	An executable is delivered	Only a remote account
Dependencies	It still runs if the author stops	Changes need the author	It depends on the author’s service
Network behavior	Auditable, no unknown callbacks	Unclear	A remote address is hardcoded
Migration cost	The logic can move to another platform	Has to be rewritten	Starts from zero

Outsourcing can be done. Ask separately whether the right to change it is still in your hands: if you cannot reach this person tomorrow, can the script still be changed? Compress the measures above into one table and the difference among the three paths is easy to see:

Dimension	Build in-house	Buy finished	AI generated
First delivery	Slow, one to four weeks	Fast, same day to one week	Very fast, same day
Cost per run	Labor time	Quoted per script	Close to zero
Freedom to change	Fully your own	Depends on the author’s schedule	Fully your own
Complex logic	Highest ceiling	Depends on the author’s skill	Medium, exception branches need a person
Parameter support	Depends on whether you wrote it	Often missing	You have to organize the config yourself
Team barrier	Someone has to be able to write code	None	None
Long-term risk	People leaving	Author unreachable, charged per change	Logic hard to control, hard to audit

The split among the three paths is two things: whether the flow will change, and whether the team can take it. For the standard a delivered script has to meet, those 5 evaluation criteria when buying cluster-control software can be used directly as an acceptance list. Building in-house fits a flow that keeps changing and a team with at least one person who can read code. The typical case is long-running matrix operations while the platform is still redesigning. Changes do not depend on asking someone. Buying finished fits a flow that is very fixed and will not move in the short term, for example checking orders at a fixed time every day. It starts fast, and the right to change it stays with someone else. AI generation fits one-off tasks, exploratory needs, and a small team with no development resource. The unit cost is the lowest, exception branches are incomplete, and someone has to fill in “what if it goes wrong.” Which tasks fit it is drawn more specifically in how the two are divided. A steadier mix is to build the core flow in-house or buy out the source, and hand edge tasks to AI.

How to staff it by team, delivery pitfalls, and the books

One person managing thirty devices, with nobody to write code and a flow that will change, should use a visual workflow plus AI generation. Put accounts, keywords, and time windows into a config table and keep one copy of the flow. Phone automation without writing code goes into that in more detail. A two-person team, one who knows the business and one who knows code, should build the core flow in-house and hand the edges to AI. If that machine will eventually run a matrix, the way the scripts are organized also has to follow the parameterization standard in that side-by-side of matrix setups. If you are already outsourcing, rewrite the few scripts that change most often yourself first, get them stable, then take the rest back step by step. Writing “how much one change costs, and what form is delivered” into the contract is more useful than pushing for a lower price. When the platform covers several markets, look at whether one flow can be reused on Android and HarmonyOS. That platform-selection comparison already has the comparison.

Delivery has six common pitfalls: treating “it runs” as “it can be maintained,” accepting only that it ran through and never checking whether it is parameterized, then finding three months later that adding an account means changing thirty files; buying only an executable, so every change means finding the author, and network behavior cannot be audited; no exception branches, so the demo is smooth and a real phone gets stuck on a popup; one script per account, so twenty accounts are twenty files; accepting only the result and not the evidence, when a problem should let you look back at what the screen was; no version record, so after a bad change you want to roll back and the previous version has already been overwritten.

The books look at how much manual time was replaced. The unit price of a script does not show that:

Item	One-time	Each year
Build in-house (labor time)	One to four weeks of development	Maintenance and iteration time
Buy finished	Quoted per script	Each change charged per job
AI generated	Close to zero	Time spent filling exception branches by hand
Devices and licenses	Counted by device	Grows when you add devices
Rework from a platform redesign	None	Depends on how often the platform updates

Take one concrete case. One person spends forty minutes a day on this action, about two hundred and forty hours a year. Script development plus debugging takes three days, and it comes back in one or two months. An action that happens once a month is not worth a script. Letting AI run it once is a better fit. Rework from a platform redesign is not on the quote, and it happens once or twice every year. When you pick a setup, ask what happens when the platform redesigns and who fixes it. To total the bill for your own device count, use the method in that cost-estimate article.

A few selection notes: first ask whether this flow will change in three months, and if it will, do not hand the right to change it away; write the change price into the contract, and negotiate the first price together with the price of every later change; the acceptance list has to include parameterization, exception handling, screenshots kept as evidence, and who owns the source; a small team should prefer a visual workflow and should not find a person for every change; the three paths can be stacked, core built in-house or bought out, edges handed to AI, and after it is stable decide whether to settle it in.

About EasyClick: A mobile automation script development platform covering three phone ecosystems: Android without root, iOS without jailbreak, and HarmonyOS. It also offers Apple script writing, Apple cluster control, Android cluster control, remote cloud control, and AI phone cluster control. → Explore all products