iOS cluster control is a technique for centrally managing multiple iPhones from one computer, without jailbreaking, without plugins and without dev boards.
This one answers: A New Batch of iPhones in iOS Cluster Control. Why Do the Taps Land Wrong.
Someone running a jewellery matrix swapped in a batch of second-hand phones last year.
The old ones were iPhone 8s; the new batch was iPhone 11s. The first job after the swap ran beautifully，every device in the console showed success, and it took about twelve minutes.
He went to make coffee. When he came back he opened one of the accounts. Nothing there. He opened a second. Nothing.
Ten devices, all reporting success, and not a single post had gone out.
The problem was coordinates. An iPhone 8 and an iPhone 11 do not share a resolution. The same tap coordinate lands on the publish button on the old device and about twenty pixels to its left on the new one，where there is nothing, and tapping nothing raises no error.
This is the most common and least visible failure after a hardware swap: no error, just nothing.
Why coordinates stop working, and why there is no error
A script taps a point, not an object.
That point is defined relative to screen resolution. The old device is 750×1334, the new one 828×1792. The same (400, 1200) lands somewhere completely different on each，mid-page on the old screen, near the bottom on the new one.
And a tap has no concept of a target. The script does not know whether it tapped a button. It presses and releases at (400, 1200). On a button, that triggers something. On empty space, nothing happens at all.
So the failure looks like this:
- Every task shows success in the console (every step did execute)
- No error is raised (there is nothing to raise)
- The result is empty (nothing happened)
All three together are what make this more dangerous than an error. An error tells you immediately. This does not.
Confirming it in two minutes
No dismantling, no script edits. Do this first.
Take one device of the new model and walk the last action by hand. Open the app, tap through to the publish step, and see how far the actual button is from the coordinate in your script.
Concretely: open that device in the console’s screen mirroring, move the mouse over the publish button and read the cursor coordinate from the toolbar. Compare it with the number in your script.
A few dozen pixels of difference is normal across models and points at coordinates. A few hundred means the page layout itself may have changed, which is a different class of problem.
The value of this step is not starting to edit the script before you know the cause. After a hardware swap the first suspect is always coordinates; system version, app version and network come second.
What order to fix it in
Once confirmed, the order matters, because doing it wrong drags down devices that were running fine.
Step one: split devices by model. Separate old and new models into their own groups in the device list first. Without this, every later adjustment is blind.
Step two: re-mark coordinates on the new model only. Walk the key actions device by device，usually three to five points: open the app, enter the publish page, the input area, the publish button. Record them as a new set of parameters.
Step three: have the script read parameters per group. Not a duplicated script, but one script that reads a different coordinate set based on which group the device belongs to. Next time you add a model, you add a parameter set rather than maintaining a second script.
The connected issue people miss: wait times
Once coordinates are right, look at wait times at the same time.
Newer models are usually faster and load sooner. A two-second wait set on the old model may only need one second on the new one. That sounds like good news, but it cuts the other way: shorten the waits to suit the new model and the old devices no longer keep up.
So wait times should be set by the slowest device, not by the average or by the newest. The usual approach is a generous wait plus a “wait for the element to appear” check, rather than a hard-coded number of seconds.
Avoiding it at purchase time
The root of this is procurement, not scripting.
Buy one model in one batch where you can. One model means one coordinate set and an order-of-magnitude less maintenance. Mixing models is tolerable under ten devices; past thirty it is ongoing drag, because every addition means re-marking coordinates.
If you genuinely need to mix，say only one model exists at the price point in the second-hand market，then manage model as a permanent dimension: put the model in the device alias, group script parameters by model, and put any new model through a full validation pass rather than plugging it in and running.
Finally
Back to those ten devices.
He spent two hours that day re-marking coordinates, splitting old and new into two groups, and changing the script to read parameters per group. He then ran it twice more to confirm before pushing the batch.
Afterwards he added a rule: any new model entering the room runs a single test job that publishes one item, and a person confirms the item actually appeared, before it joins the live schedule.
That rule looks slow. What it blocks is “ten devices report success and nothing happened”，and that costs far more than the few minutes of testing.