Highlights
🐛 The Wi-Fi tunnel for iOS 17.0-17.3 now targets the device you asked for
On a device without CoreDeviceProxy, --userspace falls back to RemotePairing over bonjour. That lookup ran unnamed whenever a single device was attached and no --udid was given, so every paired device on the network was contacted and the first answer won — after identifying a device over USB, the tunnel could be built against a different phone, and the services that lost the race were opened and never closed. It also always sat out the whole bonjour window.
The lookup now asks for the device the lockdown handshake already named, so exactly one service is built and the browse stops at it. An explicit --udid still wins.
Only affects the pre-17.4 RemotePairing path under an explicit --userspace; the default tunnel chain, and macOS's native route, never reach it.
📚 Windows: install the iTunes package that can see Wi-Fi devices
The installation page sent Windows users to the Microsoft Store listing, which is the "Apple Devices" app. Its Apple Mobile Device Service does not discover devices over Wi-Fi, so an uncabled device never appears in pymobiledevice3 usbmux list even after lockdown wifi-connections on. The page now points at the classic installer, matching what the troubleshooting and iOS 17+ tunnel guides already said.
# https://www.apple.com/itunes/download/win64
pymobiledevice3 usbmux listWhat's Changed
- a530399 userspace_tunnel: Ask RemotePairing for the device we handshook with (#1982) (@doronz88)
- 3d327c8 docs: Recommend the iTunes package that can see Wi-Fi devices on Windows (#1981) (@doronz88)
Full Changelog: v11.17.1...v11.17.2