Introduction

Many developers ran into very slow debugging in Xcode 11, especially in Swift-heavy projects. The slowdown was real, but it usually came from several interacting factors rather than one single switch or bug.

Why the debugger becomes slow

When Xcode stops at a breakpoint, LLDB is not just pausing the process. It also loads symbols, renders variable summaries, evaluates expressions, and tries to understand Swift types that may be heavily generic or nested.

That gets expensive quickly in large projects. The worst cases often include:

• many active breakpoints
• conditional breakpoint expressions
• large Swift modules and frameworks
• expensive variable inspection in the sidebar
• 'po and expression evaluation on complex values'

So the feeling of "the debugger is slow" is often a combination of stop-time overhead, LLDB expression work, and project size.

Start with debug-friendly build settings

A debug target should be compiled in a way that helps the debugger. If optimization creeps into the debug configuration, stepping and inspection can become much worse.

SWIFT_OPTIMIZATION_LEVEL = -Onone
GCC_OPTIMIZATION_LEVEL = 0
DEBUG_INFORMATION_FORMAT = dwarf

These settings do not guarantee a fast debugger, but they remove a common source of avoidable pain: trying to debug code built with settings that are hostile to source-level inspection.

Reduce expensive debugger work

In practice, many Xcode 11 slowdowns come from asking the debugger to do too much. Expanding huge objects, keeping dozens of breakpoints enabled, or running rich Swift expressions in the console can add noticeable delay.

A pragmatic debugging workflow is often faster:

• enable only the breakpoints you actually need
• avoid complex conditional breakpoints unless necessary
• inspect small values before large object graphs
• use lightweight logging when expression evaluation becomes painful

That may sound unsatisfying, but it is often the difference between a usable session and a stalled one.

Clean stale build state when behavior degrades

Some sluggish debugger behavior gets worse after upgrades, derived-data corruption, or project reconfiguration. Clearing derived data is a realistic troubleshooting step.

rm -rf ~/Library/Developer/Xcode/DerivedData

This is not a magic performance optimization. It is simply a good reset step when the debugger becomes abnormally slow for reasons that do not match the code change in front of you.

Swift projects are hit harder

Swift debugging can be especially expensive because the debugger tries to reconstruct rich type information and pretty-print values from advanced language features. Projects with deep generics, protocol-heavy designs, or very large app targets tend to expose the worst debugger latency.

That is why some teams saw Xcode 11 behave acceptably on tiny samples and painfully on real production apps. The scale and shape of the codebase matter.

Common Pitfalls

• Debugging optimized builds and expecting clean stepping and fast variable inspection.
• Leaving many conditional or action breakpoints enabled at once.
• Using heavy po and expression evaluation on large Swift object graphs by default.
• Ignoring stale DerivedData or build-state issues when the slowdown changes suddenly.
• Assuming every debugger slowdown has one root cause instead of a stack of LLDB, build, and project-size factors.

Summary

• Xcode 11 debugger slowness was a real issue for many Swift projects.
• The slowdown often came from LLDB expression evaluation, symbols, breakpoints, and project size together.
• Keep debug builds unoptimized and avoid making the debugger do unnecessary work.
• Clearing DerivedData is a sensible reset step when debugger behavior becomes abnormally bad.
• Large, generic Swift codebases are more likely to trigger painful debugging latency.