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.

Composition is a super useful technique that lets us share code between multiple types in a more decoupled fashion. It's often posed as an alternative to subclassing, with phrases like "Composition over inheritance" - which is the idea of composing functionality from multiple individual pieces, rather than relying on an inheritance tree.

This week, let's take a look at a few situations in which composition can be used with structs, classes and enums in Swift.

Almost every Swift program uses collections in one way or another. Whether it's to store values to be displayed in some form of list, to keep track of observers, or caching data - collections are everywhere.

This week, let's take a look at some of the standard library APIs that lets us easily transform collections in a very functional way.

Mocking is a key technique when it comes to writing unit tests in pretty much any language. Whether we're testing networking code, code relying on hardware sensors like the accelerometer, or code using system APIs like location services - mocking can enable us to write tests a lot easier, and run them faster in a more predictable way.

This week, let's take a look at a few different situations and how mocking can be used - or avoided - to make our tests easier to write, read and run.

Languages that support first class functions enable you to use functions and methods just like any other object or value. You can pass them as arguments, save them in properties or return them from another function. In order words, the language treats functions as "first class citizens".

This week, let's take a look at a few different ways that first class functions can be used in Swift!

Separation of concerns is a core principle when it comes to designing architectures and systems that are easy to maintain. It's the idea that each object or type should only know enough about its surroundings to do its work, and no more.

However, even though it's a principle most programmers learn about early in their career, it's not always very easy to apply in practice. This week, let's take a look at how to more easily separate the concerns of various types in Swift using protocols.

In previous posts, we've taken a look at a few different ways to use dependency injection to achieve a more decoupled and testable architecture in Swift apps. So far, most of my posts and examples have used initializer-based dependency injection. However, just like with most programming techniques, there are multiple "flavors" of dependency injection - each with its own pros & cons. This week, let's take a look at three such flavors and how they can be used in Swift.

UI testing can be a really useful tool in order to assure that the key user interactions of your app work as expected. Maybe even more importantly though, it's a great way to add an extra level of protection against regressions as you are continuously changing and refactoring your code base.

This week, let's take a look at how to add UI tests to verify an app's analytics code, and how it can be a great way to quickly gain a broad UI testing coverage.

Gathering some form of analytics from your users is super important when continuously building, iterating on and improving a product. Learning how your users use your app in real life situations can sometimes be really surprising and take its development in new directions or act as inspiration for new features.

This week, let's take a look at how an analytics system can be architected and implemented, based on one of my favorite Swift features - enums!