Up to 3 hours per day were spent just waiting source code to be compiled. Sick! Right? They knew that they were spending a lot of time simply on waiting, but they didn’t know how big the problem was.

Of course, it doesn’t mean that while the project was building they were staring at the screen and waiting until build was finished. But definitely they weren’t writing code at that moment. It’s almost impossible to do something like that while project is building. At least, not on their MBPs.

By simply moving release and testing builds on Jenkins, they decreased build times to under 1 hour per day.

The spike on the right was at the day when Jane was playing with compilation flags, and tried to decrease build times for the main project. So she had a lot of full-clean builds that day. You can see it by small light-green area on the top graph (which represents clean events)

Splitting to pods (Failure)

Right after vacation John was pretty sure that they need to split project to prevent full-project recompilation problem which was happening very often. Somehow the full-project recompilation was happening only if some files were edited. John and Jane spent a lot of time trying to understand what was causing the full-recompilation, but, unfortunately they failed. It was happening in some files while it worked fine in others. And they haven’t found any valid answers. But they tried a lot. Once per month they were returning to this question again and again, but right after moving to files that weren’t causing full-recompilation they hoped that this would never happen again.

Since they weren’t able to track down the reason why incremental compilation was failing all the time, they decided to simply move parts of code to different pods.

The plan

If you think that this was easy, I would assure you — it wasn’t. The project was in that state when it’s really hard to separate something into a module. They failed at first try

They tried to move some part of the project to pod(“Awesome Feature”), and failed. They tried to move one part and then realized that they needed to move dependencies as well… Finally they realized that they would need to move everything to the “Awesome Feature”. While it potentially was a solution, that they could be living with, there weren’t able to test that the whole migration went fine, because there were too many lines of code dependent on resources in main bundle.

So they stopped and decided to go with another “Cool Feature” pod. And then they failed again.

The fact

Splitting to pods (Success)

Week later they changed approach and tried again. After almost a week of trying, they knew, what parts of the project could be separated, and what parts were really hard to separate(BFS (Big “Functional” Storyboard))

They created two pods Utils and Models and started to move files one by one. If they weren’t able to move some files, they were adding //TODO: comments to come back to those files later. A lot of tests were added to cover moved files, just to freeze up functionality before next rounds of refactoring.

These pods weren’t that big. Utils pod, was simply a container of helpers — functions and extensions they were using everywhere. Models pod contained base domain models and code that performed transformation from JSON to Models and back. All logic that was in domain models was covered with tests in transition process.

What was the result? They were able to move only about 10% of code to the submodules, but that was enough to decrease compilation time(in worst case scenario) by almost 25%.

Also, moving domain objects and related parsing to Models pod allowed them to perform pretty fast transition to the new API, almost without touching main project.

Splitting to pods (Success again)

Next time, when totally new “Gorgeous feature” came in, John and Jane already knew what to do. They immediately started new pod specifically for this feature. They created separate example project which allowed to jump right to this new feature without even running whatever was in the main project. By doing this, our iOS engineers were able to achieve blazingly fast development speed. And they were spending about ~10x less time waiting for builds.