Post

Replies

Boosts

Views

Activity

Reply to Debug from a remote location
Quinn's outline above (a Bonjour bridge between the two networks) is the right direction. For anyone landing here now, it's worth being specific about why a plain VPN on its own doesn't get you there, especially since iOS 17 / Xcode 15. Wireless debugging is no longer "talk to lockdownd on a known port". CoreDevice discovers the phone over Bonjour/mDNS on the local network, and the remote pairing connection is scoped to the interface it was discovered on. A routed VPN gives you unicast reachability (the Mac can ping the phone's VPN address), but it doesn't carry link-local multicast, so Xcode never sees a service record for the device and reports it as unavailable. Reachability without discovery is the gap. Simpler options first. If the device can be where the Mac is, use a cable or the same LAN. If you only need to get a build onto the device and don't need the debugger, TestFlight avoids the problem entirely. If the device has to stay remote and the Mac has to stay put, the bridge Quinn describes does work in practice: register the device's service on the Mac's side and relay the pairing and tunnel traffic to the address the VPN gives the phone. I ended up packaging that as a Mac menu-bar app, Nuticast (disclosure: I'm the developer). You pair once on the same Wi-Fi; after that it keeps the device visible in Xcode over Tailscale, ZeroTier or Netbird. Limits: the phone has to be on Wi-Fi at the far end (cellular doesn't work), and both ends need to be on the same mesh VPN. https://www.nuticast.com One caveat for the original question: iOS runs one VPN configuration at a time, so if the thing you're debugging is your own Network Extension VPN, a mesh VPN on the phone can't be active at the same moment. This helps for everything except the sessions where your own tunnel has to be up.
11h
Reply to Debug from a remote location
Quinn's outline above (a Bonjour bridge between the two networks) is the right direction. For anyone landing here now, it's worth being specific about why a plain VPN on its own doesn't get you there, especially since iOS 17 / Xcode 15. Wireless debugging is no longer "talk to lockdownd on a known port". CoreDevice discovers the phone over Bonjour/mDNS on the local network, and the remote pairing connection is scoped to the interface it was discovered on. A routed VPN gives you unicast reachability (the Mac can ping the phone's VPN address), but it doesn't carry link-local multicast, so Xcode never sees a service record for the device and reports it as unavailable. Reachability without discovery is the gap. Simpler options first. If the device can be where the Mac is, use a cable or the same LAN. If you only need to get a build onto the device and don't need the debugger, TestFlight avoids the problem entirely. If the device has to stay remote and the Mac has to stay put, the bridge Quinn describes does work in practice: register the device's service on the Mac's side and relay the pairing and tunnel traffic to the address the VPN gives the phone. I ended up packaging that as a Mac menu-bar app, Nuticast (disclosure: I'm the developer). You pair once on the same Wi-Fi; after that it keeps the device visible in Xcode over Tailscale, ZeroTier or Netbird. Limits: the phone has to be on Wi-Fi at the far end (cellular doesn't work), and both ends need to be on the same mesh VPN. https://www.nuticast.com One caveat for the original question: iOS runs one VPN configuration at a time, so if the thing you're debugging is your own Network Extension VPN, a mesh VPN on the phone can't be active at the same moment. This helps for everything except the sessions where your own tunnel has to be up.
Replies
Boosts
Views
Activity
11h