Why & How to Implement Clean Architecture for iOS/Android

What is Clean Architecture and Why Should You Use It?

If you’re the kind of person who can’t stay focused without an organized desktop (both on your monitor and on your literal, physical desk), chances are that you’ll love clean architecture. And even if you’re not the hyper-organized type, you’ll be able to appreciate how it streamlines the mobile development process. To me personally, clean architecture turns mobile app development into a work of art.

First popularized by Agile Manifesto co-author Robert C. Martin (more commonly known as “Uncle Bob”), clean software architecture is the idea that you can modularize the different functions of an application so that each component is separate and can be updated and tested independently. This makes the application easy to maintain, extensible, and testable because working with one module won’t impact the other modules unintentionally.

A well-built clean architecture usually consists of at least four high-level layers, which Martin defines as:

• Entities: Enterprise-wide business rules
• Use Cases: Application-specific business rules
• Interface Adapters: Convert data from the Entity and Use Case levels into the format that works best for the Frameworks and Drivers layer
• Frameworks and Drivers: I/O components like the database, web framework, user interface, or devices

Clean architectures are those that do a good job of separating the above concerns, making it easier for both current and future developers to understand exactly what’s going on in an application.

If you’re a new engineer joining a mobile app development project, seeing a clean architecture already in place is like a breath of fresh air, because it means that there’s likely less untangling you’ll have to do to make changes as the product evolves. It should be clear exactly where each piece of code belongs, increasing your efficiency and driving down time-to-market.

Common Clean Architecture Patterns

In iOS and Android development specifically, there are a number of different patterns developers you can use that follow clean software architecture principles. A couple that I like to use include:

Model-View-ViewModel (MVVM)

This pattern encapsulates some of the logic that you’d usually have within a View Controller by separating the GUI (or the View) from the business logic (or the Model) underneath. The ViewModel, meanwhile, manages the interactions between the GUI and the business logic.

For iOS development, in particular, you can also work in flow coordinators within this pattern. Usually, to transition between views in a model application, you’d end up writing repetitive code and add it to your logic flow. The flow coordinator, however, automates that process while also separating this concern so it can be modified independently.

View, Interactor, Presenter, Entity, Router (VIPER)

One of my favorite clean patterns, VIPER, is more granular than MVVM and is widely used when an application’s requirements are already well-formed.

Similar to the general clean architecture layers, each letter in VIPER stands for a different layer with a different purpose:

View: Displays information from the Presenter and sends input from the user back to the Presenter

Interactor: Business logic layer, dependent on the Use Case rules (see above)

Presenter: Sends information to the View layer and reacts to user inputs sent from the View layer

Entity: Contains model objects that the Interactor uses

Router: In charge of navigation, or which screens are shown to the user in which order
VIPER takes away much of the repetitive code and redundancies you’d encounter outside of a clean pattern so that everything is organized and operates more efficiently.

How Can You Transition to Clean Architecture?

If you’re starting a mobile development project from scratch, implementing clean architecture is simply a matter of selecting the right patterns, tools, languages, and teammates to build something that follows clean guidelines. Hand-me-down projects, however, can present more challenges. How do you transition to clean architecture when you’re starting with something really messy?

The short answer is that you implement clean architecture the same way you eat an elephant – one bite (or step) at a time.

While it might be tempting – especially in moments of frustration – to do a complete refactor when you’re dealing with messy code and architecture, business realities usually don’t allow for those kinds of changes. Starting from the ground up would likely be a months-long project that most clients, whether internal or external, wouldn’t be too happy about (and understandably so).

Instead, you’ll have to go slowly. While it may seem at first like untangling a complex knot, the end result will be more efficient code and architecture throughout the application, which means better future efficiency and resiliency as the app changes hands.

If your project is ongoing or needs a new feature added, this is a great opportunity to start implementing a clean architecture. You can create a subdirectory just for the new section or feature that you’re working on, and start to separate everything into layers based on the pattern you’ve chosen.

Before you know it, you’ll have one module that’s very nicely architected and written. As you move on to older, messier sections, you can apply the pattern from the new module to gradually transition to something cleaner.

This approach isn’t without its challenges, however. Sometimes, you’ll encounter features for which software developers have previously written tests. When you try to refactor the feature, the test breaks because it’s dependent on the original code. In these situations, you may have to adjust your plan to get the best result, as adapting the tests themselves can prove even more complex and time-consuming.

Transitioning to clean architecture will be a gradual process, and the plan you follow will depend on your organization’s own goals and priorities. Do what you can, and try not to break anything. Ultimately, the work you do will likely be an upgrade to what was there before and will set up your product for success.