Clean Swift Implemented in iOS and Android
I recently came across Real Swift, a framework for Swift implementing Uncle Bob’s Clean Architecture. I quickly fell in love with the ideals it encapsulated. Of course I had grown frustrated with Apple’s approach at MVC. Apple’s documentation suggests you follow an MVC pattern, but iOS’s main component is called
UIViewController… Just from the name alone, we’ve already encroached on the idea of MVC!
After looking into
Clean Swift, it sounded like a dream come true. After all, TDD is something we all (should) strive for. Writing all your code in a way that it is easily testable means that your code has a clear purpose, even if you don’t write those tests (but seriously, you should write those tests).
So I decided to embark on a journey to adopt this architecture. Luckily, I was at a point where we needed to do a major redesign of our iOS and Android apps. Since the UI was changing significantly, I opted to completely rewrite the apps. Not only would we have to make major changes to our UI, we could also implement our newly found architectural approach.
Clean Swifts founder Raymond Law was very gracious to me. I often reached out to him through email and the project’s Slack channel. He pointed me in the right direction and considered my feedback as I worked through a production level implementation of his framework. For the most part, the framework was as-promised. Most things have a well defined place inside the framework, and we were able to build out a fully-functioning app with the ideals of
Clean Swift in mind.
One point that was less clear was the conversion between each class’s representation of some data. The
View all have protocols (or interfaces), so it was well defined from the perspective of our code. But deciding which class held the responsibility of making the conversion from one representation to the next was really up to our team’s preference.
Ultimately, it didn’t really matter. The important part was that we developed a cohesive strategy and we were consistent with it. After all, frameworks are only effective if they are adhered to by the team implementing them.
Because the strategy is so well defined, we were able to take Raymond’s iOS templates (modifying them slightly to our needs) and built out our own templates for Android. Because there are a lot of files in this structure, the templating saved us a lot of time.
However, even with the templating in place we found that there was a lot of overhead in terms of file count. While everything was well defined, it was also a lot of work.
At the end of our re-write, we ended up with a perfectly functional app. The
Clean Swift architecture served us well. Because all of our code followed this methodology, we were able to thoroughly test almost all of our code with relative ease. Each class has a defined protocol/interface, so it was clear to write tests around those methods and easy to mock out behavior. This is where
Clean Swift shines.
I learned a lot from the
Clean Swift mantra. The ideals of
Clean Swift are great! But they don’t come without a cost. To do things strictly by the book, you end up with a lot of boilerplate code. Every single screen (
Fragment) ends up with a
Router at a minimum. You still need some kind of
Worker classes to perform things extraneous to the VIP cycle (networking, caching, etc).
So what? Boilerplate code exists in almost any framework. But does it make your life easier?
If you really grasp Clean Swift, you will have a good understanding of where certain responsibilities should live. There are a handful of grey areas where you have to decide where some conversions happen, but once you settle on an answer as a team, that’s not such a big deal.
The real win here is Unidirectional Data Flow. Unidirectional data flow results in very testable code. And if you write it the right way, you end up with pure, functional methods, which are easily testable.
We ultimately ended up moving in another direction, but not one far-removed from
Clean Swift. We kept everything we learned in mind.
Clean Swift was a great jumping off point, and you won’t regret following the principles Raymond and Uncle Bob set forward.