Guide

Powering an iPhone farm: hubs, amperage and phantom faults

August 1, 2026 · 8 min read

A device drops mid-flow. Another one vanishes from the list and comes back thirty seconds later. A run that worked yesterday fails at step forty today, on a different device each time. Almost everyone's first instinct is to blame the automation. Almost everyone is wrong.

Intermittent, device-specific, un-reproducible failures in a farm are power failures until proven otherwise. This is the least interesting problem in the whole build and the one that costs the most days.

What a working phone actually draws

An idle iPhone sipping from a charger is not the load you are designing for. A phone that is running automation is doing several expensive things at once: the screen is on, the radio is active, the CPU is working, and the battery is charging — often from a low state, which is when charging draws the most.

USB-A ports on a cheap hub commonly deliver 0.5 A at 5 V. That is 2.5 W. A modern iPhone will happily take 10 W or more when it wants to, and considerably more on fast charge. The gap between what the phone wants and what the port gives is where your problems live.

The dangerous part is that it does not fail cleanly. An underfed phone does not display an error. It charges slowly, then not at all, then the USB connection renegotiates, then the session your automation was holding is gone.

Reading a hub spec honestly

Hub marketing quotes total power. You care about power per port, under simultaneous load.

Two further things the spec sheet will not tell you. Many hubs cannot deliver their rated total across all ports simultaneously — the number assumes one or two ports drawing heavily. And some share a power budget between groups of ports, so which physical socket you use changes what a device gets.

Tiered hubs beat one big hub

The instinct at twenty devices is to buy a twenty-port hub. Resist it.

Several 4- to 7-port hubs, each with its own power supply, all upstream to the Mac, gives you three things a single large hub does not:

• Failure isolation. A hub that starts misbehaving takes down five devices, not thirty. You will notice a cluster of five failing together and know exactly where to look.
• Real power headroom. Five hubs with their own supplies genuinely deliver five times the budget. One hub advertising the same total usually does not.
• Enumeration that works. USB has practical limits on how many devices a controller will present reliably. Spreading across hubs — and, if the Mac has them, across separate controllers — avoids a wall that looks like random disconnects.

Cables are half the problem

Bulk cable packs are full of charge-only cables. They have no data lines. A phone on one powers on, charges, shows every sign of life, and never appears in the device list.

This wastes an afternoon roughly once per farm. The diagnosis is quick when you know to look: if a device charges but does not enumerate, swap the cable before touching anything else.

Cable quality also degrades. A cable that is fine today can develop intermittent data faults after months of sitting under tension in a rack. When one device starts misbehaving and only that device, the cable is the first suspect, not the phone.

Heat, which is the same problem wearing a different hat

Phones that charge and work continuously get warm. iOS responds to heat by throttling, and a throttled device runs flows slower — which shows up as timeouts on steps that were previously fine.

Worse, heat and charging interact: iOS will slow or stop charging a hot battery, so a thermally stressed device can end up underpowered even on an adequate port.

The fix is unglamorous. Space the devices so air moves between them, and put a fan across the rack. It is the cheapest reliability improvement available and it costs about twenty dollars.

Battery health over months

Keeping lithium cells pinned near 100% around the clock at slightly elevated temperature is close to the worst case for longevity. In a farm this is the default state unless you do something about it.

The options, roughly in order of effort:

1. Accept it. Treat batteries as a consumable and budget replacements. For older devices bought cheaply, this is often the rational choice.
2. Cycle power on a schedule. Smart plugs on the hub supplies, cutting charge for part of the day. Crude, effective, needs the devices to tolerate discharge windows.
3. Keep them cool. Temperature does more damage than charge state alone. The fan again.

What matters practically is knowing which devices are degrading, because a phone with a tired battery under load behaves like a phone on a weak port — the same brownouts, the same phantom faults.

Telling power from software

When something fails, this ordering resolves it fastest:

1. Does the failure follow the device or the step? Following the step is software. Following the device — or following nothing consistently — is hardware.
2. Does it get worse when more devices run? That is power, almost definitionally.
3. Swap the cable. Ten seconds, eliminates the most common cause.
4. Move the device to a different hub. If it recovers, you have found your hub.
5. Run the same flow with everything else idle. If it passes, you were never looking at a bug.

Only after all five is it worth opening the flow.

A build that avoids all of this

For a first farm of five devices: one powered hub with at least 10 W per port under simultaneous load, five known-good data cables, two spares, and a fan. That is roughly a hundred dollars over the cheapest possible option and it removes an entire category of problem.

Scaling from there means adding hubs, not ports. Each new group of five gets its own hub and its own supply, and the failure domain stays small.