Handling asynchronous code in a way that is predictable, readable and easy to debug can be really challenging. It's also something that is very common, almost all modern codebases have parts that are highly asynchronous - whether that's loading data over the network, processing big datasets locally or any other computationally intensive operations.

This week, let's take a look at a technique that can make managing asynchronous calls a bit simpler and less error prone - using tokens.

Ever since blocks were introduced into Objective-C as part of iOS 4 they have been an important part of most modern APIs for Apple's platforms. The convention of using blocks also carried over to Swift with closures, which is a language feature that most of us use every single day.

But 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.

We all use open source code every day. Whether it’s by directly pulling in a framework in one of our apps, or indirectly in almost all of the apps, tools and utilities that we all use to get our work done as developers. So open source is incredibly important for our industry, and it's big reason why I love the Swift community so much.

This week I thought I’d try to sum up most of my tips & tricks on how to publish a new Swift open source project.

"I know singletons are bad, but...", is something that developers often say when discussing code. There seems to almost be a consensus in the community that singletons are "bad", but at the same time both Apple and third party Swift developers keep using them both internally within apps and in shared frameworks.

This week, let's take a look at exactly what the problems are with using singletons and explore some techniques that can be used to avoid them.

Using generic type constraints, you are able to only add certain APIs and behaviors to implementors of a generic type that match 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 - focusing on some of the new capabilities that were recently introduced with Swift 3.1 & 4.

While switch statements are hardly something that was invented as part of Swift, they are made a lot more powerful when combined with Swift's type system.  This week - let's go further beyond switching on single enum values and take a look at more of the powerful capabilities that switch statements offer in Swift.

When creating collections of objects or values in Swift, we usually use data structures provided by the standard library - such as Array, Dictionary and Set. While those three cover most use cases, sometimes creating a custom wrapper collection can enable you to make your code more predictable and less prone to errors.

This week, let's take a look at how we as app developers can define such custom collections in Swift!

Assertions are not only an essential tool when writing tests - they're also super useful in order to write more predictable and easier to debug code.

This week, let's look deeper into assertions, how they work and how we can implement our own assert() functions for performing various checks.

Shared state is a really common source of bugs in most apps. It's what happens when you (accidentally or by design) have multiple parts of a system that rely on the same mutable state.

This week, let's take a look at how shared state can be avoided in many situations, by using the factory pattern to create clearly separated instances that each manage their own state.

If you have ever pushed a pixel onto the screen of an Apple device, you have used Core Animation - either directly or indirectly. 

In this new (non-consecutive) series of posts - "Core Animation Gems" - we'll take a closer look at some less widely known features and APIs, and how they can be used to solve problems related to animation and rendering in a nice way. This week, let's kick it off with the first one - CAReplicatorLayer.

An important part of maintaining any app, framework or system is dealing with legacy code. No matter how well architected a system is, legacy will always be built up over time - it can be because of changes in an underlying SDK, because of an expanded feature set, or simply because no one on the team really knows how a particular part works.

This week, let's take a look at a technique that I usually use when dealing with legacy code - that lets you replace a problematic system class by class, rather than having to do it all at once.

To celebrate 6 months of weekly Swift blog posts - let's take a look back at the first 26 posts. I'll list my personal favorites, as well as the ones that have been the most popular with the community.

Asynchronous programming is arguably one of the hardest parts of building most apps. Because of this, many solutions have been invented to try to combat the above problem - basically creating abstractions around asynchronous programming to make it easier to understand and reason about.

This week, let's take a look at one such solution - Futures & Promises - and go a bit "under the hood" to see how they actually work.

Flakiness is what happens when tests don't run consistently - when you get different outcomes depending on time, which machine they're being run on, or whether they're run on CI or on the computer you work on.

This week, let's take a look at some easy-to-apply tips and tricks that can help you reduce flakiness in your tests, and make them more predictable and easier to run in any environment.

This week, let's finish building the animation framework that we started in last week's post! We'll continue building a declarative animation API, that will now also support sequencing of animations performed on multiple views.

This week, let's take a look at how we can make view-based animations (animating individual UIViews, like buttons and labels) on iOS easier to handle - by building a simple framework that will enable us to express animations in a very declarative, composable way.

We often encounter situations when we need to find a way to store objects based on some concept of identity. Whether it's in a cache, storing representations of objects on disk, or simply using a dictionary - we often need to find ways to uniquely identify objects that we deal with.

Let's take a look at some of those ways, and how we can use them for objects and values.

Almost all modern apps use JSON in one way or another. Whether it's for configurations, to store local data or to download information over the network - JSON is everywhere.

This week, let's take a look at how we can set up our JSON mapping tests to make them a lot more robust and future proof, and how we can use them to perform end-to-end testing.

One of the hardest things when building apps and designing systems is deciding how to model and deal with state. Code managing state is also a very common source of bugs, when parts of our app might end up in a state we didn't expect.

This week, let's take a look at some techniques that can make it easier to write code that handles and reacts to state changes - to make it more robust and less error prone.

Animations are a great way to explain the functionality of our apps through motion, and to delight our users. Adding animations in the right places can really make a UI look a lot more polished and nice.

This week, let's take a look at how SpriteKit can be a great tool for creating certain kinds of animations.