Multi-device scaling

Why most location simulators cap at 5 phones, what the actual technical limits are on Windows + iOS 17, what PinDrift supports per host, and how to scale a PinDrift fleet past a single PC without lying to yourself about the limits.

Why most location simulators cap at 5

Walk through the multi-device pages of iAnyGo, AnyTo, MockGo, and Dr.Fone Virtual Location and you'll see the same number repeated: 5 devices simultaneously. It's a remarkable coincidence given the four products use different tunnel implementations, target different versions of iOS, and are written by different vendors.

It's not a coincidence. Here's what's actually going on.

1. It's a licensing tier dressed up as a technical limit

"Up to 5 devices" reads as "everyone in your household" in the buying flow. It creates a natural pricing ladder: 1 device on the basic plan, 5 on Pro, contact-sales for more. The number doesn't have to be 5 specifically; it just has to be small enough that "Pro" feels like an upgrade and "Enterprise" has room to grow into.

If you reverse-engineer any of the four binaries, you don't find a MAX_DEVICES = 5 hardcoded in the tunnel implementation. You find a license-server response field that says "max_devices": 5, checked at activation time. Different license tier, different number.

2. Most of these tools inherit from the same upstream library

Three of the four (iAnyGo, AnyTo, Dr.Fone) wrap libimobiledevice or a fork of it. libimobiledevice's USB-multiplexing layer (usbmuxd) has documented serialization quirks that show up around 6–8 simultaneous device-info polls. The vendors all built tested-and-documented support up to where libimobiledevice's quirks start surfacing, then drew the line.

PinDrift is built on top of pymobiledevice3, a from-scratch Python rewrite that handles iOS 17+'s RemoteXPC tunnel properly, which gives us a different (and more forgiving) set of scaling characteristics. We hit different walls than the libimobiledevice-based tools do.

3. They tested with 5 and shipped

QA cost grows non-linearly with simultaneous device count. Testing 5 phones thoroughly is realistic on a small team; testing 20 phones thoroughly requires a dedicated lab, a power-management plan, a network with capacity, and several days per release. The competing vendors hit a point where the next device of testing was more expensive than the marginal revenue from supporting one more device, and stopped there.

4. They hit a real ceiling around that number anyway

It's not that 5 is the actual hard limit. It's that past about 7 or 8 on a typical Windows PC over direct USB, weird stuff starts to happen, and shipping past the weird-stuff threshold is a support headache. They picked a number safely below the threshold.

The next section is what that "weird stuff" actually is.

The real technical limits

Five distinct host-side ceilings, each with its own symptom and mitigation. None of these are PinDrift-specific; they apply to any iOS location tool on Windows.

1. USB controller bandwidth + enumeration timing

A typical desktop USB 3.x root hub provides 5 Gb/s of total bandwidth shared across everything plugged into it. Per-iPhone idle traffic (the tunnel keepalive + location injection) is on the order of a few kilobytes per second per device. Bandwidth itself isn't what breaks at high device counts.

Enumeration timing is. When you plug in a new USB device, Windows' kernel does a handshake: assign it a device instance ID, query its descriptors, load the right driver, fire off PnP notifications. This handshake takes a few hundred milliseconds and is single-threaded per root hub. With one iPhone plugged in, the handshake is invisible. With 8 iPhones plugged in within a few seconds of each other, Windows ends up serializing the handshakes; some get truncated; you see devices flap between "connected" and "not connected" in Device Manager for 10–30 seconds.

• Symptom: Devices that appeared briefly in Apple Devices' list disappear after a few seconds. PinDrift's Device tab shows phones popping in and out. The Apple Devices app may need a manual restart.
• Threshold: Variable but typically 8 iPhones on a single USB root hub, plugged in rapidly. Plugging them in with a 2-second beat between each fixes it up to ~12.
• Mitigation: A self-powered USB 3 hub with its own controller chipset routes a couple of phones through its own hub controller instead of all through the PC's root hub. Anker, Sabrent, and StarTech all make 7- and 10-port options around $30–$60.

2. wintun virtual network adapters

iOS 17+'s RemoteXPC tunnel uses wintun to create a virtual network adapter per iPhone. The tunnel runs over an IPv6 link-local address inside that adapter. wintun is excellent software, but it's not free of overhead.

Each wintun adapter adds:

• An entry in Windows' routing table
• An entry in netsh interface and Get-NetAdapter
• Per-adapter buffers in kernel memory
• Per-adapter ARP / NDP state

Windows supports hundreds of wintun adapters in theory. In practice, routing-table lookup time grows linearly with adapter count, and most users start to notice routing weirdness around 20 adapters per machine. Anything Internet-facing that needs to do a routing-table lookup (curl, Edge, your VPN client) gets a few extra milliseconds of latency per request once the table is large.

• Symptom: Network-heavy apps feel sluggish after 10+ phones are tunneled.
• Threshold: Soft, around 12–15 adapters. Hard ceiling much higher.
• Mitigation: Either tear down inactive tunnels (PinDrift does this automatically after 5 minutes of inactivity), or distribute phones across multiple PCs / PinDriftBoxes.

3. Apple Devices service lock contention

The Apple Devices Microsoft Store app installs a background service that handles the USB-side of every Apple device interaction. Internally that service has a per-device mutex that's held during certain operations: pairing, trust-prompt handling, lockdown handshake.

When 8+ iPhones are connecting at roughly the same time, multiple instances of those operations all want to enter the lock. Apple's service serializes them, but a couple of the queued operations time out before they get their turn. The symptom: a couple of phones end up in a "paired but not visible" state where PinDrift can't see them even though Apple Devices shows them as connected.

• Symptom: Phones disappear from PinDrift's Device tab while still showing as "connected" in Apple Devices.
• Threshold: Hits around 8 simultaneous fresh-pair operations. Already-paired phones reconnect cleanly even past that.
• Mitigation: Pair phones in batches of 4–5 with a 30-second beat between batches. Once a phone is paired, it can plug into the same PC any time without re-pairing. PinDrift's connection sequence already includes a backoff to reduce the chance of hitting this, but on cold-start fleet bring-up it's possible to trip it. Restart Apple Devices via Task Manager (kill AppleMobileDeviceProcess, it auto-restarts) if you see this; it clears the contention without losing pair state.

4. iOS 17+ RemoteXPC handshake latency

Pre-iOS 17, the spoof channel was the classic usbmuxd + DeveloperDiskImage mount, which is fast: about 200–400 ms per device to set up. Old iOS-spoofing tools could light up 20 phones at once.

iOS 17 replaced that with RemoteXPC over QUIC inside a tunneled IPv6 link. The handshake now involves:

1. The lockdown-protocol pair check (~200 ms)
2. Mounting the developer disk image (~400 ms, mostly Apple's pre-check)
3. Bringing up the wintun virtual adapter (~250 ms)
4. Negotiating the QUIC connection over the new adapter (~300 ms)
5. Subscribing to the location-injection service (~200 ms)

Total: roughly 1.5 seconds per device, serialized. PinDrift parallelizes these handshakes, but each phone needs Apple's lockdown protocol on the host side, which contends for the same lock from the previous section. Parallel handshakes share that lock until you hit ~6 concurrent attempts; beyond that, they serialize.

• Symptom: 10 phones plugged in at once take 15–25 seconds before all of them show as "tunnel up" in PinDrift's Device tab.
• Threshold: Annoying but not blocking past 6 simultaneous handshakes.
• Mitigation: Wait. PinDrift shows progress per device. A one-time slow startup beats a tool that hides the slowness behind a spinner and then claims a device is "ready" before it actually is.

5. Wireless mode scales differently

If you use wireless mode after a one-time USB pair, the scaling math changes completely. There's no USB controller bandwidth to share, no Apple Devices service lock contention (the service stays out of the way once the wireless tunnel is up), and per-device handshake latency stays the same as USB.

The new bottleneck becomes the Wi-Fi access point. Most home routers cap simultaneous clients at 32 (Eero, ASUS), 50 (UniFi consumer), or 64 (UniFi pro). Each tunneled iPhone counts as one client, plus your PC, plus everything else on your network. The math works out to:

• Home AP (32-client): ~20 phones comfortably
• Consumer mesh / Eero Pro (50-client): ~35 phones
• UniFi Pro / Aruba enterprise AP (64+ clients): 40–50 phones
• Dedicated SSID on enterprise AP (no other clients): close to the wireless protocol limit (~128)

Wireless mode also gracefully degrades. Drop a phone from the network and it can rejoin without re-pairing or restarting PinDrift; the tunnel re-establishes within a few seconds. Over USB, an enumeration glitch can require Apple Devices to be restarted.

What PinDrift's cap actually is

PinDrift is licensed for up to 10 phones spoofing at once on one active host PC. That's the contractual ceiling; what your hardware can actually do depends on the bottlenecks above. To go beyond 10, run PinDriftBox pods on the same network.

If you only need 10 or fewer phones simultaneously, a single host PC plus a $50 powered hub is the answer. That covers nearly every QA-team and personal use case we see.

When you need more than 10

If your use case genuinely needs more than 10 phones simultaneously, a mobile-app QA lab, a sales-demo farm running multiple time zones at once, an academic study with N subjects, the right architecture is PinDriftBox pods:

• One Pi (with a 4-port powered hub) drives a pod of 4–6 phones.
• Pods sit on the same network and are reachable from a central PinDrift controller (your desktop or another Pi).
• The controller's UI shows all phones across all pods as one unified device list. Apply / Stop / Route actions fan out to the pods, which fan out to their local phones.
• Network capacity becomes the new ceiling. A UniFi Pro AP and a small managed switch comfortably handle 50–75 phones across ~10 pods.

Diagnosing scaling problems

If you're seeing weirdness above ~5 phones, walk this checklist:

"Phones appear and disappear in Apple Devices"

USB enumeration race (limit #1). Plug phones in one at a time with a 2-second beat. If you're already doing that, switch to a powered hub with its own controller chipset.

"Apple Devices shows the phone as paired but PinDrift doesn't see it"

Apple Devices service lock contention (limit #3). Kill AppleMobileDeviceProcess in Task Manager (it auto-restarts), then plug phones in slower next time. PinDrift will re-pair them automatically once Apple Devices returns.

"It takes 30 seconds for all phones to come up"

iOS 17 RemoteXPC handshake latency (limit #4). Normal up to ~10 phones. PinDrift's Device tab shows per-phone progress; the slowness isn't a failure mode, just an unavoidable cost of Apple's tunnel design.

"My PC's internet feels slow after I tunnel a bunch of phones"

wintun routing-table size (limit #2). Either close PinDrift while doing other network-heavy work, or tear down phone tunnels you're not actively using (Disconnect button in the Device tab). PinDrift v0.2.1 will auto-tear-down idle tunnels after 5 minutes; until then it's manual.

"Phones drop in wireless mode but stay up over USB"

Your AP is hitting its client cap (limit #5). Either upgrade to an enterprise AP, or stay on USB for that segment of the fleet. You can mix and match: half the phones over USB, half over Wi-Fi.

Comparison: PinDrift vs the competition at scale

This is what changes when you push past 5 phones with each tool.

Last reviewed: May 2026. If you're running a fleet bigger than what this page describes and hitting walls we haven't documented, send the symptoms to the Contact us form. We add observations here.

All third-party tool, library, and product names on this page are trademarks of their respective owners and are used here only for accurate technical reference, consistent with nominative fair use.