Apple has suggested a protocol-oriented approach to architecture and they have implied it should be the de facto approach to solving architecture issues in your code. But this is quite impractical with UIKit currently.

The Swift interface for UIKit is mostly generated from Objective-C and as such frequently presents design compromises. Things are improving over time but software development on this scale is slow, so approach each design challenge with an open mind.


The above scene utilises a dedicated object for handling UITableView and a dedicated object for handling UIScrollView. …

Naming tests is a pain right? Why not group them?

Any concerns about this approach, please leave a comment. I would be interested to know what you think.

The meaning of this has matured in recent years. In my opinion, it is now time to sub-divide the concept.

Forward dependency injection

Profile depends on the passed in user object

Reverse dependency injection

Profile depends on the assigned dataSource variable

Inheriting a project from another developer is a challenge, especially if the previous developer is unavailable for questioning and zero documentation has been published. Unfortunately, poor knowledge-transfer between projects is quite common; at least it has been in my experience as an iOS developer; both home and abroad.

The user interface (UI) isn’t always complex or rather the code isn’t always hard to write. But it is often hard to read. Almost every project I have inherited from another developer has been difficult to understand, even if that other developer was my younger self.

UI is often constructed with many tiers of views to form a heirarchy.

Divide and Conquer

Avoid declaring the layout of an…

In my junior days, I blindy commited to the use of a module that handled my persistence layer, because a friend of mine suggested it was decent. It turned out to be a mistake that cost me, and since then I have become very sceptical about third party code.

A module should be like a business franchise, like Starbucks. A turnkey solution that doesn’t require much revision or change going forward. It just works out of the box and is very reliable. …

The Swift ‘guard’ statement seems to be in fashion at the moment and I want to have a mini-rant about it.

The ‘fullName’ variable above is not cool. I appreciate it’s easy to understand and a very contrived example, but even simple code like this seems cluttered when you overuse guard statements, in my opinion.

The above code is essentially saying ‘if there IS NOT a firstName [because firstName is nil, which is expressed as IS NOT nil here] then return nil’.

Why not just tell it like it is?

Avoiding force unwraps is more like obsessive-compulsive disorder…

A convenience model for view controllers


The useful design concept ‘model view view model’ MVVM is widely accepted and simply put acts as a convenience model for a view. Such a model may, for instance, format the data that is about to be presented by the view.

A convenience model is exactly what I propose for view controllers.


First, let’s understand what view controllers are typically responsible for. View controllers are responsible for co-ordinating views, which typically involves passing data them. But view controllers often do the same in reverse by co-ordinating the collection of data from views (and controls etc).

For example

Let’s consider a ‘calendar entry’…

Rob Nash

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store