Apps are no longer short business ventures or proof of concepts that we build, ship and leave. Apps are here to stay. That’s great for us iOS developers, except, we are still yet to evolve as a community. Many of us find ourselves with rigid and fragile code bases where changing existing code is hard and slow. Luckily, we aren’t the first software engineers to seek a solution to this problem. If a flexible code base that responds to change is what you’re looking for, then read on.
Patterns like MVC aren’t a complete architecture and UIViewController does way too much! A use case driven architecture focuses on the behaviour of the app and frees us from being tied into the frameworks we consume and even the platform we are developing for. In short, a clean architecture is the solution; its principles are not new, but they are proven. And the sooner we start adopting clean principles the sooner we can start moving building apps that last.
We should know by now that patterns such as MVC, MVP and MVVM are not enough on their own. Let’s talk about MVC. We know the view shouldn’t contain business logic. But sometimes we come across logic that doesn’t make sense to live in the controller or the model. Where does that go? Well, usually the controller. Before we know it we have a Massive-View-Controller. What we’re lacking is an application architecture which goes beyond MVC. You may not have heard of The Clean Architecture but it is an idea that has been around for a while.
The evils of UIViewController
The fault of the Massive-View-Controller problem doesn’t lie with us alone. Apple have made it really convenient to rapidly develop an app. Think about it. We can use a view controller to manage the life cycle of our views, build and layout UI, navigate and transition to the next view controller. We are also allowed to know about the presenting view controller or navigation controller (if there is one). Every time we subclass UIViewController we inherit all these behaviours – no wonder why we end up in this mess!
A use case driven architecture
The Clean Architecture offers a fresh perspective. Whilst apple’s framework revolves around the front end view controllers, this architecture offers a use case driven approach. The use cases contain business logic that has no bearing on the platform or frameworks involved. The use cases don’t care whether we’re building an iOS or macOS app; they don’t care whether we use Core Data or Realm; or even AlamoFire or NSURLSession. No, the business logic in the use cases is completely independent of any platform or frameworks.
Architecture layers and boundaries
How is an architecture free from platform and frameworks? Well, primarily with the idea of architecture layers and respecting their boundaries. The rules are simple; only an outside layer can know about an inside layer, nothing declared in an inside layer can be referenced in an outside layer, and any data types declared in an outer circle cannot be referenced by an inner circle.
The layers in order from the inner most entity to the outermost frameworks:
Entities – the unchanging business rules.
Use cases – the high level rules of the app.
Adapters – convert logic between the use cases and the view, network, database, or anything else.
Frameworks and platforms – UIKit, iOS, Core Data, Realm, NSURLSession, AlamoFire.
iOS Developers no more!
Final words (for now)
There is so much more to talk about that I can’t cram into this post. Next up is the VIPER architecture and how we can apply The Clean Architecture principles. If you’re interested in reading more about The Clean Architecture then check out the following links: