I tested macOS 15.4 (24E248), Xcode Version 16.3 (16E140) - issue is here. UPD After a complete reinstallation Xcode, following the instructions provided by @podkovyr , the issue has been resolved!

Furthermore, we have devised another approach to addressing the LLDB problem. We have crafted a script that momentarily alters the mach_type of all frameworks to dynamic (where it's possible) for the purpose of debugging.

I have soultion: https://developer.apple.com/forums/thread/767051?answerId=819237022#819237022

I found a solution to provide metadata for all modules: Enable dSYM for Debug (note: this increases build time, even for incremental builds). Copy the necessary symlinks for the Swift modules from Derived Data to a temporary folder, e.g., /tmp/lldbmodules. Configure lldbinit locally in Xcode: customLLDBInitFile = "$(SRCROOT)/lldbinit" with the following option: settings set target.swift-module-search-paths /tmp/lldbmodules Kill the lldb-rpc-server process to ensure a clean state. Build and run.

Hi everyone! We have found that the issue is caused by static Swift frameworks. If we change the Mach-type to dynamic, most of the problems are solved. We also found a comment in the thread: https://forums.swift.org/t/unable-to-inspect-local-swift-variables-or-step-over-await-calls-in-xcode/62702/97 The comment says: "Static archives often do need some manual work in the build system since there is no channel to communicate the existence of a .swiftmodule to the linker". So, what can we do now? Should we move to the nearby libraries?

I found that adding OTHER_LDFLAGS=$(inherited) -Wl,-ld_classic to the build settings fixes errors with PCM files. Additionally, I turned off the ENABLE_DEBUG_DYLIB option. Also, I added the path for AST, as @artyom-stv-joom suggested. Now I can po self without errors. However, the first breakpoint still takes one or two minutes, so I cannot use these options as an effective solution because we cannot move to the old linker.

Also lldb-rpc-server "eats" a lot of RAM - 8GB and more...

I also have a lot of logs like this when app becomes paused by lldb: /Users/egormerkushev/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/23S4HX6OW8E8S/MyModule-2XYB5G9W7D2Z.pcm is out-of-date (hash mismatch). Type information from this module may be incomplete or inconsistent with the rest of the program. Rebuilding the project will regenerate the needed module files. When I try print something I get it: (lldb) po self 0x000000015d9de300 (lldb) po self.dismissGestureRecognizer error: type for self cannot be reconstructed: type for typename "$s5MyModule31FullscreenContentViewControllerCD" was not found (cached) error: Couldn't realize Swift AST type of self. Hint: using `v` to directly inspect variables and fields may still work.

Our team found working solution: Run in Terminal nano ~/.lldbinit Type and save: settings set target.experimental.swift-enable-cxx-interop false Restart lldb-rpc-server process

I think there is a bug in Xcode. Normally lldb can get symbols from binary with DWARF. dSYM is not required.

After spending several hours profiling lldb, I have identified the reason behind the high CPU usage and slow app launch and breakpoints. It turns out that a custom xcconfig file was disabling dSYM for the Debug build. However, once I restored the dSYM in the Derived Data Xcode, both lldb and our app started up quickly again.

Hello! We are currently working on a large project consisting of 3.97 million lines of code, with 1.3 million lines in Swift, 1.5 million lines in Objective-C, and several files in other languages. Our app's debug build size is over 700MB, while the main binary is 350MB. However, after updating to Xcode 15 (15.0.1, 15.1b1, 15.1b2), we have noticed a significant increase in build time, launch time, and debugger attaching time. It now takes approximately 1 minute from the installation completion to the app's start launching. Furthermore, the initial retrieval of variables on the first breakpoint also takes 1 minute or even longer. Could you please advise us on how to resolve this problem? Thank you