Reflection is a common programming language feature that enables us to inspect, and work with, the members of a type — dynamically, at runtime.

That may seem at odds with Swift’s heavy focus on compile-time validation — but this week, let’s take a look at when reflection can come in handy, and how it can let us automate tasks by working with our code in a more dynamic fashion.

Just like sequential code, concurrent code can come in many different shapes and forms. Depending on what we’re trying to achieve, the abstraction that’ll prove to be the best fit might vary quite a lot from use case to use case.

One such abstraction is Tasks, and this week, let’s take a look at some scenarios in which they can become really useful.

When writing automated tests, such as unit tests, many of us have a tendency to focus mostly on verifying that our code behaves correctly under ideal conditions, but we should ideally also test how our code behaves when something goes wrong.

This week, let’s take a look at how unit tests can be used not only to verify correct outcomes — but to verify the correctness of the errors that our code can produce as well.

Whether or not syntactic sugar and other mostly cosmetic code changes actually add value, or whether they cause confusion and complexity, is a common source of debate among developers.

What we ideally want is to be able to strike a nice balance between low verbosity and clarity, and this week, let’s take a look at a few different ways that type aliases can enable us to do just that.

We might not realize it, but most of us share code with other people every single day. However, sharing code in a way that’s clear and effective can be quite difficult — and it’s easy for misunderstandings to happen, and for bugs to start occurring because an API was used “the wrong way”.

So for the 100th weekly article on this site — let’s take a look at what goes into sharing code in a nice way, and some techniques that we can employ to make any code that we share easier to understand.

Networking is a particularly interesting topic when it comes to app development. On one hand, it's something that most apps need — and on the other hand it's something that can be really tricky to get right.

This week, let's take a look at a take on writing networking code that utilizes Apple's built-in URLSession API — but augments it using both Futures & Promises, as well as several functional programming concepts.

While 2018 has been the first year since Swift was introduced in 2014 without a new major release — it has still proven to be quite a transformative year for the language, its usage, and the community as a whole.

Let’s take a quick look back at 2018 — at what has been some of the most popular articles on this site, as well as general trends in the development and usage of Swift.

Designed to be an easy way to quickly prototype a piece of Swift code, to learn the language, or to explore the standard library and Apple’s SDKs — Swift playgrounds have become an integral part of many developers’ daily workflows.

This week, let’s take a look at some tips and tricks that can make working with Swift playgrounds — both in Xcode and on the iPad — easier, less error prone, and more productive.

One of the most challenging decisions that all programmers have to make on an ongoing basis is when to generalize a solution versus just keeping it tied to a specific use case.

This week — let’s take a look at a way of building UIs that might allow us to strike a nice balance between those two approaches — using slots.

How we manage the control flow within the apps and systems that we work on can have a huge impact on everything from how fast our code executes, to how easy it is to debug.

This week, let's take a look at how we can use Swift's built-in error throwing and handling model to make our control flow more clear and predictable.

When getting started with unit testing, it usually doesn't take long to realize that some form of mocking is needed. Although mocking will most likely remain essential for many types of testing, there are also many cases where avoiding mocks can lead to much simpler code - both in terms of testing and actual production code.

This week, let's take a look at some of those cases, and a few different ways to write mock-free unit tests in Swift.

One of the most important roles of any software architecture is to make the relationships between the various objects and values within an application as clear and well-defined as possible.

This week, let's take a look at how we can do that by using Swift's powerful type system to set up locks and keys to get a stronger, compile-time guarantee that the intended flow of our app will remain intact at runtime.

A really elegant aspect of Swift's implementation of optionals, is that a large part of this feature is implemented using the type system - since all optional values are actually represented using an enum under the hood.

That gives us some interesting capabilities, since we can extend that enum to add our own convenience APIs and other kinds of functionality. This week, let's take a look at how to do just that.

Whether or not you believe that the iPad is the future of computing, it does bring a ton of interesting new features and capabilities to the table - especially with the latest release of the Pro version.

This week, let’s take a look at how we as third-party developers can take advantage of some of those capabilities to build interesting new features for our iOS apps.

A race condition is what happens when the expected completion order of a sequence of operations becomes unpredictable, causing our program logic to end up in an undefined state.

This week, let's take a look at a common scenario that can cause race conditions, possible ways to avoid them - and how we can make our code more robust and predictable in the process.

Since Swift was originally designed with a strong focus on compile time safety and static typing, it mostly lacks the sort of dynamic features commonly seen in more runtime-focused languages.

However, Swift keeps gaining more and more features that are more dynamic in nature - while still retaining its focus on type safe code. This week, let’s take a look at how key paths in Swift work, and some of the cool and powerful things they can let us do.

Protocols continue to be an integral part of Swift - both in terms of how the language itself is designed, and also in how the standard library is structured.

This week, let's take a look at how we can use protocols to create multiple levels of abstraction, and try out a few different techniques that let us start out with a more general protocol that we then increasingly specialize to become more and more specific to each use case.

A DSL, short for Domain Specific Language, can be explained as a special kind of API that focuses on providing a simple syntax that's tailored to working within a specific domain.

While DSLs are often written in more dynamic languages, such as Ruby - Swift's type inference and overloading capabilities also make it a really great language to build DSLs in - and this week, let's do just that!

Most modern apps require some form of networking - which means working with URLs in different shapes and forms. However, constructing URLs - especially dynamic ones based on user input - isn't always straight forward, and can lead to a wide range of bugs and problems if we're not careful.

This week, let's take a look at various techniques for working with URLs in Swift, how to make our URL construction code more robust, and how different kinds of URLs might warrant different approaches.

The way that an app’s data is used tends to vary quite a lot depending on what view the data is being displayed in - requiring custom data logic for each view.

View models attempt to make it easier to write and maintain such logic, by introducing dedicated types for it. This week, let’s take a look at a few different ways that various flavors of view models can be implemented in Swift.