There comes a time during the life of your Swift project when the compile times just don’t cut it. There are some tweaks and knob twirling you can do to improve them, but honestly, it doesn’t make that much of a difference.

I started looking around and found the deck “Swift compile time is so slow” by Masato Oshima where he claims that concatenating all the files together improved his build time sevenfold, from 6 minutes 55 seconds to a bit under a minute. “Impressive!” I thought and decided to test this approach for our project.

Now, concatenating all files to help the compiler out is not a new method, I know for certain that some game developers use it for C++ and the results are no less staggering, so this is a legitimate thing to try.

Let’s get to the test results. At the time of writing our project is about 40k lines of Swift code and a dozen of external frameworks. I used the slightly modified concatenate_swift_files.sh from keychain-swift, their version disposed of the newlines we used in some of our strings so I had to edit the script to handle that. Otherwise, no changes.

The time is from tapping on Run in Xcode to the Simulator appearing.

Concatenated files: 2 minutes 8 seconds.
Normal source files (around 300 of them): 2 minutes 32 seconds.

Result: a measly 16% improvement. Not worth pursuing for our project. On top of that, the logger we use (XCGLogger) showed all debug prints originating in the concatenated file (versus a specific source file), which is logical and expected, but annoying and unhelpful.

Another small piece of software I’m sharing with you. This time it’s an actual visible control!

YKProgressBar is a simple drop-in progress bar control with rounded edges all-around (ha-ha). Just copy the files YKProgressBar.[hm] into your project and you’re good to go.

Here’s a demo of YKProgressBar. The floating things on top are scrolled collection view cards.

If you’ve missed the link in the beginning, it’s up on GitHub.

It’s often inconvenient to use the full-blown debugger: longer cycles, blocks, whatever. When there’s no concern for performance, I just throw in an NSLog.

NSLog, though, is a chore when there is anything but strings involved. I do remember the format syntax but boy is it annoying to put all those %ld, %lu, %g and everything else (which would also complain on architecture change) instead of a simple %@!

So recently I started using an NSNumber literal notation for any ints and floats:

NSLog(@"%@", @(var));

Nothing to remember, no warnings, and gets the job done.