How to decrease build times / speed up compile time in Xcode?

Question

What strategies can be used in general to decrease build times for any Xcode project? I\'m mostly interested in Xcode specific strategies.

I\'m doi

Answer 1

You mentioned using static libs for your most-often used files to prevent compilation. You can accomplish something similar by putting headers to your code that it's frequently used but not in your static libs in the precompiled header. At least they'll only be compiled once.

Care must be taken to avoid issues if you have multiple compilation types across your project (e.g. Obj-C, Obj-C++, C++).

Answer 2

If your whole project gets rebuilt every time you hit run, that's probably the bug in XCode 7.0 <= 8.1 giving you a hard time.

Creating the user defined build setting HEADERMAP_USES_VFS to YES cut the macbook compile time from 75 seconds each time, to 25 seconds. See Xcode 8 does full project rebuild for more info.

Answer 3

If you're not using 8GB of RAM, upgrade now.

I just upgraded my macbook pro from 4GB to 8GB. My project build time went from 2:10 to 0:45. I was floored by the improvement. It also makes web browsing for research snappier and general Xcode performance when indexing, etc.

Answer 4

I used a script to make use of a RAM drive, together with some "forward declarations" optimizations my project clean build time went from 53 seconds to 20 seconds.

I was tempted to get the Gui on the AppStore, but opted rather to go for command line. I put the script as part of git repository.

To see the build times, enter this in a terminal: "defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES"

Restart Xcode to notice the build times in the toolbar. (this is my non clean build time using objective-c)

Adjust the script to your liking. - Note the script clears the derived data folder.

#!/bin/sh

#2 GIG RAM
GIGA_BYTES=$((2*1024*1024*1024))

# a sector is 512 bytes
NUMSECTORS=$((${GIGA_BYTES}/512))

#ram disk
mydev=`hdiutil attach -nomount ram://$NUMSECTORS`
newfs_hfs $mydev

# make mount point
MOUNT_POINT=/Users/your_user_name/Library/Developer/Xcode/DerivedData

# ******************************************* 
# ** WARNING - MOUNT POINT WILL BE DELETED ** 
# *******************************************
rm -rf ${MOUNT_POINT}
mkdir -p ${MOUNT_POINT}

# mount
mount -t hfs $mydev ${MOUNT_POINT}
echo unmount $(MOUNT_POINT)

To see the effect and to control the RAM Drive:

mount                       - see mount points
umount mount_point          - unmount point
diskutil list               - see disks
diskutil eject /dev/diskX   - eject the disk
df -ahl                     - see free space

NOTE: I essentially use the hdiutil provided by macOs. I tried switching the -kernel option (no swapping to disk) on but failed on my machine, saying it is not implemented.

Maybe the new OS coming soon we will see even more improvements as the new file system copy feature is really fast, and possibly makes this script redundant.

Answer 5

I wrote an extensive blog post about how I improved the iOS development cycle at Spotify:

Shaving off 50% waiting time from the iOS Edit-Build-Test cycle

It boiled down to:

1) Stop generating dSYM bundles.

2) Avoid compiling with -O4 if using Clang.

Answer 6

Hey there, I would recommend you to optimize your project's physical structure. There's some good reading about this ( at least in the C++ world ) , but I do objective-C and the same principles often apply.

Here's a great article about project's physical structure optimization, which tends to improve compile times Games From Within: Physical Structure Part 1

Good luck :)