Guide

How to build an iPhone farm in 2026

August 1, 2026 · 11 min read

Most phone farms run Android, and the usual explanation is that iPhones are impossible to scale. That was true for a long time. It stopped being true, and the reasons are worth understanding before you spend money on hardware.

This is a practical guide: what to buy, how to power and network it, how provisioning works on iOS, which control layer to pick, and — the part most guides skip — what actually breaks when you go from three devices to thirty.

Why almost every farm is Android

Android farms are easy for three reasons. ADB gives you a documented, first-party remote control channel over USB or TCP. Emulators are free and unlimited, so you can test on a laptop before buying hardware. And nothing stops you from installing an APK you built yourself.

iOS gives you none of that. There is no ADB. There is no emulator — the iOS Simulator runs a different build of your app compiled for the host machine, which is a genuinely different thing (more on that below). And you cannot install anything on a device without going through Apple's signing chain.

So historically, iPhone automation meant one of two things: jailbreak the devices and run something like AutoTouch, or wire up Appium and write code. Jailbreaks stopped keeping pace with iOS releases years ago, and Appium is a test-automation framework that happens to move a finger — it was never built to run fifty devices unattended for weeks.

The gap that leaves is real. If your work depends on iOS specifically — because that is where your users are, or because the app behaves differently there — an Android farm does not substitute for one.

What you actually need

A Mac, and it has to be Apple Silicon

Everything that installs software onto an iPhone goes through Apple's toolchain, and that toolchain only runs on macOS. There is no way around this. A Mac mini is the usual choice — it is the cheapest machine that will sit in a rack and never need a screen.

Base-spec is usually fine. The Mac is orchestrating USB traffic and running a control process, not rendering video. Memory matters more than cores once you are past about ten devices, because each connected device holds an open session.

iPhones — which ones, and how old

The constraint is iOS version support, not performance. Automation drives the UI, so a five-year-old device runs a flow about as well as a current one. What matters is whether the device still takes a current iOS release, because that determines whether apps you care about still install and run.

Buy in batches of the same model. Mixed fleets are a maintenance tax: different screen sizes mean flows that use coordinates break, and different iOS versions mean the same app renders a different layout. Element-based automation absorbs a lot of that, but not all of it.

Power and USB — the part people get wrong

An iPhone that is running a flow and charging draws real current. Ten of them on one consumer USB hub will brown out, and the failure mode is not obvious: devices disconnect at random, sessions drop mid-flow, and you spend a day blaming your software.

What works:

• Powered hubs with a real power budget. Check the per-port amperage, not just the port count. A 10-port hub advertising 60 W total is 6 W per port — borderline.
• Data-capable cables. Charge-only cables are extremely common in bulk packs and will silently give you a device that powers on but never appears in the device list.
• Airflow. Devices running 24/7 get warm, and iOS throttles when they do. A cheap fan across the rack is the highest-value twenty dollars in the build.
• Tiered hubs, not one giant hub. Several hubs of 4–7 ports each, all upstream to the Mac, isolates failures. One hub misbehaving takes down five devices instead of thirty.

Charge management matters over months, not days. Keeping lithium cells pinned at 100% around the clock degrades them. Some operators put hubs on smart plugs and cycle power on a schedule; others simply accept battery wear as a consumable cost.

Network and proxies

This is where iOS differs from Android in a way that catches people out. On iOS, HTTP proxy settings live on the Wi-Fi network, not the device and not the app. Configure a proxy on an SSID and every device joined to that SSID uses it.

That gives you a few options, roughly in order of effort:

1. One SSID per device. Crude but reliable. A router that can broadcast many SSIDs, each with its own proxy, each device joined to its own.
2. Routing upstream by MAC address. One SSID, and the router or a gateway box decides which egress each device gets. Cleaner to manage, needs a router you can actually program.
3. Per-device egress handled by your control layer. If the tool driving the devices already tracks which account belongs to which device, letting it own the proxy assignment too keeps one source of truth. Icemoon does this — proxy and account are assigned per device from the dashboard.

Whatever you choose, the principle is the same: an account should keep the same egress it started with. Rotating a mature account through a new IP every day is a stronger signal than almost anything you do on-device.

Provisioning: the iOS-specific tax

To drive an iPhone you have to install a runner app on it, and installing anything means signing it. Two paths:

The seven-day expiry is the single most annoying thing about free provisioning, and it is why a lot of people conclude iPhone farms do not scale. It is only unmanageable if you are doing it by hand. Tooling that re-signs and reinstalls automatically makes the distinction mostly academic for small fleets — Icemoon handles the re-sign itself, so a free Apple ID is genuinely workable. Past roughly ten devices, the paid account stops being optional, simply because you want fewer moving parts.

Each device also needs two one-time things done by hand: tapping Trust when it is first plugged into the Mac, and enabling Developer Mode in Settings. Budget a couple of minutes per device on intake. There is no way to script this — it is deliberately a physical-presence gate.

Choosing the control layer

This is the decision that determines whether the farm is a pleasure or a second job.

The honest framing: Appium is the right answer if you have engineering time and your workload is test runs. It is the wrong answer if what you actually need is thirty devices doing the same thing every day for a year without supervision. We wrote a longer comparison at Icemoon vs Appium, and one for the jailbreak route at Icemoon vs AutoTouch.

What breaks as you scale

At 3–5 devices

Nothing, really. A single powered hub, one Mac, manual intake. This is the stage where people conclude iPhone farms are easy.

At 10–20 devices

Power delivery becomes the first real wall, followed by USB enumeration — some hub chipsets simply will not present twenty devices reliably. Certificate expiry stops being a curiosity and becomes a weekly chore if it is not automated. Flows that used screen coordinates start failing on the one device with a different screen size.

At 30+ devices

Two things dominate. First, recovery: at this size something is always in a bad state — a device rebooted, a session dropped, an app updated and moved a button. If your tooling does not detect and recover on its own, you become the recovery mechanism. Second, per-account state: which account is on which device, which proxy it uses, when it last ran. A spreadsheet works until it very suddenly does not.

A realistic starting build

Call it $1,500–2,000 to have five iPhones running unattended, most of it in the devices. The Mac is a fixed cost that does not repeat as you grow — the same machine handles many more devices than five.

Compare that to the alternative most people reach for first: a cloud Android phone service at a few dollars per instance per month. Cheaper to start, and genuinely the right call for throwaway workloads. But it is not iOS, and for anything where the device identity matters, a physical device is a different category of thing.

Where to start

Buy one iPhone and one Mac before you buy ten. Get a single device running a real flow end to end — provisioning, a proxy, an account, a schedule — and you will discover which of the constraints above actually bite for your workload. Almost nobody's first plan survives contact with the first device.

Then scale in one direction at a time. More devices with the same flow is easy. More flows across the same devices is easy. Both at once, on hardware you have not tested, is how weekends disappear.