Unit testing can be a great tool in order to improve the quality of an app, and to enable the team working on it to iterate and release faster and more often. However, being able to use unit testing in a productive way also requires the various parts of an app to be written with testability in mind, which isn't always the case.

This week, let's take a look at a few different refactoring techniques that can help us make non-testable code much easier to test.

While subclassing is not universally bad, avoiding it can in many situations leave us with simpler code that is easier to change and reuse. This week, let's take a look at a few different techniques that can help us write subclass-free view controllers, and how it can help us avoid the Massive View Controller problem.

View controller containment has been an essential part of UIKit ever since the early days of the iPhone. This week, let's take a look at how we can build our own container view controllers, and how doing so can help us make parts of our UI code more modular and easier to manage.

One of the most important aspects of any app's architecture is how data and models are dealt with. Building a robust model structure and establishing well-defined data flows can really help us avoid a large set of bugs and problems, but at the same time we also need to make our model code easy to use and maintain.

This week, let's take a look at a few different techniques that can help us make code dealing with mutable models a bit more predictable.

This week, let's explore various versions of the commonly used Result type (including the implementation included in the Swift 5 version of the standard library), and some of the cool things it lets us do when combined with some of Swift's language features.

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.