Reduce Xcode Build Time for iOS

There are a lot of ways to reduce the build time of your iOS app and also to improve code quality and create reusable modules. Let’s see the list of possible ways to do that:

Split App Into Modules

This is one of the best ways to achieve less compilation time. For large projects you need to think an architecture that the app uses different modules instead of having all the code in the same project.

For this tutorial we have a banking app in which you have some API calls to retrieve your credit, your cards and do other banking operations. The app also could scan a card to retrieve automatically the Card Number, the Expiration and the Card Holder name.

The idea here is to create a workspace instead of a project and create modules that we can use for a specific reason. For this project one idea is to split the Network part (mechanism for API calls), the Credit Card reader and the Main Project. In this way, if you made for example a change in the main project the other two modules will not be compiled again.

The benefit of splitting App into modules is not only to reduce Compilation time but also to reuse those modules in other projects just only importing them and not do a copy/paste every time you need them.

Remove Unnecessary Pods

Don’t add pods that you will use them for small tasks. For example if you need to do simple http requests you don’t have to import Alamofire to your project as you can achieve that with a single file/class.

Use Private IBOutlets (Swift)

When you are creating a new UIViewController and you have some IBOutlets like UIButtons or UILabels you should make them private (they are public as default). In most of cases the outlets will not be used in other classes but only in your respective UIViewController. Having less public objects can reduce your compilation time.

Remove unnecessary Header from .h Files (Only for Objective-C)

When your project is developed in objective-c you need to import .h files into your .m files to import the objects that you need, but usually it will import more stuff than you really need. For example don’t declare you IBOutlets in the .h file but use the .m instead (it will compiled it only for that file). Also do not add any properties that only your .m file needs in the .h file.

Remove Unused files

Try to delete all the files that you don’t need anymore. Those files could be an unused class, an old asset (image that is not used anymore) or forgotten functions that you are not using anymore

Add SwiftLint

SwiftLint is a library for iOS application that you can have some rules about your project (those rules could be something like a function should not be more than 40 lines, or a complexity of a function not more than 10 etc). Also you can add rules about coding standards like properties naming, spaces after a comma and a lot of other stuff. Importing that library could increase your building time but for large projects you can have a benefit (probably decreasing the compilation time) because this tool could give you suggestions about deprecating methods, having less code in a file (means less compilation time) and remove all the unused functions.

Disable DSYM Generation

This one is only for simulator builds. You need to change settings for simulator SDK (project and pods) and only output dwarf.

Swift Extensions

When you are creating a new extension it’s by default public. This can increase compilation time as it should/could be used by every swift class. Avoid to create extensions that you will use them only in one part of your code. Although you can create the extension but it could be a good idea to declare it as private into your file that should use that.

Specify Types

If you don’t do that the compiler should do it for you and that it will increase the compilation time. For example if you have a float number do the following:

let number = 10

let number: CGFloat = 10

Storyboards

Avoid having storyboards with a lot of UIViewControllers inside. Instead of that you can try to create for every “story” a new Storyboard. For example if you have an App that have a registration flow, login and a dashboard you can split them to 3 different storyboards

Use Code instead of Storyboard or xib

This is not always a good practice because it could be more difficult to understand an UI if you see them with the code and not in a storyboard, but for very simple UI (for example a view controller that has only a webview) you can do it simply from code instead of creating a new file only for the UI.