App Startup with Debugger in Xcode 26 is slow

Is this limited to when the debugger is attached? You can check on that by going to your scheme settings, looking at the Run tab, and unchecking Debug Executable.

— Ed Ford,  DTS Engineer

Please help... I think my debugger is scanning all of the disk operations that I am doing...

When you launch your app with the debugger attached, one of the tasks that LLDB needs to do is load debug information for all of the libraries in your app. Those libraries have two sources, those coming from the system, and those that you're integrating as part of your app. If the system doesn't find a copy of this information on disk, it reads the information out of memory instead, which can be slow. This is one potential theory for the long delay you're experiencing.

To figure out if that theory is right, please load your app once with the debugger attached, and let it complete. Once the initial launch is finished, pause the debugger, and run image list in the LLDB console. This will print every binary loaded in the process from both the system and your app, and these days, that's easily over 1,000 binary images. When LLDB reads a binary out of memory (instead of from disk), the output of this command will include the virtual address of the loaded binary in parentheses after the binary name. Ideally, you could share the output of this command here so we can review it together. You'll need to save it as a text file and then use the file attachment feature here in the forums to share it. (If the output exceeds the file size limit for the forums, please attach it to a bug report and post the FB number of the report, and I'll review it that way.)

The interesting detail that I want to look for here is whether or not the binaries being loaded from memory are from your app, for from the system libraries, and where we go from that point will be based on that information.

If it turns out that everything is being read from disk as expected, then the next thing we want to look at is the communications the debugger is doing with the device. I see you ruled out network debugging and are using a USB cable already, which is great for isolating potential causes based on the physical transport (network or USB). For anyone coming upon this thread that's not @isaacweisberg, it would be helpful for us to know if you are connected directly to the device with a USB cable, or if you are debugging through the network. To verify the type of connection Xcode is using with the device, open Window > Devices and Simulators, and locate the device in the sidebar. If the connection to the device is using a standard network interface, Xcode places a globe icon next to the device name, and if its using USB instead, the globe icon won't be present.

To capture all of the debugger packets for analysis, run this command in Terminal:

echo log enable -T -f /tmp/packets.txt gdb-remote packets >> ~/.lldbinit

This adds a line to your ~/.lldbinit file, which you'll want to remove in the future. This line will output the debugger communication packets with timestamps to /tmp/packets.txt, and that file will be overwritten each time a new debug session session starts. If all of the libraries were read from disk above and you're now here, please attach that packets.txt file to a bug report, and post the FB number of that report here so I can follow-up on it.

— Ed Ford,  DTS Engineer

Both files are attached to FB20344064 now.

That's sincerely appreciated.

To narrate for those following along, the image library list @isaacweisberg provided has only a very small number of images loaded from memory, and that set is expected since they pertain to extra debugging features in Xcode, like the view debugger. Here's what a log line looks with the memory address after the image name in parentheses to signify it is loaded from memory for an example:

[  6] 63FB4197-7D54-3BC9-A58F-6A600AD49233 0x000000010cb4c000 /usr/lib/libViewDebuggerSupport.dylib (0x000000010cb4c000)

So from there, we're off to the debugger packet capture provided, and looking over that may take some time since even of one minute, that's a sizable log file.

If anyone else is seeing the same behaviors, and also only sees a very small of debug libraries loaded from memory, please also capture the debugger packet trace as I detail above, attach them to a bug report, and post the FB numbers here.

— Ed Ford,  DTS Engineer

Hi, I'm working with @isaacweisberg and have been investigating this for the past few days.

I've opened FB20359822 (Xcode 26 on device debugging performance severely degraded) which contains extensive information about the issue, a vanilla project that reproduces the behavior we see and experience as well as leads to what is causing this issue (a mix of new gdb/gdb-remote behavior, threads and dynamic libraries).

Sincerely,

Marty, iOS Engineering @amo

Hi @DTS Engineer !

I'm working with @isaacweisberg and have been investigating this issue for the past few days.

I've opened FB20359822 (Xcode 26 on device debugging performance severely degraded) which contains extensive information and attachments regarding the issue, a vanilla project reproducing it and showing the same behaviors that we see in our main app as well as some leads to the source of the issue (changes in gdb/gdb-remote, threads and dynamic libraries).

Sincerely,

Marty, iOS @amo

Meow we really need you DTS Engineer Ed Ford... We are still trapped in the Xcode 16.4 realm...

Any news on this, issue is still present with Xcode 26.1 beta 2 (17B5035f)