Xcode 12.5 very slow launch time for app in simulator

Configuration

  • Big Sur 11.3

  • Xcode 12.5

(recently updated from Catalina and Xcode 12.4)

Problem
When running app in iOS 14.5 simulator launch takes incredibly long time (more than 30 seconds). In comparison launching installed app in simulator - 2 seconds, launching app on the real device (iOS 14.4) - 6 seconds.

Additional information
When running against simulator Xcode says "launching app", "attaching to app", and then "running app", at the running app stage we get a ~30 second pause. debugserver at 100% activity at that time.

Looking for solution
Methods described here https://developer.apple.com/forums/thread/651012 (deleting the contents of ~/Library/Developer/Xcode/iOS DeviceSupport) didn't help.
If I untick Debug Executable for the scheme app starts normally but then logically debugging isn't possible so it's not a solution.

Up vote post of OlKir1143 Down vote post of OlKir1143
29k views
Posted by
OlKir1143
Reply

  • The problem seems to be related to Big Sur 11.3 and Big Sur 11.4. Not to specific Xcode version (Xcode 12.4 got about the same results that 12.5).

    I do some measures for 2 applications in debug on Big Sur 11.1 and Big Sur 11.4. Here the launch time results: App1 - Big Sur 11.1 = 0m21s - Big Sur 11.4 = 1m20s App2 - Big Sur 11.1 = 0m31s - Big Sur 11.4 = 5m08s

    Conclusion: Debugging Application on 11.4 is between 4 to 10 time slower than 11.1.

    Note App2 have nearly 100 dylib to load while App1 have only 30.

    —
    oldnpoor

  • @oldnpoor I am using Big Sur, but my build always fails with the Build input cannot be found. Here If I removed the product name in the build settings, Build got succeeded. But the app was not installed because the .app file was not available in the Build input file cannot be found: '/Users/name/Library/Developer/Xcode/DerivedData/App-dhdivlzaazbnhtguhlgnkkglsibo/Build/Products/Debug-iphonesimulator/Hello App.app/Hello App. Could you please let me know any workarounds.

    —
    Jesphinj

  • Upgrading to macOS 11.6 helped somewhat - after a brief evaluation, debugging seems doable now with "only" 15-30 second pauses. Better than the several minutes observed with 11.3 but still a horrible developer experience (small project size with a few dependencies).

    —
    ugammelby
Add a Comment

Accepted Reply

As others have noticed, this issue was triggered by updating a newer versions of macOS. We have a change to address this performance issue when running on newer versions of macOS available in Xcode 13 Beta, available today.

Posted by
jeremyhu
Up vote reply of jeremyhu Down vote reply of jeremyhu
Post marked as solved

  • 👍 Thank you very much for the update!!

    —
    Rumio

  • @jeremyhu Do you plan to update Xcode 12.5 with this fix? I am unable to use Xcode 13.

    —
    d.subbotin

  • @jeremyhu Could you please clarify what the users are asking? From many reasons, development will continue on Xcode 12.5 for a couple of months for many users. When will Xcode 12.6 be released with the change addressing the performance issue?

    —
    mihaicris

Replies

FB9092650
Posted by
drewcrawford
Up vote reply of drewcrawford Down vote reply of drewcrawford
Add a Comment
Unfortunately i can't find any of the radar's in openRadar or openFeebackAssistant and in the current Feeback Assistant from apple we can't see "Radar's" opened by others.
This is mean't to waste our time and duplicate issues or i'm missing something?
Posted by
parterif
Up vote reply of parterif Down vote reply of parterif
Add a Comment
I am new to "Radar". How and where to do that? I have the same problem. My tests are running for ages now.

Update: Runs way faster when disabling "Debug Executable"
Posted by
Kila
Up vote reply of Kila Down vote reply of Kila
Add a Comment
I have this same issue of slow simulator but only on my Intel machine, in the M1 ones everything works smoothly.
Posted by
imrabti
Up vote reply of imrabti Down vote reply of imrabti
Add a Comment
Have you guys tried on macOS Big Sur 11.5 Beta? Lol today Apple released macOS Big Sur 11.5 Beta even though 11.4 Beta still in Beta/Release Candidate
Posted by
ajisaputrars
Up vote reply of ajisaputrars Down vote reply of ajisaputrars

  • @ajisaputrars I just updated to Big Sur 11.5.2 and Xcode 12.5.1 last night. The slowness issue remains unfixed.

    —
    Teslum
Add a Comment
I just tested on macOS Big Sur 11.5 Beta 1 (20G5023d). Still the same on my side...

For information, my Mac is a MacBook Pro (Retina, 13-inch, Late 2013) // 2,6 GHz Dual-Core Intel Core i5 // 16 GB 1600 MHz DDR3 // Intel Iris 1536 MB.
Posted by
alpennec
Up vote reply of alpennec Down vote reply of alpennec
Add a Comment
MacBook Pro 13, 2018, with Touch Bar - the same issue.
Posted by
sdidanov
Up vote reply of sdidanov Down vote reply of sdidanov
Add a Comment
Not sure if this is exactly the same issue but my App will be unresponsive to mouse click for about 10 seconds after run in simulator. I've tried everything the only one worked was to delete the simulator then add it back. It only worked for maybe half a day then it'll come back unfortunately.
Posted by
fireup
Up vote reply of fireup Down vote reply of fireup
Add a Comment
Seems related to the not-responsive-for-touch-for-several-seconds-bug. Big issues on first rotation (at least on iPad-simulator) as well. Still a problem in first 11.5 beta
Posted by
DJ Almost
Up vote reply of DJ Almost Down vote reply of DJ Almost
Add a Comment
Maybe it's something affecting only Intel macs… @imrabti said it's not affecting his M1 machines. All I have is an Intel one, though lol
For now, using a scheme with "Debug Executable" off. I just hope Apple won't try and force everyone to upgrade to M1 machines just for this; it's not an option.
— MacBook Pro 2020 - Intel
Posted by
rgomesbr
Up vote reply of rgomesbr Down vote reply of rgomesbr
Add a Comment
With 11.4 RC my app is starting a lot faster than 11.3.1 but still a little slower than it was a month ago. And once started it's responsive immediately, unlike before where I had to wait another 20 seconds or so.

Not perfect but at least I can leave Debug Executable checked without needing to find a way to kill time.

This is on a 13" 2017 MacBook Pro.
Posted by
angelFrog
Up vote reply of angelFrog Down vote reply of angelFrog
Add a Comment
I got the same problem. I'm currently on Big Sur 11.3, Xcode 12.5. Start a debug session of a macOS application UE4Editor is really slow since about 3 weeks. I expect this to be solved soon. I do time profiling. If we remove time for "instruments" to profile itself, So we can see that nearly all time is spend in debugserver process. And that UE4Editor is stuck in dlopen.

Code Block 
3.37 s   45.6%	0 s	 	debugserver (37427)
3.36 s   45.6%	0 s	 	 Main Thread  0x5af1b6
3.36 s   45.6%	0 s	 	  start
3.36 s   45.6%	0 s	 	   main
3.36 s   45.6%	0 s	 	    RNBRunLoopInferiorExecuting(RNBRemote*)
3.36 s   45.5%	0 s	 	     RNBRemote::HandleReceivedPacket(RNBRemote::PacketEnum*)
3.35 s   45.4%	0 s	 	      RNBRemote::HandlePacket_jGetLoadedDynamicLibrariesInfos(char const*)
3.35 s   45.4%	0 s	 	       DNBGetLibrariesInfoForAddresses(int, std::__1::vector<unsigned long long, std::__1::allocator<unsigned long long> >&)
3.35 s   45.4%	0 s	 	        MachProcess::GetLibrariesInfoForAddresses(int, std::__1::vector<unsigned long long, std::__1::allocator<unsigned long long> >&)
3.35 s   45.4%	0 s	 	         _dyld_process_info_create
3.35 s   45.4%	0 s	 	          withRemoteBuffer(unsigned int, unsigned long long, unsigned long, bool, int*, void (void*, unsigned long) block_pointer)
3.35 s   45.4%	0 s	 	           ___dyld_process_info_create_block_invoke
3.35 s   45.4%	0 s	 	            std::__1::unique_ptr<dyld_process_info_base, dyld_process_info_deleter> dyld_process_info_base::make<dyld_all_image_infos_64, dyld_image_info_64>(unsigned int, dyld_all_image_infos_64 const&, unsigned long long, int*)
3.35 s   45.4%	0 s	 	             withRemoteBuffer(unsigned int, unsigned long long, unsigned long, bool, int*, void (void*, unsigned long) block_pointer)
3.34 s   45.2%	2.00 ms	 	              invocation function for block in std::__1::unique_ptr<dyld_process_info_base, dyld_process_info_deleter> dyld_process_info_base::make<dyld_all_image_infos_64, dyld_image_info_64>(unsigned int, dyld_all_image_infos_64 const&, unsigned long long, int*)
3.34 s   45.2%	0 s	 	               dyld_process_info_base::addImage(unsigned int, bool, unsigned long long, unsigned long long, char const*)
3.07 s   41.6%	0 s	 	                dyld_process_info_base::copyPath(unsigned int, unsigned long long)
3.07 s   41.6%	1.00 ms	 	                 withRemoteBuffer(unsigned int, unsigned long long, unsigned long, bool, int*, void (void*, unsigned long) block_pointer)
3.06 s   41.5%	1.00 ms	 	                  RemoteBuffer::create(unsigned int, unsigned long long, unsigned long, bool)
3.06 s   41.5%	1.00 ms	 	                   RemoteBuffer::map(unsigned int, unsigned long long, unsigned long)
2.96 s   40.1%	1.00 ms	 	                    mach_vm_remap_new
2.96 s   40.1%	2.00 ms	 	                     _kernelrpc_mach_vm_remap_new
2.96 s   40.1%	1.00 ms	 	                      mach_msg
2.96 s   40.1%	2.96 s	 	                       mach_msg_trap
50.00 ms    0.6%	1.00 ms	 	                    mach_vm_deallocate
38.00 ms    0.5%	38.00 ms	 	                    _platform_memmove$VARIANT$Haswell
9.00 ms    0.1%	4.00 ms	 	                    _malloc_zone_malloc
1.00 ms    0.0%	1.00 ms	 	                   malloc
3.00 ms    0.0%	0 s	 	                  invocation function for block in dyld_process_info_base::copyPath(unsigned int, unsigned long long)
1.00 ms    0.0%	0 s	 	                  free_small
1.00 ms    0.0%	1.00 ms	 	                 _Block_object_dispose
257.00 ms    3.4%	0 s	 	                dyld_process_info_base::addInfoFromRemoteLoadCommands(unsigned int, unsigned long long)
11.00 ms    0.1%	10.00 ms	 	                dyld_process_info_base::addInfoFromLoadCommands(mach_header const*, unsigned long long, unsigned long)
8.00 ms    0.1%	0 s	 	              RemoteBuffer::create(unsigned int, unsigned long long, unsigned long, bool)
2.00 ms    0.0%	0 s	 	         _dyld_process_info_for_each_image
1.00 ms    0.0%	0 s	 	         MachProcess::GetMachOInformationFromMemory(unsigned int, unsigned long long, int, MachProcess::mach_o_information&)
1.00 ms    0.0%	0 s	 	         free_tiny
1.00 ms    0.0%	0 s	 	       RNBRemote::SendPacket(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)
3.00 ms    0.0%	0 s	 	      RNBRemote::HandlePacket_v(char const*)
2.00 ms    0.0%	0 s	 	      RNBRemote::HandlePacket_p(char const*)
1.00 ms    0.0%	0 s	 	      RNBRemote::HandlePacket_c(char const*)
1.00 ms    0.0%	1.00 ms	 	      DYLD-STUB$$__error
2.00 ms    0.0%	0 s	 	     HandleProcessStateChange(RNBRemote*, bool)
1.00 ms    0.0%	0 s	 	     PThreadEvent::WaitForSetEvents(unsigned int, timespec const*) const
1.00 ms    0.0%	0 s	 	 MachTask::ExceptionThread  0x5af1be
2.98 s   40.3%	0 s	 	Instruments (37042)
249.00 ms    3.3%	0 s	 	Xcode (3162)
225.00 ms    3.0%	0 s	 	WindowServer (150)
160.00 ms    2.1%	0 s	 	lldb-rpc-server (6834)
118.00 ms    1.5%	0 s	 	UE4Editor (37426)
102.00 ms    1.3%	0 s	 	 -[UE4AppDelegate runGameThread:]  0x5af2f7
102.00 ms    1.3%	0 s	 	  thread_start
102.00 ms    1.3%	0 s	 	   _pthread_start
102.00 ms    1.3%	0 s	 	    __NSThread__start__
102.00 ms    1.3%	0 s	 	     -[FCocoaGameThread main]
102.00 ms    1.3%	0 s	 	      -[UE4AppDelegate runGameThread:]
102.00 ms    1.3%	0 s	 	       GuardedMain(char16_t const*)
102.00 ms    1.3%	0 s	 	        EnginePreInit(char16_t const*)
102.00 ms    1.3%	0 s	 	         FEngineLoop::PreInit(char16_t const*)
102.00 ms    1.3%	0 s	 	          FEngineLoop::PreInitPostStartupScreen(char16_t const*)
102.00 ms    1.3%	0 s	 	           FEngineLoop::LoadStartupModules()
102.00 ms    1.3%	0 s	 	            FPluginManager::LoadModulesForEnabledPlugins(ELoadingPhase::Type)
102.00 ms    1.3%	0 s	 	             FPluginManager::TryLoadModulesForPlugin(FPlugin const&, ELoadingPhase::Type) const
102.00 ms    1.3%	0 s	 	              FModuleDescriptor::LoadModulesForPhase(ELoadingPhase::Type, TArray<FModuleDescriptor, TSizedDefaultAllocator<32> > const&, TMap<FName, EModuleLoadResult, FDefaultSetAllocator, TDefaultMapHashableKeyFuncs<FName, EModuleLoadResult, false> >&)
97.00 ms    1.3%	0 s	 	               FModuleManager::LoadModuleWithFailureReason(FName, EModuleLoadResult&)
92.00 ms    1.2%	0 s	 	                FMacPlatformProcess::GetDllHandle(char16_t const*)
92.00 ms    1.2%	0 s	 	                 GetDllHandleImpl(NSString*, NSString*)
92.00 ms    1.2%	0 s	 	                  dlopen


Posted by
oldnpoor
Post not yet marked as solved Up vote reply of oldnpoor Down vote reply of oldnpoor
Add a Comment
Problem still present with Big Sur 11.4 / Xcode 11.5 ...
Posted by
skrobs
Post not yet marked as solved Up vote reply of skrobs Down vote reply of skrobs
Add a Comment
Wanna try to check it out if the problem is already solved, but Apple seems has not release Xcode 12.6 yet.
Apple is releasing iOS 14.6 but not releasing Xcode 12.6. Can you run and deploy your app to iOS 14.6 directly from Xcode 12.5?
Posted by
ajisaputrars
Up vote reply of ajisaputrars Down vote reply of ajisaputrars

  • Yes, Xcode 12.5 allows running and debugging apps on iOS 14.6 devices.

    —
    TAIFUN
Add a Comment

I‘m also affected by this bug on a Mac mini i7, 2020 with 16 GB RAM.

The worst thing is the slow down in UITests because I receive so many timeouts and as a consequence the tests are not reliable anymore with Xcode 12.5 on BigSur.

I switched back to Catalina, but now I can not archive my project anymore because some external swift packages are build with 12.5. Apple, please fix it soon!

Posted by
Rumio
Post not yet marked as solved Up vote reply of Rumio Down vote reply of Rumio

  • I do a lot of test (related to very slow debugging for application using a lots of dylib). This problem start with Mac OS Big Sur 11.3 up to first beta of 12.5. So you can install 11.2.1 and Xcode 12.5.

    —
    oldnpoor

  • Thanks, I’ll do it that way until the issue is fixed!

    —
    Rumio
Add a Comment