The project I will take as an example for this article is a project with multiple “modules”. “Core” modules contain code that can be used everywhere in the application: some standard components, helper functions to have easy access to the keychain, extension of dependencies, etc. “Libraries” modules hold business logic; a module corresponds to a certain part of the business. Finally, each “feature” module contains a navigation flow of the application. On top of that, we have an “app” module that links everything.
These modules are Xcode projects that generate frameworks, except for the “app” one that generates the application. All of these projects are contained in an Xcode workspace.
Each project is a bit special :
There are dependencies between these projects: in this case, they are added as “Non-embedded” frameworks.
The project uses Carthage as its dependencies manager. The external dependencies are already pre-compiled and available in the Carthage/Build folder, and it avoids the issue of the non-support of Cocoapods by Tuist.
The first step is to convert each project to Tuist: we should be able to generate them with the command tuist generate.
Since the syntax to generate a project is a bit verbose, we first created a template that fits our needs.
This content should be put in a file Tuist/ProjectDescriptionHelper/Project+Template.swift near every existing Xcode project. At the end, the duplicates will be deleted, but this allows us to do the conversion project by project.
Our config is very close to the default suggested by Tuist, so we don’t have that much change to do.
As you can see, all use cases described in the previous section are handled as parameters of this function. And it helps us to reduce the content of the Project.swift file. For example, here is the project containing the code to do API calls.
As you can see, external dependencies are for now manually linked as external xcframework at their old installation path. This will change when dependencies will be handled by Tuist.
Our process was to convert project by project, cleaning the Xcode cache and rebuilding the app every time. This way, we were quickly able to know if there was an error during our conversion process. We could also stop at any time and merge the current work if needed since nothing was broken.
Next, we attacked the main project, the one building the app. This one has a config too different to use the pattern presented in the previous section.
First of all, it has a notification service extension. This target needs to be declared in the Project.swift for this module. This target has a specific configuration. To be sure not to forget anything, we extracted the configuration in a readable way. Tuist has a command for this:tuist migration settings-to-xcconfig -p Project.xcodeproj -t ServiceExtension -x ServiceExtension.xcconfig
We read this xcconfig file to add the following configuration and create the target.
⚠️ A little warning, we had to change the plist for this extension target and add the CFBundleExecutable and CFBundleName keys. Otherwise, the app could not be installed on the simulator.
Then, it was time to attack the main target: the application. We used the same Tuist migration command to extract the configuration.
The app target is very similar to the extension service. Just don’t forget to add the scripts you created for your app target and the dependencies, like this :
With these two targets, the project itself is quite short:
Finally, there is just the workspace file to create at the root of the project
You can now delete all the project helper files in the project folders and put it only of the root of the workspace. When you do a tuist edit at this level, you should see the workspace, all the project files in their folder, and the project helper.
And if you run tuist generate, the workspace should generate as it was before. You should be able to build, test and archive.
If everything is working fine, you can delete the project files and git ignore them: everything will be generated by Tuist. When doing so, don’t forget to add the command tuist generate -n to your CI / CD before trying to build everything.
⚠️ If you have an error, check that you named correctly your schemes and target. If something changed, the command lines break.
Now it is time to remove the xcframework path you had to put everywhere. As explained before, Tuist support both Carthage and SPM. On our project, it allows us to do a smooth transition between these two systems, waiting for the SPM support by the dependencies.
First, we created the Dependencies.swift file at the root of the project and fill it with our dependencies, all in the Carthage section. Then, we ran the tuist fetch command (and waited a bit since Carthage can be a bit long). When it is done, we replaced all the .xcframwork references with the path by external with just the name of the dependency.
You will notice that Tuist handle automatically the status of the framework (embed and sign or do not embed): it differentiates static and dynamic framework, no more need to read precisely the documentation of the libraries to find this information.
After one successful build, we started moving dependencies from the Carthage array to the SPM array. One thing to note is that the dependencies can not exist in both systems at the same time. You may also delete the files in the Carthage folder.But you can’t mix the two systems any way you want. If lib B depends on lib A, they both need to be handled by the same system.
Following these steps, we had a smooth transition between automatic xcodeproject files and Tuist. We encountered only a few errors that you can see next to the ⚠️ icon in this article. It reduced drastically the number of git conflicts we have had since. And the onboarding cost for the new devs is not as big as expected.