Hey! Thanks for stopping by. I’m Raymond Law, and my goal is to teach you everything I know about developing iOS apps using Clean Architecture and unit testing.
How I got started
In my first job out of university, I was responsible for a module that needed to interface with 5 other modules developed by other people and companies simultaneously. Communication can be synchronous and asynchronous, so we would get all kinds of errors, sometimes missing responses.
Essentially, everyone wrote their own code separately according to some predefined specs (waterfall was still main stream at that time).
On integration day, everyone fired up their own module and nothing would work. No one knew exactly why. We all had to bang our heads against the wall, trying to iron out issues while under tremendous stress and managers overlooking our shoulders.
Integration day turned into integration week.
I didn’t want to go through that experience again. Since I had a lot of motivation and worked very fast, I almost always finished my module quickly, before other modules were ready for integration.
With the spare time that I had, I wanted to prove my code work and that it was someone else’s fault if integration didn’t go smoothly. So I wrote classes to represent these other modules, and made them return some expected outputs provided they worked according to the spec.
That’s how I began “testing” my own code.
I wasn’t introduced to formal terminologies such as unit tests, mocks and stubs, dependency injection, single responsibility, or test driven development. But I was essentially mocking other people’s modules, and making sure my module works correctly.
I now realize that’s the essence of testing.
Testing shouldn’t be done as an afterthought by QA. Tests should be written by responsible programmers who care about correctness and not wasting other people’s time.
As a result, during the integration week, I often just sat there and start/stop my module while browsing ESPN at other times. I could name every single player, even the reserves, on every team in the NBA. But I didn’t know who Uncle Bob, Martin Fowler, Kent Beck, or Joel Spolsky were.
I have since practiced these same techniques in all my projects. They have served me very well.
There were situations such as tight deadline and too many developers that I ignored these well established software development principles. Every time, the seemingly quick and small wins often lead to slower and more painful consequences.
It was difficult to get back on track.
In the dark world of iOS
However, these principles seem to get lost in the midst of learning all the cool new frameworks Apple gives us in WWDC every year.
In the week-long WWDC, there are only 2 to 3 sessions on higher level concepts such as architecture and testing. Almost all sessions are about the shiny new frameworks.
I did a search on “architecture” and “testing” in past WWDC sessions, and here is what I found:
WWDC 2015
- Building Better Apps with Value Types in Swift
- UI Testing in Xcode
- Continuous Integration and Code Coverage in Xcode
WWDC 2014
- Core iOS Application Architectural Patterns
- Advanced iOS Application Architecture and Patterns
- Advanced User Interfaces with Collection Views
- Testing in Xcode 6
- Continuous Integration with Xcode 6
WWDC 2013
Nothing in WWDC 2012 and before.
To make matters worse, Apple’s sample code focuses on demonstrating how to use these frameworks by dumping everything in the view controller. Architecture and testing are largely ignored.
If you search for “test” in the developer library sample codes, there is a grand total of 1 sample project on unit testing and code sharing.
Do you know there used to be just one person responsible for the unit testing framework at Apple? And he was new to the Xcode group?
Even when you find a blog post attempting to teach good architecture and unit testing. The examples are too trivial. It makes you wonder how well it will work for larger projects.
As a result, developers just put all the code in the view controller because it’s the most convenient place. In a rush to market, more and more apps were built this way.
At the beginning of the App Store era, it was fine because technical debt and cruft hadn’t accumulated past the intolerable pain threshold.
But we’ve reached that point already.
I’ve been there. I’ve been through all of that. I stumbled forward in the dark for a few years, until I figured out the way forward. And I want to help you do the same.
A brighter future
As iOS development becomes more mature, experienced developers started to realize the problem.
There have been attempts to solve the massive view controller problem such as MVVM and VIPER. But they are not without their shortcomings. MVVM and ReactiveCocoa require you to learn a new paradigm in signal programming, and it deals with only part of the problem. VIPER is incompatible with storyboard segues and the flow of control isn’t any cleaner.
Nowadays, I stick to Uncle Bob’s Clean Architecture in my projects. I also teach other developers these principles that have served me very well throughout my journey.
I am not perfect. No one is. It is very likely that there are better ways to do things, especially as the Swift language continues to evolve. I look forward to connect with you so we can learn and improve together.
My passion is to help you write better code and increase developer happiness on the iOS platform that we all love.
I’ll never be able to reach everyone. But I hope you’ll find the information here useful that you’ll share with your colleagues and friends.
Have a question or want to get in touch? Let’s talk
So why should you listen to me?
There is seemingly a new framework being released every week.
For architecture, we have: MVVM, ReactiveCocoa, VIPER, and many others.
For mocking, we have: OCMock, OCMockito, Specta, OHHTTPStubs, and many others.
For matcher, we have: OCHamcrest, Expecta, Nimble, and many others.
For TDD/BDD, we have: Kiwi, Cedar, Catch, Quick, and many others.
You don’t have time to research and evaluate any of these frameworks, and then find out they aren’t suitable for your project. Or you simply don’t like them. Or you may run into issues and have to hack around it.
Your time is better spent writing your app.
You don’t want to add another 5 CocoaPods for testing purpose. You don’t want to wait for some open source maintainer to keep it up to date for every new Xcode release. You don’t want to wrap your head around advanced Swift features such as generics.
You just need something lightweight for everyday use, something easy to learn for you and your team.
If that’s the case, I encourage you to browse around my site.
Clean Swift is not a framework. It is simply a set of Xcode templates to generate the Clean Architecture components for you.
So you don’t have to write the boilerplate code. You can start writing your first test and implement your first business rule.
Unlike a framework, you can freely modify the templates to suit your needs.
I’ve been developing software professionally for over 15 years, from embedded systems to web apps to mobile apps. My clients range from the government to consultancies to startups. I’ve used languages from Pascal to C++ to Java to Ruby on Rails to Javascript to Objective-C and now Swift.
My belief is that languages and tools do not matter, unless your code base is built with a clean architecture.
Are you ready to level up together?