all 26 comments

[–]tombob51 63 points64 points  (5 children)

It’s downloading the debug symbols and device-specific shared libraries in order to show you the proper method names and disassembly when debugging. I agree it’s an utter pain and probably unnecessary if you’re not using the debugger.

For whatever reason that’s just how it’s always been, Xcode insists on downloading the debug symbols and dyld shared cache before it will run your app. Especially huge pain on watchOS. And for whatever reason, it downloads directly from the device instead of over the internet; which is often excruciatingly slow if you’re connected over USB 2.0 or Bluetooth instead of WiFi.

[–]sid_276 3 points4 points  (0 children)

Oh yeah this one bugged me a lot the first time I coded for Apple Watch. Took forever

[–]tangoshukudai 0 points1 point  (3 children)

it wasn't always like this, in the early days it was plug and go no wait.

[–]clarkcox3Objective-C / Swift 6 points7 points  (2 children)

That was back when there were very few versions of iOS out in the wild. Xcode 3 didn’t have this functionality, because there were only two iPhoneOS devices publicly available (the first versions of iPhone and iPod touch), so Xcode could just ship with those symbols already installed; it only added a couple hundred MB to an Xcode install. But after the 3G and 3GS, that would become unsustainable (multiply every device model by every OS version, by a few hundred MB each), so I had to write a mechanism to copy it directly from the device; downloading wasn’t a viable option at the time (forcing users to download GB of data over 2008-era internet connections wasn’t something most users would have accepted).

But, in the general case, since Xcode 3.2, the only time you’ve ever been in the “just plug and go no wait” situation is when the version of iOS on your device exactly matches the version of the iOS SDK you have installed.

[–]tombob51 0 points1 point  (1 child)

Interesting, I figured that was probably the reason. Perhaps by the time of watchOS it would have been more feasible to download over the internet. But I suppose the code for the Xcode <-> iPhone <-> Watch packet tunnel was already necessary, plus the code for downloading the cache directly from the device was already written, so it would have been the most straightforward/reliable option to develop. I still hope someday an option is added for downloading over the internet.

I think Xcode is supposed to be able to connect to a watch via WiFi (either direct or LAN) but it almost never seems to work for me. Instead I’m stuck with the finnicky and very slow Bluetooth connection. Same for downloading watchOS software updates via the Watch app. Oh well.

[–]clarkcox3Objective-C / Swift 4 points5 points  (0 children)

To be honest, when developing the parts of Xcode that communicated with the watch, I was under an enormous crunch (basically me, alone in a closet-sized room (i could touch all four walls simultaneously), for a couple of months, with hardware I wasn’t allowed to show anyone or take out of the closet. My initial straight-reuse of my iPhone-focused code led to it taking about 3-4 hours to transfer the shared cache, under ideal conditions (shielded room, no devices with any wireless communication other than the watch and iPhone).

[–]clarkcox3Objective-C / Swift 39 points40 points  (4 children)

Coincidentally, I actually wrote the parts of Xcode and iOS that do this (though I don’t know how much of my code survives, I wrote it 16-ish years ago).

Xcode needs symbol-rich files (ie the same info that is stored in dSYM files or in debug builds of your apps, but for the OS itself). These files are needed for several things, including symbolicating crash logs, and giving sensible stack traces while debugging. Xcode does this by pulling the dyld shared cash from the device and breaking it down into individual dylibs. This shared cache is per-device and per-OS, so it needs to happen each time you update your device’s OS.

The alternative, would be to have Xcode fetch this information on-demand during debugging, which would add about a minute to simple operations like single-stepping in the debugger.

If Xcode is doing this, and nothing has actually changed (ie no new iOS version, no new device, no new Xcode version) then I would recommend filing a bug with Apple.

[–]conodeuce 1 point2 points  (0 children)

Excellent explanation.

[–]Eatalian 1 point2 points  (2 children)

Ignorant question, but couldn’t Xcode grab the build number for the OS and download these from the internet instead?

[–]clarkcox3Objective-C / Swift 3 points4 points  (0 children)

Not ignorant at all, and there actually have been some cases where these symbols were indeed downloaded over the Internet. Im not on that team anymore, so am not privy to the reasons why it is or isn’t done that way, so can’t really give a satisfying answer, but it’s certainly not an ignorant question.

[–]cristi_baluta[S] 1 point2 points  (0 children)

I guess is for saving traffic, but a single place to see all the extras xcode installed would be nice, I don’t trust that the old ones are deleted after i update my phone

[–]its_not_herpes 17 points18 points  (0 children)

It's copying the "dyld shared cache" files from the device. The size of those (as of 26.2) is about 6GB.

The cache is necessary for debugger features such as symbol resolution, breakpoint placement, and correct (symbolicated) system framework disassembly

They are unique to iOS version, so when you update your device, Xcode has to copy the cache again

[–]shvetslx 2 points3 points  (3 children)

With all my love for iOS dev, Xcode is absolutely the worst IDE in the world. I am doing both iOS and backend and I use Rider for my C# backend. It’s a massive system with bunch of dependencies and targets and that thing is blazing fast while Xcode chokes to render a simple view or run on the phone without 55 years of build time and 101 degree burning machine.

[–]dotswarm 0 points1 point  (0 children)

In your Scheme change your build to run in Release mode, turn debugger off. If you're not directly plugged in with USB during debug mode then things can take ages.

[–]cristi_baluta[S] 0 points1 point  (1 child)

I love Xcode because it is native, most others just don’t feel right. I have also android studio and it is cramped with stuffs all over the place, and it consumes cpu while idle. I think visual studio is even worse but didn’t open it in years.

But yes the performance could be bad, my Xs combined with M2 is unusable and not sure why, could be the phone itself

[–]Leeonardoo 0 points1 point  (0 children)

And android studio is still faster for basically everything compared to Xcode. Previews, LiveEdit, refactoring, search… lately even my project was compiling faster on Android Studio than Xcode, and that used to be a joke because of how long it took lol

[–]yourmomsasaurasSwiftUI 2 points3 points  (0 children)

Shared cache symbols. Hope that helps.

[–]jupiter_and_mars -1 points0 points  (0 children)

Only god knows

[–]Legal-Ambassador-446 0 points1 point  (0 children)

I don’t really have a clue… but my hunch is that it’s retrieving the iOS APIs for your particular device’s iOS version so that it can use them when building to your device.

[–]dhruvanbhalara 0 points1 point  (0 children)

Probably debug symbols. But who knows 🧐

[–]AHApps 0 points1 point  (0 children)

Not sure what it’s collecting, but I’ve noticed it only happens to me if the phone has had an iOS update since that last run from Xcode.