We refactor a declarative wrapper around stack views we wrote in episode #7. Instead of wrapping UI controls to provide an interface with callbacks, we write a dedicated target-action class.

This week Lisa joins us to show the test-driven approach to reactive programming they take at Kickstarter.

We look at how we can delete code we wrote in previous episodes by taking advantage of some of the new features in Swift 4.

Brandon from Kickstarter is back to show us how the company uses playgrounds to prototype and style individual view controllers.

We continue to build our PostgreSQL wrapper. This time, we add the possibility of using queries with properly escaped parameters. To achieve this, we have to dive deep into Swift's unsafe pointer APIs.

Brandon from Kickstarter joins us to discuss deep linking into an iOS app. We show how to unify all potential entry points into the app using a common route enum, and then we take a look at this pattern in Kickstarter's open source codebase.

We start writing a lightweight wrapper around the libpq C library to interface with PostgreSQL.

Brandon from Kickstarter joins us and shows how the company uses view models to write highly testable code. We integrate Apple Pay payments and look at Kickstarter's open-source codebase.

We look at multiple ways to create variables that have a class type but also conform to a protocol.

We build the basic routing infrastructure to map paths to the code that should handle a particular request. We take a different approach than most web frameworks in an attempt to make the code type safe and more at home in Swift.

In this first episode about server-side Swift applications, we set up our development environment using Docker and the Swift Package Manager.

We refactor some view controller logic while working on our upcoming tvOS app. Instead of letting multiple view controllers manage the navigation bar's state individually, we pull this code out and unify the logic in one place.

We make our Signal implementation thread-safe by safeguarding the access to shared resources.

In this final episode of our collection series, we make our custom IndexSet collection type conform to the Collection protocol, implementing a custom index type along the way.

We add the ability to map over signals and control subscriptions in a more fine-grained manner. Along the way, we improve the signal ownership model and implement the concept of disposables.

We build upon the Future type of a previous episode to implement a simple reactive library. Along the way, we dive into debugging a reference cycle in our implementation.

In this episode, we make a custom collection conform to Sequence. This allows us to efficiently iterate over the elements, and we gain all the useful functionality of Sequence.

We take a look at how to implement a custom collection type. As an example, we build a simple IndexSet implementation. In upcoming episodes we'll make this type conform to collection protocols.

We look at implementing a Futures type that we can use instead of callbacks. This is the first step toward a simple implementation of a reactive library.

We look at extracting a sorted array type in order to increase code clarity. We'll also make it conform to Collection.

We take a look at reactive programming and see how it challenges us to think differently.

We continue to make the collection extension from the last episode more generic: we implement it on the Sequence protocol and discuss infinite sequences in the process.

We show how to make an extension on array available to other collections: first, we implement it for array slices, then we implement it as a protocol extension for all collections.

We solve an interesting challenge from a Stack Overflow question: mutating a nested untyped dictionary. In the process, we discuss the mutability of value types and the concept of l-values.

We talk about the importance of types and interfaces as tools to express your intent precisely and to set the proper boundaries.

We refactor a class hierarchy using a protocol and discuss the differences between both approaches.

We extend the typed notifications code from the last episode to custom notifications and discuss an alternative protocol-based approach.

We build a lightweight generic wrapper around Foundation's notification API. This allows us to abstract away common boilerplate code and to work with a type-safe interface.

We show how you can build a generic, type-safe table view controller that can display different types of items using multiple cell classes.

We come back to our unfinished Swift Talk iOS app and implement a lightweight network cache for offline support. We keep our networking code from episode #1 untouched to maintain a clear separation of concerns.

We discuss the pros and cons of delegates versus callback functions and why delegate protocols are always class only.

We talk about a familiar but surprisingly tricky problem: splitting an array into groups of elements. We discuss the pros and cons of our own solutions along with the solutions people sent us via Twitter!

We show how we build simple command line tools leveraging the Cocoa frameworks. We use the Swift Package manager to include dependencies in our project.

We look at multiple ways to change structs: mutation, functional chaining, and inout parameters. We discuss how they differ at the call site and why they’re all equivalent.

In this episode we wrap NSMutableData in a struct while maintaining value semantics. Then we implement copy-on-write to make it efficient and discuss how the standard library uses the same approach.

We build a flexible sort descriptor abstraction, similar to NSSortDescriptor, on top of Swift's native sort methods. Because we make use of generics and first-class functions, the result is dynamic and type safe.

In this episode, we implement search functionality for our Ledger GUI app. In the process, we leverage several aspects we've talked about before, such as connecting view controllers, managing application state, and parsing user input.

We connect multiple view controllers using a central coordinating object and callback functions. Then we refactor the UI state into its own struct to simplify the control flow.

We continue to implement some of the more challenging parts of parser combinators. Join us for mental gym session part two!

We implement the basic building blocks of a parser combinator library. Join us in the functional programming gym to stretch your object-oriented comfort zone!

We build a tree structure beginning with a flat array of Ledger account names. We first implement the tree using a class, and then we refactor it to a struct and discuss the differences and tradeoffs involved.

We look at two different techniques to parse a simple expression language: handwritten parsers and parser combinators.

We evaluate transactions using the code from the previous episode. We need continuous refactoring to keep our code simple and clean.

We write an evaluator for a simple expression language. We write our code in a test-driven way, which saves us time and helps us verify the correctness the code.

We show a quick overview of our new project: a bookkeeping app that's based on plain text.

In this episode, we answer some of the questions we've received over the past few weeks. We cover networking, table views, stack views, our App class, and testing.

We extend the networking code from the first episode to support POST requests. Besides using Swift's enums with associated values and generics, we get to implement a map function on a custom data type.

Stack Views are great for prototyping. To make them even easier to set up in code, we create an abstraction using enums to specify UI elements in a declarative style.

We explore how Swift's generics can be used to create a simple, reusable table view controller. As a welcome side effect, this process helps us keep our view controller code clean.

We refactor our code by moving the app's flow from the storyboard into a separate class. Our goal is to manage the view controller flow from a central place so that view controllers don't have implicit knowledge of their context.

We continue building the CommonMark renderer we started in episode #2. This time, we add customizable styles using structs and inout parameters.

Many view controllers have to load data asynchronously. We explore different options to factor out this code using protocols, container view controllers, and generics.

We create attributed strings from CommonMark. We continually refactor our code to make the central logic short and understandable.

We explore an alternative approach to building the networking layer of an app. We make use of Swift's generics and structs to end up with simple, testable code.