Unable to inspect local Swift variables or step over await calls in Xcode

Using Swift
,
109

The Xcode Swift debugging experience is one of the poorest I've ever had. I use JetBrains and Visual Studio daily alongside Xcode and it's shameful that Apple does not produce a better quality IDE in light of these others that have been capable of such an efficient developer experience as that have already for many, many years.

Does anyone know why Xcode editor does not hover-inspect instance fields but can hover over local variables? I have to then expand self and hunt for the variable in the list. I simply don't understand why this isn't possible. It's infuritating and wastes developer time trying to figure out the contents of an instance variable. There's a great deal more I could write but I won't bother.

I suppose it disappoints me that it seems like it will never get any better. Apple devotes time to AI code completion but no the efficiency and capability of the debugger?

7 Likes
110

This seems like a very good enhancement request to file via Feedback Assistant. For what it’s worth, I never use the locals window either; I just type p instanceVar in the debugger window. That might be a habit born out of switching to full-time Mac development almost 20 years ago, back when Xcode and its gdb integration were much more primitive.

Please do file feedback reports and share the numbers here. It’s always helpful to hear what people are missing most when they switch from Visual Studio.

Please don’t engage in the fallacy that any feature you don’t use came at the expense of a feature or design change you would have liked to see.

3 Likes
111

You're right. I guess I would have thought that with millions of developers and thousands of Apple's own developers (and the ones who build Xcode itself) who have to deal with these inefficiencies every single day for years on end in light of the industry alternatives, that tiny developers like me with nothing but a Feedback Assistant wouldn't have to complain and rant so often for years before anything is done. But maybe I'm just delusional! Haha.

For what's it's worth, I'll try to submit my feedback and hope for the best.

4 Likes
112

In other news, I do love Swift as a language. The if let existing = optional { } and its guard if let variant is one of my favourite things.

1 Like
113

I’d would attribute the “inefficiency” to your muscle memory reaching for a Visual Studio feature in a different IDE. Xcode has learned from other editing environments in the past—it gained vim mode a few years ago, which spares me the “inefficiency” of using the wrong shortcuts when I switch between editing code and commit messages. In this case, since Xcode already supports the feature you want on locals, it certainly isn’t helping retrain your muscle memory.

114

Different ways of doing things is fine. I have to context switch between Visual Studio, JetBrains PhpStorm and Xcode almost every day. Xcode simply fails to live up to the standards of these alternate IDEs in major ways. The debugger makes life slow and laborious. It requires much more manual interaction just to inspect variable contents. Hovering over local variables works, but why doesn’t instance variables in class methods while you’re debugging them? This just doesn’t make any sense. Why do I have to go searching in the watch list, expanding and expanding self.variable.somethingElse whenever I want to just look at a variable in the code editor that happens to be an instance field? This isn’t “doing things different”, this is “strangely missing?”.

I guess my point is that when you have to do this day in day out for years on end, debugging, refactoring and code editing efficiencies and capabilities such as what VS and JB give you make a huge difference over time.

I’m not the only person in the world who finds Xcode to be below the standard that 2024 sets for IDEs, especially from a company as enormous as Apple.

I’ll go and rant politely to the Feedback Assistant.

4 Likes
115

Thanks for filing, and please do share the feedback numbers here. I interact with many people who have been daily drivers of Visual Studio for many years, and I’m interested in learning where the pain points are when switching to Xcode. Often times, they've spent years accessing equivalent functionality through a different UI path.

1 Like
116

I submitted one regarding the hovering of variables, "Hovering in code editor is limited to top-level local variables only" - FB15245704

1 Like
117

I submitted one requesting the ability to disable animations that waste the user's time by blocking any input. Debug variable inspector and Rename Refactor animation being unnecessary. I use these functions significantly and waiting for animations is annoying as heck. FB15245818

P.S. I realised you can disable them in Accessibility but I don't want to do this for the entire system, just Xcode.

4 Likes
118

Thanks for encouraging me to submit ksluder. I suppose I gave up believing that my feedback would have any effect or ever be seen by anyone (maybe it will, maybe it won't!). I guess my main complaint is really with the debugger. The rest of Xcode I can generally work with fine.

4 Likes
119

I'd be much more satisfied if the existing features actually worked. They still don't in Xcode 16.

4 Likes
121

Specifically, the ability to step over and into await calls. FB10899199, FB12250088, FB10012674.

4 Likes
122

I realized shortly after asking that you were probably referring to the issues that started this thread.

1 Like
123

It (somewhat) worked in Xcode 15, but it seems completely broken in Xcode 16 again.

Stopping after the guard in something trivial like

        Task {
            do {
                for try await update in CLLocationUpdate.liveUpdates() {
                    guard let location = update.location else {
                        logger.debug("Can't gather location")
                        print("update: \(update)")
                        return
                    }
                    self.location = location
                    logger.debug("New location: \(location)")
                }
            } catch {
                logger.debug("Can't gather location: \(error)")
            }
        }

leads to an unhelpful debugger conversation like that:

(lldb) p update
error: type for self is invalid
error: Couldn't realize Swift AST type of self. Hint: using `v` to directly inspect variables and fields may still work.
(lldb) v update
(CoreLocation.CLLocationUpdate.Updates.Element) update = <Failed to dereference pointer from 0x18faed58 for DW_OP_deref: failed to send packet: 'x18faec00,200'

Ok, in this particular case I'm debugging watchOS (which probably is the most fragile platform to develop I've ever encountered in my 40 years of professional experience), so YMMV.

5 Likes
124

Can attest to having run into the exact issue you’re describing as well.

2 Likes
125

Did you find a solution? It's May 2025 and the ugly bug is still there :(
I opened a thread on the Apple's developer forum, got asked for a bug report with a reproducible case, filled one and never heard back from them. Another guy also reported a Feedback Assistant ID, so that makes at least two cases where they can test and fix it.

Maybe you can ping the Apple engineer that went silent here, I don't know what else to do LLDB error: type for self cannot b… | Apple Developer Forums.

2 Likes
126

It's useless, indeed. I've filled one too and never heard back. The latest beta 16.4 is still buggy.

127

A solution to which issue specifically?

In this thread, many people are posting about quite different problems, some of which share similar symptoms. Feel free to send me (privately or publicly) a project that reproduces a problem you would like get help with and I'm happy to take a look!
Without a reproducer or at least a healthcheck log describing a concrete problem it is very difficult to give advice. Because LLDB has global view of the entire application being debugged, details such as the OS the app is running on, the project setup and compiler flags often make a huge difference, so just posting source code fragments is often not enough to accurately diagnose an issue.

129

Adrian detailed above why "Just search for the symptoms" is unhelpful — reliable reproduction steps need to be very specific, and are tough to come by. In the absence of a specific repro case, it's effectively impossible to investigate the issue.

Any non-trivial project is going to have bugs in it, the presence of which is not an indication that the authors don't care. This is just rude, and has no place here. If you have a reliable repro case to share, please do share it; otherwise, this adds nothing to the conversation.

3 Likes
130

Yes, I filed a FB at the request of a DTS Engineer and passed the ID to him on March 25, about two months ago. Never heard back since. About a week ago, I asked him about it - no response. And of course, no response in the Feedback Assistant app either. Check the linked thread on the Apple Forums.

What else could I have done in these two months to get an answer? Should I have danced in front of Apple Park?

Another developer also submitted a FB on my thread three weeks ago and got no response either. What is this, if not a clear sign of not caring? Why does Apple even ask for feedback if they never respond?
Also, check this thread to see how widespread the LLDB bugs are when it comes to inspecting variables and properties: error: type for self cannot be rec… | Apple Developer Forums - I'm sure that Apple has received more than just those two FBs, so it’s not a matter of "tough to come by" test cases.

Complexity and bugs do not arise by themselves, it’s people who decide what goes in or not, in terms of LLDB features. I was delighted when I read about LLDB being able to run code and such, but those fancy features are useless if you can’t use the debugger to do its basic job. Some people shipped those features and maybe got a promotion, and we, the developers, are left to deal with the bugs.
Flag my response for deletion if you feel attacked, but the trust in Apple, its tools, and its philosophy won’t magically come back.

1 Like