1p4mha
Last Updated: November 20, 2018
·
9.366K
· rerel

Reduce XCode build times

DerivedData

Xcode intensively cache temporary “information” on the file system.
Each time you clean in a project, make a new build, or launch the app in the iOS Simulator, XCode will read & write into the DerivedData folder.

The DerivedData folder contains all the intermediate build information, debug- and release-built targets, as well as your project's index. It's helpful to delete the derived data when you have odd index problems (code completion not working right, constant re-indexing, or even just a slow project). Deleting the entire folder nukes this information for all projects Xcode knows about.

You can safely try to rm -rf ~/Library/Developer/Xcode/DerivedData/* in the Terminal and notice how much space is freed. Xcode will regenerate everything your project need when you build it again.

A simple way to save some time is to create a RAM disk and mount it at ~/Library/Developer/Xcode/DerivedData.

Creating a 2 GB volume RAM disk via the Terminal:

$ hdid -nomount ram://4194304

hdid outputs the device name of the RAM disk. Change the number instead of the 'N' for newfs_hfs and diskutil commands.

$ newfs_hfs -v DerivedData /dev/rdiskN
$ diskutil mount -mountPoint ~/Library/Developer/Xcode/DerivedData /dev/diskN

Mounting a volume on top of your existing DerivedData hides the old files. They continue to take up space, but are unreachable until you unmount the RAM disk.
The contents of the RAM disk disappear when you reboot or eject it from the Finder. Xcode will need to rebuild its indexes and all of your project’s intermediate files the next time you create one.

Such RAM disks are not “allocated” in the memory, they take only as much space as needed to keep all files.

I personally use that at work on a Mac with 8 GB of RAM and a SSD and build times are about 5 seconds maximum. It's especially useful if you use Interface Builder. It's definitely worth a try and I hope it will reduce also your build times.

1 Response
Add your response

31287

As Swift has matured, so has its compiler. We’ve come a long way since the days of the notoriously slow build times of Swift 2. Combined with the general bugginess of Xcode at the time, I’m not sure how we ever got work done back then! Although compile times seem to have gotten much better with Swift 4 and Xcode 9, are there any tweaks that we can apply to further increase performance? What about our Swift code? If you’ve followed the issue at all over the past two years, you may have run into recommendations for how to optimize your Swift code to speed up compilation times. Are those tweaks still necessary as well? In this post, I’ll do my best to answer these questions as well as provide some learnings from my own experiences with build times in Swift 4. https://www.minimilitia.mobi/ https://www.applock.ooo/ https://www.7zip.vip/

14 days ago ·