How to make Xcode take up less space

Xcode 9 is over 10GB, but that's only its starting size…

Paul Hudson September 21st 2017 @twostraws

We all know that Xcode has struggled with being a little on the portly side for some years, and even Apple acknowledged this back at WWDC 2012. Here’s what Matthew Firlik (Director of Development Technologies at Apple) had to say at the time:

Last year [at WWDC 2011] when we shipped Xcode 4.1 our download size was a little bit over 4 gigabytes, and I don't think there's anything more to be said about that. When we shipped Xcode 4.2 we were able to shrink that package size down to about 1.5 gigabytes by making some of the legacy content – like the older iOS simulators – downloadable on demand.

At the time that was a big and welcome improvement, but sadly it wasn’t to last: after going on its crash diet in 2012, Xcode has since been busy at the dessert aisle and has grown far beyond the “no more to be said about that” size of Xcode 4.1.

Let’s take a look at some figures:

Version	Download	Installed
Xcode 5.0	2.05 GB	4.37 GB
Xcode 6.0	2.62 GB	5.18 GB
Xcode 7.0	3.85 GB	7.79 GB
Xcode 8.0	4.41 GB	9.97 GB
Xcode 9.0	5.37 GB	10.41 GB

Now, some amount of natural fluctuation is to be expected – as Firlik said back in 2012, Apple can adjust its selection of simulators in order to reduce the initial download at the expense of possible later downloads.

It’s also important to note that Xcode has added features over those years, such as Swift in Xcode 6 or App Thinning in Xcode 7, so some amount of natural growth is inevitable. Many developers – myself included! – have a long wish list of features we want to see in Xcode 10, so there’s a never-ending trade-off between cutting size and adding features.

Sponsor Hacking with Swift and reach the world's largest Swift community!

But wait – there’s more!

All this extra growth means that Xcode 9 is more than twice the size of Xcode 5, but even that’s not the whole story. You see, Xcode is a bit sneaky: the 10.41GB that Xcode 9 takes up is actually only its starting size.

Each time you connect a device to your computer, you might have noticed Xcode likes to spend some time “Processing symbol files” or “Preparing debugger support” for that device. This happens once per iOS version, although it’s extremely fine-grained – even going from iOS 11 beta 9 to iOS 11 beta 10 will cause this process to repeat.

What Xcode is doing is configuring its device support system so that it understands all the frameworks that ship inside the iOS version you connected, which in turn means it can symbolicate crash logs. This is no small amount of data – you can expect Xcode to chew up 2-3GB for each iOS version you connect.

The problem is, Xcode doesn’t ever seem to want to remove device support once it’s installed, so if you’re an active iOS developer who doesn’t actively prune this yourself there’s a good chance you’ll find around 40GB or more of device support data – most of which is for iOS versions that you don’t even think about any more.

In my case, I recently finished writing a book teaching all the new iOS APIs in iOS 11, which meant I had installed iOS 11 betas 1 through 10 on my devices. If I hadn’t been cleaning Xcode’s device support directory, each of those combined would have been taking up a whopping 20GB of space, even though each beta version was effectively rendered obsolete as soon as its successor came out.

Save 20GB with this one weird trick

Xcode’s initial install size is beyond our control, but its extended post-install growth is something you can reduce. First, install the awesome tool GrandPerspective, then point it at your ~/Library/Developer directory.

This is where Xcode stores three chunky parts of its ecosystem:

The iOS Device Support directory stores debugging data for individual iOS versions.
The Derived Data directory is the storage area Xcode uses while building your apps.
The CoreSimulator directory is where Xcode’s simulator data lives, including all apps you’ve installed into simulators.

Keep in mind that each of those simulators is feature complete, right down to those sample photos you see in the Photos app. If you’re curious, try searching ~/Library/Developer for “IMG_0005.JPG” – I found 90 copies of the same photo. Nice!

When GrandPerspective finishes – and it might take some time – you’ll see something like the image below:

GrandPerspective shows you the total space taken up by the scanned directory in the bottom-left corner (20.7GB for me), but you can also hover over individual files to see what they are and how much they take up.

To make things easier to read I’ve added some annotations to mine so you can get an idea of where all the space goes:

OK, so maybe I’ve been a touch facetious, but the point is that the majority of the files you can see in my developer directory aren’t needed. You can literally just delete them outright and Xcode will recreate the bits it actually needs when you next plug an iOS device in.

If you want to clear out individual simulator directories you can, but honestly the easiest thing to do is zap the device support directories – they will usually be well over half the used space.

Here’s how to do it:

Right-click one of the big files GrandPerspective found – it will be called dyld_shared_cache_arm64 – and choose Reveal In Finder.
In Finder, hold down the Cmd key and press the Up cursor key a few times until you finally have a folder called “iOS DeviceSupport” selected.
Go back into that folder and you’ll see it has directories for iOS version numbers, e.g. 9.3.5 (13G36), 10.3.2 (14F89), and 10.3.3 (14G60).
Select all of them, delete them, then empty the trash.
Plug in your iOS devices then launch Xcode so it can download the symbols you actually need.
Feel smug.

Isn’t there a better way?

It’s understandable that Xcode needs some device support in order to function correctly. However, its insistence on keeping all device support is unhelpful, and it would be great to see some work being done to have this trimmed automatically.

For example, would it be so bad for Xcode to scan its device support every time it launches, and say “well, they haven’t connected one of these in three months; let’s scrap it”? It could even be an option that’s disabled by default if Apple think so many want old device support around – but at least give the rest of us the chance to have Xcode use up less than 50GB.

Xcode: I love you, but I hope you’ll consider this an intervention and stay off the carbs in the run up to Xcode 10.

And finally, in case you were curious…

As difficult as it is to weigh one version of Xcode against another because their contents differ, it’s deeply unfair to weigh one IDE against another – what Apple chooses to bundle and what Google chooses to bundle bear little to no relation.

Still, admit it: you’re a teensy bit curious how Xcode stacks up against Android Studio, which is the tool our Android counterparts rely on for building apps.

Well, to satisfy your curiosity if nothing else, let me re-make that table…