Why my iOS team switched to Clean Architecture

#ios#clean#architecture

Switching to Clean Architecture helped our mobile teams collaborate. It also added boilerplate and complexity, so the decision was not free.

This post explains why we changed our iOS architecture and what happened afterward. If the approach is new to you, read The Clean Architecture first.

The problem we needed to solve#

Before switching to Clean Architecture, we used the View, Interactor, Presenter, Entity, and Router (VIPER) architecture. VIPER is well known in the iOS community, and many companies have adopted it.

Our iOS developers understood VIPER, but developers outside the team did not always know its terms. That difference mattered when we started rotating people across iOS, Android, and Flutter projects.

Without a shared architecture, developers needed more time to understand code from another platform. Even familiar ideas had different names.

The architecture we chose#

After research and discussion, we chose Clean Architecture with model-view-viewmodel (MVVM). Google’s Guide to App Architecture inspired our implementation.

The guide targets Android projects, but its boundaries and terms also made sense for our other mobile platforms.

Why Clean Architecture fit our team#

After comparing Clean Architecture with VIPER, we found these differences:

What changed for us#

We switched to Clean Architecture with MVVM and now use it for new projects. Collaboration across iOS, Android, and Flutter has improved.

Mobile developers can discuss a UseCase, Repository, Domain Layer, or Data Layer with the same meaning. They can also review code from other platforms with less context.

We created a document that explains how to implement Clean Architecture with MVVM on iOS. Its sections cover the Presentation, Domain, and Data layers with code examples.

Detailed iOS application
architecture

We also applied Clean Architecture and MVVM to our iOS templates. The templates give new projects the same starting structure.

Clean Architecture is not a default answer for every project. Discuss the extra boundaries and boilerplate before your team adopts it. For us, the shared cross-platform language made that cost worthwhile.

This change worked because it addressed a collaboration problem that our team could already see. If your team has a similar problem, the same architecture might be worth exploring.

If you have questions, mention me on X or LinkedIn with this post.