This week, let’s take a look at how we can use the presenter pattern to move some code normally contained within view controllers - specifically related to the presentation of additional UIs - into separate, dedicated types, to improve our separation of concerns.

Proper encapsulation of logic is one of the most important things when it comes to building well-architected apps and systems. This week, let's take a look at how we can better incapsulate our model layer's logic by using model controllers.

Most objects require some form of setup before they're ready to be used in an app. While it’s very common to create subclasses for that purpose, this week, let's take a look at an alternative approach to writing setup code that doesn't require any form of subclassing - by using static factory methods.

One big challenge that most Swift developers face from time to time, is how to deal with Massive View Controllers, both in terms of scope and number of lines of code. This week, let’s take a look at how such view controllers can be broken up using Logic Controllers.

The delegate pattern has long been very prominent on Apple's platforms, and used for everything from handling table view events using UITableViewDelegate, to modifying cache behavior using NSCacheDelegate. This week, let's take a look at a few ways to implement the delegate pattern, along with their pros and cons.

This week, we'll continue exploring various ways to implement the observer pattern in Swift. Last week we took a look at using the NotificationCenter API and observation protocols to enable an AudioPlayer to be observed, and this week we'll do the same thing but instead focusing on multiple closure-based techniques.

Often when building apps, we find ourselves in situations when we need to set up a one-to-many relationship between objects. In such situations, it's very common to want to add some way for certain objects to be observed. We'll start by taking a look at two such observation techniques this week, and then next week we'll continue with a couple of other ones.

Like many abstractions and patterns in programming, the goal of the builder pattern is to reduce the need to keep mutable state - resulting in objects that are simpler and generally more predictable. By enabling objects to become stateless, they are usually much easier to test and debug - since their logic consists only of "pure" input and output.