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)

Hello, Any news on this ? This is making Xcode 26 unusable for us (the issue is still present in the latest version).

I have news! Xcode 26.2 beta 2 is now available, and it contains improvements to the debugging infrastructure that will result in improved launch times with the debugger attached. To reap the benefits, you'll need to update iOS to 26.2 beta 3 for your app debugging. The bug report from @isaacweisberg and @amo_marty was helpful to us, so I do want to thank you for collecting those details that helped us understand the issue.

— Ed Ford,  DTS Engineer

This is good news, but why is an update of iOS required ? Does this mean that the debugging experience on all iOS versions below 26.2 will not be fixed ? It was working fine with Xcode 16 on all iOS versions, so this is not an iOS bug.

Just checked new Xcode 26.2 with iOS 26.2 and the debug builds startup time indeed improved significantly. We still have ~7 seconds of initial sluggishness (difference between debug executable on/off), but it's way better than it was before! 👍

Thanks for sharing [@Alexander Vasenin](https://developer.apple.com/forums/profile/Alexander Vasenin)!

@guillaume-amo asked:

This is good news, but why is an update of iOS required?

You can think of LLDB as a client-server architecture. In Xcode, your use of the debugger is the client side of the infrastructure involved in enabling the debugger. On the other side of the infrastructure is a server process (called debugserver) that the client is talking to. It's this component that is receiving the debugging commands from the client, managing the Mach task port that allows for a debugger to attach to a running process to inspect and manipulate its state, and sending all of the information and commands back and forth to the LLDB client in Xcode for you to view.

While on iOS, the debug server happens to be on a different device than where the debugger client is running, the same architecture is at play if you are working on a macOS app. If you are debugging on the same Mac as where Xcode is running, the client and server components just so happen to be running on the same device in that case. You can look for the debugserver process in Activity Monitor to see it start up when you debug to debug a Mac app.

For this particular issue, changes were needed to the debugging components that are part of Xcode, as well as the components that are a part of the operating system, which is why seeing improvement for the issue reported in this thread requires both an updated Xcode and an updated iOS version.

— Ed Ford,  DTS Engineer

Just checked new Xcode 26.2 with iOS 26.2 and the debug builds startup time indeed improved significantly. We still have ~7 seconds of initial sluggishness (difference between debug executable on/off), but it's way better than it was before! 👍

That’s not an improvement, that's a partial rollback of a huge regression. On Xcode 16 it was ~1s. That was the baseline. Seven seconds of launch + long initial sluggishness in debug is still absurd.

Stop celebrating “less bad.” This shouldn’t be acceptable and Xcode 26 is still unusable for any serious work.

Just checked new Xcode 26.2 with iOS 26.2 and the debug builds startup time indeed improved significantly. We still have ~7 seconds of initial sluggishness (difference between debug executable on/off), but it's way better than it was before! 👍

While I appreciate the movement in the right direction, this still represents a substantial regression from the prior baseline, ~1s in Xcode 16.

A reduction in severity isn’t a resolution. If Xcode is to remain viable for professional workflows, startup and initial responsiveness need to return to the Xcode 16 baseline.

While I appreciate the movement in the right direction, this still represents a substantial regression from the prior baseline, ~1s in Xcode 16.

Hi LWK, I would appreciate it if you could run an experiment to help us understand where the last bits of performance regression are.

Open ~/.lldbinit and add this line:

settings set target.experimental.swift-tasks-plugin-enabled false

It might be best to do this while Xcode is closed, so that we can be sure the setting is read correctly. (You can confirm the setting worked by looking at the thread navigator while stopped in some async function, if you have any in the code, you should no longer see any threads called "Tasks").

With this setting, do you still experience a slow launch?

(please remember to remove that setting, as keeping it on will make stepping through async functions stop working)

If you could also open a terminal, run sample lldb-rpc-server 60 --wait -file sample.txt, and then immediately launch your application, this would be very helpful as well. Please attach the sample.txt file to a bug report.

I tried to disable swift-tasks-plugin-enabled as you described, but that barely had noticeable effect (<1s difference). With the debugger attached (and iPhone connected with USB) our app becomes responsive after about 6-7 seconds from start, while this time decreases to less than 1s if I turn off "Debug executable" option in scheme. I collected lldb-rpc-server sample as you described and added it to FB21378487. Hope it would be helpful!

Thank you, this has been helpful! If you don't mind, could you collect one more piece of data for us?

Add the following to your ~/.lldbinit:

log enable gdb-remote packets --timestamp -f /tmp/log_packets.txt

Like before, make sure Xcode is closed. Then, launch the app to experience the slow startup, stop the application, and attach /tmp/log_packets.txt to the bug reported you opened. Please make sure you only do the experiment once, so that the log doesn't contain more than one run.

Thank you for assisting us!

Just did the experiment and attached the logs to FB21378487. Hope it helps!

Add the following to your ~/.lldbinit:

log enable gdb-remote packets --timestamp -f /tmp/log_packets.txt

how is this not escalated to the top by now?

Networking process (0x136104100) took 79.626742 seconds to launch GPU process (0x1360d81e0) took 80.618887 seconds to launch WebContent process (0x1360780c0) took 80.989579 seconds to launch

And still frozen after 4 minutes.

Added log files to FB20359822 (Packets and sample, with the experimental feature disabled and enabled)

Xcode 26.2 in conjunction with iOS 26.2 fixed the exponential time it took to do a DLOpen with the debugger attached on Xcode 26, however the time it takes for one DLOpen is still ~0.10/0.15s on Xcode 26.x when it was only ~0.02/0.03s on Xcode 16.4.

A huge number of DLOpens at app start will still cause the issue (We have around 200 dylibs that are loaded after app delegate init, mostly from Accessibility Bundles).

2000.15 = 30 seconds 2000.02 = 4 seconds

Pretty consistent with what we see when the debugger is attached on Xcode 26.2 vs Xcode 16.4.

Thank you.

Sincerely,

Marty, iOS @amo

I have attempted to use Xcode 26.2 with a device running iOS 26.2, same configuration as in the original post, and I don't find the user experience to have improved one bit:

• app startup takes ages before I even see my UIWindow and UIViewController on screen
• starting without debugger and attaching afterwards causes the app to lag horribly, which was not a problem originally when I only started to try Xcode 26.0

@fpiovezan Thank you for joining the conversation.

You have requested for me to:

• validate the state of Accessibility options
• run an experiment and file a new FB with logs attached

After gathering our bearings, it's clear to me that I will not be able to provide anything new that was not already provided in FB20359822 . Can you please consult that FB ticket as it has all the extensive info and logs of using Xcode 26.2 with iOS 26.2, and what's also important, a project that reproduces the issue.

As for the accessibility options, we are certain that we do not really enable anything on by hand, never. We are going to attach a video recording of our accessibility options to the same FB20359822.

Hello, Can we have an update on the progress ? It's been several months, we're now at Xcode 26.5, and still no fix in sight for this issue. We are still stuck on Xcode 16 for any kind of device debugging and we are not alone...

I am now using Xcode 26.4 and an iOS 26.4.1 device iPhone 16 Pro, and the app performance at the start is still absolutely unusable, the app stutters. While on Xcode 16.4 everything is as fine as it was. Can somebody please take a look? Makes it really unproductive when working on Liquid Glass specific stuff.

@Developer Tools Engineer @fpiovezan