Xcode 15.3 device connection issues

This thread is for discussing device connection issues in Xcode 15.3 and later. For the backstory, see the Apple Recommended answer on the original thread.

IMPORTANT My goal here is to separate the post-TN3158 discussion from all the earlier stuff. If you haven’t read TN3158, read it before posting here.

Obviously this is a critical issue for many folks but, please, let’s keep this professional. If in doubt, review the Apple Developer Forums Agreement before you post. There’s also the main DevForums page, Apple Developer > Support > Developer Forums, and Quinn’s Top Ten DevForums Tips.

If you work through the process in TN3158 and continue to have problems, please file a bug. Use the instructions I posted here. Also, make sure that your bug explains how you set up the isolated test environment that’s central to the process described in TN3158.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

FB13683931

Come on now, this can't be your solution...

We have to setup clean secondary Macs to test this?

And the following is just icing on the cake:

If your VPN product or security configuration uses PF to filter network packets, update your PF rules to allow traffic on the network interfaces Xcode uses for device communication. These rules need to be continuously updated, as the network interfaces Xcode uses to communicate with a connected device changes over time.

To monitor for network interface changes, use NWPathMonitor, or create a nw_path_monitor_t through nw_path_monitor_create(). Each time the path monitor notifies you that the network interfaces changed, use ioctl with a SIOCGIFDIRECTLINK request to identify the multiple network interfaces Xcode uses for device connection traffic. The system marks these interfaces with the ifr_is_directlink flag. Configure your PF rules to allow any IPv6 traffic on interfaces marked with this flag through the filter.

Can someone translate this?

I used to be able to use Xcode with physical devices attached while on VPN with no problems. Now I have to do all these crazy experiments?

We have to setup clean secondary Macs to test this?

If you only have access to a single Mac, one option is to install a clean macOS on an external drive. This doesn’t have to be anything fancy. I have a selection of USB thumb drives that I use for this purpose. They’re not fast, but they’re fast enough for this sort of testing.

Beyond that, TN3158 speaks to a number of audiences:

  • App developers working independently

  • App developers working in a managed organisation

  • IT admins in a managed organisation

  • Developers building VPN products

How would you characterise your situation?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I've filed FB13683931 with all my logs.

As discussed in that Feedback, my problem seems simply to be that Xcode is "sticky" with its selection of interface.

If Xcode sees my iPad over WiFi, first (the common case since WiFi is always on but cable is not always connected) it will establish debugging over WiFi. It will continue to use WiFi for debugging even if USB has subsequently connected and the devices list is no longer showing the WiFi "globe" icon. It never seems to switch unless forced.

As a workaround for this problem, I can disable WiFi, start debugging (forcing Xcode onto USB) and subsequently re-enable WiFi. Due to the apparently sticky nature, Xcode will stay on USB for some time (when my computer next goes to sleep, all bets are off).

As a followup, I should note: it's definitely not a network availability or routing issue. I can ping the iPad over the USB connection. And Xcode itself is discovering the USB connection (as indicated by it removing the "globe" icon). The problem is that Xcode isn't moving debugging over to USB unless forced.

10

I came to the same thing as @mattgallagher independently. For me it was extremely slow to debug. Step over took up to 10 seconds as well as loading current variables.

So, after some investigation, I realised that Xcode, after it first discovered your device by WiFi, continue use WiFi even if it's connected by cable.

Solution which worked for me:

  1. Unpair device in the "Device and Simulators" window. Connect usb cable to device. Start debugging.

You have to repeat this every time after you disconnect the cable.

  1. Go to airplane mode on device. Connect the cable. Switch off the airplane mode. Start debugging.

You have to repeat this every time after you disconnect the cable.

Same observation as Matt's above, which is once it starts using Wi-Fi, it is not switching to USB, even though Xcode explicitly asked me to connect iPhone with USB in order to enable debugging. Environment: M3 MacBook Pro, iPhone 13 Pro, both on Wi-Fi, no ethernet, no VPN, nothing fancy.

Step 1:

  • Connect iPhone via USB cable to Xcode, pair;
  • Xcode starts copying symbols. At a rate of about 3% in 3 minutes or slower. !!!

Step 2:

  • Turn on Airplane mode on the iPhone;
  • Xcode re-starts downloading symbols from scratch, but now at a rate of 100% in 3 minutes. !!!

Hope this helps.

@eskimo Please advise your fellow engineers to roll this whole thing back, or give us an option to disable debugging over network altogether.

This has obviously been a huge mistake and can't easily be fixed (we're on Xcode 15.3!) and it's still not working.

Too much time has already been wasted.

This won't work for everyone, but I've had success simply turning off my computer Wi-Fi while my device still has internet access. (Be sure it is not being used as a hotspot!) For me, this forces access via USB cable and debugging is fast again.

I have had the same problem since the Xcode 15 betas last summer. Network debugging is a beautiful idea, but in practice there are too many variables, and for some of us it's not an option. Eg we are required to use VPNs which route everything and don't allow local traffic, or other network configurations that get in the way. Network environments are just too varied for a one-size-fits-all approach.

I agree with those calling to revert this to the prior opt-in requirement for network debugging. And Xcode should prefer a usb connection if both are available. (We've indicated a preference by going to the trouble of plugging the thing in.)

As a workaround, I have to disconnect the device from usb, then pull down control center on the device and disable wifi. Then plug in the device and Xcode connects over usb. Then I can reenable wifi. Repeat ad nauseam multiple times a day.

In our case, we need to debug while iPhone is connected to the network for some realtime streaming communications. It's insane that debugging is accidentally coerced to go over wifi, which congests the connection that we need to test on. So turning off the network (Airplane), connecting the debugger, and turning on network, is a very cumbersome workflow.

Xcode 15.3 debug behaviour is definitely a regression in this regard.

This fixed one device for me:

  1. Turn off Mac WiFi
  2. Put your iPhone in Airplane Mode
  3. From XCode Devices&Simulators > Devices: Forget all devices
  4. Click + to open Choose a connected device to set up dialog
  5. Connect your iPhone via USB
  6. Click Okay when asked if you trust the computer (and enter password)
  7. Select device and press the Next button
  8. Wait for it to sync the cached symbols.
  9. Verify that the device shows up in the Connected list
  10. Turn on Mac WiFi
  11. Turn off Airplane Mode

After this, I was also able to sync another phone just by pulling it back into the computer via USB, trusting, and waiting for cached symbols.

Prior to this, I spent hours trying all sorts of combinations. I guess killing wifi as the silver bullet in my case.

I know some of developers already provided enough input and logs for this issue. However I want to highlight that even with great WiFi connection and good speed this connection over WiFi makes debugging big projects slow and therefore leads to poor developer experience that me and my colleagues struggle with. I understand that intention for this feature was good, but in this case I would be really happy if you kill this feature or make it fully controllable. Thank you for understanding.

Just trying to add another name to the list. The project I work on is quite large and this has made debugging a joke. I need to be connected to net for my app so most of the solutions mentioned does not help. Interestingly I don't face this issue on my iPad when connected to VPN since I am able to toggle off the connect via network toggle. Please just provide a way to turn that toggle off

I have filed FB14957989 with logs and reproduce steps, also tried workarounds from TN3158 and your response on 771548022.

But it seems like these workaround was mainly for developers who need cable connection instead of 'wifi build'

As the only iOS engineer in our team, I need to debug our MFi accessories via network, but it's seems like there's no workaround for wifi connect build for iOS 17.2 device.

I believe most of us just want debugging to be usable. It is usable over usb, but it isn't over wifi. Simple as that. Nothing to do with VPN's.

Testing my most recent app, with wifi enabled it takes 57 seconds from reaching a breakpoint to finishing loading variables. Same operation with wifi disabled takes less than 2 seconds.

Ideally I would like to connect to my device over wifi without this enormous time penalty. If that's not possible, I would like to be able to set usb as my default connection without having to use the workarounds above. Unreasonable?

Xcode 15.3 device connection issues
 
 
Q