A quick look at a new, more concise way to unwrap optional values that’s being introduced in Swift 5.7.

New in Swift 5.6: We can now use type placeholders to select what generic types that we want the compiler to infer. Let’s take a look at how those placeholders work, and what kinds of situations that they could be really useful in.

How to use either explicit self references or a capture list to capture self strongly within an escaping Swift closure.

How Swift’s generics system enables us to create specialized extensions that only apply to types that fit certain requirements, and how that capability can be really useful.

How Codable’s auto-synthesis works for enums, and how that part of the system has been upgraded in Swift 5.5 to support associated values.

How Swift 5.5 enables us to conditionally compile postfix member expressions using compiler directives, and what kinds of situations that this new feature could be useful in.

How we can now use Swift’s very convenient “dot syntax” to refer to protocol-conforming types, and how that improves some of SwiftUI’s styling APIs.

What Swift’s @unknown attribute does, and why the compiler tells us to use it when switching on certain enums.

How Swift 5.5 enables computed properties to become either throwing or asynchronous, and what sort of situations that these new capabilities could become useful in.

What sort of capabilities that a mutating Swift context has, and what the mutating and nonmutating keywords do.

Swift’s enums are awesome, but they’re not always the best choice for modeling a given piece of data. Let’s explore why that is, and what other tools that can be good to keep in mind in order to avoid certain problematic enum cases.

How a Swift property wrapper can refer to its enclosing type, and examples of how that capability could be used.

A roundup of some of the key ways in which Swift 5.3 enhances the overall experience of building views using SwiftUI.

An overview of the tools and directives that enable us to influence how our Swift code gets compiled, and what sort of situations that each of those tools might be particularly useful in.

A closer look at Swift’s result builders feature, and how it can give us some really valuable insights into how SwiftUI’s DSL operates under the hood.

A look at a few somewhat lesser-known ways in which enums can be used to solve various problems in Swift-based apps and libraries.

Let’s take a closer look at opaque return types, how they can be used both with and without SwiftUI, and how they compare to similar generic programming techniques, such as type erasure.

Swift enums are really powerful, but they can often be made even more capable when mixed with other kinds of Swift types — such as protocols and structs. This week, let’s take a look at a few examples of doing just that.

This week, let’s take a look at how Swift’s property wrappers work, and explore a few examples of situations in which they could be really useful.

This week, let’s dive deep into the world of pattern matching in Swift — to take a look at how we can construct completely custom patterns, and some of the interesting techniques that we can unlock by doing so.

Swift 5.1 has now been officially released, and despite being a minor release, it contains a substantial number of changes and improvements. This week, let’s take a look at five of those features, and what kind of situations they could be useful in.

This week, let’s take a look at how subscripting works in Swift, and a few different ways to incorporate it into the way we design APIs — including some brand new capabilities that are being added in Swift 5.1.

SwiftUI brings a new, declarative way to build UIs for Apple’s platforms, and also pushes the Swift language itself to new limits — by making heavy use of a set of key new syntax features, that are being introduced as part of Swift 5.1, in order to provide a very DSL-like API. This week, let’s take a first look at those features and how they work.

Being able to express basic values using inline literals is an essential feature in most programming languages. This week, let’s focus on string literals, by taking a take a look at the many different ways that they can be used and how we — through Swift’s highly protocol-oriented design — are able to customize the way literals are interpreted.

One really elegant aspect of Swift’s design is how it manages to hide much of its power behind much simpler programming constructs. Pattern matching is one source of that power, especially considering how it’s integrated into many different aspects of the language.

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 make our code a bit more dynamic.

When using syntactic sugar, 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.

A really elegant aspect of Swift's take on optionals is that they're largely 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.

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.

With each new release, Swift keeps getting better and better at creating compiler-generated implementations of common boilerplate. One such new feature in Swift 4.2 is the new CaseIterable protocol - that enables us to tell the compiler to automatically synthesize an allCases collection for any RawRepresentable enum. This week, let's take a look at some examples of scenarios in which this new feature can come very much in handy.

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.

One really interesting feature of Swift is the ability to create lightweight value containers using tuples. The concept is quite simple - tuples let us 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 interesting opportunities, both in terms of API design and when structuring code.

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, 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 and cons of using them.

Languages that support first class functions enable us to use functions and methods just like any other object or value. We 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".

Even though closures are very widely used, there's a lot of behaviors and caveats to keep in mind when using them. This week, let's take a closer look at closures, how capturing works and some techniques that can make handling them easier.

Using generic type constraints, we are able to add new APIs and behaviors to a type only under a certain set of constraints. This week, let's take a look at some techniques and patterns that are made possible because of type constraints, and how they can be used in practice.

Swift’s @autoclosure attribute enables us to define an argument that automatically gets wrapped in a closure. It’s primarily used to defer execution of a (potentially expensive) expression to when it’s actually needed, rather than doing it directly when the argument is passed.

Lazy properties allow you to create certain parts of a Swift type when needed, rather than doing it as part of its initialization process. This can be useful in order to avoid optionals, or to improve performance when certain properties might be expensive to create. This week, let’s take a look at a few ways to define lazy properties in Swift, and how different techniques are useful in different situations.

One major focus of Swift is compile time safety — enabling us as developers to easily focus on writing code that is more predictable and less prone to runtime errors. However, sometimes things do fail for various reasons — so this week, let’s take a look at how we can handle such failures appropriately, and what tools we have at our disposal for doing so.

While Swift does not yet feature a dedicated namespace keyword, it does support nesting types within others. Let’s take a look at how using such nested types can help us improve the structure of our code.