Filed Feedback FB13198191. More observations that might help to narrow down the issue: Using Instruments to start the app, it runs smoothly, and the app remains responsive with or without cable; at least, I cannot tell the difference easily. (can somebody else try this as well?) Using Xcode to start the app in iOS 17.0.2, the following are observed: If Wi-Fi is enabled, the app is slow at everything: lanching, response to touch, and debugging; it doesn't seem to care if I connect the cable or not Bonus: if I unplug the cable during debugging, Xcode debugging is not disconnected (fail safe or was never going through the cable in the first place?) If Wi-Fi is disabled and the cable is plugged in, the app is almost as responsive as it is in the instrument, and debugging is very fast as well Using Xcode to start the app in iOS 16.7 (make sure to turn on Network debug), the following are observed: If the cable is plugged in, debugging is very fast. If the cable is unplugged during debugging, Xcode will disconnect from the device If the cable is not plugged in, debugging is very slow. You can plug the cable in during debugging, but the app will still be unresponsive since it does not hot-swap the debug section to the cable connection

Just tried it on Xcode 15.1 Beta 3 (15C5059c) and iOS 17.1.1 (21B91), can confirm this is still an issue. Let's strap in and be prepared to deal with this for quite a long time. Meanwhile, I want to offer a workaround that works for me 100% of the time, although judging by what we have been seeing in this thread, no workaround posted so far works for 100% of the people 100% of the time. Background of my workaround: I noticed that when Xcode 15 and iOS 17 work together, they are pretty persistent in using the network as the debug method; as @eskimo said, the cable should be considered a virtual network, but in practice, Xcode 15 always prioritize my Wi-Fi The persistency is so prevalent, to the point that even when I turn off all networks on my iOS device, Xcode still tries to hunt the iOS device down over Wi-Fi Continuing from point 2, I found the only way to guide the stubborn Xcode to reconsider how it should connect to iOS is to quit Xcode and start it from scratch Steps to workaround: Start your regular debug session with a cable plugged in. Hopefully, a new version of Xcode already works for you without issue If it doesn't work, take your iOS device off the network and start debugging again. This can be turning off Wi-Fi, entering airplane mode, etc. When step 2 fails, quit Xcode completely, restart Xcode, and start debugging. We are leveraging Xcode's stubbornness to our advantage in this step; it should be trying a cable connection relentlessly now If your device has a backup network, such as cellular, it should be working now, and you can feel free to turn your network back on. If your device does not have a backup network, it will display an error message saying you need to connect to the internet to authorize the App, move to the next step If your device does not have a backup network, e.g. a Wi-Fi-only iPad, make sure you see an error message complaining about network authentication when trying previous steps; once you see the error message, you will know for sure that Xcode is trying to debug over the cable. You can safely turn the Wi-Fi back on and continue your debug session. More data points for Apple debugging this issue: In my setup, I connect my MacBook to a HP TB Dock G2 (https://support.hp.com/us-en/product/details/hp-thunderbolt-dock-g2-with-combo-cable/21816261), my iOS devices does not connect to my mac directly, they connect to it via the dock.

I think this is a bug in xcrun 67 (you can check it by running xcrun 68), it seems to fixed with xcrun 68. At the moment of writing xcrun 68 is not available from App Store yet, you can: Get it from developer website by downloading Xcode 15.3 beta. Once unzipped and the beta is in the Application folder, run the following command so xcode-select points to the Developer beta sudo xcode-select -s /Applications/Xcode-beta.app/Contents/Developer Run "xcrun --version" to check the version number of xcrun, it should say "xcrun version 68." now Now you can clear the status_bar of the running simulator by running: xcrun simctl status_bar Booted clear Set the status_bar by running something like below: xcrun simctl status_bar Booted override --time "9:41" --cellularBars 4

Same issue, newest public release of iOS18 FB15747195

I can confirm that it is still an issue; bump the visibility. FB15747195