Adding new features to an app or framework often involves adding new arguments to existing functions. While most such changes may seem trivial at first, if we're not careful, we could - over time - end up with functions that are a bit unclear and cumbersome to use. This week, let's take a look at how to deal with such functions, and how they often can be simplified by reducing the number of arguments they accept.

Type inference is a key feature of the Swift type system and plays a big part in the syntax of the language - making it less verbose by eliminating the need for manual type annotations where the compiler itself can infer the types of various values.

This week, let's take a look at how we can make Swift's Codable API a bit nicer and less verbose to use, by leveraging the power of type inference.

One thing that almost all apps and frameworks have in common is that they tend to grow in both size and complexity as time passes. As a project grows it becomes more and more important to maintain a solid and consistent structure, but at the same time it also becomes increasingly difficult to do so.

This week, let's take a look at some tips and tricks as to how we can improve the structure of our Swift projects in a few key ways.

Adding new features to existing code can be really challenging - especially if that code is heavily used throughout one or many projects. Backward compatibility can in many ways help us make such changes in a much smoother fashion, so this week, let's take a look at a few different techniques that can help us make changes to our code base fully backward compatible.

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.

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.