You Cannot Just Plug an iPhone Into a Remote Mac for Xcode

The usual assumption is that a remote desktop session moves the whole development setup onto your laptop. It moves the screen, the keyboard and the mouse, and nothing else. The iPhone has to reach the Mac that runs Xcode, and that is a separate connection with its own trust, transport and permission requirements. Everything below follows from that split, and the split is where most failed setups lose an afternoon.

The myth: remote control moves the device too

Remote desktop software forwards a display and an input stream, and on a good connection it feels as though the Mac is sitting in front of you. What it does not forward is USB, and it does not place the phone on the Mac network either. The session ends at the Mac desktop, where Xcode then has to find a device by its own rules. Assuming the phone travels with the pixels is the most common mistake in this arrangement.

The two connections are independent, and one can be perfect while the other does not exist at all. Repairing the desktop session tells you nothing about the device path.

Decide where the phone physically is before you configure anything

If the phone stays next to the Mac, do the ordinary local setup there: trust the computer, enable developer mode on the device, and confirm that Xcode builds and runs to it while you are sitting in front of the machine. Remote desktop then controls a workflow that already works. That is the cheapest arrangement and the one to prefer whenever the hardware allows it.

If the phone travels with you and the Mac stays in the office, the Mac needs a supported path to that device. A VPN supplies a network route between the two ends and supplies nothing else: pairing, developer mode, signing identity and device registration all remain separate requirements. Treat the tunnel as one layer in a stack rather than as the connection itself.

Write down which of those two arrangements you are in. Every later check depends on it, and mixing them up produces fixes that cannot work.

Treat discovery and transport as two different problems

Xcode finds paired wireless devices through Bonjour on the local network, and it can also reach a device at a known address through Connect via IP Address. Those are two mechanisms with two different failure modes. A device that never appears in the list and a device that appears but refuses to attach are not the same symptom, even though both read as a missing phone.

Browse for the advertisement before changing anything: dns-sd -B _apple-mobdev2._tcp lists the service a paired phone publishes on the local link. If nothing appears, discovery is the broken layer and an address-based connection is the only route left. If the service appears but Xcode still cannot attach, discovery works and the transport or the trust relationship is what fails.

The Apple wireless-device help covers both the same-network requirement and the address workflow, so read it against your installed versions instead of following a menu path remembered from an older release. Menu labels move between Xcode releases even when the mechanism underneath does not.

Check what the Mac can see from where it sits

Run the enumeration on the Mac rather than on your laptop, because the Mac is the machine that needs the device. xcrun devicectl list devices prints the devices Xcode can reach, and system_profiler SPUSBDataType shows what is physically attached. A phone that appears in the second list but not the first is attached and not paired, which is a trust problem rather than a network problem.

xcrun devicectl list devices
system_profiler SPUSBDataType | grep -i iphone
xcrun devicectl device info DEVICE_UDID

If the device sits on another subnet, confirm the Mac can reach the address the phone publishes, and remember that link-local IPv6 addresses are scoped to one link and are not routable across a tunnel. That is why a VPN alone rarely makes a remote phone appear: the address the device advertises is only meaningful on its own segment.

The Apple technote TN3158 states that from version 15 onward Xcode talks to a cabled device across a network interface built on link-local IPv6, so local filtering can interfere even with a phone that is physically plugged in. Escalate that case to whoever owns the filtering policy rather than disabling it yourself.

Prove it with a build, not with a device icon

A device entry in a list, a green indicator in the toolbar or a successful pairing prompt are intermediate observations. The workflow is proven when Xcode installs a permitted build and the debugger attaches to a process running on the device.

Run the full sequence from the Mac. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app installs without the IDE, which separates an Xcode interface problem from a device-path problem. Then launch the app and attach a console to it. If the command line install works and the IDE does not, the remaining fault is in the scheme or the signing configuration rather than the network.

Keep the arrangement narrow: one authorized developer, one registered Mac, one device, and access that ends when the session ends. Revoke credentials when the arrangement stops. If the phone can simply stay beside the Mac, choose that instead, because the simplest supported path is the one with the fewest layers left to debug.