Yo Apple: Xcode debugging Swift is *STILL* horribly broken

I have a hard time clicking the “like” button for that, but sadly it resembles my experience as well.


I wish it was only every fall. But it's all the time. For what .. a year? longer?

po thing -- 10 seconds
p thing -- 10 seconds
v thing -- 10 seconds
frame v -- 3 minutes

so useless



Regardless of whether it is LLDB or Xcode - I'm genuinely baffled by how Apple has failed to fix debugging after years of having been broken.

It begs the question - how do Apple engineers writing modern Swift debug their code when something so fundamental is broken? Print-based debugging?


TDD, if your test passes then it's not broken. :face_with_peeking_eye: If you don't have have tests, it equals the same outcome: not broken. :sweat_smile:


Apple sent back one of my bugs on this issue (FB11236399) saying to test it against Xcode 14.2 beta. It is still just as broken as ever, which tells me Apple doesn't actually attempt to reproduce and test bugs in-house.

This has always been my experience. It's primary reason why I stopped sending bug reports; it was a waste of time.


Given this situation, isn’t there a way to escalate this to some senior Apple people? All the shiny WWDC material is useless when the state of the toolchain is as problematic as it is. We developers are what makes the ecosystem tick, where are the Apple managers taking care of this situation?

The toolchain needs at least two Snow Leopard cycles, if not more.


Imo it is remarkable how many people chime in this rant — in a forum which is the place for Swift-fanboys :joy:.
My expectation is that most who actually use Swift would be really happy to completely relinquish new features for some years in exchange for a better developer experience.
Especially with big additions like macros, I fear that those will make things even harder for the teams which are responsible for the tooling.


it would be surprising if people who do not use swift frequently were complaining about the developer experience, you have to use a technology a lot to be able to identify issues with that technology.

but i agree with the sentiments of this thread. i would add that life is not particularly great in the linux/vscode world either, because i imagine many of these issues are not XCode issues, but upstream sourcekit-lsp issues, or even compiler issues.

my personal wishlist:

  1. symbolicated crash dumps on linux. for many years, we have not even been able to symbolicate crash dumps on linux without adding 3rd party dependencies or having the python script on hand.
  2. debugging SPM targets that use custom build flags. this is really difficult right now, because it requires fiddling with global settings; it is not associated with a particular package manifest.
  3. "find all references" that reports an error when the SKLSP index has not been built yet, instead of falsely returning "no references".
  4. SKLSP indexing that can invalidate its cache when files are deleted or renamed, instead of forwarding you to filepaths that do not exist.
  5. code completion that doesn’t unconditionally prepend the module namespace to every symbol. aside from being annoying, this generates invalid code when you have a module that contains a type of the same name.

I actually feel like the general tone of these forums is fairly negative. I've certainly noticed that my posts here tend to be harsher than my actual feelings on the language because outside of pitches and proposals that need a +1 there's rarely a reason to post about the good things, and instead I find myself only posting about the things I don't like. I assume that's true as well for the other people who seem to only ever post complaints.


yes, that is my assessment as well. on the other hand, i was only drawn to comment on this thread because i myself am also currently resorting to debugging with print statements, on VSCode, because something is wrong with reflection on the 5.8 toolchain branch.

codelldb: /home/build-user/swift/stdlib/public/RemoteInspection/TypeLowering.cpp:747: swift::reflection::BitMask::BitMask(unsigned int, const uint8_t *, unsigned int, unsigned int): Assertion `initialValueEnd <= sizeInBytes' failed.
Received signal: SIGABRT

it seems to happen when debugging anything in an actor-isolated context, but unfortunately i have not had time to reduce a crash case.

To be sure: I absolutely love Swift. I'm just aggravated at Apple’s (and yes, it's really Apple who's responsible for all of this) apparent inability or disdain for the tools and developers that have helped make it so obscenely wealthy. I pay $99/yr (for many years) and sell paid apps in the app store. I write Feedback on a weekly basis. From my perspective, Apple has no excuse for the state of these tools.

Metrowerks CodeWarrior worked so much better than Xcode. I've seen tools on Windows work even better than that. I've seen code editors that were far superior at code completion, able to work in spite of syntax errors and incomplete expressions (even perfectly compiled Swift code rarely has perfect code completion). It just boggles my mind how bad it is.

And yes, Apple needs to have more engineers just fixing issues, rather than working on new features. I do appreciate the improvements in Swift (and SwiftUI), but I don't think Apple has made good decisions with the constant re-skinning of the macOS and iOS UIs.


I don't think it's that remarkable. I think many people agree with your sentiment and it's the undercurrent felt in the community outside of some of the hyper positive influencers—they spent years shoveling feature after feature on top of the core language, before spending the time to ensure the tools for the core language were widely stable and performant. What we have now is a kitchen-sink language with every imaginable feature (and more coming!) that still suffers from major tooling and stability issues.

It feels very much like a move fast (at adding features) and break things (like performant and stable code editing, compiling, and debugging) kind of mentality. If you were around for Swift 1-3 it felt even more-so that way back then. And personally, that's not how I want a programming language to evolve and has been a major turn off for me.


It's almost as if there's a broken underlying socioeconomic system, that we should be collaborating on fixing, which otherwise will be surreptitiously built into "Swift evolution", any mention of which is missing from the mission statement of the language. :money_mouth_face:


Yes, It‘s really a pity. I grew accustomed to the fact that the cross platform story woes and that swift-corelibs-foundation violates its mission statement without much resistance, but that the stability of the tools on the PRIMARY platform is so bad is astounding to me. Especially given where we come from. The state of the union 10 years ago was in many aspects much better. And that‘s not just sad for Swift, the language, and its developers, it will inevitably have an impact on the whole ecosystem, if the ones in power can not be convinced to change directions.


I spotted the memory gauge going upwards… perhaps I have a leak. Let's check memory debugger:

Bildschirm­foto 2023-03-17 um 15.58.14

Ok, no worky. How about instruments?

Bildschirm­foto 2023-03-17 um 16.27.29

Ok, everything broken. Guess that means knocking-off time for today.


Yeah, these are always fun. You can see some bit of tooling working properly (memory gauge, local variable list, etc) but when you try to interact with a slightly different bit of tooling it doesn't work at all. I assume you didn't have any other documents open in Instruments?

1 Like

Yes, nothing else open in Instruments. And this time the usual dance of restarting all things, erasing DerivedData, etc. didn't fix the memory graph debugger either.

In case it’s with swiftpm:

Thank you, I must have overlooked this thread. It's indeed a SwiftPM project. FB12064838 can be closed as a dupe then…

1 Like