XcodeGen — Collaboration Made Easy
Tags: ios, xcode, xcodegen, swift
Published: 2020-07-20 08:11:35

---
title: XcodeGen — Collaboration Made Easy
description: "If you have ever worked in a team, I’m sure that many times, you’ve encountered conflicts with the\_.xcodeproj file while merging your code."
date: '2020-07-27T20:11:35.004Z'
tags: iOS, Xcode, Xcodegen, Swift
slug: /@robertofrontado/xcodegen-collaboration-made-easy-9d1fdef548de
published: true

---

![Illustration from [https://github.com/yonaskolb/XcodeGen](https://github.com/yonaskolb/XcodeGen)](https://cdn-images-1.medium.com/max/800/1*mjtv3txAKlkUPB7643Ekuw.gif)

If you have ever worked in a team, I’m sure that many times, you’ve encountered conflicts with the .xcodeproj file while merging your code.

Solving this kind of conflict is not always easy, because the .xcodeproj file is not human — readable, especially if you are adding and removing lots of files, modifying your project configuration, or editing your schemes…

In the past, I used a simple solution to this problem, adding this line to the .gitAttribute file.

```
\*.pbxproj merge=union
```

This solution merges both sides automatically, so you don’t get to see the conflict. It works most of the time if you are in a small team. However, it is definitely not bulletproof nor scalable.

Wouldn’t it be better if you had a more reliable tool to solve this kind of problem? Here, XcodeGen comes to the rescue.

## What Is XcodeGen, and How Do You Use It?

XcodeGen is a command-line tool written in Swift. It generates your Xcode project using your folder structure and a project spec, which contains all the information necessary to generate a project, such as targets, schemes, settings.

First, you need to install XcodeGen. You can do this using **homebrew:**

```
brew install xcodegen
```

> There are other ways of installing XcodeGen. You can check them out in the official documentation

Next, you need to create a file called `project.yml` in the project root folder. This file will contain the project configuration.

> XcodeGen supports YAML and JSON files, but in this article, we use YAML because it is considered to be more human-readable and is the standard format for configuration files.

{% gist https://gist.github.com/robertofrontado/44c6fc76b8d3d81653f7a244a9f7db07 %}

To generate the project, run the following command:

```
xcodegen
```

As simple as that, you have now generated an Xcode project!

In projects, you also have a unit tests target. It can be added to the project.yml file as follows:

{% gist https://gist.github.com/robertofrontado/ddd86e25943112887b5d1af603430ffc %}

**Important:** Next time you merge code, and it modifies the project configuration, you’ll need to generate your project again by running `xcodegen`.

That’s not all, though. Let’s make things more interesting.

Imagine you are building a modular application, with two 2 frameworks: one to handle the authentication and one to see your user profile. Your project.yml file will look like this:

{% gist https://gist.github.com/robertofrontado/ace0906e1268341d3011eba16f849ac7 %}

As you can see, this file starts to grow in size, making it harder to wrap our heads around it. Thankfully, XcodeGen allows us to split our configuration into multiple files, so it easier to manage. For example:

{% gist https://gist.github.com/robertofrontado/83a191ecffde4de2d71e6310f8a2e8b2 %}

{% gist https://gist.github.com/robertofrontado/55e184c168204617924d1f5fa4d53995 %}

{% gist https://gist.github.com/robertofrontado/3b037196f96dd8db4c589d08d89efdb3 %}

Now generate the Xcode project again, and you will see that everything is working.

> I have placed all frameworks in a folder called Subprojects, and their configuration files in another folder called Subspecs. You can organize them however you want.

You can also add build scripts. This is how you can add a script to run SwiftLint:

{% gist https://gist.github.com/robertofrontado/f74749c1c542824322214708f9f91c0a %}

**Note:** When working with git, **remember** to add these lines to the .gitignore file because you don’t want to commit those files anymore:

```
\## Ignore project files as we generate them with xcodegen ([https://github.com/yonaskolb/XcodeGen](https://github.com/yonaskolb/XcodeGen))  
\*.xcodeproj  
\*.xcworkspace
```

You can find the source code used for this article here:

{% github robertofrontado/xcodegen-sample no-readme %}

## Conclusions

Implementing a tool such asXcodeGen can seem overwhelming at first because it changes how you configure your project. However, I can assure you that you will reap its benefits from day one — especially if you work in a modular application and a large team.

Moreover, another benefit is that since you need to specify the entire project configuration through code, you **automatically** **document** **your project configuration**.

While XcodeGen is my preferred tool, here are some alternatives you can try and see which one suits you best:

{% github tuist/tuist no-readme %}

{% github igor-makarov/xcake no-readme %}

{% github lyptt/struct no-readme %}