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.

While the documentation for Equatable discusses the notions of “equivalence relation” and “substitutability”, there are conformances in the Standard Library that run afoul, but for pragmatic reasons. Let’s explore them and then dive deeper into a related protocol: Hashable.

In this series we go back to basics with a deep dive into the subject of Equatable types. Equatability is a deceptively simple topic. It is a surprisingly tricky protocol that has some very specific semantics that must be upheld baked into it, and there are many misconceptions on how one can or should conform types to this protocol.

We round out our series with one more feature: the ability for our users to manage a list of their favorite facts. It will allow us to explore a complex side effect, persistence, and show how the same Swift code can save and load data across iOS app launches and web page refreshes.

We’ve already covered a lot of ground and could have ended the series last week, but let’s do a few more things to show just how powerful cross-platform domain modeling can be by adding a new feature to our cross-platform application and see just how easy it is to integrate with SwiftUI, UIKit, and WebAssembly.

We will introduce UI controls and focus logic to our SwiftWasm application by leveraging a binding type inspired by SwiftUI, and we will see how similar even our view logic can look across many platforms.

We will introduce navigation APIs to our Wasm application, starting simply with an alert before ramping things up with a dialog tag that can be fully configurable from a value type that represents its state and actions.

Let’s dial up the complexity of our Wasm application! We’ll introduce some async logic in the form of a network request. We’ll take steps to not only control this dependency, but we’ll do so across both Apple and Wasm platforms, and we’ll isolate its interface from its live implementation to speed up our builds and reduce our app’s size.

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.

While we rebuilt SwiftUI bindings in UIKit to power state-driven navigation, that’s not all SwiftUI uses them for! Let’s see what it takes to power UIControls from model bindings. And finally, let’s ask “what’s the point?” by comparing the tools we’ve built over many episodes with the alternative.

We round out our stack navigation tools with support for an @Environment-like feature for holding onto the stack’s path, a NavigationLink-like feature for pushing features onto the stack from anywhere, and we’ll handle every corner case from deep-linking to user dismissal.

We have now implemented tree-based navigation in UIKit, driven by the Observation framework, but there is another form of navigation to think about: stack-based navigation, where you drive your navigation from a flat collection of states rather than a heavily-nested type. Let’s leverage Observation to build a really nice tool for stack-based navigation.

While SwiftUI bindings were almost the perfect tool for UIKit navigation, they unfortunately hide some crucial information that we need to build out our tools. But never fear, we can rebuild them from scratch! Let’s build @Binding and @Bindable from scratch to see how they work, and we will use them to drive concise, tree-based navigation using enums.

We have built the foundation of powerful new UIKit navigation tools, but they’re not quite finished. Let’s improve these APIs to handle dismissal by leveraging another SwiftUI tool: bindings. We will see how SwiftUI bindings are (almost) the perfect tool for UIKit navigation, and we will see where they fall short.

Now that we have a tool that brings the power of the Observation framework to UIKit, let’s put it through the paces. We will use it to build state-driven navigation tools that can drive alerts, sheets, popovers, drill-downs, and more, and they will look a lot like SwiftUI’s navigation tools.

It’s time to build modern tools for UIKit from scratch, heavily inspired by SwiftUI and using the Observation framework. Surprisingly, Swift 5.9’s observation tools can be used in UIKit, and in fact they work great, despite being specifically tuned for SwiftUI.

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.

It’s incredible how easy @Shared makes it to persist complex data types to the file system, but currently it completely ruins our ability to test features that use it. Let’s fix that, and we will also explore what it means to derive a small piece of shared state from a bigger piece of shared state.

While user defaults is convenient for persisting simple bits of state, more complex data types should be saved to the file system. This can be tricky to get right, and so we take the time to properly handle all of the edge cases.

We can now persist simple bits of state to user defaults using the @Shared property wrapper, but there is more work to be done. We need to observe changes to user defaults in order to play those changes back to @Shared, and we need to put in a bit of extra work to make everything testable.

Let’s enhance the @Shared property wrapper with the concept of persistence. We will begin with user defaults, which is the simplest form of persistence on Apple’s platforms, and that will set the stage for more complex forms of persistence in the future.

We will employ @Shared’s new testing capabilities in a complex scenario: a sign up flow. We will see how a deeply nested integration of features all sharing the same state can be tested simply, and we will see how we can leverage the same tricks employed by the test store to add debug tools to reducers using shared state.

The @Shared property wrapper can effortlessly share state among features to build complex flows quickly, but because it is powered by a reference type, it is not compatible with the Composable Architecture’s value-oriented testing tools. Let’s address these shortcomings and recover all of the library’s testing niceties.

We finish building a complex, flow-based case study that leverages the new @Shared property wrapper. Along the way we will flex recently added superpowers of the library, and we will experience firsthand how simple this new model of shared state can be.

The various approaches of sharing state in the Composable Architecture are mixed bag of trade offs and problems. Is there a better way? We’ll take a controversial approach: we will introduce a reference type into our state, typically a value type, and see what happens, and take it for a spin in an all new, flow-based case study.

We tackle one of the biggest problems when it comes to “single source of truth” applications, and that is: how do you share state? Let’s begin by analyzing the problem, and truly understanding what vague mantras like “single source of truth” even mean, and then we will be in a good position to provide a wonderful solution.

To celebrate our 6th anniversary we had another livestream! We updated an app from the most recent Composable Architecture tour to the latest observation tools, showed how these tools can improve UIKit-based apps, showed off some recent enhancements to the @Reducer macro, gave a sneak peek of a highly anticipated topic, and answered your questions along the way.

So what’s the point of observation in the Composable Architecture? While we have seemingly simplified nearly every inch of the library as it interfaces with SwiftUI, let’s zoom out a bit, explore how some integration tests that benchmark certain aspects of the library have changed, and migrate the Todos application we built in the very first tour of this library to the new tools.

We have iterated on how bindings work in the Composable Architecture many times, but have never been fully happy with the results. With Observation, that all changes. By eliminating view stores and observing store state directly, we are free to totally reimagine bindings in the Composable Architecture, and get rid of even more concepts in the process.

Observation has allowed us to get rid of a number of view wrappers the Composable Architecture used to require in favor of vanilla SwiftUI views, instead, but we still depend on a zoo of view modifiers to drive navigation. Let’s rethink all of these helpers and see if we can trade them out for simpler, vanilla SwiftUI view modifiers, instead.

We can now observe struct, optional, and enum state in the Composable Architecture, but what about collections? Let’s explore what it takes to get rid of the ForEachStore wrapper view for a vanilla ForEach view instead, while still observing updates to collection state in the most minimal way possible.

We’ve made structs and optionals observable in the Composable Architecture, eliminating the need for ViewStores and IfLetStores, so what about enums? If we can make enums observable, we could further eliminate the concept of the SwitchStore, greatly improving the ergonomics of working with enums in the library.

The Composable Architecture can now observe struct state, but it requires a lot of boilerplate. Let’s fix this by leveraging the @Observable macro from the Swift open source repository. And let’s explore what it means to observe optional state and eliminate the library’s IfLetStore view for a simple if let statement.

One of the core tenets of the Composable Architecture is that you should be able to model your application’s state using simple value types, like structs and enums. However, the @Observable macro does not work with value types at all, and so in order to enhance the Composable Architecture with Observation we will need to contend with this issue and explore what it means for a struct to be observable.

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

We have now totally reimagined the design of our case paths library to create actual key paths for enum cases, but there is some boilerplate involved. Let’s create a macro that eliminates all of it and explore a few of the possibilities it unlocks.

“Case paths” grant key path-like functionality to enum cases. They solve many problems in navigation, parsing, and architecture, but fall short of native key paths…till now. Let’s close this gap using macros that generate actual key paths to enum cases.

We take all we’ve learned about the Observation framework and apply it to a larger, more real world application: our rewrite of Apple’s Scrumdinger demo. We’ll see what changes are easy to make, what changes are a bit trickier, and encounter a bug that you’ll want to know about.

We’ve explored the present state of observation in Swift, so what’s the future have in store? Currently, observation is restricted to classes, while one of Swift’s most celebrated features, value types, is left out in the cold. Let’s explore a future in which observation is extended to value types.

While the @Observable macro improves upon nearly every aspect of the @State and @ObservedObject property wrappers, it is not without its pitfalls. We will explore several gotchas that you should be aware of when adopting observation in your applications.

The @Observable macro is here and we will see how it improves on nearly every aspect of the old tools in SwiftUI. We will also take a peek behind the curtain to not only get comfortable with the code the macro expands to, but also the actual open source code that powers the framework.

It’s time to dive deep into Swift’s new observation tools. But to start we will take a look at the tools SwiftUI historically provided, including the @State and @ObservedObject property wrappers, how they behave and where they fall short, so that we can compare them to the new @Observable macro.

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.

We conclude the series by adding the final bit of functionality to our application: persistence. We’ll see how adding a dependency on persistence can wreak havoc on previews and tests, and all the benefits of controlling it.

We introduce a complex dependency to the record meeting screen: speech recognition. We will begin to integrate this dependency into our app’s logic, and show how to control it for Xcode previews and tests

We’ll learn how to precisely model navigation in the Composable Architecture using an enum to eliminate impossible runtime states at compile time. And we’ll begin to implement the app’s most complex screen and most complex dependency: the record meeting view and the speech client.

We show how to add stack-based navigation to a Composable Architecture application, how to support many different kinds of screens, how to deep link into a navigation stack, and how to write deep tests for how navigation is integrated into the application.

With the standups list and standup form features ready, it’s time to integrate them together using the Composable Architecture’s navigation tools. We will make it so you can add and edit standups via a sheet, and write comprehensive unit tests for this integration.

We continue our tour of the Composable Architecture 1.0 by rebuilding one of Apple’s most complex sample projects: Scrumdinger. We will create our own “Standups” app using the tools of the Composable Architecture.

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.

What’s the point of the work we did to make async testing reliable and deterministic, and are we even testing reality anymore? We conclude our series by rewriting our feature and tests using Combine instead of async-await, and comparing both approaches.

We continue our deep dive into advanced Swift concurrency by exploring the concept of “executors” to better understand its global enqueue hook. We will then put this hook to work and finally have reliable, 100% deterministic async tests.

We dive into Apple’s Async Algorithms package to explore some advanced usages of Swift’s concurrency runtime, including a particular tool we can leverage to bend the will of async code to our advantage in tests.

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.

We complete the series by writing a comprehensive test suite for our stack navigation-based app. We will uncover some shortcomings of the tools we’ve built and address each one, resulting in a set of tools that are a joy to test with.

We round out the functionality of the Composable Architecture’s stack navigation tools. This includes automatic cancellation of a child feature’s effects when it’s popped off the stack, and the ability for a child feature to pop itself. Along the way we will clean up the domain modeling and user experience of working with these tools.

We introduce a complementary StackState wrapper to our navigation tools to solve a few issues that came from repurposing the identified array type. Once implemented and integrated, we will put these tools’ superpowers to work by implementing two new features.

We begin designing brand new navigation stack tools for the Composable Architecture to solve all of the problems we encountered when shoehorning stack navigation into the existing tools, and more.

Let’s insert a new feature into the navigation stack. We’ll take things step-by-step, employing an enum to hold multiple features in a single package, and making small changes to how we use our existing APIs before sketching out all-new tools dedicated to stack navigation.

We enhance our navigation stack with a bit more complexity by adding the ability to drill down multiple layers in multiple ways: using the new navigation link API, and programmatically. We also prepare a new feature to add to the stack.

It’s finally time to tackle navigation stacks in the Composable Architecture! They are a powerful, new tool in SwiftUI and stray a bit from all the other forms of tree-based navigation we’ve explored. Let’s compare the two styles and see what it takes to integrate stacks into the library’s navigation tools.

We take a detour to learn about the stack, the heap, copy-on-write, and how we can use this knowledge to further improve our navigation tools by introducing of a property wrapper.

We now support many different forms of navigation in the Composable Architecture, but if used naively, they open us up to invalid states, like being navigated to several screens at a time. We’ll correct this with the help of Swift’s enums.

While we just tackled drill-down navigation, sadly the API we used was deprecated in iOS 16. Let’s get things working with the new navigationDestination view modifier, and see what testing in the Composable Architecture has to say about navigation.

We have a single navigation API powering alerts, dialogs, sheets, popovers, and full screen covers, but what about the prototypical form of navigation, the one that everyone thinks of when they hear “navigation”? It’s time to tackle links.

Let’s prepare to delete a lot of code. The navigation APIs we’ve built so far to drive alerts, dialogs, and sheets all have more or less the same shape. We can unify them all in a single package that can also be applied to popovers, fullscreen covers, and more!

We add superpowers to the navigation tools of the Composable Architecture, including automatically cancelling a child feature’s effects upon dismissal, and even letting child features dismiss themselves! Plus, we look at how “non-exhaustive” testing simplifies navigation-based tests.

We tackle a more complex form of navigation: sheets! We’ll start with the tools the Composable Architecture ships today before greatly simplifying them, taking inspiration from the tools we built for alerts and dialogs.

Let’s dip our toes into the new composable navigation tools by improving how alerts and confirmation dialogs can used in the library. We will create a new reducer operator that more correctly handles the logic and hides unnecessary details.

It’s finally time to tackle navigation in the Composable Architecture. We’ll port the Inventory app we first built to understand SwiftUI navigation, which will push us to understand what makes the architecture “composable,” how it facilitates communication between features, and testing.

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!

We conclude the series by taking control of the last two dependencies: persistence and speech recognition. We’ll make use of even more features of our new Dependencies library and we’ll write tests for our features that would have been impossible before.

Uncontrolled dependencies can wreak havoc on a modern SwiftUI code base. Let’s explore why, and how we can begin to control them using a brand new library.

We wrap up the “record meeting” screen by implementing two more side effects: speech recognition, and persistence. We’ll experience the pitfalls of interacting directly with these dependencies, and why we should care about controlling them.

After a brief digression to explore the performance and ergonomics of identified collections, we dive into the messy world of side effects by implementing the “record meeting” screen. We’ll start with the timer, which has surprisingly nuanced logic.

We add more screens and more navigation to our rewrite of Apple’s Scrumdinger, including the standup detail view, a delete confirmation alert, and we set up parent-child communication between features.

We begin to layer on behavior in our rewrite of Apple’s “Scrumdinger” demo application, starting with navigation. We will do some upfront work to model it in our application state, as concisely as possible, to avoid a whole class of bugs, unlock deep linking, and enable testability.

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!

When all-new SwiftUI navigation tools were announced at WWDC, the one that got the most attention by far was NavigationStack, which powers navigation with an array. It is extremely powerful, but comes with trade-offs and new complexities.

Why did Apple scrap and reinvent SwiftUI’s navigation APIs in iOS 16? Let’s look at some problems the old APIs had, how one of the new APIs solves one of them, and how we can work around a bug in this new API.

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.

With “immediate” and “unimplemented” conformances of the Clock protocol under our belt, let’s build something more complicated: a “test” clock that can tell time when and how to flow. We’ll explore why we’d ever need such a thing and what it unlocks.

The Clock protocol is a brand-new feature of Swift 5.7 for dealing with time-based asynchrony. We will explore its interface, compare it to Combine’s Scheduler profile, and see what it takes to write and use our own conformances.

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.

Testing is a top priority in the Composable Architecture, so what does the reducer protocol and new dependency management system add to testing features? It allows us to codify a testing pattern directly into the library that makes our tests instantly stronger and more exhaustive.

We now have a SwiftUI-inspired system for plucking dependencies out of thin air to provide them to reducers, but we can’t control them or separate interface from implementation. Once we do, we’ll have something far better than ever before.

We begin to flesh out a new story for dependencies in the Composable Architecture, taking inspiration from SwiftUI. We will examine SwiftUI’s environment and build a faithful reproduction that provides many of the same great benefits.

The new reducer protocol has improved many things, but we’re now in an awkward place when it comes to defining them: some are conformances and some are not. We’ll fix that with inspiration from SwiftUI and the help of a new protocol feature.

We are already seeing huge benefits from the reducer protocol, but one aspect is still not ideal, and that is how we compose reducers. We will look to result builders to solve the problem, and a new feature of them introduced in Swift 5.7.

Let’s begin to solve a number of the problems with the Composable Architecture by introducing a reducer protocol. We will write some common conformances and operators in the new style, and even refactor a complex demo 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.

We explore ways to tie the lifetime of an effect to the lifetime of a view, making it possible to automatically cancel and tear down work when a view goes away. This unexpectedly helps us write even stronger tests for our features.

We introduce another helper to the Effect type that can use an asynchronous context to send multiple actions back into the system. By leveraging Swift’s structured concurrency we can create complex effects in a natural way, all without sacrificing testability.

We can now run async work directly in a reducer’s effects, but time-based asynchrony, like Task.sleep, will wreak havoc in our tests. Let’s explore the problem in a new feature, and see how to recover the nice syntax of modern timing tools using a protocol from the past: Combine schedulers.

This week we start fixing the problems we outlined last week. We build the tools necessary to start using concurrency tasks directly in reducers, and along the way we open Pandora’s box of existential types to solve some mind-bending type issues.

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.

There are amazing features of Swift concurrency that don’t quite fit into our narrative of examining it through the lens of past concurrency tools. Instead, we’ll examine them through the lens of a past programming paradigm, structured programming, and see what is has to say about structured concurrency.

When working with concurrent code, you must contend with data synchronization and data races. While the tools of the past made it difficult to reason about these issues, Swift’s new tools make it a breeze, including the Sendable protocol, @Sendable closures, and actors.

Let’s look at what the future of concurrency looks like in Swift. A recent release of Swift came with a variety of tools with concurrency. Let’s examine its fundamental unit in depth, and explore how they “cooperate” in your applications.

Before developing Swift’s modern concurrency tools, Apple improved upon threads with several other abstractions, including operation queues, Grand Central Dispatch, and Combine. Let’s see what these newer tools brought to the table.

To better understand Swift’s concurrency tools, let’s first look to the past, starting with threads. Threads are a tool most developers don’t reach for these days, but are important to understand, and the way they solve problems reverberate even in today’s tools.

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 conclude our series on invertible parsing by converting a more complex parser into a parser-printer, and even enhance its format. This will push us to think through a couple more fun parser-printer problems.

We’ve had to really stretch our brains to consider what it means to reverse the effects of parsing, but let’s looks at some parsers that take it to the next level. They will force us to reconsider a fundamental part of printing, and will make our printers even more powerful.

Our parser-printer library is looking incredible, but there’s a glaring problem that we have no yet addressed. We haven’t been able to make one of our favorite operations, map, printer-friendly. The types simply do not line up. This week we will finally address this shortcoming.

Our parser-printer library is looking pretty impressive, but there are a couple problems we need to address. We have made some simplifying assumptions that have greatly reduced the generality our library aspires to have. We will address them by abstracting what it means for an input to be parseable and printable.

We will chip away at more and more parser printer conformances, some of which will truly stretch our brains, but we will finally turn our complex user CSV parser into a printer!

Now that we’ve framed the problem of printing, let’s begin to tackle it. We will introduce a Printer protocol by “reverse-engineering” the Parser protocol, and we will conform more and more parsers to the printer protocol.

We’ve spent many episodes discussing parsing, which turns nebulous blobs of data into well-structured data, but sometimes we need the “inverse” process to turn well-structured data back into nebulous data. This is called “printing” and can be useful for serialization, URL routing and more. This week we begin a journey to build a unified, composable framework for parsers and printers.

Let’s make errors a pleasure to encounter! We will make them easy to read, add more context to make them easy to debug, and even see how error messages can influence existing APIs.

Let’s explore the topic of error handling. We will scrutinize how we model errors in our parsing library and the problems that have come out of it, and we will address these problems by changing the fundamental shape of the parser type.

So what is the point of parser builders anyway? We will leverage our new builder syntax by rewriting a couple more complex parsers: a marathon parser and a URL router. This will lead us to not only clean up noise and tell a more concise parsing story, but give us a chance to create brand new parsing tools.

Let’s begin to layer result builder syntax on top of parsing. To get our feet wet, we will build a toy result builder from scratch. Then, we will dive much deeper to apply what we learn to parsers.

Let’s revisit a favorite topic: parsing! After a short recap, we will theorize and motivate the addition of result builder syntax to our parsing library, which will help unlock a new level of ergonomics and API design.

We finish modularizing our application by extracting its deep linking logic across feature modules. We will then show the full power of modularization by building a “preview” application that can accomplish much more than an Xcode preview can.

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 porting our SwiftUI application to UIKit by introducing a collection view. Along the way we will demonstrate how deep-linking works exactly as it did in SwiftUI, and we show the power of state driven navigation by seamlessly switching between the two view paradigms.

What does all the work we’ve done with navigation in SwiftUI have to say about UIKit? Turns out a lot! Without making a single change to the view models we can rewrite the entire view layer in UIKit, and the application will work exactly as it did before, deep-linking and all!

We’ve claimed that the way we handle navigation in SwiftUI unlocks the ability to deep link to any screen in your application, so let’s put that claim to the test. We will add real-world deep linking to our application, from scratch, using the parsing library we open sourced many months ago.

Over the past weeks we have come up with some seriously powerful tools for SwiftUI navigation that have allowed us to more precisely and correctly model our app’s domain, so let’s exercise them a bit more by adding more behavior and deeper navigation to our application.

Let’s explore “tag” and “selection”-based navigation links in SwiftUI. What are they for and how do they compare with the link and link helpers we’ve used so far? We will then take a step back to compare links with all of the other forms of navigation out there and propose a “Grand Unified Theory of Navigation.”

It’s time to explore the most complex form of navigation in SwiftUI: links! We’ll start with some simpler flavors of NavigationLink to see how they work, how they compare with other navigation APIs, and how they interact with the tools we’ve built in this series.

Now that we’ve built up the tools needed to bind application state to navigation, let’s exercise them. We’ll quickly add two more features to our application, beef up our navigation tools, and even write unit tests that assert against navigation and deep-linking.

This week we’ll explore how to drive a sheet with optional state and how to facilitate communication between the sheet and the view presenting it. In the process we will discover a wonderful binding transformation for working with optionals.

It’s time to look at a more advanced kind of navigation: modals. We will implement a new feature that will be driven by a sheet and can be deep-linked into. Along the way we’ll introduce a helper to solve a domain modeling problem involving enum state.

We continue our journey exploring navigation with an examination of alerts and action sheets. We’ll compare their original APIs in SwiftUI to the ones that replace them in the SDK that just shipped, and do a domain modeling exercise to recover what was lost.

Navigation is a really, really complex topic, and it’s going to take us many episodes go deep into it. We will begin our journey by coming up with a precise definition of what “navigation” is, and by exploring a couple simpler forms of navigation.

We just made the Composable Architecture’s concise binding helpers safer, but can we make them even more concise? We’ll start with a suggestion that came from the community and employ even more Swift tricks, like dynamic member lookup, to get things even conciser than vanilla SwiftUI.

Previously we explored how SwiftUI makes building forms a snap, and we contrasted it with the boilerplate introduced by the Composable Architecture. We employed a number of advanced tools to close the gap, but we can do better! We’ll start by using a property wrapper to make things much safer than before.

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.

This week we improve the performance of another part of the Composable Architecture ecosystem: case paths! We will benchmark the reflection mechanism that powers case paths and speed things up with the help of a Swift runtime function.

Did you know the Composable Architecture’s scope operation and ViewStore are performance tools? We’ll explore how to diagnose your app’s performance, how scope can help, and fix a few long-standing performance issues in the library itself.

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 will explore two more domain transformations in the Composable Architecture. One comes with the library: the ability to embed a smaller domain, optionally, in a larger domain. Another we will build from scratch: the ability to embed smaller domains in the cases of an enum!

The Composable Architecture comes with several tools that aid in breaking large domains down into smaller ones, not just pullback and scope. This week we will see how it can take a small domain and embed it many times in a collection domain.

Let’s rebuild last week’s moderately complex SwiftUI app in the Composable Architecture to explore its built-in solution for breaking larger domains down into smaller ones using the scope operator. We’ll then explore a few examples of scope in the wild.

The ability to break down applications into small domains that are understandable in isolation is a universal problem, and yet there is no default story for doing so in SwiftUI. We explore the problem space and a possible solution in vanilla SwiftUI before turning our attention to the Composable Architecture.

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.

Crafting better test dependencies for our code bases come with additional benefits outside of testing. We show how SwiftUI previews can be strengthened from better dependencies, and we show how we employ these techniques in our newly released game, isowords.

A major source of complexity in our applications is asynchrony. It is a side effect that is easy to overlook and can make testing more difficult and less reliable. We will explore the problem and come to a solution using Combine schedulers.

Exhaustively describing dependencies in your tests makes them stronger and easier to understand. We improve the ergonomics of this technique by ditching the fatalError in unimplemented dependencies, using XCTFail, and we open source a library along the way.

We talk about dependencies a lot on Point-Free, but we’ve never done a deep dive on how to tune them for testing. It’s time to do just that, by first showing how a test can exhaustively describe its dependencies, which comes with some incredible benefits.

Animating asynchronous effects with Combine schedulers is not only important for the Composable Architecture. It can be incredibly useful for any SwiftUI application. We will explore this with a fresh SwiftUI project to see what problems they solve and how they can allow us to better embrace SwiftUI’s APIs.

The Composable Architecture mostly “just works” with SwiftUI animations out of the box, except for one key situation: animations driven by asynchronous effects. To fix this we are led to a really surprising transformation of Combine schedulers.

One of the most impressive features of SwiftUI is its animation system. Let’s explore the various flavors of animation, such as implicit versus explicit and synchronous versus asynchronous, to help prepare us for how animation works with the Composable Architecture.

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.

The Composable Architecture makes it easy to layer complexity onto a form, but it just can’t match the brevity of vanilla SwiftUI…or can it!? We will overcome a Swift language limitation using key paths and type erasure to finally say “bye!” to boilerplate.

Building forms in the Composable Architecture seem to have the opposite strengths and weaknesses as vanilla SwiftUI. Simple forms are cumbersome due to boilerplate, but complex forms come naturally thanks to the strong opinion on dependencies and side effects.

For simple forms, vanilla SwiftUI does a really good job: you can quickly build a form with many components in minimal code and boilerplate. But as a form becomes more complex, SwiftUI stops being so helpful. Let’s explore the problems that emerge and how we can work around them.

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.

The performance gains we have made with the parser type have already been super impressive, but we can take things even further. We will explore the performance characteristics of closures using the time profiler and make some changes to how we define parsers to unlock even more speed.

We convert some of our substring parsers to work on lower levels of String abstractions, and unlock huge performance gains. Even better, thanks to our generalized parser we can even piece together multiple parsers that work on different abstraction levels, maximizing performance in the process.

We want to explore the performance of composable parsers, but to do so we must first take a deep dive into the Swift string API. There are multiple abstractions of strings in Swift, each with its own benefits and performance characteristics. We will benchmark them in order to get a scientific basis for comparison, and will describe how to properly write a benchmark.

Generalizing the parser type has allowed us to parse more types of inputs, but that is only scratching the surface. It also unlocks many new things that were previously impossible to see, including the ability to parse a stream of inputs and stream its output, making our parsers much more performant.

Now that we have generalized the parser type it’s time to parse things that aren’t just plain strings. In just a few lines of code the parser type can parse environment variable dictionaries and even become a fully capable URL router.

The parser type we built so far is highly tuned to work on strings, but there are many things out in the world we’d want to parse, not just strings. It’s time to massively generalize parsing so that it can parse any kind of input into any kind of output.

The zip function shows up on many types: from Swift arrays and Combine publishers, to optionals, results, and even parsers! But zip on parsers is a little unlike zip on all of those other types. Let’s explore why and how to fix it.

We finish up our XCTest log parser by parsing out the data associated with a test failure. Once done we will format the results in a pretty way and package everything up in a CLI tool we can run in our own projects.

Now that we’ve refamiliarized ourselves with parsing, let’s parse something even more complex: XCTest logs. We will parse and pretty-print the output from xcodebuild and discover more reusable combinators along the way.

We round out our parsing recap by reintroducing that functional trio of operators: map, zip, and flat-map. We’ll use them to build up some complex parsers and make a few more ergonomic improvements to our library along the way.

It’s time to revisit one of our favorite topics: parsing! We want to discuss lots of new parsing topics, such as generalized parsing, performance, reversible parsing and more, but before all of that we will start with a recap of what we have covered previously, and make a few improvements along the way.

We finish building a rich onboarding experience for our application by selectively enabling and disabling pieces of logic in the app depending on what step of the onboarding process we are on. This is only possible due to the strict “separation of concerns” the Composable Architecture maintains.

Not only can we easily redact the logic from a view using the Composable Architecture, but we can also insert new logic into our views without making any changes to the core logic of the view. To demonstrate this we will build an onboarding flow for a more complex application.

We’ve seen how cool redacted SwiftUI views are, but we’ve also seen some of their pitfalls: while it’s easy to redact UI, it’s not so easy to redact logic, that is unless you’re using the Composable Architecture!

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.

So, what’s the point of forgoing the protocols and designing dependencies with simple data types? It can be summed up in 3 words: testing, testing, testing. We can now easily write tests that exercise every aspect of our application, including its reliance on internet connectivity and location services.

Now that we’ve tackled two dependencies of varying complexity we are ready to handle our most complicated dependency yet: Core Location. We will see what it means to control a dependency that communicates with a delegate and captures a complex state machine with many potential flows.

It’s straightforward to design the dependency for interacting with an API client, but sadly most dependencies we work with are not so simple. So let’s consider a far more complicated dependency. One that is long living, and involves extra types that we can’t even construct ourselves.

Let’s scrap the protocols for designing our dependencies and just use plain data types. Not only will we gain lots of new benefits that were previously impossible with protocols, but we’ll also be able to modularize our application to improve compile times.

Let’s take a moment to properly define what a dependency is and understand why they add so much complexity to our code. We will begin building a moderately complex application with three dependencies, and see how it complicates development, and what we can do about it.

It’s time to ask: “what’s the point?” If composing bindings is so important, then why didn’t Apple give us more tools to do it? To understand this we will explore how Apple handles these kinds of problems in their code samples, and compare it to what we have discovered in previous episodes.

Now that we know that SwiftUI state management seems biased towards structs, let’s fix it. We’ll show how to write custom transformations on bindings so that we can use enums to model our domains precisely without muddying our views, and it turns out that case paths are the perfect tool for this job.

Bindings are one of the core units of SwiftUI data flow and allow disparate parts of an application to communicate with one another, but they are built in such a way that strongly favors structs over enums. We will show that this prevents us from properly modeling our domains and causes unnecessary complexity in the process.

We refactor our application’s code so that we can run it in production with a live dispatch queue for the scheduler, while allowing us to run it in tests with a test scheduler. If we do this naively we will find that generics infect many parts of our code, but luckily we can employ the technique of type erasure to make things much nicer.

The Scheduler protocol of Combine is a powerful abstraction that unifies many ways of executing asynchronous work, and it can even control the flow of time through our code. Unfortunately Combine doesn’t give us this ability out of the box, so let’s build it from scratch.

Combine is a powerful framework and is the de facto way to power SwiftUI applications, but how does one test reactive code? We will build a view model from scratch that involves asynchrony and time-based effects and explore what it takes to exhaustively test its functionality.

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.

We’ve made creating and enhancing reducers more ergonomic, but we still haven’t given much attention to the ergonomics of the view layer of the Composable Architecture. This week we’ll make the Store much nicer to use by taking advantage of a new Swift feature and by enhancing it with a SwiftUI helper.

The Composable Architecture is robust and solves all of the problems we set out to solve (and more), but we haven’t given enough attention to ergonomics. We will enhance one of its core units to be a little friendlier to use and extend, which will bring us one step closing to being ready for production.

We’ve now shown that the Composable Architecture is also quite adaptive, allowing us to transform state and actions into very domain specific situations. Let’s exercise those muscles by creating a macOS app from our iOS app and demonstrating that it’s the perfect tool for creating cross-platform applications.

When we fixed a performance problem in the Composable Architecture it gave us an opportunity to adapt the state of our application to many situations. We’ll take these learnings to see how our application’s actions may adapt as well.

There’s a potential performance problem lurking in the Composable Architecture, and it’s time to finally solve it. But, in doing so, we will stumble upon a wonderful way to make the architecture adaptive to many more situations.

It’s time to put the finishing touches to our architecture so that we can use it in production. This week we begin exploring how to make the Composable Architecture adapt to many use cases, and we will use a potential performance problem as inspiration for this exploration.

It’s time to prove that baking an “environment” of dependencies directly into the Composable Architecture solves three crucial problems that the global environment pattern could not.

Now that we’ve baked the “environment” of dependencies directly into the Composable Architecture, we’re ready to refactor our app’s frameworks and tests to work with them in a modular and more lightweight way.

While we love the “environment” approach to dependency injection, which we introduced many episodes ago, it doesn’t feel quite right in the Composable Architecture and introduces a few problems in how we manage dependencies. Today we’ll make a small tweak to the architecture in order to solve them!

Let’s explore a real world application of “case paths,” which provide key path-like functionality to enum cases. We’ll upgrade our composable architecture to use them and see why they’re a better fit than our existing approach.

Although case paths are powerful and a natural extension of key paths, they are difficult to work with right now. They require either hand-written boilerplate, or code generation. However, there’s another way to generate case paths for free, and it will make them just as ergonomic to use as key paths.

We’ve now seen that it’s possible to define “case paths”: the enum equivalent of key paths. So what are their features? Let’s explore a few properties of key paths to see if there are corresponding concepts on case paths.

You’ve heard of key paths, but…case paths!? Today we introduce the concept of “case paths,” a tool that helps you generically pick apart an enum just like key paths allow you to do for structs. It’s the tool you never knew you needed.

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?

We not only want our architecture to be testable, but we want it to be super easy to write tests, and perhaps even a joy to write tests! Right now there is a bit of ceremony involved in writing tests, so we will show how to hide away those details behind a nice, ergonomic API.

Side effects are by far the hardest thing to test in an application. They speak to the outside world and they tend to be sprinkled around to get the job done. However, we can get broad test coverage of our reducer’s effects with very little work, and it will all be thanks to a simple technique we covered in the past.

It’s time to see how our architecture handles the fifth and final problem we identified as being important to solve when building a moderately complex application: testing! Let’s get our feet wet and write some tests for all of the reducers powering our application.

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.

We’ve got the basic story of side effects in our architecture, but the story is far from over. Turns out that even side effects themselves are composable. Base effect functionality can be extracted and shared, and complex effects can be broken down into simpler pieces.

It’s time to finish our architecture’s story for side effects. We’ve described synchronous effects and unidirectional effects, but we still haven’t captured the complexity of async effects. Let’s fix that with a final, functional refactor.

We’ve modeled side effects in our architecture, but it’s not quite right yet: a reducer can write to the outside world, but it can’t read data back in! This week our architecture’s dedication to unidirectional data flow will lead us there.

Side effects are one of the biggest sources of complexity in any application. It’s time to figure out how to model effects in our architecture. We begin by adding a few new side effects, and then showing how synchronous effects can be handled by altering the signature of our reducers.

We’ve now fully modularized our app by extracting its reducers and views into their own modules. Each screen of our app can be run as a little app on its own so that we can test its functionality, all without needing to know how it’s plugged into the app as a whole. And this is the point of modular state management!

It’s time to fully modularize our app! Our views can still send any app action, so let’s explore transforming stores to focus in on just the local actions a view cares about.

While we’ve seen that each reducer we’ve written is super modular, and we were easily able to extract each one into a separate framework, our views are still far from modular. This week we address this by considering: what does it mean to transform the state a view has access to?

In exploring four forms of composition on reducer functions, we made the claim that it gave us the power to fully isolate app logic, making it simpler and easier to understand. This week we put our money where our mouth is and show just how modular these reducers are!

We will explore a form of reducer composition that will take our applications to the next level. Higher-order reducers will allow us to implement broad, cross-cutting functionality on top of our applications with very little work, and without littering our application code with unnecessary logic. And, we’ll finally answer “what’s the point?!”

Turns out, reducers that work on local actions can be pulled back to work on global actions. However, due to an imbalance in how Swift treats enums versus structs it takes a little work to implement. But never fear, a little help from our old friends “enum properties” will carry us a long way.

So far we have pulled a lot of our application’s logic into a reducer, but that reducer is starting to get big. Turns out that reducers emit many types of powerful compositions, and this week we explore two of them: combines and pullbacks.

Now that we understand some of the fundamental problems that we will encounter when building a complex application, let’s start solving some of them! We will begin by demonstrating a technique for describing the state and actions in your application, as well as a consistent way to apply mutations to your application’s state.

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.

Now that we’ve looked at how to parse multiple values given a single parser, let’s try to parse a single value using multiple parsers! And after defining a bunch of these parser combinators we’ll finally be able to ask: “what’s the point!?”

Let’s solve another common parsing problem using parser combinators! It’s common to want to parse multiple values off a string, and while zip gets us part of the way there, it doesn’t let us parse any number of values! Luckily there’s a parser combinator that can help, and it really packs a punch.

Even though map, flatMap and zip pack a punch, there are still many parsing operations that can’t be done using them alone. This is where “parser combinators” come into play. Let’s look at a few common parsing problems and solve them using parser combinators!

While flatMap allowed us to take our parser type to the next level, it introduced a nesting problem. Isn’t flatMap all about solving nesting problems!? Well, we have one more operation at our disposal: zip! Let’s define zip on the parser type, see what it brings to the table, and finally ask, “what’s the point?”

The map function on parsers is powerful, but there are still a lot of things it cannot do. We will see that in trying to solve some of its limitations we are naturally led to our old friend the flatMap function.

We now have a precise, efficient definition for parsing, but we haven’t even scratched the surface of its relation to functional programming. In this episode we begin to show how all of the functional operators we know and love come into play, starting with map.

It’s time to ask the all important question: what’s the point? We now have a properly defined parser type, one that can parse efficiently and incrementally, but does it give us anything new over existing tools?

Now that we’ve looked at a bunch of parsers that are at our disposal, let’s ask ourselves what a parser really is from the perspective of functional programming and functions. We’ll take a multi-step journey and optimize using Swift language features.

Parsing is a difficult, but surprisingly ubiquitous programming problem, and functional programming has a lot to say about it. Let’s take a moment to understand the problem space of parsing, and see what tools Swift and Apple gives us to parse complex text formats.

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.

This week we’ll put the finishing touches on our enum property code generation tool. We’ll add support for enum cases with multiple associated values and enum cases with no associated values, and we’ll add a feature that will make enums even more ergonomic to work with!

We’ve seen how “enum properties” help close the gap between the ergonomics of accessing data on structs and enums, but defining them by hand requires a lot of boilerplate. This week we join forces with Apple’s Swift Syntax library to generate this boilerplate automatically!

Swift makes it easy for us to access the data inside a struct via dot-syntax and key-paths, but enums are provided no such affordances. This week we correct that deficiency by defining the concept of “enum properties”, which will give us an expressive way to dive deep into the data inside our enums.

Name a more iconic duo… We’ll wait. Structs and enums go together like peanut butter and jelly, or multiplication and addition. One’s no more important than the other: they’re completely complementary. This week we’ll explore how features on one may surprisingly manifest themselves on the other.

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.

This week we finally make our untestable Gen type testable. We’ll compare several different ways of controlling Gen, consider how they affect Gen’s API, and find ourselves face-to-face with yet another flatMap.

Let’s set out to make the untestable testable. This week we make composable randomness compatible with Swift’s new APIs and explore various ways of controlling those APIs, both locally and globally.

Finishing our 3-part answer to the all-important question “what’s the point?”, we finally show that standing on the foundation of our understanding of map, zip and flatMap we can now ask and concisely answer very complex questions about the nature of these operations.

Continuing our 3-part answer to the all-important question “what’s the point?”, we show that the definitions of map, zip and flatMap are precise and concisely describe their purpose. Knowing this we can strengthen our APIs by not smudging their definitions when convenient.

We are now ready to answer the all-important question: what’s the point? We will describe 3 important ideas that are now more accessible due to our deep study of map, zip and flatMap. We will start by showing that this trio of operations forms a kind of functional, domain-specific language for data transformations.

Now that we know that flatMap is important for flattening nested arrays and optionals, we should feel empowered to define it on our own types. This leads us to understanding its structure more in depth and how it’s different from map and zip.

Previously we’ve discussed the map and zip operations in detail, and today we start completing the trilogy by exploring flatMap. This operation is precisely the tool needed to solve a nesting problem that map and zip alone cannot.

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.

The snapshot testing library we have been designing over the past few weeks has a serious problem: it can’t snapshot asynchronous values, like web views and anything that uses delegates or callbacks. Today we embark on a no-regret refactor to fix this problem with the help of a well-studied and well-understood functional type that we have discussed numerous times before.

We previously refactored a library using protocols to make it more flexible and extensible but found that it wasn’t quite as flexible or extensible as we wanted it to be. This week we re-refactor our protocols away to concrete datatypes using our learnings from earlier in the series.

With our library fully generalized using protocols, we show off the flexibility of our abstraction by adding new conformances and functionality. In fleshing out our library we find out why protocols may not be the right tool for the job.

Perhaps the most popular approach to code reuse and extensibility in Swift is to liberally adopt protocol-oriented programming, and many Swift libraries are designed with protocol-heavy APIs. In today’s episode we refactor a sample library to use protocols and examine the pros and cons of this approach.

We complete our dictionary for translating Swift protocol concepts into concrete datatypes and functions. This includes protocol inheritance, protocol extensions, default implementations and protocols with associated types. Along the way we will also show how concrete types can express things that are currently impossible with Swift protocols.

Now that we know it’s possible to replace protocols with concrete datatypes, and now that we’ve seen how that opens up new ways to compose things that were previously hidden from us, let’s go a little deeper. We will show how to improve the ergonomics of writing Swift in this way, and show what Swift’s powerful conditional conformance feature is represented by just plain functions.

Last time we covered some basics with protocols, and demonstrated one of their biggest pitfalls: types can only conform to a protocol a single time. Sometimes it’s valid and correct for a type to conform to a protocol in many ways. We show how to remedy this by demonstrating that one can scrap any protocol in favor of a simple datatype, and in doing so opens up a whole world of composability.

Protocols are a great tool for abstraction, but aren’t the only one. This week we begin to explore the tradeoffs of using protocols by highlighting a few areas in which they fall short in order to demonstrate how we can recover from these problems using a different tool and different tradeoffs.

This week we compare our Decodable solution to building random structures with a composable solution involving the Gen type, exploring the differences and trade-offs of each approach. Along the way we’ll rediscover a familiar old friend with a brand new application.

This week we dive deeper into randomness and composition by looking to a seemingly random place: the Decodable protocol. While we’re used to using the Codable set of protocols when working with JSON serialization and deserialization, it opens the opportunity for so much more.

Randomness is a topic that may not seem so functional, but it gives us a wonderful opportunity to explore composition. After a survey of what randomness looks like in Swift today, we’ll build a complex set of random APIs from just a single unit.

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.

This week we apply domain-specific languages to a very real-world problem: representing and rendering HTML. We code up a simple but powerful solution that forms the foundation of what we use to build the Point-Free website.

We finish our introduction to DSLs by adding two new features to our toy example: support for multiple variables and support for let-bindings so that we can share subexpressions within a larger expression. With these fundamentals out of the way, we will be ready to tackle a real-world DSL soon!

We interact with domain-specific languages on a daily basis, but what does it take to build your own? After introducing the topic, we will begin building a toy example directly in Swift, which will set the foundation for a future DSL with far-reaching applications.

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

In part two of our series on zip we will show that many types support a zip-like operation, and some even support multiple distinct implementations. However, not all zips are created equal, and understanding this can lead to some illuminating properties of our types.

The zip function comes with the Swift standard library, but its utility goes far beyond what we can see there. Turns out, zip generalizes a function that we are all familiar with, and it can unify many seemingly disparate concepts. Today we begin a multipart journey into exploring the power behind zip.

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.

We use Swift playgrounds on this series as a tool to dive deep into functional programming concepts, but they can be so much more. Today we demonstrate a few tricks to allow you to use playgrounds for everyday development, allowing for a faster iteration cycle.

We often deal with collections that we know can never be empty, yet we use arrays to model them. Using the ideas from our last episode on algebraic data types, we develop a NonEmpty type that can be used to transform any collection into a non-empty version of itself.

Our third installment of algebraic data types explores how generics and recursive data types manifest themselves in algebra. This exploration allows us to construct a useful, precise type that can be useful in everyday programming.

Let’s have some fun with the “environment” form of dependency injection we previously explored. We’re going to extract out a few more dependencies, strengthen our mocks, and use our Overture library to make manipulating the environment friendlier.

We revisit an old topic: styling UIKit components. Using some of the machinery we have built from previous episodes, in particular setters and function composition, we refactor a screen’s styles to be more modular and composable.

Today we’re going to control the world! Well, dependencies to the outside world, at least. We’ll define the “dependency injection” problem and show a lightweight solution that can be implemented in your code base with little work and no third party library.

Functional setters can be very powerful, but the way we have defined them so far is not super ergonomic or performant. We will provide a friendlier API to use setters and take advantage of Swift’s value mutation semantics to make setters a viable tool to bring into your code base today.

Let’s explore a type of composition that defies our intuitions. It appears to go in the opposite direction than we are used to. We’ll show that this composition is completely natural, hiding right in plain sight, and in fact related to the Liskov Substitution Principle.

Why does the map function appear in every programming language supporting “functional” concepts? And why does Swift have two map functions? We will answer these questions and show that map has many universal properties, and is in some sense unique.

We typically model our data with very general types, like strings and ints, but the values themselves are often far more specific, like emails and ids. We’ll explore how this can lead to subtle runtime bugs and how we can strengthen these types in an ergonomic way using several features new to Swift 4.1.

While we unabashedly promote custom operators in this series, we understand that not every codebase can adopt them. Composition is too important to miss out on due to operators, so we want to explore some alternatives to unlock these benefits.

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!

We continue our explorations into algebra and the Swift type system. We show that exponents correspond to functions in Swift, and that by using the properties of exponents we can better understand what makes some functions more complex than others.

Key paths aren’t just for setting. They also assist in getting values inside nested structures in a composable way. This can be powerful, allowing us to make the Swift standard library more expressive with no boilerplate.

This week we explore how functional setters can be used with the types we build and use everyday. It turns out that Swift generates a whole set of functional setters for you to use, but it can be hard to see just how powerful they are without a little help.

The programs we write can be reduced to transforming data from one form into another. We’re used to transforming this data imperatively, with setters. There’s a strange world of composition hiding here in plain sight, and it has a surprising link to a familiar functional friend.

Most of the time we interact with code we did not write, and it doesn’t always play nicely with the types of compositions we have developed in previous episodes. We explore how higher-order functions can help unlock even more composability in our everyday 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.