Fan has run Android cluster control for three years. This year he connected iOS for the first time.
Wednesday afternoon he plugged an iPhone 13 in at his desk, waited ten minutes, and the console device list was still empty. He unplugged and replugged, tried another USB port, and restarted the console once. In the end he sent me a screenshot and asked whether the computer was the problem.
I asked him two things: which console version, and which iOS on the phone.
He said the console was the 10.6 build, and the phone was iOS 17.4.
The computer was fine. The version was too old.
Version gates
USB HID has two hard lines. Caught on either one, further fiddling does not help.
The console has to be 10.7.0 or above. The USB-HID function module arrives in that version. Older consoles do not have that switch at all.
The phone has to be iOS 17 or above. Below 17 this route does not work. Keep going with the proxy IPA path.
After Fan upgraded to 10.7.0, that iPhone showed up in the device list on its own. Under two minutes.
The two links are mutually exclusive, and only on the same device: the same machine and the same script can use proxy automation or direct cable, and only one of them. Do not mix them in one script. If you have forty devices, thirty on cable and ten older ones still on proxy, the console can see both sides. That is not a conflict.
Scene mode has to be chosen first too. In the screencast client, open System Settings → Scene Mode.
Two of the modes involve HID. No-automation screenshot plus USB_HID: nothing installed on the phone, USB connected, and that is it. The simplest one. Main program recording plus USB_HID: the picture is smoother, but the offline main program IPA has to be installed. On start it grabs one frame first, then opens the main program and pops the livestream window. You tap Start Broadcast.
For a first connection, pick the first one. Fewer variables, and when something breaks it is easier to locate.
The developer image has to be redone after every restart
The image is easy to misread as something installed on the phone.
It is a file on the console side. It is not installed on the phone. It sits under {console install directory}\bridgebin\config\DeveloperDiskImage\. Each subfolder is named for a version number, such as 26.5 or 27.0.
Whether it went in is checked by clicking the Developer Image button in the console and reading the status. Only a status of flashed counts.
This step has two traps, and they are what stop nearly everyone.
After the phone restarts, the image is invalid and has to be flashed again. Fan told me later that the first time he got it working he was pleased, rebooted the phone the next morning, and then found it would not connect. He thought yesterday’s config had not been saved, and spent the morning checking from the start.
A new system version has no matching image. Say the phone in your hand is on 27.0 and the directory only has 26.5: copy the 26.5 folder, rename it to 27.0, restart the console and the phone, then come back and check the flash status.
One more thing to do while you are there: phones on iOS 16 and above need Developer Mode on, under Settings → Privacy & Security → Developer Mode, then the restart it prompts for. Below 16 there is no such option. Do not go looking for it.
The phones I have handled myself cluster at 17.4 and up. In the 17.0 to 17.2 range I have only touched two or three. I would not claim those few cover the whole range. If what you see does not match, go with the phone in your hand.
As for Trust This Computer on the phone, it pops up the first time you plug in. Tap it once. Unplugging, replugging, and changing ports after that do not bring it back. What you have to redo is the image. Trust, once tapped, stays.
If the cable is in, trust is tapped, and the console still cannot see the device, walk the order for a phone that will not connect. That is faster.
After it connects, check these two before writing a script
Do not write a script to test whether the link is up.
Click once on the screencast picture with the mouse and see whether the phone responds. If the tap does nothing, do not suspect the script yet. On the device thumbnail or in the device list, right-click → USB HID → Rebuild USBHID session, then try again. That step recovers most cases where the picture is there and taps do not land.
Then grab one frame and see whether the screenshot comes through. No-automation screenshot is a slow mode. A frame takes a while. If you want it smooth, switch to the main program recording tier. The price is installing the main program on the phone.
Once both pass, write the script.
A script error and a link that is not up look the same. You can spend an afternoon on coordinates and waits, and then find the image was never flashed.
How to measure coordinates, why a wait can only wait for time, and how a failure retries are covered on their own in script basics. Once the phones reach scale, cables and hubs become the new bottleneck. That layer is in choosing cables.