1. A person who edited his way into despair
Someone I know runs a small cross-border operation and writes his own scripts. He started with three phones.
At three, life was easy. One script per phone, credentials, keywords and timing all written into the code, change whatever you like.
Then he scaled to twenty. A platform moved a button, and he had to update the coordinates in twenty files. Around file eleven he started questioning his choices. Worse, the next day two devices were still running the old script, because he had missed those two files.
What he said afterwards stuck with me: the problem was not that scripts are hard to write. It was that his scripts had never been designed for twenty devices.
2. Split the matrix into layers first
The most common mistake is treating an iOS phone matrix as purely a device problem and starting with how many phones to buy.
Devices are the last layer. Get the structure straight first and every later step gets easier.
The script layer answers what to do: which flow, under what conditions, and what happens on failure. The device layer answers where: which device holds which account, how they are named and grouped. The network layer answers where from: how each account reaches the internet. And an optional fourth, the data layer, answers how it went: logs, screenshots, summaries.
3. Script layer: one codebase for N accounts
This is where a matrix diverges from ordinary automation.
The ordinary pattern hard-codes everything. The matrix pattern keeps the flow in code and moves every value out: accounts, keywords, posting windows, asset directories. None of it lives in the source.
That buys three things.
One change to a coordinate applies everywhere at once. Adding a device is a new row in a table, not a code edit. When something breaks, you know every device is running the same logic, which removes script-version drift as a suspect.
The table can be plain:
TikTok-US-01,account_a,pass_a,keyword_a,09:30
TikTok-US-02,account_b,pass_b,keyword_b,10:10The script reads its own device name at startup and pulls its row. The console already carries the device name when it dispatches, so nothing extra has to be passed in.
4. Device layer: access, naming, grouping
The point of this layer is giving every device an identity a script can read.
Access depends on the room. Phones on a rack that never move are fine on a direct data cable: console 10.7.0 or newer with iOS 17 or newer, one cable each, no extra hardware, no signing. Phones that move, or that sit across one LAN, are easier on WiFi. Cable genuinely out of reach is the only case for external hardware.
Naming, as above: ASCII with hyphens, platform-market-number. The name is read by scripts, and non-ASCII causes encoding trouble somewhere in the chain.
Group by business dimension. Platform first, then market works well. Once grouped, dispatch and troubleshooting are group operations, and a new device only needs to be dropped into the right group.
Grouping in place means task dispatch selects by group rather than ticking devices one by one, and adding hardware never touches the scripts.
5. Network layer: how to divide exits
Two common approaches are both wrong: one independent proxy per device, or one shared exit for everything.
A workable rule splits at two levels, platform and market.
Within one platform, accounts should not share an exit. Three TikTok US accounts on one address is a clear linkage signal. Across platforms, sharing is fine. A TikTok US account and an Amazon US account on the same US exit look like one American user, because those platforms do not compare notes. Per account, the exit should be stable. Logging in from A today and B tomorrow is itself an anomaly.
In practice: prepare a few exit groups by market, map each device’s network configuration to its market, and stagger same-platform accounts across the group.
One caveat on stability: an exit that keeps dropping and reconnecting is riskier than a stable reused one, because each reconnect is recorded as network switching inside a short window.
6. Data layer: getting execution records back
Optional in theory, close to mandatory past ten devices.
The reason is simple. You cannot confirm thirty devices by looking. Without records, you cannot even answer whether last night’s batch finished.
Record three things: which device, which step, what result.
For the result, the cheapest approach is having the script screenshot at key points. Screenshots serve twice: on failure you see where the screen stopped, and on success they act as evidence that the step ran.
Real-time logs are enough at low device counts. Past that, logs scroll too fast, and what you actually need is filtering and a failures-only view. Tag different outcomes in the script so they can be filtered later.
7. Failures: dropouts, stalls, reruns
At scale, failures are the normal case, not the exception. What matters is having a fixed order to handle them in.
Dropouts first. Separate device from link: swap the cable, swap the port, and if it recovers, it was one of those. If a whole group drops at once, suspect the hub’s power budget and redistribute devices across controllers.
Stalls second. The screen still updates but nothing moves, or a step never completes. Read the log to find the step, then walk that step by hand on one device to decide whether the script is wrong or the page changed.
Reruns third. One device: retry once, then pull it out and record it. Many devices at once: stop and read the script instead of retrying, because simultaneous failures are almost never hardware.
With those three in place, failures stop affecting overall progress. A matrix cannot promise zero problems, but it can promise problems do not spread.
8. A reference build at twenty devices
Script layer: one main flow plus a device parameter table. No account values in code. Device layer: twenty matching iPhones on direct cables, named platform-market-number, grouped by platform then market. Network layer: two exit groups by market, same-platform accounts staggered, exits kept stable. Data layer: screenshots at key steps, logs kept thirty days, failures tagged separately. Failure handling: single-device retry then removal, multi-device failure means read the script first.
This can be copied as-is. What you tune is the table contents, which depend on your business.
9. In closing
The test for an iOS phone matrix is plain: how many places do you have to touch to change one value.
If the answer is one, the matrix is healthy. If the answer is twenty, what you have is twenty unrelated phones.
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.