Apple Vision Pro support: wireless pairing + install over an RP tunnel

[rebelancap]

A Wi-Fi Apple Vision Pro isn't carried by usbmuxd, so it can't be reached through iloader's usbmux device path like an iPhone/iPad. This adds a parallel Vision Pro transport that reuses the RemotePairing (RSD) tunnel, alongside the completely unchanged iOS/iPad usbmux path.

What it does

• Discovers a Vision Pro over mDNS via a persistent background browser (_remotepairing-manual-pairing._tcp when unpaired, _remotepairing._tcp once paired — a paired VP stops advertising manual-pairing), and lists it next to usbmux devices.
• First-time pairs with the 6-digit code shown on the headset (Settings → General → Remote Devices) — no cable, dev strap, or Xcode.
• Reaches install services over the RP tunnel: pair-verify on RSD :49152 → TLS-PSK CDTunnel → software TCP stack → RSD handshake → installation_proxy/AFC. Signs with isideload (transport-agnostic) and installs over the tunnel, then places the RP pairing file into the app.

Structure

• src-tauri/src/vision.rs — the whole VP transport (new module).
• device.rs / sideload.rs / pairing.rs — branch on a new DeviceTransport{Usbmux,Vision} discriminator on DeviceInfo; the iOS/iPad usbmux path is untouched.
• Frontend (Device.tsx / App.tsx) — a Vision Pro device card and a "enter the code from your headset" modal.
• src-tauri/Info.plist — declares NSLocalNetworkUsageDescription + NSBonjourServices (required for mDNS multicast on macOS; without them a packaged build silently finds no devices).

Notes for review

• isideload is vendored in src-tauri/vendor/isideload as a stopgap: a VP registered under Apple's separate visionOS device platform makes isideload's ensure_device_registered hit "device already registered" (developer error 35); the tolerance for that is on isideload's git HEAD but not yet in a crates.io release. Once released, this reverts to a normal dependency.
• For a VP, the installers fetch the patched visionOS SideStore / LiveContainer builds (rebelancap forks), since the stock arm64 builds lack the visionOS fixes.
• Validated end-to-end on a real Apple Vision Pro (visionOS 27): wireless pair → install SideStore → sideload an app over Wi-Fi.

Companion visionOS patches live on the rebelancap SideStore + AltSign forks.

[barlarb]

This is amazing! Thank you so much for your work on this! I have now successfully installed Livecontainer and Sidestore and sideloaded apps on my Vision Pro. The only issue I've come across is I am unable to enable JIT despite having the pairing file. It says the Developer Disk Image is not mounted. Any suggestions you have would be really appreciated—and thank you again!

[rebelancap]

Glad it’s working for you. Check out my repo for ports for visionOS with SideStore sources! I’m working on several others yet to come.

I was not optimistic about JIT so I didn’t give it a real try. But I should take another look (well Claude Fable should - he’s doing the legwork here).

[barlarb]

Just had a look! Fantastic, thank you!
If you could (with Claude's help) I would be really grateful! I really hope to play PS2 games on it. Do you have a Ko-fi page or similar to support you?

[rebelancap]

@barlarb Unfortunately worked on this all afternoon, and visionOS 27 blocks every JIT attempt. Can mount the DDI, can attach a debugger, SideStore confirms CS_DEBUGGED, but visionOS blocks every attempt to actually execute JIT code. This is different than iOS. We can revisit in the future, perhaps when current OS is out of beta. But I'm not optimistic.

[barlarb]

Thank you for trying! Hopefully it can be figured out at some point, once OS27 is out, as you say. Finger's crossed! It feels a shame for Vision Pro to miss out on JIT. Thanks again for making sideloading such a breeze now! Really appreciate it.

[rebelancap]

Pushed an update fixing two bugs that surfaced once people started using this on macOS — the branch now matches the build my fork's users have confirmed working

1. The macOS Local Network permission prompt never appeared (iloader wasn't listed under System Settings ▸ Privacy & Security ▸ Local Network, so discovery silently found nothing). Root cause: macOS 15+ frequently fails to attribute an app's own multicast sockets (mdns_sd), so instead of prompting it silently drops the packets — user logs showed the multicast joins succeeding and then zero mDNS traffic for the whole session. Dev builds never reproduce it because terminal-launched processes get automatic local-network access (TN3179); only Finder-launched builds were affected. Discovery on macOS now goes through the system Bonjour daemon (async-dnssd → mDNSResponder), which is attributed correctly — verified on a clean macOS account that the prompt now appears and discovery works. Windows/Linux keep mdns-sd. Discovery-startup errors (e.g. permission denied) are now also surfaced in the device list's empty state, and the browse retries so toggling the permission on mid-session recovers without a relaunch.

2. The first "Tap to pair" always failed with missing server proof in SRP response (second attempt worked). Root cause is in idevice 0.1.65: when the device answers awaitingUserConsent it hardcodes PIN 000000 (an iPhone Trust-dialog assumption) — but a Vision Pro answers awaitingUserConsent whenever its pairing-code screen isn't up yet, then sends the SRP data once the code is displayed, so the first attempt could never succeed. I've vendored idevice with a one-branch patch (same pattern as the existingvendor/isideload) that routes that case to the pin callback; I'll file it upstream at jkcoxson/idevice and drop the vendor once a release carries it. Also added a silent retry when pairing fails before the user has been asked for a code, re-resolving the manual-pairing port each attempt (it rotates).