We are going to take a Swift feature into the browser. We will set up a WebAssembly application from scratch, show how to run and debug it, and even set up some basic UI. And then we will integrate our existing model into it, all powered by the magic of Swift’s Observation framework.

It’s time to go cross-platform! We will take a feature written in Swift and use it in vastly different situations, including not only SwiftUI and UIKit, but beyond Apple’s frameworks and ecosystems. We will start with a baby step and introduce our feature to a third party view paradigm, Airbnb’s Epoxy.

We finish building a modern UIKit application with brand new state-driven tools, including a complex collection view that can navigate to two child features. And we will see that, thanks to our back-port of Swift’s observation tools, we will be able to deploy our app all the way back to iOS 13.

As we approach WWDC24 and 5 years of SwiftUI, let’s talk about… UIKit! 😜 We love SwiftUI, but there will still be times you must drop down to UIKit, and so we want to show what modern UIKit development can look like if you put in a little bit of effort to build tools that allow you to model your domains as concisely as possible.

We conclude the series by stretching our use of the @Shared property wrapper in isowords to two more features: saved games and user defaults. In the process we’ll eliminate hundreds of lines of boilerplate and some truly gnarly code.

Let’s apply the Composable Architecture’s new state sharing tools to something even more real world: our open source word game, isowords. It currently models its user settings as a cumbersome dependency that requires a lot of code to keep features in sync when settings change. We should be able to greatly simplify things with the @Shared property wrapper.

We finish refactoring the SyncUps application to use the Composable Architecture’s all new state sharing tools. We will see that we can delete hundreds of lines of boilerplate of coordination between parent and child features, and we won’t have to sacrifice any testability, including the exhaustive testability provided by the library.

In our last series we developed a wonderful way to share state between features in the Composable Architecture, and even persist it, all without sacrificing testability, but we also didn’t get to show the (just now released) tools being used in real world applications, so let’s do just that, starting with SyncUps.

We’re about to completely revolutionize the Composable Architecture with Swift’s new Observation framework! But first, a sneak peek: we’ll take the public beta (available today!) for a spin to see how the concept of a “view store” completely vanishes when using the new tools.

Oh, and did we mention that the new observation tools in the library have been backported all the way back to iOS 13? This means you can use the tools immediately. 🤯

Let’s take our MacroTesting library for a spin with some more advanced macros, including those that Apple has gathered since the feature’s introduction, as well as a well-tested library in the community: Ian Keen’s MacroKit.

Macros are here! To celebrate, we are releasing a brand new tool to aid in writing tests for them. First, let’s explore testing macros using the tools that Apple provides, evaluate their shortcomings, and see how we can address them.

The Composable Architecture has reached a major milestone: version 1.0. To celebrate this release we are doing a fresh tour of the library so that folks can become comfortable building applications with it in its most modern form. We will start with a simple, but substantial application that shows off the basics, before we recreate Apple’s most complex sample project.

We explore a few more advanced scenarios when it comes to async code—including cancellation, async sequences, and clocks—and how difficult they are to test.

While Swift provides wonderful tools for writing async code, there are gaps in its tools for testing it. Let’s explore the tools it does provide to show where they succeed, and where they fall short.

Our first ever livestream! We talk about a few new features that made it into our Dependencies library when we extracted it from the Composable Architecture, live code our way through a NavigationStack refactor of our Standups app, and answer your questions along the way!

What goes into building a SwiftUI application with best, modern practices? We’ll take a look at Apple’s “Scrumdinger” sample code, a decently complex app that tackles many real world problems, get familiar with how it’s built, and then rewrite it!

A year ago we dove deep into the topic of navigation in SwiftUI. Then Apple deprecated many of those APIs at this year’s WWDC, replacing them with a brand new suite. To make sense of these changes, let’s recap what we built over those past episodes, and why.

We celebrate the release of the Composable Architecture’s new reducer protocol and dependency management system by showing how they improve the case studies and demos that come with the library, as well as a larger more real-world application.

The Composable Architecture was first released over two years ago, and the core ergonomics haven’t changed much since then. It’s time to change that: we are going to improve the ergonomics of nearly every facet of creating a feature with the library, and make all new patterns possible.

This week we are releasing the biggest update to the Composable Architecture since its first release over 2 years ago, bringing more of Swift’s modern concurrency tools to the library. To celebrate we will demonstrate how these tools can massively simplify a few real-world applications.

The Composable Architecture’s fundamental unit of effect is modeled on Combine publishers because it was the simplest and most modern asynchrony tool available at the time. Now Swift has native concurrency tools, and so we want to make use of those tools in the library. But first, let’s see what can go wrong if we try to naively use async/await in an existing application.

We conclude our tour of swift-parsing with a look at how URL routers defined as parser-printers can be automatically transformed into fully-fledged API clients, which we will drop into an iOS application and immediately use.

Now that we’re familiar with swift-parsing’s URL router, let’s take a look at Swift’s most popular web framework, Vapor. We will rebuild our site router using Vapor’s built-in router, and then we’ll use our own companion library to power our Vapor application with a parser-printer, instead.

URL routing is a large problem that has been solved in various ways over the years…but what does that have to do with swift-parsing!? A lot! swift-parsing comes with a URL routing library built on top of parser-printers, and it solves a lot of problems that still exist in today’s most popular web frameworks.

We continue our tour by comparing swift-parsing to Apple’s forthcoming Regex DSL. After taking a look at the proposal, we’ll translate an example over to be a parser-printer to compare and contrast each approach.

Today we celebrate a huge release of swift-parsing, which includes the ability to build invertible parser-printers with ease. We’ll demonstrate by using the library to build three different parser-printers, starting with a fun exercise from Advent of Code

We’ve talked about modularity a lot in the past, but we’ve never devoted full episodes to show how we approach the subject. We will define and explore various kinds of modularity, and we’ll show how to modularize a complex application from scratch using modern build tools.

We finish our search-based application by adding and controlling another MapKit API, integrating it into our application so we can annotate a map with search results, and then we’ll go the extra mile and write tests for the entire thing!

Let’s develop a new application from scratch to explore SwiftUI’s new .searchable API. We’ll use MapKit to search for points of interest, and we will control this complex dependency so that our application can be fully testable.

Let’s explore another API just announced at WWDC: @FocusState. We’ll take a simple example and layer on some complexity, including side effects and testability, and we’ll see that the solution we land on works just as well in the Composable Architecture!

The Composable Architecture does not yet support any of the fancy new concurrency features from WWDC this year, so is it possible to interact with async/await APIs like .refreshable? Not only is it possible, but it can be done without any changes to the core library.

Let’s take a look at the new refreshable API in SwiftUI. We will explore how to add it to a feature, how it depends on Swift’s new async/await tools, and how to introduce cancellation.

We typically rewrite vanilla SwiftUI applications into Composable Architecture applications, but this week we do the opposite! We will explore “deriving behavior” by taking an existing TCA app and rewriting it using only the SwiftUI tools Apple gives us.

We wrap up our tour of isowords by showing off two powerful ways the iOS client and Swift server share code. Not only does the same code that routes server requests simultaneously power the API client, but we can write integration tests that exercise the full client–server lifecycle.

It’s time to take a look at the other half of the isowords code base: the server! We’ll get you running the server locally, and then explore some benefits of developing client and server in Swift, such as simultaneously debugging both applications together, and sharing code.

Let’s dive deeper into the isowords code base. We’ll explore how the Composable Architecture and modularization unlocked many things, including the ability to add an onboarding experience without any changes to feature code, an App Clip, and even App Store assets.

In past episodes we took a peek behind the curtains of our recently released iOS game, isowords. Now it’s time to dive deep into the code base to see how it’s built. We’ll start by showing our modern approach to project management using SPM and explore how the Composable Architecture powers the entire application.

We’ve shown how to dramatically streamline forms in the Composable Architecture, but it’s time to ask “what’s the point?” We apply the concepts previously developed to a real world application: isowords. It’s a word game built in the Composable Architecture, launching soon.

It is well accepted that hand-rolled, imperative parsers are vastly more performant than parsers built with combinators. However, we show that by employing all of our performance tricks we can get within a stone’s throw of the performance of imperative parsers, and with much more maintainable code.

SwiftUI has introduced the concept of “████ed views”, which gives you a really nice way to ████ the text and images from views. This is really powerful, but just because the view has been ████ed it doesn’t mean the logic has also been ████ed. We show why this is problematic and why we want to fix it.

We conclude our tour of the Composable Architecture by demonstrating how to test a complex effect. This gives us a chance to show off how the library can control time-based effects by using Combine schedulers.

It’s time to start proving that our business logic works the way we expect. We are going to show how easy it is to write tests with the Composable Architecture, which will give us the confidence to add more functionality and explore some advanced effect capabilities of the library.

Continuing the tour of our recently open-sourced library, the Composable Architecture, we start to employ some of the more advanced tools that come with the library. Right now our business logic and view is riddled with needless array index juggling, and a special higher-order reducer can clean it all up for us.

It’s our 100th episode 🎉! To celebrate, we are finally releasing the Composable Architecture as an open source library, which means you can start using it in your applications today! Let’s take a tour of the library, see how it’s changed from what we built in earlier episodes, and build a brand new app with it.

In this week’s free holiday episode we show what it looks like to snapshot test a SwiftUI application in our architecture and compare this style of integration testing against XCTest’s UI testing tools.

We’ve made testing in our architecture a joy! We can test deep aspects of our application with minimal ceremony, but it took us a whole 18 episodes to get here! So this week we ask: what’s the point!? Can we write these kinds of tests in vanilla SwiftUI?

Now that we’ve explored the Combine framework and identified its correspondence with the Effect type, let’s refactor our architecture to take full advantage of it.

Let’s explore the Combine framework and its correspondence with the Effect type. Combine introduces several concepts that overlap with how we model effects in our composable architecture. Let’s get an understanding of how they work together and compare them to our humble Effect type.

With our moderately complex SwiftUI application complete we can finally ask ourselves: “what’s the point!?” What does SwiftUI have to say about app architecture? What questions are left unanswered? What can we do about it?

This week we finish up our moderately complex SwiftUI application by adding more screens, more state, and even sprinkle in a side effect so that we can finally ask: “what’s the point!?”

Let’s begin exploring application architecture by understanding what are the common problems we encounter when trying to build large, complex applications. We will build an app in SwiftUI to see how Apple’s new framework approaches solving these problems.

Today we finally extract our enum property code generator to a Swift Package Manager library and CLI tool. We’ll also do some next-level snapshot testing: not only will we snapshot-test our generated code, but we’ll leverage the Swift compiler to verify that our snapshot builds.

Let’s put some finishing touches to our random artwork generator, incorporate it into an app, and write some snapshot tests to help support us in adding a fun easter egg.

Now that we have made randomness both composable and testable, let’s have a little fun with it! We are going to explore making some complex generative art that is built from simple, composable units.

Our snapshot testing library is now officially open source! In order to show just how easy it is to integrate the library into any existing code base, we add some snapshot tests to a popular open source library for attributed strings. This gives us the chance to see how easy it is to write all new, domain-specific snapshot strategies from scratch.

Templating languages are the most common way to render HTML in web frameworks, but we don’t think they are the best way. We compare templating languages to the DSL we previously built, and show that the DSL fixes many problems that templates have, while also revealing amazing compositions that were previously hidden.

The third, and final, part of our introductory series to zip finally answers the question: “What’s the point?”

Join us for a tour of the code base that powers this very site and see what functional programming can look like in a production code base! We’ll walk through cloning the repo and getting the site running on your local machine before showing off some of the fun functional programming we do on a daily basis.

Swift 4.1 deprecated and renamed a particular overload of flatMap. What made this flatMap different from the others? We’ll explore this and how understanding that difference helps us explore generalizations of the operation to other structures and derive new, useful code!

What does the Swift type system have to do with algebra? A lot! We’ll begin to explore this correspondence and see how it can help us create type-safe data structures that can catch runtime errors at compile time.

We bring tools from previous episodes down to earth and apply them to an everyday task: UIKit styling. Plain functions unlock worlds of composability and reusability in styling of UI components. Have we finally solved the styling problem?

Side effects: can’t live with ’em; can’t write a program without ’em. Let’s explore a few kinds of side effects we encounter every day, why they make code difficult to reason about and test, and how we can control them without losing composition.

Our first episode is all about functions! We talk a bit about what makes functions special, contrasting them with the way we usually write code, and have some exploratory discussions about operators and composition.

Point-Free is here, bringing you videos covering functional programming concepts using the Swift language. Take a moment to hear from the hosts about what to expect from this new series.