When writing tests for any application, it's always important to consider what the debugging experience will be like when they eventually start failing. After all, the purpose of all kinds of automated tests is to eventually fail - since it'll let us catch bugs and errors before they reach our users.

This week, let's take a look at a few different scenarios, and how we - with just a few subtle tweaks - can make our tests a lot easier to debug.

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.

When and how to write documentation and code comments tends to be something that causes a lot of debate among developers. This week, let's take a look at a few simple tips and tricks that can let us write code that is more self-documenting - code that makes the underlying intent and details more clear, simply by the way it's structured and how it's written.

While launch arguments are probably most commonly used as input to command line tools - this week, let's take a look at how we can also use the power of launch arguments when working on, debugging, and testing an iOS app.

In most code bases, we need a way to uniquely identify certain values and objects. It can be when keeping track of models in a cache or database, or when performing a network request to fetch more data for a certain entity.

This week, let’s take a look at how we can create type-safe identifiers that enable us to write more robust model handling code.

One big challenge that most Swift developers face from time to time, is how to deal with Massive View Controllers. Whether we're talking about subclasses of UIViewController on iOS & tvOS or NSViewController on the Mac, this type of classes tend to grow very large - both in terms of scope and number of lines of code.

This week, let’s take a look at how Massive View Controllers can be broken up using Logic Controllers.

The delegate pattern has long been very prominent on Apple's platforms. Delegation is used for everything from handling table view events using UITableViewDelegate, to modifying cache behavior using NSCacheDelegate.

Just like the observer pattern, the delegate pattern can be implemented in many different ways. This week, let's take a look at a few of those ways, 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 & output.

This week, let's take a look at how the builder pattern works, what problems it aims to solve, and how it can be used in various situations in Swift.

This week. let's take a look at Swift 4.1's new Conditional Conformances feature, and how it enables us to design code in a much more recursive fashion, making it more flexible while also reducing duplication. We'll take a look at both a simple and more advanced example, and how the standard library uses this new feature.

When developing new features for an app, it can be really useful to have some form of mechanism to gradually roll out new implementations & functionality, instead of having to launch to every single user at once.

Feature flags can act as such a mechanism. They essentially allow us to gate certain parts of our code base off under certain conditions, either at compile time or at runtime. This week, let's take a look at a few different ways that feature flags can be used in Swift.

Something that tends to be particularly tricky when it comes to finding a good balance between convenience & maintainability, is when setting up relationships between the view layer and the model layer. This week, let's take a look at a few different ways that we can decouple our UI code from our model code, and some of the benefits of doing so.

One really interesting feature of Swift is the ability to create lightweight value containers using tuples. The concept is quite simple - tuples let you easily group together any number of objects or values without having to create a new type. But even though it's a simple concept, it opens up some really cool opportunities, both in terms of API design and when structuring code.

This week, let's take a look at how we can use tuples in our code, and some of the techniques that they enable us to use.

Although Set is one of those core data structures that you see in almost every programming language - it sometimes get a bit overlooked as our default choice for storing collections of non-keyed objects tend to be to use an Array.

This week, let's take a look at a few different examples of when using a set can lead to more predictable performance & simpler code, as well as how to use some of Swift's Set type's lesser known - yet very powerful - features.

One of the biggest challenges when working on a continuously evolving code base is to keep things nicely encapsulated. Adding new capabilities without leaking abstractions can be really tricky.

This week, let's take a look at a few techniques that can let us define more clearly encapsulated APIs in different situations.

Every app that doesn't only consist of one single UI needs some form of navigation - to enable users to move between different screens and to display information or react to events.

This week, let's take a look at a few different options for dealing with navigation in Swift apps, focusing on iOS this time.

When starting to work with tests, there's one problem in particular that almost every developer runs into - how to test asynchronous code. While we've touched on this subject before, this week, let's focus in on a few different techniques that can help make testing asynchronous code a lot easier.

Few Swift features cause as much heated debate as the use of custom operators. While some people find them really useful in order to reduce code verbosity, or to implement lightweight syntax extensions, others think that they should be avoided completely.

This week, let's take a look at a few situations that custom operators could be used in, and some of the pros & cons of using them.