App Startup with Debugger in Xcode 26 is slow

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.