How to add reactive-ness to Clean Swift

I answered different forms of this same questions many times in emails, comments, and my mentorship program. I understand why people ask this question. They’ve seen MVVM, ReactiveCocoa, RxSwift, and want to see if Clean Swift can handle this model-view update automatically.

My answer is always the same. You don’t need it. You don’t need to add yet another dependency just to do this simple thing.

Your interactor can invoke a method of the presenter multiple times, and/or invoke multiple methods of the presenter.

The following is taken directly from a discussion in my mentorship program.

Continue reading →

Organizing source code files by type vs intent

All of us have certainly seen source code files being organized by types. There’s a group named View Controllers, a group named Models, a group named Views, and so on. But organizing by types like this may not be a sound strategy.

Such code organization doesn’t provide any useful context about why you group some files together, while keeping others separate.

It is also redundant. PostsViewController.swift already tells you it’s a view controller. PostView.swift already tells you it’s a view. Putting a view controller file inside a View Controllers group, and a view file inside a Views group isn’t going to help you learn anything new. It feels so redundant just by reading it. Isn’t it?

It doesn’t scale well. When your app is in its infancy with just 5 view controllers, it’s manageable. But when it grows to have 35 view controllers, you’ll have 35 files listed under the View Controllers group.

As programmers, we know vertical screen real estate is at a premium. And most of us are allergic to scrolling. Constant expanding and collapsing groups is just not very productive.

Continue reading →

Full routing analysis

Last time, we looked at the route from the ListOrders scene to the ShowOrder scene in details. This time, we’ll examine all the routes from all the scenes in the CleanStore app, so that you can see how the new and improved router handle other situations.

Routing in Clean Swift is a simple 3-step process:

  1. Getting a hold on the destination
  2. Passing data to the destination
  3. Navigating to the destination

Every route goes through these 3 steps. Step 2 is optional if you don’t have any data to pass. Step 3 is also optional if you use storyboard segue. So routing can be even simpler than this 3-step process.

In other words, if your route is based on storyboard segue and you don’t need to pass data, you can skip steps 2 and 3. If you skip them, that means you don’t need the destination references, and you can skip step 1 too. You don’t have to do anything!

Continue reading →

Error handling in a Clean Architecture

Today, you’ll learn a lot about how to handle errors in a Clean Architecture. As you’ll see from a conversation I had with Łukasz, there’re both complexities and architectural considerations.


Hi Raymond,

My name is Łukasz, I’m the iOS developer from Poland.

First of all, I want to thank you for all the work you’ve put into creating the Clean Swift architecture. After dealing with MVC and MVVM, this looks like a very compelling alternative.

Currently I’m trying to apply this architecture to my own project, and if it works out, I’ll very likely use it in the upcoming project that I’ll be developing in the company that I work for.

However, after studying the Clean Store example for a while, a question about error handling for all those cases when the Worker, and hence the Interactor can fail due to for example no Internet connection while trying to fetch a JSON, arose.

Continue reading →