How modularity changed not only our code, but also the whole process

When we started to modularize our application, we didn't even know how drastically our development process will change as a result. Just like many others, we decided to do this only when compile time went beyond all reason and the build simply started to crash because of excessively long compile commands. But now we use modularity mainly to organize concurrent feature development in separate projects, and the problem of long compilation with minimum expenses is not that critical.

There have already been talks on this topic, but back in the day we couldn't find answers to specific questions: on what modules should we divide our application? How should we connect them? When it's time to stop? Which tools can make the process easier? How to arrange all that in order to make creating separate project for each feature comfortable? In this talk, we'll cover all these questions, discuss the pitfalls of using CocoaPods, backup tooling, working with tests, through case histories see how to organize dependency inversion between modules, and finally talk about what we got in the end and at what price.

Multimodularity completely changed not only our code, but also our process, our attitude towards the project. This talk's purpose is to help you avoid possible mistakes and encourage you to try this approach even if you don't have to face the big monolith problem.