Top-notch video tutorials for Swift developers

In this episode we'll examine a type that has too many responsibilities and refactor it into multiple types, each with their own responsibility.

This episodes kicks off a new series on SOLID principles for improving at object-oriented design. Writing better code means writing code that costs less to change, which can be a crucial factor in delivering project successfully. In this series we will see how these principles apply to Swift.

In this episode we continue with our caching example, this time introducing a new type that will handle the caching for us, as well as wrapping the response type into a new type that will indicate to the view controller if the response was served from the cache or from the network. We end the episode by implementing Equatable so that our store can avoid needless double callbacks if the data has not changed.

In a recent project I leveraged the Codable protocol to save API responses to disk to make the application more responsive (and to have an offline mode). I was happy with the results. In this episode we will add some caching to an existing application, saving JSON responses to the caches directory on the device.

Codable is a great API, but sometimes real APIs can be tricky to model. In this episode we’ll examine a real use case of an API that returns a collection of elements, each of them similar but specified by a type. We’ll leverage Codable and inheritance to create a representation of this structure and show how you can peek into the container in order to determine what type to decode.

We tackle some more complex (read: realistic) scenarios where the JSON structure doesn’t quite match the structure of the objects. We’ll do this by providing custom implementations of Encodable and Decodable, talk about keyed and unkeyed containers, and how you might be able to transform the date during the encoding process

Swift 4 finally answers the long-debated question of: How should I parse JSON with Swift? In this episode we'll take a look at the new Codable protocol in Swift 4, and talk about how to use JSONEncoder and JSONDecoder to serialize your objects into JSON and back again.

We finish the CloudKitNotesManager by providing a generic save and delete methods that we can use for any CKRecordWrapper type. We also implement a custom notification when a note is saved so that we can update an interested view controllers to update their UI.

In this episode we implement a CloudKit version of our NotesManager protocol. Along the way we'll implement a reusable query function and run into a limitation with Swift generics that we will have to work around.

Since our model objects will be backed by a CKRecord, we will leverage computed properties to marshal values back and forth to the record. Doing so in a type safe way gets pretty redundant, so we can reuse a lot of this boilerplate code by extracting a protocol we’ll call CKRecordWrapper. We can leverage this protocol to give us type-safe access to record keys and to provide default implementations of identifier, modifiedAt, and createdAt fields.

So far in this series we've been using CloudKit directly from our controllers. This can be somewhat limiting. It requires you to be online or everything fails, we may want to add a caching layer, or we might want to use CloudKit as a network synchronization layer, rather than a primary data store. In this episode we'll examine an architecture that will allow you to decouple your view controllers from CloudKit as a first step to achieving more flexibility with your CloudKit implementation.

In the refactoring series, Soroush mentioned a protocol he uses to make initializing view controllers from a storyboard as easy as adopting a protocol (and completely type-safe). In this episode we will build this using Swift protocol extensions. The end result is something you can easily carry with you from project to project.

Writing boilerplate code can get tedious and boring. It can also lead to code duplication, which means it becomes a liability to keep in sync. Sourcery is a code generation tool that can help leverage your existing types and reflect on them in order to generate useful bits of code. In this episode Sam Soffes shows us how to install and use Sourcery, how to integrate it with Xcode’s build system, and how to create a simple Sorcery template to automatically count the number of items in a Swift enum and add it as an option.

In this episode we cover some lesser-known features of Swift, including @discardableResult, escaping closures, defer, and using dump versus print for better debugging output.

In this final episode in the Poker Hands Kata with Soroush Khanlou, we finish off by improving the design of our program, improving our tests, and implementing the remaining features for detecting the more complicated hands.

In this episode I am joined again by Soroush Khanlou. We continue our exploration of the Poker Hands kata, focusing on fleshing out our types. We also begin matching poker hands, leveraging enums with associated types.

In this episode I am joined by Soroush Khanlou. Together we pair up to implement the Poker Hands Kata. We start off by parsing the raw string input into structured types, complete with tests.

In this episode we will implement the Yahtzee Kata, which entails scoring hands based on dice rolls. We'll look at leveraging protocols and protocol extensions to mix & match shared behaviors across disparate types in order to perform matching and scoring of the dice.

In the last episode we showed how to run Swift tests automatically with guard, but it wasn't an ideal setup. We couldn't see compiler errors, nor could we see any output from our program using print. In this episode we leverage Ruby's open3 library to capture stdout and stderr so we can output it to the terminal in the appropriate colors.

Code Katas are interesting challenges that can help you practice programming. Some are extremely difficult and others are fairly easy, but they all allow us to exercise the act of programming. Doing code katas can help you learn a new programming language, a new algorithm, or a new style of programming.In this episode we’ll tackle one of the most trivial katas: FizzBuzz.

Swift 3 is now out and contains a host of new features and syntax changes. In this episode we'll look at a few of the more common changes you'll run into when upgrade projects to Swift 3 including implicit method argument labels, dropping the NS prefix on a bunch of classes, and the new Swift API naming guidelines.

In this free episode, we take a look at a core Swift 2 feature: Optionals. Unlike Objective-C, where nil is considered a no-op, in Swift nil is specifically recognized by the compiler, which forces you to handle cases where nil might be present in a variable.

In this episode we cover a horribly named, yet fairly powerful concept called flat map. We'll use this technique to solve the problem we discovered last time dealing with Result<T> and having to use a switch statement everywhere.

In this episode I talk about the pattern of communicating errors in Cocoa and how it can be improved by leveraging features in Swift. By introducing a Result type that is generic and applies to any type, it appears useful, however we run into some cumbersome use cases that will require further discussion.