It’s a cheap shot to complain about developer tools — and Xcode overall is great! — but something is seriously wrong in Xcode debugging in recent years. Feels like I can reload an entire React Native app’s JavaScript faster than I can view simple variables when stepping through Swift or Objective-C.

Heath Borders

@manton genuine question: what other developer tools have you used as much as Xcode?

deeje

@manton wired or wireless? For me, plugging in is not enough, I have to disable WiFi!

Manton Reece

@heathborders Nothing as much as Xcode. These days the only other tools I use for coding are Nova and Android Studio. Going back decades, I’ve used all the old Mac stuff (THINK Pascal, Symantec C++, CodeWarrior…) and they were relatively zippy.

Manton Reece

@deeje Usually wired. That’s interesting that just having wi-fi enabled may matter. I’ll check that!

Mitch Winn

@manton before I worked full time in Xcode I used to be a C# developer and couldn’t believe how slow Xcode debugging was compared to visual studio.

Patrick McConnell

@manton this presumes the debugger will even show you the variable. So many times it just says nope

Tom #8215 Boston Marathon

@manton bring back CodeWarrior!

Havn.blog (Erlend)

If you want “zippy”, I’d take a look at Zed! 🙂

(It’s just a text editor, though - I know it’s not the same! But you know, Fast Software, the Best Software. 😎)

Constantin Jacob

@manton @deeje there is a bug in Xcode in which it will use the wireless connection even if you're plugged into USB.
Disable WiFi on your phone, build & run to the device and things will be speedy again

Jason Molenda

@manton If you'd like to pursue a feedback report with apple, I'd enable packet logging between the mac & device by putting `log enable -T -f /tmp/log.txt gdb-remote packets` in `~/.lldbinit`, start debugging, step once or twice, then in Xcode debug console do `swift-healthcheck`, attach /tmp/log.txt and the records from swift-healthcheck to the feedback report. That's a good first cut for measuring where the time might be spent.

Jason Molenda

@manton The first time the debugger does something - an expression, looking at the locals in a stack frame - there may be startup work being done, so it's important to distinguish between the first and second time something is done in a debug session. Not that a slow first-time is acceptable, but it points to a problem of a different nature than slow-every-time.

Jason Molenda

@manton idk anything about comm layer but if you do find that a hardwired device is slow, then you disable wifi and it becomes faster, I don't think that's expected and it would be valuable feedback. That packet log with timestamps would make it easy to see the difference in comm times, even if the channel used is opaque at this layer.

Jason Molenda

@manton the feedback may come back asking for more specific details / logs, but that's a good first cut towards understanding what type of issue this might be.

Manton Reece @manton
Lightbox Image