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: Two People Sharing One iOS Cluster Control Pool. How Do You Split the Work Safely.
A team of two shares one batch of devices.
They have a conversation in their group chat that goes roughly like this:
“Did you touch device 07 today?” “Don’t think so.” “Its alias shows as changed yesterday.” “Ah, maybe me，I added two devices yesterday.” “You could have said.” “I didn’t know you were using 07 too.”
Every line is reasonable. Together they say one thing: they share a device pool without sharing a set of rules.
With one operator, a lot never needs writing down. You remember which device you touched yesterday, which account sits on which device, when the jobs run. With two, that breaks, because your memory is only useful to you.
Three things to settle before sharing a pool.
One: record changes, and record them in one place
The problem is that change records scatter，someone mentions it in chat, someone keeps a notebook, someone records nothing.
The fix is simple: any change that affects the other person goes in the same place.
What needs recording:
- Adding, removing or renaming devices (affects whether the other person can find it)
- Changing groups (affects the scope the other person dispatches to)
- Changing script versions (affects what the other person’s runs produce)
- Changing scheduled times (affects whether schedules collide)
It does not need to be formal. One line is enough: who, when, which device, changed to what. The essential part is “the same place”：half in chat and half in a document is the same as not recording.
Renaming and regrouping in the console take effect immediately. So this rule is not for the system, it is for people: it makes the second person’s actions traceable.
Two: stagger schedules, with a rule for who takes a slot
When two people schedule independently, the common failure is collisions.
A collision is quiet. Two jobs land on the same moment, devices can only run one, the other is skipped，and no failure record is written. You simply discover hours later that something never went out.
The answer is not asking each other. It is picking a rule. Two common ones:
Rule one: split by time band. A takes the morning jobs, B takes afternoon and evening. Simple, but it requires that your work is inherently time-bound，if your work is “it must go out today” with no fixed slot, this does not fit.
Rule two: first to schedule takes the slot, then records it. Whoever schedules first holds that moment, and logs it in the shared place afterwards. Flexible, and it depends on the logging actually happening.
What matters is not which rule, but that one rule exists and both people know it. Mixing the two produces more collisions than not scheduling at all.
Three: account-to-device mapping must be checkable
The third failure point is “which account is on which device”.
With one operator you remember. With two, the second person does not，so you get two similar accounts signed in on one device, or worse, the same account having been signed in on two.
The answer is not memorising. It is making the relationship checkable:
- Write the account-to-device mapping in one place：a spreadsheet or the system, as long as there is a single source
- Put the purpose in the device alias, so the name alone tells you roughly what kind of account sits there
- Check before moving an account, never move from memory
One floor worth stating up front: do not switch sign-ins rapidly on one device. That is an anomaly in itself. Accounts spread across devices, each device handling its own set, is the normal shape. This is especially easy to break when a pool is shared, because both people think “it’s free, I’ll just use it”.
Split by task or by shift
This is the core choice, and both have a cost.
| Basis | Suits | Cost |
|---|---|---|
| By task type (A publishes, B replies) | Clear task types that do not cross | Devices must be allocated per person, lowering utilisation |
| By shift (A takes mornings, B afternoons) | Work that is inherently time-bound | Handover is the weak point，someone must own unfinished morning work |
Under ten devices, splitting by task type is easier, because there is no handover to write. Past thirty, you usually have to split by shift, because one person cannot cover a full day’s volume.
Either way, one floor applies: at any given moment, on any given device, only one person is operating. Hold that and everything else is an efficiency question. Break it and it is an incident.
Finally
Back to that group chat.
They settled on three things: all changes go in one shared document; schedules are first-come-first-served and logged; the account mapping is maintained in exactly one table. A month later, the “did you touch device 07” conversations had essentially stopped.
Sharing a pool between two people is really moving what lives in one person’s head onto paper. It costs a little recording time and saves repeated reconciliation and a class of failures nobody can explain.