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 →

Improved routing and data passing

Routing in Clean Swift is the one thing that I wanted to improve the most from the previous version. I’ll walk through a specific, concrete use case first, because it’s easier to read and understand when given a specific context. Then, I’ll generalize it to make it useful for any route in your app.

The specific use case we’ll look at is routing from the ListOrders scene to the ShowOrder scene when the user taps on an order in the table view.

The old way of passing data

While the old way of passing data worked, it didn’t make me proud when writing:

In the above code, we first get the selectedIndexPath of the table view. Next, we retrieve the selectedOrder from the orders array. Finally, we get the destinationViewController from the segue, cast it to the proper UIViewController subclass. The actual data passing is done by setting order to selectedOrder.

This works but there are a couple annoyances.

Continue reading →

Using Swift optionals to simplify asynchronous work

There is a subtle change in the latest template update. The variables viewController, interactor, and presenter are now declared as real optionals using ?. (They were forced unwrapped optionals with ! before.)


There was a situation where it could cause a crash if presenter is deallocated and a method is invoked on it.

This happens when the interactor does some asynchronous work. Before it can finish, the user has navigated away (such as tapping the back button) from the current scene.

Continue reading →