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 →

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 →